David Jencks wrote:
On Nov 10, 2009, at 9:57 AM, Rick McGuire wrote:
David Jencks wrote:
On Nov 10, 2009, at 7:59 AM, Rick McGuire wrote:
There are two subprojects in the jaxws plugin that I'm having
trouble building, and I can't figure out why. The cause of the
failure is a resolution failure trying to resolve the javax.jws
package, version 2.0. These classes are contained in the
geronimo-ws-metadata specs bundle, and should be there. Running
the build with the -X option does not show any sign that this
bundle is getting installed and started before the error. I've
tried adding this as dependency in every pom I could think of to
force this to be loaded first and nothing appears to have made a
difference. That bundle just doesn't seem to get loaded. The
manifests look good in all cases, but it just doesn't appear to load.
I also tried specifying a version in the karaf config.properties on
the javax.jws packages, but that didn't make any difference
either. There's obviously something going wrong with how the
dependencies are processed here, but I can't seem to spot what's
messing up. Everything looks like what I'd expect to see when I
use dependency:tree.
For now, I've just commented these two items out so they won't
build, but this is going to need to be solved eventually.
I suspect these classes are also in the jvm. Maybe the situation is
similar to the one for javax.transaction where some classes come
from the jvm and some from the spec jar? The mysterious fix for
that seems to be, in etc/config.properties from
framework/config/karaf-framework/src/main/resources/filtered-resources/etc/config.properties
org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.transaction,javax.transaction.*
and
javax.transaction; javax.transaction.xa; partial=true;
mandatory:=partial, \
I did that experiment already, and that didn't work either. The root
of the problem appears to be the explicit request for the 2.0
version. That is available in the geronimo-ws-metadata bundle, but
there's no sign in any of the Felix debug output to indicate that
this is getting loaded.
I'm now stuck on a similar situation with geronimo-service-builder.
I'm getting a constraint loading error on geronimo-service-builder
because it can't find the org.apache.geronimo.xbeans.j2ee package.
That's in the geronimo-schema-jee_5.1.2 bundle, but again, I'm not
seeing that bundle loaded before the geronimo-service-builder bundle,
so the geronimo-service-builder can't be resolved. It's really
looking like there's an ordering problem in the dependency manager
that's resulting in bundles not getting installed before the bundles
that depend on them.
I don't have time to look into it right now.... I thought I made the
dep-manager install all the bundles then run through and try to start
them to avoid this problem. I expected that if we got a jar into the
dependencies list it would then be installed and known to felix before
we actually needed any of its classes. Not sure if this makes sense
or if I got the code in to actually do this...
I think I figured out the root cause of this. A lot of poms had a
dependency for geronimo-gbean-deployer with a scope of provided
<artifactId>geronimo-gbean-deployer</artifactId>
<version>${version}</version>
<type>car</type>
<scope>provided</scope>
This resulted in all of the dependencies of geronimo-gbean-deployer
getting marked as provided also. As a result, even if you explicitly
added one of these dependencies to a plugin that had a dependency on
geronimo-gbean-deployer, it was not getting installed because that
dependency was already marked as "provided". It appears that the
reasons for geronimo-gbean-deployer being marked as provided must be
obsolete or else this somehow needs to be forced to load somewhere in
the dependency manager.
Rick
david jencks
Rick
Might be worth experimenting with anyway.
david jencks
Rick
