geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Strange dependency problem building jaxws
Date Wed, 25 Nov 2009 09:47:26 GMT
2009/11/13 Rick McGuire <rickmcg@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

Mime
View raw message