Grzegorz Grzybek commented on KARAF-4100:

For me, the workaround was to put exactly the same set of 
{{org.ops4j.pax.url.mvn.*}} properties to {{etc/config.properties}} file.
pax-url-aether, when starting checks if configuration for this PID is available 
(or if configadmin service is available at all). In case it doesn't find the 
config, it calls {{org.osgi.framework.BundleContext#getProperty()}} which uses 
{{etc/config.properties}} as a source.

It's obvious duplication, but it works without problems.

Other solution would be to reimplement 
{{org.ops4j.pax.url.mvn.internal.Activator#start()}}, but this issue should be 
created at https://ops4j1.jira.com/browse/PAXURL.

> [karaf-3.0.x] Error resolving artifact of feature due to 
> org.ops4j.pax.url.mvn.cfg not loaded yet
> -------------------------------------------------------------------------------------------------
>                 Key: KARAF-4100
>                 URL: https://issues.apache.org/jira/browse/KARAF-4100
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-feature
>    Affects Versions: 3.0.5
>         Environment: Karaf 3.0.4, Windows 7
>            Reporter: Jerry Meng
> I set the mvn repository to the karaf_home/system directory in 
> org.ops4j.pax.url.mvn.cfg.
> However, I found there is a chance that Karaf was trying to access the 
> Internet and threw an exception since it's in a closed environment.
> {code}
> Error resolving artifact 
> org.apache.karaf.features:enterprise:xml:features:3.0.4: Could not transfer 
> artifact org.apache.karaf.features:enterprise:xml:features:3.0.4 from/to  
> (http://mvn.mycompany.net/content/groups/public): Not authorized , 
> ReasonPhrase:Unauthorized.
> {code}
> Root Cause
> =========
> Through further tracking, the root cause may happen in 
> org.ops4j.pax.url.mvn.internal.Activator (pax-url-aether). The pax url fails 
> to load org.ops4j.pax.url.mvn.cfg before Karaf connects the feature url. 
> Therefore Karaf ignores my settings in the configuration file but tries to 
> access default remote repository. Here are some logs to describe the 
> situation...
> {code}
> 1. activator.updated.dictionary: null
> 2. updated directory from safeRegisterService: null
> 3. activator.openConnection: 
> mvn:org.apache.karaf.features/enterprise/3.0.4/xml/features
> 4. Unable to add features repository 
> mvn:org.apache.karaf.features/enterprise/3.0.4/xml/features at startup
> 5. updated directory from safeRegisterService: 
> {felix.fileinstall.filename={file:/D:/karaf/etc/org.ops4j.pax.url.mvn.cfg... }
> 6. activator.updated.dictionary: 
> {felix.fileinstall.filename={file:/D:/karaf/etc/org.ops4j.pax.url.mvn.cfg... }
> {code}
> Workaround
> =========
> I'm not sure if I should call this a bug, but in my case I can assume 
> org.ops4j.pax.url.mvn.cfg is existent definitely.
> Therefore, I make Activator.openConnection to wait if the Dictionary is not 
> set.
> Then invoke notifyAll in Activator.updated after receiving an non-null 
> Dictionary.

This message was sent by Atlassian JIRA

Reply via email to