cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: CXF OSGI application and HTTP transport
Date Wed, 09 Mar 2011 17:04:03 GMT
Hi Christian

On Wed, Mar 9, 2011 at 1:06 PM, Christian Schneider <
> wrote:

> Hi Sergey,
> I am currently starting to work on
> which also depends on
> unifying the servlet an osgi http transports.
> Currently the code has some subtle differences mostly in the
> servletcontroller. I am trying to use the same code and see if the tests
> still work.
> Then we could try to remove any special osgi code for http. The only thing
> that would remain are the two spring contexts.
> As I am also not sure if these contexts are a good way to setup CXF in OSGi
> I would be very interested in your thoughts about this.
> Perhaps we can work on a better design. I am sure David could help a lot as
> he did a quite different aproach in DOSGi.
Perhaps it might make sense to try and experiment with replacing the
existing http-osgi spring-dm configuration with the equivalent
implementation. This even can be tried in the http-osgi. For the sake of the
experiment only...

So we can start with removing that spring context and adding an Activator
implementation in the .osgi sub-package. This Activator uses ServiceTracker
to catch the HttpService and then immediately uses it to register the
servlet using the required context name - it can find about the custom name
from the ConfigAdmin. The activator also registers itself as the
ManagedService and exposes properties (those in the spring-dm context and
more as needed).

This is really what Spring DM/Blueprint does under the hood...DOSGi also
interacts directly with the HTTP service.
So having this Activator can meet your requirement of detecting the OSGI

This Activator would need to be referenced from the cxf-bundle manifest
which is a bit strange but it is exactly what we have at the moment with the
http-osgi transport being the 'CXF OSGI Application'.

May be it is too simplistic but may be it can work :-)
Cheers, Sergey

> Am 09.03.2011 12:26, schrieb Sergey Beryozkin:
>  Hi
>> I'd like to discuss a bit the possibility of making the CXF HTTP-OSGI
>> transport redundant. Not sure if it's a good idea but I'd like to give it
>> a
>> chance :-) by discussing it on this list.
>> The reason I'm concerned about CXF HTTP-OSGI transport is that it
>> effectively takes the role of the CXF OSGI application.  At the moment
>> it's
>> a Spring DM application and may get updated to become a Blueprint one. CXF
>> is bigger than its HTTP transport but we're limited only to its HTTP
>> transport registering itself as the Servlet.
>> The other thing which concerns me is its static nature to do with
>> hard-coding the context name and the names of the properties it may
>> support.
>> Having a single context within a given container instance is a limitation,
>> not a big one, but it is nonetheless. And hardcoding the names of the
>> properties is not good at all because OSGI gives us a ManagedService
>> interface.
>> Finally we are just totally out of control here and just depend on the
>> external injection.
>> I hope we can find a way to break this dependency. It was really needed at
>> a
>> time but IMHO it limits the way CXF as a whole can play in OSGI.
>> If we look at DOSGi, one of the reasons it is interesting to developers is
>> that it effectively makes CXF JAX-WS and JAX-RS runtimes taking more
>> active
>> roles in the process. DOSGi provides callbacks for these components to
>> wrap
>> the registered/looked-up interfaces. Yet alternative way is to have
>> individual Activators check a given bundle for the presence of say JAX-RS
>> Application or may be JAX-WS @WebService interface and react.
>> I'm wondering if the idea of introducing a top-level Activator (at the
>> distribution level) delegating to module-specific Activators works or not.
>> At the moment it seems like it can. HTTP, JAX-WS, JAX-RS/etc Activators
>> can
>> do whatever they need to and also expose the properties which can be
>> dynamically updated...
>> My only concern is how to synchronize the whole process and the idea of
>> say
>> HTTP Transport registering itself as some OSGI service (discussed in the
>> other thread) can be a perfect solution. If it all can work then we will
>> end
>> up having a real CXF OSGI application, very flexible and advanced, it will
>> be a different level really...
>> Of course that could be a bad idea - there could be constraints there
>> which
>> basically make it not-workable...
>> Cheers, Sergey
> --
> ----

Sergey Beryozkin

Application Integration Division of Talend <>

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