You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2011/03/09 12:26:12 UTC
CXF OSGI application and HTTP transport
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
Re: CXF OSGI application and HTTP transport
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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
> >
>
Re: CXF OSGI application and HTTP transport
Posted by David Bosschaert <da...@gmail.com>.
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 <sb...@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
>
Re: CXF OSGI application and HTTP transport
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Christian
On Wed, Mar 9, 2011 at 1:06 PM, Christian Schneider <chris@die-schneider.net
> wrote:
> 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.
>
>
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
env.
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
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
>
>
--
Sergey Beryozkin
Application Integration Division of Talend <http://www.talend.com>
http://sberyozkin.blogspot.com
Re: CXF OSGI application and HTTP transport
Posted by Christian Schneider <ch...@die-schneider.net>.
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