I could use more details.... and I'm not entirely sure of what karaf does now either, and am thinking mostly about what I'd like it to do soon to solve this kind of problem :-)
On Feb 16, 2011, at 1:05 PM, jamie campbell wrote: > 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. My thinking about assemblies uses the stuff I added in trunk to put stuff in kar files and assemble the server out of kar files. (I don't think this process is complete in relation to how startup.properties might be assembled) Using this approach I'd the versions of the core bundles would be specified in single a kar project pom, and rebuilding that project and the karaf assembly projects would result in a complete set of upgraded servers. How does this relate to what you are doing? > > 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 think you can now specify start level for bundles in a feature. I don't think the feature itself has a start level concept. > > 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 :) I don't think I fully understand what you actually need to do. A couple possibilities I can think of... - have a really easy and completely non-redundant way to assemble a lot of custom karaf assemblies, each of which works for exactly one scenario (I hope the packaging stuff I did in trunk can be polished up to do this) - have a single karaf server that can easily shifted from one purpose to another, perhaps by starting with a command line "profile name" thanks david jencks > > -Jamie
