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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
