Hi David On Wed, Mar 9, 2011 at 11:53 AM, David Bosschaert < [email protected]> 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 <[email protected]> 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 > > >
