Hi Gert, afaik we have clone for that. It should clone the current instance.
regards, Achim 2013/10/25 Gert Vanthienen <[email protected]> > L.S., > > > The current implementation of the admin:create command uses copies > from the Karaf assembly of the config.properties and > startup.properties files when creating the instance. > > If you're running a plain Karaf container, that's pretty much OK but > if you have something else built on top of Karaf (e.g. ServiceMix), it > would make a lot more sense to get those properties files out of your > current root instance instead. Unlike the settings files for > features, logging, ..., these files are used to bootstrap the > container, so by the time the child container has started, it's too > late to update them. > > One example: in ServiceMix 5, we are using the startup.properties file > to ensure we have Features OBR support installed and that our Camel > instrumentation hook is being started as soon as possible to ensure > all our routes get instrumented. If you do an admin:create in > ServiceMix 5, you will have to manually go and edit the > startup.properties file before starting the child container to get the > same behavior. > > The same probably goes for the config.properties. If I want to build > a product/project on top of Karaf that uses Equinox instead of Felix > by default, the admin:create command would still create a plain Karaf > container running Felix. > > In my mind, it would make more sense for the admin:create command to > create a child instance with the same bootstrap settings as the root, > so if that's OK for everyone, I'll raise a JIRA and fix this. > > > Regards, > > Gert Vanthienen > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
