karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Dolan (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KARAF-910) Race between FeatureService and ConfigAdmin for resolving mvn: URLs?
Date Fri, 30 Dec 2011 17:44:30 GMT

    [ https://issues.apache.org/jira/browse/KARAF-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177709#comment-13177709
] 

Chris Dolan commented on KARAF-910:
-----------------------------------

Here is a proposed multi-part solution to this race: 1) change pax-url-common to optionally
delay registering an URL handler until the service is configured, 2) change FeaturesValidationUtil
to treat MalformedUrlException specially.

The class org.ops4j.pax.url.commons.handler.HandlerActivator currently unconditionally registers
the URL handler in its start() method. I propose that it should instead check a flag (perhaps
a boolean Java system property like "${pid}.configurationRequired") and if that flag is true
the URL handler should be registered only after ManagedService.updated() is invoked with a
non-null value. This flag is the most unpleasant part of this proposal: we need to preserve
the existing behavior that the handler will be registered with default configuration, but
we also need a way to indicate that the configuration is required. This reminds me of the
Declarative Services feature `configuration-policy="require"` which is exactly the desired
behavior here.

The malformed URL is even harder to solve, I think. The FeaturesServiceImpl needs to detect
the URL failure, and retry validation at some later time when the URL handler is registered.
That "when" can be satisfied by registering a listener for the registration of an URLStreamHandlerService
with bundle the property "url.handler.protocol" including the desired URL scheme. Again, thinking
in terms of Declarative Services this is like adding a `<reference interface="org.osgi.service.url.URLStreamHandlerService"
cardinality="1..1" filter="(url.handler.protocol=mvn)"/>`

Open questions:
 * is there a better way to signal to pax-url-common that the configuration is required?
 * should FeaturesServiceImpl have a timeout while waiting for the URL handler?
 * should FeaturesServiceImpl block while waiting for the URL handler?
 * if FeaturesServiceImpl asynchronously waits for the URL handler, how will a user who loads
the feature from the Karaf command line know about real validation failures?

                
> 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
>
>
> 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

       

Mime
View raw message