karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Issue with the latest mvn change on trunk
Date Sat, 14 Jan 2012 15:02:36 GMT
Another issue that we have to address is the startup time.

Karaf 2.2.x is very quick to start (something like 5 seconds on my 
machine), whereas Karaf 3.0.0 is very long (I got the shell in around 5 
seconds, but to have all services available (features, etc), it takes 
something like 1mn, we can see it with la and see the installation of 
the bundles and the state change).

Regards
JB

On 01/14/2012 03:58 PM, Jean-Baptiste Onofré wrote:
> Hi David,
>
> I built Pax URL 1.4-SNAPSHOT on my machine (with a fresh git pull).
>
> And I have exactly the same issue. Moreover I have another issue at
> startup:
>
> ERROR: Bundle org.ops4j.pax.url.wrap [2] Error starting
> mvn:org.ops4j.pax.url/pax-url-wrap/1.4-SNAPSHOT
> (org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.ops4j.pax.url.wrap [2]: Unable to resolve 2.0: missing requirement
> [2.0] osgi.wiring.package; (osgi.wiring.package=org.slf4j.impl))
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.ops4j.pax.url.wrap [2]: Unable to resolve 2.0: missing requirement
> [2.0] osgi.wiring.package; (osgi.wiring.package=org.slf4j.impl)
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
>
>
>
> I think due to the startup order as pax-logging/slf4j is not yet started
> when pax.url.wrap start.
>
> Anyway, the issue is still present with the latest pax-url.
>
> I'm digging to find the cause.
>
> Regards
> JB
>
> On 01/13/2012 07:37 PM, David Jencks wrote:
>>
>> On Jan 13, 2012, at 2:30 AM, Jean-Baptiste Onofré wrote:
>>
>>> Hi all,
>>>
>>> I saw an issue while updating the Spring version in Karaf
>>> 3.0.0-SNAPSHOT.
>>>
>>> It seems that now, Karaf goes on Central first, before cheking in the
>>> Karaf system repository.
>>>
>>> For instance, the Karaf Spring features XML is correct in the system
>>> repo, but after performed a features:list-url, this features XML is
>>> overwritten by the one on Central.
>>>
>>> I think that it's related to the latest change made by David.
>>>
>>> I think that the order of artifact resolution should be:
>>> 1/ check in the Karaf system repository
>>> 2/ check in the user .m2/repository
>>> 3/ check in the repositories defined in the
>>> etc/org.ops4j.pax.url.mvn.cfg
>>
>> That's what I've seen happening after my changes (and never before my
>> changes, where it always checked remote repos first).
>>
>> I wonder if you have an up to date copy of pax-url-aether? I don't
>> know the snapshot publishing policy at ops4j.
>>
>> david jencks
>>
>>>
>>> I'm going to check if the ${karaf.default.repository} is correctly
>>> used in Pax URL localRepository.
>>>
>>> I suspect the + (prepend) could be the cause of the problem (I gonna
>>> check).
>>>
>>> I will give you more information later today.
>>>
>>> More over, I saw that the demos features is present by default in the
>>> distribution (with file: protocol). I think it should be "optional"
>>> and provided by a demos features that the user has to reference
>>> (add-url).
>>>
>>> Regards
>>> JB
>>>
>>>
>>>
>>>
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message