cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: CXF OSGI application and HTTP transport
Date Wed, 09 Mar 2011 13:06:17 GMT
Hi Sergey,

I am currently starting to work on 
https://issues.apache.org/jira/browse/CXF-3384 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.

Christian


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
>

-- 
----
http://www.liquid-reality.de


Mime
View raw message