cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: DOSGI: Update to CXF 2.2.9
Date Wed, 30 Jun 2010 17:16:10 GMT
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
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message