Sorry, i have the same behavior when i have the data directory but it starts well because the cache is already done.
In fact the start method is called of featureServiceImpl is called directly by the blueprint extender and i have seen that the method will also be called by the configuration service. 2011/3/25 Hervé BARRAULT <[email protected]> > Hi, > By doing some other tests, i have found one interesting thing. > > The parallelism can only be seen when data folder is not created (first > deployment) > because the block which reads the feature is not always used : > FeaturesServiceImpl : > if (boot != null && !bootFeaturesInstalled) { > new Thread() { > public void run() { > String[] list = boot.split(","); > Set<Feature> features = new LinkedHashSet<Feature>(); > > .... > } > > Ans it is in this new thread that i have my exceptions. > > If i use a well written settings.xml in the right folder there is no more > problems as documented in constructor of MavenSettingsImpl : > /** > * Creates new settings with the following resolution:<br/> > * 1. looks for the specified url > * 2. if not found looks for ${user.home}/.m2/settings.xml > * 3. if not found looks for ${maven.home}/conf/settings.xml > * 4. if not found looks for ${M2_HOME}/conf/settings.xml > * > * @param settingsURL prefered settings.xml file > * @param useFallbackRepositories if fallback repositories should be > used instead of default repositories > */ > > > Thanks for help. > > > > > > 2011/3/25 Hervé BARRAULT <[email protected]> > >> Hi i have noticed in my case that mvn doesn't use the configuration >> written in etc/org.ops4j.pax.url.mvn.cfg but the default configuration in >> code as defined in org.ops4j.pax.url.maven.commons.MavenSettingsImpl >> >> private static final String DEFAULT_REPOSITORIES = >> "http://osgi.sonatype.org/content/groups/pax-runner";; >> >> >> >> >> 2011/3/25 <[email protected]> >> >> Hi Herve, >>> >>> I'm gonna make some tests cause I don't understand your issue. >>> PAX URL is managed by etc/org.ops4j.pax.url.mvn.cfg file. >>> It's where especially you can define the mvn repo to use. >>> First Karaf looks into system repo and go the mvn repo after. >>> >>> I will keep you posted if I can reproduce your issue. >>> >>> Regards >>> JB >>> -----Original Message----- >>> From: Hervé BARRAULT <[email protected]> >>> Date: Fri, 25 Mar 2011 10:48:15 >>> To: <[email protected]> >>> Reply-To: [email protected] >>> Subject: Karaf startup and configuration mechanism >>> >>> Hi, >>> I'm using Karaf 2.0.0 and at the startup (in particular conditions), >>> karaf >>> doesn't start correctly due to maven resolution failure. >>> >>> I hope having understand the startup : >>> >>> The Bundle OPS4J Pax Url - mvn: (start level 5) starts and allows >>> resolution >>> of mvn protocol (but it is not configured with the dedicated properties >>> file >>> :org.ops4j.pax.url.mvn.cfg). >>> >>> The Bundle Apache Felix Configuration Admin Service (start level 10) : >>> offers a service to do the configuration of managed services (the >>> configuration process of mvn will be done here). >>> >>> The Bundle Apache Karaf :: Features Core : (start level 30) reads >>> org.apache.karaf.features.cfg for features (using a blueprint >>> property-placeholder) >>> >>> But with the configuration in Admin Service is a new Thread so, in some >>> cases the startup of Features Core is done before the Configuration Admin >>> Service has started its job to configure the maven url handler. >>> >>> The result is like this : >>> java.io.IOException: URL >>> >>> [mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.3.0-fuse-00-00/xml/features] >>> >>> could not be resolved. : >>> >>> mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.3.0-fuse-00-00/xml/features >>> >>> at >>> >>> org.apache.karaf.features.internal.RepositoryImpl.load(RepositoryImpl.java:191) >>> >>> at >>> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.internalAddRepository(FeaturesServiceImpl.java:168) >>> >>> at >>> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.getFeatures(FeaturesServiceImpl.java:704) >>> >>> at >>> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.getFeature(FeaturesServiceImpl.java:674) >>> >>> at >>> >>> org.apache.karaf.features.internal.FeaturesServiceImpl$1.run(FeaturesServiceImpl.java:751) >>> >>> Caused by: java.lang.RuntimeException: URL >>> >>> [mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.3.0-fuse-00-00/xml/features] >>> could not be resolved. >>> at >>> >>> org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195) >>> >>> at >>> >>> org.apache.karaf.features.internal.RepositoryImpl.load(RepositoryImpl.java:92) >>> >>> ... 4 more >>> >>> >>> I have also noticed that at this step the service logging is not yet >>> configured (as it is processed by the Configuration Admin Service after >>> the >>> maven resolver) so i must edit java.util.logging.properties to have some >>> logs. >>> >>> To reproduce the bug with an IDE is simple : >>> Add a breakpoint in the run method of >>> org.apache.felix.cm.impl.UpdateThread >>> Start KARAF with the KARAF_DEBUG option to be able to attach debugger. >>> Attach quickly (the more difficult step) the debugger to be sure that >>> the thread "Configuration Updater" will be stopped at the beginning. >>> >>> >>> If order of service registered is safe when bundle level is different, is >>> it >>> possible to use the Configuration Admin Service to do the job of feature >>> file loading, so maven, logging service and other configurations are >>> terminated ? >>> >>> Or is there a way to be sure that mvn is correctly started before >>> starting >>> Features Core ? >>> (I don't want to do a bundle which loop on a bundle using mvn protocol to >>> be >>> sure of the configuration). >>> >>> I've seen that there is a known bug which can perhaps be linked to this : >>> KARAF-334 <https://issues.apache.org/jira/browse/KARAF-334> >>> >>> Thanks >>> Hervé >>> >>> >> >
