On 11-02-16 02:20 PM, David Jencks wrote:
Do you need this in ability for different flavors in one karaf instance or
would you be just as happy to assemble separate karaf instances for each
purpose?
thanks
david jencks
Right now the approach is separate assemblage, which has been fine, I'm
just getting discontent with the large amounts of replication. When
core startup bundles change because I've upgraded something, it would be
good to change just the core file rather than having to redo all core
changes for every purpose.
I've also considered that maybe Karaf doesn't do that because maybe one
is supposed to take some other approach. I briefly thought maybe
something using features:install would do it, but then noticed the
features stuff doesn't seem to have a run level concept. The only place
I've seen the run levels so far is the startup.properties.
I was peeking through the source code and thought I found the solution
in a comment at org/apache/karaf/main/Main:545-551.. I thought I read
that in config.properties I could specify multiple files (space
separated) for the config.properties karaf.auto.start , but got array
index out of bounds type exceptions when I tried to do so. Another read
of the comment implied maybe it's actually talking about the bundles IN
the auto.start specified file rather than the specifier line itself. If
my interpretation had been correct, it would have been a fully
acceptable solution, allowing modularity without requiring new syntax in
the property files themselves.
On that note, I realize now that the possible approach in my original
post is kind of silly if karaf is using standard java property files,
because I think they have to adhere to the format enumerated in
http://download.oracle.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.Reader%29
, which has no compositional support of the type I was mentioning.
Still, despite the erroneous nature of the "possible solution" I
mentioned, my original need remains :)
-Jamie
