[ 
https://issues.apache.org/jira/browse/KARAF-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks updated KARAF-910:
-------------------------------

    Attachment: KARAF-910-ops4j-2.diff

Again, for ops4j.  

This version depends on a flag in framework properties 
org.ops4j.pax.url.mvn.require.config.admin.config

If present, it waits for a config admin based configuration (that should not 
include this flag).  So including this flag in framework properties should 
prevent the mvn url handler from registering until the config admin config 
shows up.

The other url handlers don't check for validity so they will work with 
framework property configuration as they do now.

Another difference is that to make this work you need to avoid fallback 
configuration.  Either you use config admin config or framework property config 
but you can't mix them.  Otherwise the flag will always be seen and prevent any 
configuration at all.
                
> 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é
>            Priority: Blocker
>             Fix For: 2.2.6, 3.0.0
>
>         Attachments: KARAF-910-ops4j-2.diff, KARAF-910-ops4j.diff
>
>
> 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


Reply via email to