cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eoghan Glynn <eogl...@gmail.com>
Subject Re: DOSGI: Update to CXF 2.2.9
Date Tue, 29 Jun 2010 07:52:33 GMT
> 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.

Well it could be a convenience *option*, just to get folks started out of
the box.

Agreed we would have to continue with the multi-bundle style option that
could be plonked into an existing runtime and be expected to work (without
too much bother).

> 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!

Yeah.

But the way I'd see it is that CXF has kinda been backed into a corner by
what is fundamentally a framework bug. Exposing all the system packages as
0.0.0.0 makes absolutely no sense IMO, when many of these packages have a
clearly versioned provenance and it's likely that dependent bundles will
pull them in via version-constrained imports. The framework's 0.0.0.0 might
have been workable back in the day when only java.lang.String etc. were
being pulled in from the system package, but as more and more javax.* stuff
is being piled into the JRE, this isn't really feasible any more.

That said however, if there's a smarter fix/workaround that could be applied
to CXF instead, then great!

> We could also reorder the bundles in the multibundle distro definition
> file (distro_bundles.xml).

Just a ceveat, re-ordering bundles can be very fragile. SMX hit some nasty
issues whereby the ordering was subtly changed when the bundles were being
pulled in from a slowish NAS.

Cheers,
Eoghan


On 29 June 2010 08:24, David Bosschaert <david.bosschaert@gmail.com> 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!
>
> 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 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...
>
> Cheers,
>
> David
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message