cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Loading HTTP OSGI transport only when needed
Date Mon, 18 Jan 2010 21:46:19 GMT


I'm thinking of removing the http-osgi dependency from cxf-minimal and
cxf-jaxrs bundles only.

Here're the reasons why :

1. The issue has been reported against a CXF JAX-RS bundle

2. CXF Minimal is used by DOSGi RI which uses its own (more dynamic)
approach toward allocating contexts (I'd like to update the cxf osgi
transport somehow to be more dynamic too, that is, for individual CXF
endpoints be able to allocate individual contexts, as opposed to all of
them having to share some root context)

3. CXF Minimal and CXF JAXRS are 'minimal' by definition, so it kind of
makes sense at this stage to limit the distribution of the osgi
transport to the all-inclusive bundle only.

4. Going forward (from CXF 3.0 ?), I reckon it would make sense to
remove the osgi transport from the distribution all together. Instead
ServiceMix CXF feature may get updated to depend on CXFBundle + CXF OSGI
transport, other OSGI environments which may need it will depend on cxf
bundle and on the osgi transport (bundle). Or may be we can have a
CXF-All-OSGI which will include all the 'active' OSGI-related
components, those causing some immediate side-effects when loaded into


The only problem I see here is that CXF 2.2.5 users have started using
CXF JAX-RS or CXF Minimal in OSGI environments we're not aware of and
started using the osgi transport. A bit unlikely but it will be worth
checking with the users list. Has anyone tried to do it already ? Please
let us know...


Users can modify the CXF bundles locally and remove this transport but
I'd rather the transport be lazily loaded or when really needed. I have
a feeling this issue might hiner a bit the migration to later CXF
versions for users which can not afford, say, easily migrating to the
next Spring DM server, etc...




Thoughts ?




<quote author="Sergey Beryozkin-2">




Some users have reported that the CXF HTTP OSGI transport is causing
issues in OSGI containers depending on the Spring DM 1.0.2 or earlier,
due to Spring DM eagerly loading the CXF HTTP OSGI context but failing
to deal with the (spring-)osgi-compendium related elements.


The only solution which seems to work in this case is to remove a cxf
osgi transport bits altogether from a bundle given that the user
reporting the issue is not using this transport.


This works but it is not ideal.

I'm also thinking that may be DOSGI might be affected a bit too given
that DOSGI users do not use this transport as well but will have a /cxf
context busy already, not that they need '/cxf'  but anyway...


I'm just wondering, what options we might have here ?

Perhaps one option is not to bundle this transport for cxf-minimal and
cxf-jaxrs bundles ? Users who do need it, say ServiceMix users, can get
it from the full bundle.


Another option is to add a CXF OSGI HTTP transport BundleActivator and
repackage META-INF/spring/cxf-osgi-transport.xml into say
META-INF/cxf//spring/cxf-osgi-transport.xml. Our BundleActivator will
somehow delegate to META-INF/cxf//spring/cxf-osgi-transport.xml, I don't
know how yet, but I think, as far as I recall from writing SpringDM
tests, it might be possible to point SpringDM to some custom location.
However, before delegating, the BundleActivator will check, say a system
property which if set would disable the osgi transport. Something along
these lines.


Thoughts ?


cheers, Sergey


P.S. I might not be able to contribute to this thread until this coming


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