Mailing-List: contact issues-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Date: Tue, 11 Oct 2016 08:38:21 +0000 (UTC)
From: "Grzegorz Grzybek (JIRA)" <jira@apache.org>
To: issues@karaf.apache.org
Message-ID: <JIRA.12911155.1446833299000.791655.1476175101574@Atlassian.JIRA>
In-Reply-To: <JIRA.12911155.1446833299000@Atlassian.JIRA>
References: <JIRA.12911155.1446833299000@Atlassian.JIRA> <JIRA.12911155.1446833299541@arcas>
Subject: [jira] [Commented] (KARAF-4100) [karaf-3.0.x] Error resolving
 artifact of feature due to org.ops4j.pax.url.mvn.cfg not loaded yet
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 11 Oct 2016 08:38:23 -0000


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

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
(v6.3.4#6332)