Hi Gareth,
my comments in-line:
(1) I see in the documentation that you should be able to do this to do this
in a feature file:
<config name="com.foo.bar-alias">
myProperty = myValue
</config>
where com.foo.bar is a factory pid.
What version of karaf should this be available for? Should this work in
2.2.x (normal pids work - I don't see anything for these factory pids)? I
see something in 2.3.x (I see something in the UI but nothing goes to the
etc directory)...though I haven't got it to work yet (my bundle doesn't see
it). Is there any requirement to have a metatype.xml for this to get it to
work?
Yes <config/> and <configfile/> are both supported in Karaf 2.2.x (we
already use it in Karaf itself, Cellar, etc). However, you should be
able to see the config (using config:list
"(service.pid=com.foo.bar-alias)") but not the config file in etc. To
have a config file in etc, you should use <configfile/> in the feature
(as Cellar does).
(2) Should cellar 2.2.4 work with karaf 2.3.x? I am trying it out as I would
like to play with an OSGi 4.3 environment. Would karaf 3.0.x and cellar
trunk be better? Anyway, here is the exception I get when I try this:
2012-08-31 00:44:04,986 | ERROR | rint Extender: 1 | BlueprintContainerImpl
| container.BlueprintContainerImpl 362 | 9 -
org.apache.aries.blueprint.core - 1.0.0 | Unable to start blueprint
container for bundle org.apache.karaf.cellar.features
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
intialize bean synchronizer
at
org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:710)[9:org.apache.aries.blueprint.core:1.0.0]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:820)[9:org.apache.aries.blueprint.core:1.0.0]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:783)[9:org.apache.aries.blueprint.core:1.0.0]
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[9:org.apache.aries.blueprint.core:1.0.0]
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown
Source)[:1.7.0_05]
at java.util.concurrent.FutureTask.run(Unknown Source)[:1.7.0_05]
.
.
Caused by: java.lang.NullPointerException
at
org.apache.karaf.cellar.features.FeaturesSynchronizer.pull(FeaturesSynchronizer.java:103)[101:org.apache.karaf.cellar.features:2.2.4]
at
org.apache.karaf.cellar.features.FeaturesSynchronizer.init(FeaturesSynchronizer.java:53)[101:org.apache.karaf.cellar.features:2.2.4]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)[:1.7.0_05]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
Source)[:1.7.0_05]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)[:1.7.0_05]
at java.lang.reflect.Method.invoke(Unknown Source)[:1.7.0_05]
I tested Cellar with Karaf 3.0.0 and I know we have an issue with that
(I created a Jira and gonna fix that).
To be honest, I didn't yet tested Cellar 2.2.4 (or 2.2.5-SNAPSHOT) with
Karaf 2.3.0-SNAPSHOT. I will do that and fix for Cellar 2.2.5 if required.
(3) It appears that features install bundles in the following way:
install bundle
start bundle
install bundle
start bundle
.
.
Any reason why you don't do this?:
install bundle
install bundle
install bundle
.
.
start bundle
start bundle
start bundle
The advantage of doing it this way is that you can be sure all optional
dependencies/fragments are resolved before starting any bundle (thus you
don't have to worry about ordering the bundles). I have a patch...and I will
open a JIRA unless someone thinks this is foolish. This solves for me
problems with getting fragments resolved (which are started after their
bundle hosts)
I gonna check that, it's "weird" as we already use fragment in features
without problem.
(4) Another idea for a feature for the feature file:
Currently you can do this:
<configfile
finalname="/etc/jetty.xml">mvn:org.apache.karaf/apache-karaf/2.2.5/xml/jettyconfig</configfile>
It would be nice if you could also lay down a tar to a directory as well (I
have a whole host of config files to lay down):
<tarfile
directory="/etc/myconfigfolder">mvn:com.mycompany/myproject/1.0.0/tar.gz/myconfig</configfile>
Is this a reasonable idea?
Why not, even if it should be the responsability of a provisioning
layer, like Kalumet for instance.
Kalumet is able to manage config files (for instance) coming from any
kind of VFS (http:tar, zip, bzip2, cifs, etc).
Regards
JB
thanks in advance,
Gareth
--
View this message in context:
http://karaf.922171.n3.nabble.com/More-Questions-Mostly-On-Features-tp4025892.html
Sent from the Karaf - User mailing list archive at Nabble.com.
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
