Uploaded image for project: 'Karaf'
  1. Karaf
  2. KARAF-910

Race between FeatureService and ConfigAdmin for resolving mvn: URLs?

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.2.2
    • Fix Version/s: 3.0.0
    • Component/s: karaf
    • Labels:
      None
    • Environment:

      Talend Service Factory 2.4.2.0 (includes Karaf 2.2.2) with the Equinox core.

      Description

      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

        Attachments

        1. KARAF-910-ops4j.diff
          5 kB
          David Jencks
        2. KARAF-910-ops4j-2.diff
          7 kB
          David Jencks

          Activity

            People

            • Assignee:
              jbonofre Jean-Baptiste Onofré
              Reporter:
              cdolan Chris Dolan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: