Re: [akka-user] reference.conf conflicts in fat jar (I think)

[Zach Cox]

Could reference.conf files be located further down the package dir
structure to avoid conflicts? /akka/actor/reference.conf,
/akka/remote/reference.conf, etc?

We've been using the "deploy fat jars, restart processes" philosophy
with all of our apps for simplicity. It was working well with Akka 1.x
but we're now running into this reference.conf issue with Akka 2.0.

I'll try to convince sbt assembly plugin to generate the single
overall reference.conf file and include it in the fat jar.

Or is it more recommended to use the Microkernel instead of fat jars?

Thanks,
Zach

On Thu, Feb 2, 2012 at 12:50 AM, Patrik Nordwall
<patrik....@gmail.com> wrote:
> You have already found the other thread that is the best way to solve it, if
> fat jar is to be used. The problem is that all reference.conf files are not
> know at akka build time, since additional modules can have their own. So the
> reference.conf files must be merged at application build time. I don't know
> how that works together with that specific plugin. May I ask why you need to
> use fat jar?
>
>
> On Thu, Feb 2, 2012 at 6:37 AM, Zach Cox <zco...@gmail.com> wrote:
>>
>> Hi - I have a very simple app using 2.0-M3 to test out remote actors,
>> using the same .conf settings as the Remoting docs. If I just sbt run the
>> app, or if I use sbt console, then everything works great. But when I sbt
>> assembly up a fat jar and run the app using java -jar, I get exceptions
>> about missing config settings, like this:
>>
>> Exception in thread "main" com.typesafe.config.ConfigException$Missing: No
>> configuration setting found for key 'akka.remote.failure-detector.threshold'
>>
>> If I add akka.remote.failure-detector.threshold into application.conf,
>> then I just get another exception about a different missing setting.
>>
>> I'm guessing that multiple resource.conf files are conflicting in the fat
>> jar, as in this thread:
>>
>>
>> https://groups.google.com/forum/#!searchin/akka-user/conf$20jar/akka-user/P6QkNsYEw5c/7OZuwEsXseIJ
>>
>> I'm not really seeing how to use the solution in that thread with the sbt
>> 0.7 assembly plugin. Is there any standard procedure for creating fat jars
>> with Akka 2.0 to avoid this resource.conf conflict problem?
>>
>> Thanks,
>> Zach
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/akka-user/-/1kNgEk5098EJ.
>> To post to this group, send email to akka...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> akka-user+...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/akka-user?hl=en.
>
>
>
>
> --
>
> Patrik Nordwall
> Typesafe -  The software stack for applications that scale
> Twitter: @patriknw
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to
> akka-user+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/akka-user?hl=en.

[Josh Marcus]

We've also been trying to use the 'fat jars' method for deployment, which is pretty common these days in the scala world.  There are three one jar sbt 0.10+ plugins ( https://github.com/harrah/xsbt/wiki/sbt-0.10-plugins-list ) that I've tried w/ akka -- proguard, onejar, and assembly -- which have all had their own issues with akka.  I generated my own reference.conf as per the previous thread, but for some reason the jar generated by assembly wasn't picking it up.

In any case, this is a standard process that anyone wanting to deploy a production app will have to go through in one way or another, so it would be great if we could eliminate these issues or document best practices.

--j

--
Josh Marcus
Senior GIS Software Architect

Azavea |  T: 215.701.7505
www.azavea.com

[Patrik Nordwall]

2 feb 2012 kl. 16:21 skrev Zach Cox <zco...@gmail.com>:

> Could reference.conf files be located further down the package dir
> structure to avoid conflicts? /akka/actor/reference.conf,
> /akka/remote/reference.conf, etc?

Those locations are not known. The design reason for having a predefined location is to be able to support modules which add their own config, with default values (reference.conf).

>
> We've been using the "deploy fat jars, restart processes" philosophy
> with all of our apps for simplicity. It was working well with Akka 1.x
> but we're now running into this reference.conf issue with Akka 2.0.
>
> I'll try to convince sbt assembly plugin to generate the single
> overall reference.conf file and include it in the fat jar.

It is possible to load them and write the merged to a new file.

>
> Or is it more recommended to use the Microkernel instead of fat jars?

Personally I prefer explicit jar files with version numbers so I know exactly what is running.

[Zach Cox]

Our app is a simple HTTP web service built on Unfiltered+Jetty, we
were deploying great as a fat jar until upgrading Akka to 2.0-M3. I
have things working now using the Akka Microkernel via the
akka-sbt-plugin, but that required completely changing the build
process, deployable artifact, and upstart script on production. And
now it feels a bit messy to have the actor framework starting up our
web service.

To Josh's points, it would be awesome to just make this a non-issue
somehow. But at the least, maybe there should be a section in
http://akka.io/docs/akka/2.0-M3/intro/deployment-scenarios.html that
describes this fat jar issue as well as configuration for the various
sbt (and maven?) fat jar plugins to generate the one big
reference.conf and get it included in the fat jar.

Thanks,
Zach

On Thu, Feb 2, 2012 at 10:16 AM, Patrik Nordwall

[√iktor Ҡlang]

I'm open to solutions.
V

[Zach Cox]

Hi Josh - is there any chance you could post to this list the relevant
parts of your sbt build in which you got the overall reference.conf to
work with the proguard plugin? Or maybe what you tried with the
assembly plugin that didn't quite work?

Thanks,
Zach

[Zach Cox]

Here's an interesting data point:

In some dir /path/to/your/conf put these files:
- application.conf that has whatever custom conf your app needs
- reference.conf that contains all the individual reference.conf your app needs

First line of application.conf:
include "reference"

$ java -Dconfig.file=/path/to/your/conf/application.conf -jar
/path/to/your/fat.jar

That seems to load both the .conf files in /path/to/your/conf, so you
get all the defaults from reference.conf as well as your custom
application.conf.

So this seems to allow both a single fat jar as well as external akka
.conf files. Again, this is with 2.0-M3.

[√iktor Ҡlang]

Sounds pretty badass to me.

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Zach Cox]

Here's another question: if the Microkernel includes all akka jars,
isn't any app deployed in Microkernel loading up every possible
reference.conf file? If so, then why not just have akka-actor.jar have
one single reference.conf with all of those default config settings
already in it?

[Patrik Nordwall]

That works until the any default value (reference.conf) is changed as you have assembled the merged fat reference.conf manually. It should be done automatically at build time of your application to be a real sustainable solution.

[Patrik Nordwall]

On Thu, Feb 2, 2012 at 11:32 PM, Zach Cox <zco...@gmail.com> wrote:

Here's another question: if the Microkernel includes all akka jars,
isn't any app deployed in Microkernel loading up every possible
reference.conf file? If so, then why not just have akka-actor.jar have
one single reference.conf with all of those default config settings
already in it?

It's simply a dependency issue. akka-actor doesn't know about the whole world, it doesn't even know of other akka modules built on top of akka-actor, such as akka-remote.

You can also add third party extensions that contain their reference.conf, for example play2 framework is using the same config library.

[Jonas Bonér]

Badass it is...

--
Jonas Bonér
CTO

Typesafe - The software stack for applications that scale

Phone: +46 733 777 123
Twitter: @jboner
Blog: letitcrash.com

[Zach Cox]

I agree it is brittle to build that fat reference.conf by hand. I'll have to rebuild it whenever 1) we add/remove akka dependencies, or 2) we upgrade to a newer akka version.

However, so far I have not been able to convince the sbt assembly plugin, either in sbt 0.7 or 0.11.2, to merge all of the reference.conf files from my project's dependencies and use that in the fat jar.

[Zach Cox]

After sinking 2 days into this, I have reached the conclusion that 1)
the sbt assembly plugin, in its current state, is incapable of
including a generated fat reference.conf file in the fat jar, and 2)
sbt may not even be capable of generating that fat reference.conf
using the jars in the project's dependencies.

I would love more than anything for someone to prove me wrong by
posting code samples to the mailing list. :) #hinthint

At this point we have to move forward with using a manually-generated
fat reference.conf file. Got these deadlines.

This would not be an issue if every module used a unique name for its
default config file, like reference-{module}.conf. Why again is this
not possible?

Thanks,
Zach

[Patrik Nordwall]

4 feb 2012 kl. 06:52 skrev Zach Cox <zco...@gmail.com>:

> After sinking 2 days into this, I have reached the conclusion that 1)
> the sbt assembly plugin, in its current state, is incapable of
> including a generated fat reference.conf file in the fat jar, and 2)
> sbt may not even be capable of generating that fat reference.conf
> using the jars in the project's dependencies.
>
> I would love more than anything for someone to prove me wrong by
> posting code samples to the mailing list. :) #hinthint
>
> At this point we have to move forward with using a manually-generated
> fat reference.conf file. Got these deadlines.
>
> This would not be an issue if every module used a unique name for its
> default config file, like reference-{module}.conf. Why again is this
> not possible?

If the locations are not known the config library doesn't know from where to load them. Now it loads all /reference.conf from all jars/directories/whatever in classpath and merges them in run/parse time.

[Zach Cox]

>> This would not be an issue if every module used a unique name for its
>> default config file, like reference-{module}.conf. Why again is this
>> not possible?
>
> If the locations are not known the config library doesn't know from where to load them. Now it loads all
> /reference.conf from all jars/directories/whatever in classpath and merges them in run/parse time.

Could the config library load all /reference-*.conf files?

[√iktor Ҡlang]

On Sat, Feb 4, 2012 at 2:50 PM, Zach Cox <zco...@gmail.com> wrote:

>> This would not be an issue if every module used a unique name for its
>> default config file, like reference-{module}.conf. Why again is this
>> not possible?
>
> If the locations are not known the config library doesn't know from where to load them. Now it loads all
> /reference.conf from all jars/directories/whatever in classpath and merges them in run/parse time.

Could the config library load all /reference-*.conf files?

Show me the code.

--

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Chris Van Vranken]

> After sinking 2 days into this, I have reached the conclusion that 1)
> the sbt assembly plugin, in its current state, is incapable of
> including a generated fat reference.conf file in the fat jar, and 2)
> sbt may not even be capable of generating that fat reference.conf
> using the jars in the project's dependencies.
>
> I would love more than anything for someone to prove me wrong by
> posting code samples to the mailing list. :) #hinthint

Here to prove you wrong. (At least on point #2)

I am not familiar with the assembly plugin, but I have this working using a modified version of the proguard plugin.  https://github.com/cessationoftime/xsbt-proguard-plugin 

I want to do a little more work on it before I do a pull request to siasia/xsbt-proguard-plugin. The config isn't as pretty as it could be, I want to split up my Tuple Injar\Outjar filter setting.  But it works well.

I feel the best solution would ultimately be a fork of the proguard plugin which handles akka config issues.  Or a plugin that simply uses the sbt-proguard-plugin as a dependency and handles akka config issues.

The config works like this:

plugins.sbt: 

list the akka JARs which contain reference.conf files so that they may be merged at compile time

Commands.scala: 

implements finding and merging of the reference.conf files at compile time. Also strips comments from the .conf files.

All reference.conf files merge with myapp.conf and common.conf and become application.conf. But I ONLY merge in the "node" configuration of myapp.conf

Build.scala :  (resourceGenerators in Compile <+= Commands.AkkaConfig.akkaMergedRefConfigKey)

this causes me to generate the merged akka config file when I compile, the file ends up in sbt's managed resource folder, which is merged into the final jar.

proguardCfg.sbt:

in this file I have the standard proguard config for xsbt-proguard-plugin and InJar\OutJar filters. The config for this is a little ugly, I have a single Tuple setting for the Injar\Outjar filter. The normal siasia/xsbt-proguard-plugin is currently missing an outJar filter. Injar filter removes the reference.conf files from the akka Jars prior to proguard. Outjar filter removes common.conf and myapp.conf from my build since they are also now part of the merged config.

I also included a command which takes the output of proguard and copies\renames it to signed-min.jar.  In the next step I would then sign the proguarded jar (signed-min.jar) with the xsbt-webstart plugin.

and the configuration looks (approximately) like this:

proguardCfg.sbt

---------------------------------------

//filter resource files from JARs

makeJarFilter <<= (makeJarFilter) {

  (makeFilter) => 

  val (makeInJarFilter,makeOutJarFilter) = makeFilter; 

  val InFilter =

  (file:String) => file match {

      case "akka-remote-2.0-M3.jar" => makeInJarFilter(file) + ",!reference.conf"

      case "akka-actor-2.0-M3.jar" => makeInJarFilter(file) + ",!reference.conf"

      case "akka-agent-2.0-M3.jar" => makeInJarFilter(file) + ",!reference.conf"

      case "application.conf" => makeInJarFilter(file)

      case _ => makeInJarFilter(file)

    };

     val OutFilter =

  (file:String) => file match {

      case "myjar_2.9.1-0.0.1-SNAPSHOT.min.jar" => "!myapp.conf,!common.conf"

      case _ => makeOutJarFilter(file)

    };

  (InFilter,OutFilter)  

}

Commands.proguardOutputRename := "signed-min.jar"

project/plugins.sbt

-----------------------

//akka JARs which will have reference.conf files merged into the proguard output reference.conf file

libraryDependencies ++= Seq(

    "com.typesafe.akka" % "akka-actor" % "2.0-M3",

    "com.typesafe.akka" % "akka-remote" % "2.0-M3",

    "com.typesafe.akka" % "akka-agent" % "2.0-M3",

    "com.typesafe.akka" % "akka-slf4j" % "2.0-M3"    

)

project/Build.scala

-----------------------------------------------------------------------

lazy val aProject: Project = Project("project-name", 

      file("project-name"),

      settings = commonSettings ++ Commands.tasks ++ (libraryDependencies ++=  aProjectDependencies) :+ (resourceGenerators in Compile <+= Commands.AkkaConfig.akkaMergedRefConfigKey),

      dependencies = Seq(dependency1, dependency2))

project/Commands.scala

---------------------------------------------------------------

import sbt._;

import Keys._

import Keys.Classpath

import Keys.TaskStreams

import Project.Initialize

import classpath.ClasspathUtilities

import ProguardPlugin._

import akka.actor.ActorSystem

import scala.collection.immutable.StringLike

import com.typesafe.config.ConfigFactory

import com.typesafe.config.ConfigParseOptions

import com.typesafe.config.ConfigResolveOptions

object Commands extends Build {

  

   object AkkaConfig {

    

    def stripComments(mergedConfigString : StringLike[_]) : String = {

      val Rege = """^\s*#.*""".r

     val nc : Iterator[String]= mergedConfigString.lines;

     val noComments = nc.flatMap (_ match {

        case Rege() => None

        case x => Some(x)

      })

          noComments.mkString("\n") 

    }

    

   /**

     * get the merged version of the default settings (from the reference.conf files in the JARs on the classpath)

     */

   def mergedConfig(configName: String) : String = {

     

     //load application.conf and then use  .withFallback() on the reference.conf object       

     val referenceConfig = ConfigFactory.parseResourcesAnySyntax(getClass,"/reference", ConfigParseOptions.defaults)

     val applicationConfig = ConfigFactory.parseFile(new java.io.File("src/main/resources/myapp.conf"), ConfigParseOptions.defaults).getConfig(configName)

     val mergedConfig = applicationConfig.withFallback(referenceConfig)

     val mergedConfigString :StringLike[_]  = mergedConfig.root.render;

            

     stripComments(mergedConfigString)

    }

  

    lazy val akkaMergedRefConfigKey = TaskKey[Seq[java.io.File]]("merge-akka-refconfig","pulls the reference.conf files from akka jars and merges them into a new reference.conf file for inclusion later in the proguard output")   

    lazy val akkaMergedRefConfigTask = akkaMergedRefConfigKey <<= (resourceManaged) map { (managedResourceDir : File)=>

   val targetFile = managedResourceDir / "application.conf";

      IO write (targetFile, mergedConfig("node"))

   Seq(targetFile.asFile)

    }  

   

  }

import AkkaConfig._

  

  val proguardOutputRename = SettingKey[String]("proguard-output-rename","final name of the proguarded jar")

 val runMinjarKey = TaskKey[Unit]("run-minjar","executes the mainClass of the proguarded .min.jar file");

lazy val renameProguardOutputKey = TaskKey[Unit]("rename-proguard-output","copied the proguarded jar with a new name")

lazy val renameProguardOutputTask = renameProguardOutputKey <<= (proguard,minJarPath,crossTarget,proguardOutputRename) map { (doProguard,minJar:File,crossDir,newName)=>

    List("cp", minJar.toString, crossDir.toString + "/" + newName) ! ; //execute console command to launch jar

 }

 //execute the mainClass of the proguarded Jar (the .min.jar)

 lazy val runMinjarTask = runMinjarKey <<= (minJarPath,proguard) map { (minJar:File,p)=>

    List("java", "-jar", minJar.toString) ! ; //execute console command to launch jar

  }

val tasks = Seq(runMinjarTask,renameProguardOutputTask, akkaMergedRefConfigTask)

-Chris

[Zach Cox]

Chris - thanks for describing your solution & posting code! Is
plugins.sbt the only place you declare those Akka dependencies? Or are
they duplicated in another build.sbt or Build.scala file?

[cessationoftime]

They are declared in my Build.scala as dependencies too. And
mentioned in proguardCfg.sbt so it knows what to remove reference.conf
files from.

I mention the version number of akka in so many config files with this
setup that I put a list of locations that need to be changed in my
Build.scala. So if anyone has a good idea where one should declare
the akka version in an easy-to-update location where both Build.scala
and plugins.sbt, and proguardCfg.sbt can get at it, I'd love to hear
about it. Though thinking about it now it would probably be optimal
to read it out of my akka .conf files since it is there too. Then I
could update the version in common.conf and not need to update
Build.scala, plugins.sbt and proguardCfg.sbt too.

[Zach Cox]

I think the most sustainable solution would be to only declare Akka
dependencies in one place as usual (build.sbt or Build.scala) and then
anything that generates a fat reference.conf just uses those project
dependency jars. DRY and such.

[cessationoftime]

"The project directory is another project inside your project which
knows how to build your project."  -- SBT wiki

when I initially set this up I found that these two projects, my sbt
Build (plugins.sbt) and my project itself (Build.scala) had 2
different sets of dependencies which are not shared.  So I had to
declare my dependencies in both places. I didn't find a way to make
those two projects share dependencies, but I also did not try very
hard.

Chris

> >> > For more...
>
> read more »

[Josh Marcus]

Hey folks,

Thanks for sharing your approach -- hopefully we can collectively figure out a way to solve this problem cleanly, moving forward.

I opted for the maximally simple solution, for now.  I renamed the reference.conf files from akka-actor and akka-remote (the two I needed), copied them into my local project resources directory, and then included them directly in my own reference.conf. 

--j

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--

[Havoc Pennington]

Hi,

On Sat, Feb 4, 2012 at 8:50 AM, Zach Cox <zco...@gmail.com> wrote:
>>> This would not be an issue if every module used a unique name for its
>>> default config file, like reference-{module}.conf. Why again is this
>>> not possible?
>>
>> If the locations are not known the config library doesn't know from where to load them. Now it loads all
>> /reference.conf from all jars/directories/whatever in classpath and merges them in run/parse time.
>
> Could the config library load all /reference-*.conf files?
>

(belatedly reading this thread)

The reason it can't load /reference-*.conf is that the Java
ClassLoader class doesn't have a "list directory" feature. You can
only load things by name, not enumerate which things exist.

However, it does have a way to load all things with the name
/reference.conf, if there are multiple. So that's what the config
library does.

There are hacks out there to "list directory" on the classpath but
they are really ugly stuff (ugly like: locate the jar files and unpack
them manually, puke entirely on custom classloaders).

Another thought, maybe more related to the older thread: there is no
need to use the config library to merge multiple reference.conf. A
simple textual concatenation should work fine, I think. The only trick
is that in theory, the order could matter (you might want each
dependency's reference.conf to appear before the reference.conf of the
jar depending on the dependency, in case one overrides the other). In
practice I bet the order doesn't matter for any of the actual
reference.conf out there, since having your reference.conf redefine
stuff from another one is sort of kooky.

So, the plugins that build fat jars could do something very simple I
think: concat all the reference.conf, in dependency order for bonus
points, and put the result in the fat jar. Or more generally, for any
*.conf, if they have the same name, concat them.

This also eliminates the issues with having system props in the merged
config and so on.

Hmm: well, I thought of one exception. If the .conf file has root
braces {} (begins and ends with { and }), then concat would not work.
However, you could just send pull requests to anyone who pointlessly
specifies root braces, since they are completely optional clutter in
the .conf format. The assembly plugins could maybe pretty easily check
for a brace as first thing in the file, the only trick is to skip both
"#" and "//" comments, and all whitespace, that may appear before the
opening brace. If there's no opening brace then there can't be a close
brace, so it's only necessary to check for an initial brace. If root
braces are found it could either be an error or they can just be
stripped off.

Havoc

[Josh Marcus]

Havoc,

On Tue, Feb 7, 2012 at 6:25 PM, Havoc Pennington <h...@pobox.com> wrote:

Another thought, maybe more related to the older thread: there is no
need to use the config library to merge multiple reference.conf. A
simple textual concatenation should work fine, I think. The only trick
is that in theory, the order could matter (you might want each
dependency's reference.conf to appear before the reference.conf of the
jar depending on the dependency, in case one overrides the other). In
practice I bet the order doesn't matter for any of the actual
reference.conf out there, since having your reference.conf redefine
stuff from another one is sort of kooky.

It's actually the case that my library *does* currently redefine configuration parameters.  I'm using your config file library, and users of my library can override parameters using their own application.conf.  But I have akka configuration parameters that I need to set for all users, so I override akka configuration in my library's reference.conf.  Do you have an alternate suggestion?

--j

[Havoc Pennington]

Hi,

On Tue, Feb 7, 2012 at 9:44 PM, Josh Marcus <jma...@azavea.com> wrote:
> It's actually the case that my library *does* currently redefine
> configuration parameters.  I'm using your config file library, and users of
> my library can override parameters using their own application.conf.  But I
> have akka configuration parameters that I need to set for all users, so I
> override akka configuration in my library's reference.conf.  Do you have an
> alternate suggestion?
>

Without knowing the particulars, you may be able to use the "lift a
subtree" approach.

Say your library is "foo", do this:

foo {
akka {
// your akka stuff here, matching akka's normal config file
}
// your other foo-specific settings
whatever = something
bar = baz
}

Now, copying the simple-lib example,
https://github.com/typesafehub/config/blob/master/examples/simple-lib/src/main/scala/simplelib/SimpleLib.scala
you might have a constructor for your library's main object or
whatever that takes a Config. In there you lift up your foo-specific
akka config and then provide it to Akka:

class FooContext(config: Config) {
val system = new ActorSystem("Foo",
config.getConfig("foo").withFallback(config))
}

That is the general idea anyway. So foo.akka.* is now just akka.*, for
purposes of your ActorSystem. But for someone else's actor system, you
won't be messing with akka.*

Also, in application.conf, people can now separately configure akka.*
and foo.akka.* depending on their intent.

One somewhat lame feature of the above is that foo.whatever and
foo.akka were both "lifted out" by getConfig("foo"), so in the final
config, a toplevel "whatever" exists identical to "foo.whatever",
which is namespace pollution. Not the end of the world but could cause
trouble. At the moment you'd have to fix that by hand-building a
Config object containing foo.akka as just akka, and I don't think
there's a very nice API for that in the config lib. It might be nice
to have a Config.filter or other API in the library that would fix
this, in Scala it could be

config.getConfig("foo").filter({ kv => kv._1 == "akka" })

but since it's a Java library I'm not sure. Maybe just a hardcoded
"filterPath(String pathToKeep)" kind of thing, or just methods to add
parent/child nodes.

val akkaOverrides = ConfigFactory.empty().put("akka", getConfig("foo.akka"))

("put" doesn't work since it conflicts with j.u.Map though)

Another thing that could be tricky in the above pattern is that system
properties are in "config" already, so if someone specifies a system
property -Dakka.something, but in the config file there's a
foo.akka.something, the foo.akka.something will always end up
overriding the -Dakka.something for purposes of library foo. Whether
this is a bug or a feature probably varies by context. You could
change the behavior by adding the overrides again on top:

ConfigFactory.defaultOverrides().withFallback(config.getConfig("foo").withFallback(config))

I'm not sure whether to suggest doing that or not, fortunately it
probably doesn't matter that much in practice.

This is a pattern I'm hoping will work well, since we had it in mind
when designing the config lib. But if it doesn't maybe we will need
more ideas...

Havoc

[Havoc Pennington]

Hi,

On Tue, Feb 7, 2012 at 10:37 PM, Havoc Pennington <h...@pobox.com> wrote:
> One somewhat lame feature of the above is that foo.whatever and
> foo.akka were both "lifted out" by getConfig("foo"), so in the final
> config, a toplevel "whatever" exists identical to "foo.whatever",
> which is namespace pollution.

An alternative solution to this is:

foo {
actor-system.akka {

}
}

config.getConfig("foo.actor-system").withFallback(config)

i.e. introduce a superfluous "actor-system" node just so you have a
"clean" node containing the "akka" node.

Havoc

[Havoc Pennington]

Hi,

To address the below issue I got around to adding withOnlyPath,
withoutPath methods to Config, in the master branch:
https://github.com/typesafehub/config

Havoc

[√iktor Ҡlang]

So what do we/I need to do?

Cheers,

√

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Havoc Pennington]

nothing urgent it's just a nice to have API addition related to the earlier thread.

though, there's also a serialization fix on master so it might be good to update Akka's copy. 

[√iktor Ҡlang]

On Tue, Feb 21, 2012 at 12:58 AM, Havoc Pennington <havoc.pe...@gmail.com> wrote:

nothing urgent it's just a nice to have API addition related to the earlier thread.

though, there's also a serialization fix on master so it might be good to update Akka's copy. 

We updated it just prior to RC1 (last tuesday)

[Havoc Pennington]

On Feb 20, 2012, at 7:04 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Tue, Feb 21, 2012 at 12:58 AM, Havoc Pennington <havoc.pe...@gmail.com> wrote:

nothing urgent it's just a nice to have API addition related to the earlier thread.

though, there's also a serialization fix on master so it might be good to update Akka's copy. 

We updated it just prior to RC1 (last tuesday)

 

this is a new fix since then. a couple of serialVersionUID were missing. 

[√iktor Ҡlang]

On Tue, Feb 21, 2012 at 1:57 AM, Havoc Pennington <havoc.pe...@gmail.com> wrote:

On Feb 20, 2012, at 7:04 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Tue, Feb 21, 2012 at 12:58 AM, Havoc Pennington <havoc.pe...@gmail.com> wrote:

nothing urgent it's just a nice to have API addition related to the earlier thread.

though, there's also a serialization fix on master so it might be good to update Akka's copy. 

We updated it just prior to RC1 (last tuesday)

 

this is a new fix since then. a couple of serialVersionUID were missing. 

Awesome, will embed today.

[bryan hunt]

For those who are using Maven as a build tool, a similar problem exists, fortunately it can be circumvented by merging the resource.conf files together.

The Maven shade plugin configuration for doing so is as follows:

           <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>1.5</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>shade</goal>
                        </goals>
                        <configuration>
                            <shadedArtifactAttached>true</shadedArtifactAttached>
                            <shadedClassifierName>allinone</shadedClassifierName>
                            <artifactSet>
                                <includes>
                                    <include>*:*</include>
                                </includes>
                            </artifactSet>
                                <transformers>
                                <transformer
                                        implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                                    <resource>reference.conf</resource>
                                </transformer>
                                <transformer
                                        implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                                    <manifestEntries>
                                        <Main-Class>com.binarytemple.FooMain</Main-Class>
                                    </manifestEntries>
                                </transformer>
                            </transformers>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

[Oleg Zhurakousky]

Bryan

While I understand the general reason why we still have fat jars in this world, it usually points to a problem  (e.g., the target runtime environment is less then adequate to manage the application's classpath amongst other things). If its your own runtime (e.g., standalone akka app) then I would err on the side of creating a small launcher scrip or look at Akka Microkernel. I would also look at the features of build tools you are using (Sbt, Gradle, Maven etc...). Some of them have plugins that would do those things for you. For example; the 'Application' plug-in in Gradle would package all that is required into a zip while also generating startup scripts with classpath etc. I am sure Sbt has something similar. 

Fat jar just sounds kind of patchy and depending on what you are putting in it may also present a legal question that I am sure you don't want to deal with

Oleg

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.

To post to this group, send email to akka...@googlegroups.com.

Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.

[√iktor Ҡlang]

Hi Bryan,

Sounds great, would be fantastic if you'd consider contributing it to our documentation!

http://doc.akka.io/docs/akka/2.2.3/dev/developer-guidelines.html

http://doc.akka.io/docs/akka/2.2.3/dev/documentation.html

--

>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.

To post to this group, send email to akka...@googlegroups.com.

Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.

--

Cheers,

√

———————

Viktor Klang

Chief Architect - Typesafe

Twitter: @viktorklang

[bryan hunt]

It’s just one of those things, operations people love to have a single artefact with command line flag parsing etc. 

java -jar application.jar -c <config> -l <logging> -p <port> -n <name>

When something can be downloaded, and directly executed, it is so nice to work with, no crappy bash scripts to get in the way. 

Compare and contrast with Tomcat and it’s startup scripts, how many hours of my life have been wasted that way, I do not know. 

You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/p6C0Stlgbe0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

[Raymond Guo]

Hi,

could you please tell me how to rename the file in the jars(actor and remote), I found out that I cant do that with my zip sofware, thank you!!

[Konrad Malawski]

Hi all,

I'd highly discourage fiddling with published artifacts (i.e. by unzipping and changing files in there).

You should use a plugin like https://github.com/sbt/sbt-assembl in which you configure all reference.conf files to be concatenated,

then your application.conf simply overwrites any settings you need.

-- 

Cheers,
Konrad `ktoso` Malawski

Akka @ Typesafe

--

>>>>>>>>>> Read the docs: http://akka.io/docs/

>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html

>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.

To post to this group, send email to akka...@googlegroups.com.

Visit this group at http://groups.google.com/group/akka-user.

For more options, visit https://groups.google.com/d/optout.