cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tang Yong <tangy...@cn.fujitsu.com>
Subject Re: About Distributed OSGi greeter_rest demo
Date Fri, 04 Jan 2013 14:08:38 GMT
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