cxf-dev mailing list archives

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

On Wed, Mar 9, 2011 at 11:53 AM, David Bosschaert <
david.bosschaert@gmail.com> wrote:

> 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...
>
> No, DOSGi RI does not use it and I basically propose (though I didn't get
to that in detail) for the CXF HttpTransport to do what DOSGi RI does with
respect to creating contexts, per-endpoint, dynamically...At the moment I'm
not sure how viable this approach is in the context of the CXF bundle being
loaded outside of DOSGIi but at least we can discuss it a bit and may be
something will come out of it...

Actually this reminded me of the fact I had to exclude the HTTP Osgi
transport from the CXF JAX-RS bundle because it was causing problems for
users loading the bundle in the SpringDM server...

Cheers, Sergey


> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message