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 <sberyoz...@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 >
