You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2009/11/10 16:59:22 UTC
Strange dependency problem building jaxws
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.
Rick
Re: Strange dependency problem building jaxws
Posted by Rick McGuire <ri...@gmail.com>.
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
>>>
>>>
>>
>
>
Re: Strange dependency problem building jaxws
Posted by Ivan <xh...@gmail.com>.
2009/11/13 Rick McGuire <ri...@gmail.com>
> 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.*
>>>>
>>>>
>>> Ok, I've think I've tracked this problem back to its root cause and fixed
> it now. I'm able to build with this fix and with the changes to the
> geronimo-gbean-deployer backed off.
>
> The issue here was how the framework system classes were getting defined
> and how the build/runtime was providing access to spec class that are JRE
> resident. With my original problem, the issue was showing up with the
> javax.jws packages, but this would be an issue with any of our spec jars.
> Here's how some of these issues showed up:
>
> 1) During the build, any configuration or bundle that had a dependency on
> the javax.jws classes was getting built using the geronimo-ws-metadata spec
> jar. This resulted in these bundles having an import dependency against the
> version 2.0 of the javax.jws packages.
>
> 2) When building the configuration using the car plugin, the provided
> scope on the geronimo-gbean-deployer was preventing the geronimo-ws-metadata
> bundle from getting installed. This caused a resolution failure because
> there was no javax.jms package available with a version >= 2.0.
> 3) Removing the provided scope from the geronimo-gbean-deployer allowed
> the geronimo-ws-metadata bundle to be installed, but this had the side
> effect of having two versions of the javax.jws packages visible in the
> framework. One at the 2.0 level (the geronimo-ws-metadata one) and a second
> at the 0.0.0 level (the one from the jre). In some complex environments,
> this resulted in bundle constraint violations because the uses relationships
> required visibility to both versions of these packages.
> The solution was to explicitly specify the framework exported versions of
> these packages so that they match the version level we specify in the
> geronimo spec bundles. This allows bundles dependent upon specific versions
> of these packages to use the framework version without requiring the
> geronimo bundle to be installed and if the geronimo version does end up
> getting installed, bundles will still be wired to just a single source for
> these package files.
> This correction needed to be made in both the car plugin and the karaf
> config.properties files.
>
Since Geronimo 3.0 will only support JDK 1.6+, those packages like jws are
provided by JRE, so do we still need to ship our own spec ? After keeping
the same version number, it seems that the ones from JRE are always used.
>
> Rick
>
>
>
>
>>>>
>>>> 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...
>>
>> david jencks
>>
>>
>> Rick
>>>
>>>>
>>>>
>>>> Might be worth experimenting with anyway.
>>>>
>>>> david jencks
>>>>
>>>>
>>>>> Rick
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Ivan
Re: Strange dependency problem building jaxws
Posted by Rick McGuire <ri...@gmail.com>.
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.*
>>>
Ok, I've think I've tracked this problem back to its root cause and
fixed it now. I'm able to build with this fix and with the changes to
the geronimo-gbean-deployer backed off.
The issue here was how the framework system classes were getting defined
and how the build/runtime was providing access to spec class that are
JRE resident. With my original problem, the issue was showing up with
the javax.jws packages, but this would be an issue with any of our spec
jars. Here's how some of these issues showed up:
1) During the build, any configuration or bundle that had a dependency
on the javax.jws classes was getting built using the
geronimo-ws-metadata spec jar. This resulted in these bundles having an
import dependency against the version 2.0 of the javax.jws packages.
2) When building the configuration using the car plugin, the provided
scope on the geronimo-gbean-deployer was preventing the
geronimo-ws-metadata bundle from getting installed. This caused a
resolution failure because there was no javax.jms package available with
a version >= 2.0.
3) Removing the provided scope from the geronimo-gbean-deployer allowed
the geronimo-ws-metadata bundle to be installed, but this had the side
effect of having two versions of the javax.jws packages visible in the
framework. One at the 2.0 level (the geronimo-ws-metadata one) and a
second at the 0.0.0 level (the one from the jre). In some complex
environments, this resulted in bundle constraint violations because the
uses relationships required visibility to both versions of these packages.
The solution was to explicitly specify the framework exported versions
of these packages so that they match the version level we specify in the
geronimo spec bundles. This allows bundles dependent upon specific
versions of these packages to use the framework version without
requiring the geronimo bundle to be installed and if the geronimo
version does end up getting installed, bundles will still be wired to
just a single source for these package files.
This correction needed to be made in both the car plugin and the karaf
config.properties files.
Rick
>>>
>>>
>>> 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...
>
> david jencks
>
>
>> Rick
>>>
>>>
>>> Might be worth experimenting with anyway.
>>>
>>> david jencks
>>>
>>>>
>>>> Rick
>>>
>>>
>>
>
>
Re: Strange dependency problem building jaxws
Posted by David Jencks <da...@yahoo.com>.
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...
david jencks
> Rick
>>
>>
>> Might be worth experimenting with anyway.
>>
>> david jencks
>>
>>>
>>> Rick
>>
>>
>
Re: Strange dependency problem building jaxws
Posted by Rick McGuire <ri...@gmail.com>.
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.
Rick
>
>
> Might be worth experimenting with anyway.
>
> david jencks
>
>>
>> Rick
>
>
Re: Strange dependency problem building jaxws
Posted by David Jencks <da...@yahoo.com>.
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, \
Might be worth experimenting with anyway.
david jencks
>
> Rick