2009/11/13 Rick McGuire <[email protected]> > 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
