cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: About Distributed OSGi greeter_rest demo
Date Mon, 07 Jan 2013 09:17:08 GMT
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
>>>
>>


Mime
View raw message