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
