Re: About Distributed OSGi greeter_rest demo
I also think making cxf plugable in dosgi would be a great thing. One such implementation would be with a Hazelcast backend like JB implemented for Cellar. Another interesting option would be JAXWS using the jdk JAXWS and JAXB version. This should allow to create a really slim implementation that might even be interoperable with the CXF implementation. An obvious place to implement this flexibility is the org.apache.cxf.dosgi.dsw.handlers.ConfigTypeHandlerFactory. There it checks for the backend to use ańd creates a org.apache.cxf.dosgi.dsw.handlers.ConfigurationTypeHandler. In this handler we have one reference to the cxf Server which would need to be abstracted. Apart from this the interface is already independent from cxf. The ConfigTypeHandlerFactory currently creates the ConfigTypeHandlers directly. This would have to be switched to use OSGi services. In the IntentManagerImpl I already have org.apache.cxf.dosgi.dsw.qos.IntentManagerImpl.assertAllIntentsSupported which shows how to check for OSGi services and how to wait for them in case of race conditions on startup. Christian On 04.01.2013 15:08, Tang Yong wrote: > 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 >>> >>
Re: About Distributed OSGi greeter_rest demo
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 >> > >
Re: About Distributed OSGi greeter_rest demo
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 >
