Get command line arguments when running an Akka Microkernel?

Question

class ServiceKernel extends Bootable {

  val system = ActorSystem("service-kernel")

  def startup = {
    system.actorOf(Props(new Boot(false))) ! Start
  }

  def shutdown = {
    system.shutdown()
  }
}

Because the kernel extends Bootable and not App, how would I access command line arguments used when starting the kernel? For instance if I run the kernel using start namespace.ServiceKernel -d rundevmode or similar. Thanks!

Additional Info

I thought it would be worth adding this information about the start up script in the microkernel. In /bin/start you notice the following:

#!/bin/sh

AKKA_HOME="$(cd "$(cd "$(dirname "$0")"; pwd -P)"/..; pwd)"
AKKA_CLASSPATH="$AKKA_HOME/config:$AKKA_HOME/lib/*"
JAVA_OPTS="-Xms256M -Xmx512M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:ParallelGCThreads=2"

java $JAVA_OPTS -cp "$AKKA_CLASSPATH" -Dakka.home="$AKKA_HOME" akka.kernel.Main "$@"

Although om-nom-nom originally suggested -D options, it looks like it's in use and the main start up parameter is being passed to the akka.kernel.Main class (which in this case would be the ServiceKernel class above).

Actually, if you're using -D options (which stands for *define*) you can just use `System.getProperty("rundevmode")` and check whether property was defined (passed in). — om-nom-nom, Apr 08 '13 at 20:50
hmmm...that might do the trick. do properties require a value passed as well? and does it follow Scala `Option` or simply throw a java `null` if it can't find it? — crockpotveggies, Apr 08 '13 at 21:01

om-nom-nom · Answer 1 · 2013-04-08T21:21:37.427

3

Here is the minimal example:

object Foo extends App {
    val debugModeOn = System.getProperty("debugmode") != null
    val msg = if (debugModeOn) "in debug mode" else "not in debug mode"
    println(msg)
}

» scala Foo -Ddebugmode
in debug mode
» scala Foo            
not in debug mode

You can do extra check to overcome this issue:

» scala Foo -Ddebugmode=false
in debug mode

P.S. you might also want to use Properties helper, that contains bunch of methods like propOrNone, propOrElse, etc

edited Apr 08 '13 at 21:21

answered Apr 08 '13 at 21:14

om-nom-nom

62,329
13
183
228

Ah thanks for the quick answer. Here I was starting to write all this pattern matching. How silly and verbose of me ;) – crockpotveggies Apr 08 '13 at 21:21
You'll notice I just de-accepted this. sadly after further debugging i realized i was being fooled. If you look at the start script in `/bin`: `java $JAVA_OPTS -cp "$AKKA_CLASSPATH" -Dakka.home="$AKKA_HOME" akka.kernel.Main "$@"` meaning that `-D` has already been used :( – crockpotveggies Apr 23 '13 at 20:56
i might have a solution by supplying a custom script during build to accept more parameters. will update this when i know more. – crockpotveggies Apr 23 '13 at 21:10
haven't got something working yet. i'm probably going to fork the microkernel to allow for more `-D` parameters in a similar way it allows for JAVA_OPTS. nearly on a sharable solution. – crockpotveggies Apr 30 '13 at 16:37
Upgraded my SBT to `0.12.3` and looks like my version had a bug. It wasn't setting the main class. Now that I'm able to set my own main class (instead of Akka.main) I might be able to create custom classes representing dev/prod modes (or other params). Will update as it continues. – crockpotveggies May 17 '13 at 17:38

cmbaxter · Answer 2 · 2013-04-24T23:14:43.033

0

It looks like in the sh script that they give you an opportunity to provide JAVA_OPTS, and if not, they give you one that they pre-define. I suppose you could just set JAVA_OPTS in a script that then calls this one, specifying a -D option for your custom args in the JAVA_OPTS. That way you can be sure your custom args get passed in via the -D system property you specify. Hackish but I think it should work. The beauty of -D is that you can supply as many as you want, so the fact that they are already using it for some of their own system properties should not matter.

edited Apr 24 '13 at 23:14

answered Apr 24 '13 at 14:51

cmbaxter

35,283
4
86
95

Tried playing around with this solution, too, but the problem came down to the same issue om-nom-nom encountered with his: the default behavior of the Microkernel is to seek out Java classes using any parameters supplied. Therefore, anything will fail unless the start script is modified. Actively looking for a way to customize it during build without pain. – crockpotveggies Apr 24 '13 at 22:35
2

In looking at the source for the akka.kernal.Main class, I can see the issue now that you are talking about. It treats any arg supplied as a class to boot, meaning if you supplied something like `my.BootClass -d testing` the `-d` and the `testing` would be expected to be FQN of `Bootable` classes and thus instantiated and booted up. Hmmm. Let me think a little more, see if there might be a way around this... – cmbaxter Apr 24 '13 at 23:02
A workaround would be preferrable (though I wonder if achievable). It's really messy when we need to modify the build process. `sbt dist` is just so clean on its own LOL – crockpotveggies Apr 25 '13 at 21:54

Get command line arguments when running an Akka Microkernel?

Additional Info

2 Answers2