cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: CXF OSGI application and HTTP transport
Date Wed, 09 Mar 2011 11:53:11 GMT
Hi Sergey,

Not sure I understand your email 100% (maybe I should spend more time
reading it ;) but just to make sure, the component you're proposing to
remove is not related to DOSGi, correct? DOSGi als uses a HTTP
transport, but that's is not the one you're suggesting to remove...

Cheers,

David

On 9 March 2011 11:26, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> 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
>

Mime
View raw message