Hi Sergey, Thanks for adding the topic into dev list.
> I guess it does not matter at DOSGi level how HTTPService is provided, > whether with pax-web > or via the container-specific implementation Yes, I felt maybe also needing a pluggable point for switching OSGi HttpService implementation. > any practical solution. > If someone can ever come up with some practical patch with CXF being the > default DSW stack - then why not :-) About pluggable, if I plan to try it with glassfish, several points need to be investigated: 1 in DSW, discriminate CXF logic/function from CXF-outside 2 considering adding a pluggable layer My initial idea is: 1)defining some reasonable interfaces for these CXF logic for 2) 2)whether can inject these CXF logic/function using service-oriented way, eg1. using Declare Service(xml or annotation) eg2. if integrated into appserver(for example, glassfish), I maybe consider using a JSR330 implementation(glassfish sub-project called hk2) to re-wrap these CXF logic/function in service-injection way eg3. using simple dependency injection with ServiceLoader in jdk6 I more will try eg1. 3 doing a default DSW stack based CXF based 2 4(Optional)switch another framework(eg. jersey) Here, we need to do a detailed investigation about difference between CXF logic/function and jersey server side(or other framework). This belongs to integration vendors's thing. Thanks --Tang Sergey Beryozkin wrote: > Hi Tang > > CC-ing to dev as it might of the general interest > > On 04/01/13 15:53, Tang Yong wrote: >> Hi Sergey, >> >> Thanks, I still have many needing to learn... :) >> >> I have two questions and want to ask you or Christian, >> >> [Background] >> In the future(not very long), I will try to integrate DCXF into >> Glassfish v4 in order to make glassfish have DOSGi capability(this is >> also why I start to join DCXF and indeedly, DCXF is an excellent >> framework!), as to how to integrate it, I am still in thinking, because >> ,currently, glassfish has not some functions similar to Karaf's feature >> or OSGi subsystem(this is also why I start to do some research on >> Karaf's kernel/feature). >> >> [Question1] >> However, glassfish has a itself OSGi http container implementation, and >> I wish that defaultly, while starting DCXF, it can use glassfish's OSGi >> http container, so could you give me some advice(if spenting your too >> much time, no problem, I will investigate it in depth, :)) > > I guess it does not matter at DOSGi level how HTTPService is provided, > whether with pax-web > or via the container-specific implementation >> [Question2] >> glassfish has itself jax-rs/ws implementation(jersey), and currently, >> DCXF uses CXF as core jax-rs/ws implementation, I have an unmature idea: >> whether there is a possibility that we can swich jax-rs/ws >> implementation and also use other framework(for example, jersey), of >> course, I know that this is a litter unpractical. > Well, quite awhile back there was some discussion on how to get the > actual DSW implementation pluggable, example, some experts wanted a very > slim RI implementation based on something like RMI, but it never came to > any practical solution. > If someone can ever come up with some practical patch with CXF being the > default DSW stack - then why not :-) > > Cheers, Sergey > >> Thanks >> --Tang >> > >
