You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by David Jencks <da...@yahoo.com> on 2011/10/10 19:32:57 UTC

Re: [jira] [Commented] (KARAF-910) Race between FeatureService and ConfigAdmin for resolving mvn: URLs?

I think this problem is causing the difficulties I'm having with the mvn url handler.  AFAICT  the mvn url handler is using aether and downloading old snapshots of jars I have more recent versions of locally, and are blocked from downloading in my local nexus instance.  I presume once the config deployer gets going and installs the mvn url handler config these problems would stop.

Could you describe how you are thinking of solving this problem?

thanks
david jencks

On Oct 5, 2011, at 12:27 AM, Jean-Baptiste Onofré (Commented) (JIRA) wrote:

> 
>    [ https://issues.apache.org/jira/browse/KARAF-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120731#comment-13120731 ] 
> 
> Jean-Baptiste Onofré commented on KARAF-910:
> --------------------------------------------
> 
> Chris, is your feature part of org.apache.karaf.features.cfg file, in the bootFeatures ?
> 
> As the fix will certainly include some refactoring, I prefer to postpone to at least 2.2.5.
> 
>> Race between FeatureService and ConfigAdmin for resolving mvn: URLs?
>> --------------------------------------------------------------------
>> 
>>                Key: KARAF-910
>>                URL: https://issues.apache.org/jira/browse/KARAF-910
>>            Project: Karaf
>>         Issue Type: Bug
>>         Components: karaf-features
>>   Affects Versions: 2.2.2
>>        Environment: Talend Service Factory 2.4.2.0 (includes Karaf 2.2.2) with the Equinox core.
>>           Reporter: Chris Dolan
>>           Assignee: Jean-Baptiste Onofré
>>            Fix For: 2.2.5, 3.0.0
>> 
>> 
>> I have an intermittent problem where my custom features.xml cannot be resolved. I use a tweaked etc/org.ops4j.pax.url.mvn.cfg file so the features.xml file is never present in $HOME/.m2/repo but is instead is resolved to local repo relative to the app:
>> org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.base}/system@snapshots,\
>>    file:${karaf.home}/${karaf.default.repository}@snapshots,\
>>    file:${karaf.base}/../../../.env/.m2/repo@snapshots
>> Sometimes when I start Karaf, I get this error (actual URL edited for privacy)
>> karaf@tsf> 2011-09-30 09:23:09,760 WARN  [FeaturesServiceImpl.java:924] Unable to add features repository mvn:<my-group-id>/<my-artifact-id>/<my-version>/xml/features at startup - o.a.k.f.i.FeaturesServiceImpl
>> java.lang.RuntimeException: URL [mvn:<my-group-id>/<my-artifact-id>/<my-version>/xml/features] could not be resolved.
>> 	at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195) [na:na]
>> 	at org.ops4j.pax.url.mvn.internal.AetherBridgeConnection.getInputStream(AetherBridgeConnection.java:68) [na:na]
>> 	at org.apache.karaf.features.internal.FeatureValidationUtil.validate(FeatureValidationUtil.java:49) [na:na]
>> 	at org.apache.karaf.features.internal.FeaturesServiceImpl.validateRepository(FeaturesServiceImpl.java:199) [na:na]
>> 	at org.apache.karaf.features.internal.FeaturesServiceImpl.internalAddRepository(FeaturesServiceImpl.java:210) [na:na]
>> 	at org.apache.karaf.features.internal.FeaturesServiceImpl.start(FeaturesServiceImpl.java:922) [na:na]
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:1.6.0_26]
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [na:1.6.0_26]
>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [na:1.6.0_26]
>> 	at java.lang.reflect.Method.invoke(Method.java:597) [na:1.6.0_26]
>> 	at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:226) [org.apache.aries.blueprint:0.3.1]
>> 	at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:824) [org.apache.aries.blueprint:0.3.1]
>> 	at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:636) [org.apache.aries.blueprint:0.3.1]
>> 	at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:724) [org.apache.aries.blueprint:0.3.1]
>> 	at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64) [org.apache.aries.blueprint:0.3.1]
>> 	at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219) [org.apache.aries.blueprint:0.3.1]
>> 	at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147) [org.apache.aries.blueprint:0.3.1]
>> 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:640) [org.apache.aries.blueprint:0.3.1]
>> 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:331) [org.apache.aries.blueprint:0.3.1]
>> 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227) [org.apache.aries.blueprint:0.3.1]
>> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [na:1.6.0_26]
>> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [na:1.6.0_26]
>> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [na:1.6.0_26]
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) [na:1.6.0_26]
>> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) [na:1.6.0_26]
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_26]
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_26]
>> 	at java.lang.Thread.run(Thread.java:662) [na:1.6.0_26]
>> If I put a breakpoint in org.ops4j.pax.url.mvn.internal.Connection.getInputStream(), I can see that when it fails m_configuration.getDefaultRepositories() contains one repo ($HOME/.m2/repo) and when it succeeds m_configuration.getDefaultRepositories() contains the three repos I've specified in etc/org.ops4j.pax.url.mvn.cfg.
>> I interpret that to mean that sometimes the features resolution happens before Felix reads the files in etc/ and sometimes the features load afterward. Mostly I'm using the same startlevels as Karaf -- my startup.properties file is identical to the following except for a few additions I made.
>> http://svn.apache.org/viewvc/karaf/trunk/assemblies/apache-karaf/src/main/filtered-resources/etc/startup.properties?revision=1176017&view=markup
> 
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 
>