I spent a little while debugging this today and found that the issue was that the bundles internally used by the system tests didn't have the proper startlevel set which meant that they would get assigned level 5 and be started way before any of the other bundles, nailing the jaxws package to the one from the JRE again (0.0.0). I've changed the start level of these bundles and now everything is working correctly.
I've committed this in r964787. I think we're ready for a release! Eoghan would you have some cycles? Cheers, David On 30 June 2010 18:16, Daniel Kulp <dk...@apache.org> wrote: > On Tuesday 29 June 2010 3:24:55 am David Bosschaert wrote: >> It troubles me that if people want to use CXF-DOSGi they would have to >> fiddle with the org.osgi.framework.system.packages. This is a major >> usability drawback from where we were before. >> >> > A more long-term option might to ship an entire distro of karaf with >> > dOSGi, >> >> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf >> distro as OSGi is all about reusable components that can be used in >> any compliant OSGi Framework. We shouldn't have to ship a tweaked >> runtime for people to be able to use it. >> >> >> I'm just curious, why was the CXF import updated to include 0.0.0 ? >> > >> > So it works with an "out of the box" setup of Equinox without requiring >> > the user to update funky setup things like the system.packages thing. >> >> Depending on version 0.0.0 is potentially dangerous because you have >> no idea what version you will get. In OSGi this dependency means: take >> any version available! > > Depending on ANY version range it dangerous. The same problem could pop up > with the old version range "[2.1,3.0)". For example, lets say the system was > properly configured to export the system packages as 2.1 (assuming Java 6 > update 4 or later). However, the user wants to use JAX-WS 2.2. (also > assume the 2.3 version of CXF that will support both 2.1 and 2.2). With the > current ordering, CXF would start, get version 2.1, then spec/api bundle would > start, then the client bundle would start and get 2.2, but then not be able > to use CXF due to the JAX-WS API version mismatch things. JAXB apis would be > the same way. Really, anything in the JDK could be an issue. > > JAXB is really a "could be an issue now" type thing. 2.2.9 supports the new > placements of @XmlElement on the method parameters to control the required and > nillable and such. This was added in JAXB 2.2 and required for JAX-WS 2.1, > but easily ported back to CXF 2.2.9, but only active if using JAXB 2.2. Thus, > there is a case where someone would WANT to use JAXB 2.2 with CXF today. In > the above scenario, CXF could pick up 2.1 from the system, but the user bundle > could want 2.2. Mismatch failure. > >> >> For CXF-DOSGi, as a temporary workaround, we *could* is *fix* the CXF >> jar that's part of our multibundle distro (during the build) and >> change the starting version back to what it was before. >> >> We could also reorder the bundles in the multibundle distro definition >> file (distro_bundles.xml). > > > I think this is the best option. I would think all the "spec"/"api" jars > should be pretty much the first things started up. > > >> I managed to get things working in the >> standalone case by putting the cxf bundle below the jaxws/jaxrs >> bundles, however for some reason it still hangs in the system tests... > > Not sure on that. > > Dan > > >> >> Cheers, >> >> David > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
