You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by K Fung <kf...@gmail.com> on 2011/10/07 20:51:35 UTC
How to contribue a CXF JAX-RS OSGi Sample?
Hi everyone,
(long time lurker here ... thought it was about them we started to
contribute something back)
As everyone who's played with CXF JAX-RS and OSGI knows, it's not too
easy to get CXF and OSGI to co-operate outside of the Apache
ServiceMix bundle/example.
I've been sitting on a CXF JAX-RS OSGI example for the last few months
that illustrates the minimal dependencies needed for CXF JAX-RS OSGI
to work correctly but I don't know what's the best way to distribute
it.
As it's a combination of both CXF JAX-RS code and ServiceMix code,
it's in the middle ground where it neither fits with ServiceMix nor
CXF perfectly. So I'm looking for feedback about where you think this
sample would fit best?
Some thoughts I had...
1) As an example in the CXF distribution
2) As an entry in the CXF wiki (https://cwiki.apache.org/confluence/display/CXF)
3) As just a blog entry somewhere in the world wide web where it may
be referenced
Do any of you have any thoughts? Would it even be welcomed in the CXF trunk?
Regards,
kl
Re: Activators for individual frontends
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 20/12/11 19:04, Daniel Kulp wrote:
> On Monday, December 19, 2011 10:35:07 AM Sergey Beryozkin wrote:
>> Hi KL, All,
>>
>> On 16/12/11 22:34, K Fung wrote:
>>>> In 2.5.2 on later we can think of introducing an activator into the
>>>> jaxrs>
>>> frontend so that it can discover custom Applications and providers
>>> registered as OSGI services
>>>
>>> Perhaps we should have a discussion on a separate thread to discuss how
>>> you envision seeing this? In particular, I'm wondering what's the
>>> baseline/environment you think this would be running. For example, right
>>> now there is no activator in the CXF JAX-RS bundle but what are the
>>> consequence of an activator in 2.5.2+ - can it be disabled? Do we rely
>>> on
>>> the OSGI HttpService or do we use a built-in Jetty? Can we support both?
>>>
>>> I guess you can see that I'm pretty interested in this topic :-)
>>
>> I was thinking earlier on that CXF can get a master/root activator which
>> will provide BundleContext, etc to individual activators which say JAXWS
>> and JAXRS frontends may offer; I think these activators will not act as
>> independent activators on its own, they will simply be able to react to
>> the information (BundleContext for ex) that the actual root activator
>> may offer.
>
> Well, we could have the current activator grab a list out of the current
> bundle (cxf-bundle) of other activators to instantiate and call. For example,
> we could have a META-INF/cxf/osgi-activators.txt that is created during
> bundling (shade can do it) that the OSGiExtensionLocator thing will grab and
> then call the start/stop on it.
Super, this looks like a good way to start
> We'd only need to look in the current
> bundle. Once we split into modules, the "core" bundle would not have that and
> thus wouldn't do anything, but the jaxrs bundle could properly define it's own
> activator in it's manifest. This wouldn't be hard to do.
>
Yea;
Cheers, Sergey
> Dan
>
>> For example, in case of JAX-RS, this sub-activator will probably
>> register ServiceTrackers and start listening for (JAX-RS) Application
>> interfaces and then will create an endpoint by using HttpService or
>> embedded Jetty, something like that
>>
>> What do you think ?
>> Sergey
Re: Activators for individual frontends
Posted by Daniel Kulp <dk...@apache.org>.
On Monday, December 19, 2011 10:35:07 AM Sergey Beryozkin wrote:
> Hi KL, All,
>
> On 16/12/11 22:34, K Fung wrote:
> >> In 2.5.2 on later we can think of introducing an activator into the
> >> jaxrs>
> > frontend so that it can discover custom Applications and providers
> > registered as OSGI services
> >
> > Perhaps we should have a discussion on a separate thread to discuss how
> > you envision seeing this? In particular, I'm wondering what's the
> > baseline/environment you think this would be running. For example, right
> > now there is no activator in the CXF JAX-RS bundle but what are the
> > consequence of an activator in 2.5.2+ - can it be disabled? Do we rely
> > on
> > the OSGI HttpService or do we use a built-in Jetty? Can we support both?
> >
> > I guess you can see that I'm pretty interested in this topic :-)
>
> I was thinking earlier on that CXF can get a master/root activator which
> will provide BundleContext, etc to individual activators which say JAXWS
> and JAXRS frontends may offer; I think these activators will not act as
> independent activators on its own, they will simply be able to react to
> the information (BundleContext for ex) that the actual root activator
> may offer.
Well, we could have the current activator grab a list out of the current
bundle (cxf-bundle) of other activators to instantiate and call. For example,
we could have a META-INF/cxf/osgi-activators.txt that is created during
bundling (shade can do it) that the OSGiExtensionLocator thing will grab and
then call the start/stop on it. We'd only need to look in the current
bundle. Once we split into modules, the "core" bundle would not have that and
thus wouldn't do anything, but the jaxrs bundle could properly define it's own
activator in it's manifest. This wouldn't be hard to do.
Dan
> For example, in case of JAX-RS, this sub-activator will probably
> register ServiceTrackers and start listening for (JAX-RS) Application
> interfaces and then will create an endpoint by using HttpService or
> embedded Jetty, something like that
>
> What do you think ?
> Sergey
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 16/12/11 22:34, K Fung wrote:
> Hello,
>
>> I'm sorry - I should've put it into 2.5.1 - but it will definitely make
> it into 2.5.2 - and I hope it would be of interest to users.
>
> No worries Sergey. Thanks for all your helpful suggestions and guidance
> while I worked on this in 2 week spurts.
>
> It took us countless hours and much frustration to figure out how to run
> CXF JAX-RS in our OSGI environment. Hopefully this sample will alleviate
> the time needed for others to get up to speed with CXF JAX-RS in their own
> environments.
>
>> In 2.5.2 on later we can think of introducing an activator into the jaxrs
> frontend so that it can discover custom Applications and providers
> registered as OSGI services
>
> Perhaps we should have a discussion on a separate thread to discuss how you
> envision seeing this? In particular, I'm wondering what's the
> baseline/environment you think this would be running. For example, right
> now there is no activator in the CXF JAX-RS bundle but what are the
> consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on
> the OSGI HttpService or do we use a built-in Jetty? Can we support both?
>
> I guess you can see that I'm pretty interested in this topic :-)
>
me too :-), I started a new thread
thanks, Sergey
> On Fri, Dec 16, 2011 at 2:21 PM, Sergey Beryozkin<sb...@gmail.com>wrote:
>
>> Hi KL
>>
>>
>> On 16/12/11 22:13, K Fung wrote:
>>
>>> Hi Sergey,
>>>
>>> I've uploaded the final version (for now) to CXF-3859. I've bumped up the
>>> version to 2.5.2-SNAPSHOT and commented out the Apache Snapshot
>>> repository.
>>> Hopefully, this meets the quality bar for commit :-)
>>>
>>
>> I'm sorry - I should've put it into 2.5.1 - but it will definitely make it
>> into 2.5.2 - and I hope it would be of interest to users.
>>
>>
>>
>>> I did investigate creating the JAXRSServerFactoryBean directly (instead of
>>> subclassing CXFNonSpringJaxrsServlet). If I went down this route, I would
>>> have had to include a dependency on Jetty directly (as the traffic
>>> wouldn't
>>> be provided via the OSGI HttpService) or duplicate much of the servlet
>>> code
>>> in CXFNonSpringJaxrsServlet. In the end, I decided that it just wasn't
>>> worth it.
>>>
>>
>> Sounds right...
>> In 2.5.2 on later we can think of introducing an activator into the jaxrs
>> frontend so that it can discover custom Applications and providers
>> registered as OSGI services
>>
>> thanks, Sergey
>>
>>
>>
>>> Cheers,
>>> kl
>>>
>>> On Mon, Dec 5, 2011 at 9:39 AM, Sergey Beryozkin<sberyozkin@gmail.com**
>>>> wrote:
>>>
>>> Hi KL
>>>>
>>>>
>>>> On 03/12/11 00:50, K Fung wrote:
>>>>
>>>> Hi Sergey,
>>>>>
>>>>> Adding Dynamic-Import: * would likely resolve the issue. It also makes
>>>>> any
>>>>> package/class name resolution a lot slower because all the OSGI bundles
>>>>> will basically now be a gigantic class path. I would not be inclined to
>>>>> go
>>>>> down this route.
>>>>>
>>>>> I've uploaded a new version to CXF-3859. I've updated the code so that
>>>>> it
>>>>> compiles in Java 5 (turns out this wasn't too hard once I figured how
>>>>> ServiceMix got it to work) and now when you compile the samples pom.xml,
>>>>> it'll also compile the JAX-RS Minimal OSGI sample.
>>>>>
>>>>> The final things on my TODO list are to investigate how to avoid using
>>>>> my
>>>>> own special servlet and the removal the snapshot repository. For the
>>>>> latter, I'll likely just comment this out since it turns out that in the
>>>>> samples pom.xml, snapshots are enabled.
>>>>>
>>>>>
>>>> Please try commenting it out. It seems like it's ready for a commit,
>>>>
>>>> thanks, Sergey
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>> kl
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> Sergey Beryozkin
>>
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi, this demo is on the trunk now, I tested it and it worked fine
Thanks for this contribution,
Cheers, Sergey
On 16/12/11 22:34, K Fung wrote:
> Hello,
>
>> I'm sorry - I should've put it into 2.5.1 - but it will definitely make
> it into 2.5.2 - and I hope it would be of interest to users.
>
> No worries Sergey. Thanks for all your helpful suggestions and guidance
> while I worked on this in 2 week spurts.
>
> It took us countless hours and much frustration to figure out how to run
> CXF JAX-RS in our OSGI environment. Hopefully this sample will alleviate
> the time needed for others to get up to speed with CXF JAX-RS in their own
> environments.
>
>> In 2.5.2 on later we can think of introducing an activator into the jaxrs
> frontend so that it can discover custom Applications and providers
> registered as OSGI services
>
> Perhaps we should have a discussion on a separate thread to discuss how you
> envision seeing this? In particular, I'm wondering what's the
> baseline/environment you think this would be running. For example, right
> now there is no activator in the CXF JAX-RS bundle but what are the
> consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on
> the OSGI HttpService or do we use a built-in Jetty? Can we support both?
>
> I guess you can see that I'm pretty interested in this topic :-)
>
> On Fri, Dec 16, 2011 at 2:21 PM, Sergey Beryozkin<sb...@gmail.com>wrote:
>
>> Hi KL
>>
>>
>> On 16/12/11 22:13, K Fung wrote:
>>
>>> Hi Sergey,
>>>
>>> I've uploaded the final version (for now) to CXF-3859. I've bumped up the
>>> version to 2.5.2-SNAPSHOT and commented out the Apache Snapshot
>>> repository.
>>> Hopefully, this meets the quality bar for commit :-)
>>>
>>
>> I'm sorry - I should've put it into 2.5.1 - but it will definitely make it
>> into 2.5.2 - and I hope it would be of interest to users.
>>
>>
>>
>>> I did investigate creating the JAXRSServerFactoryBean directly (instead of
>>> subclassing CXFNonSpringJaxrsServlet). If I went down this route, I would
>>> have had to include a dependency on Jetty directly (as the traffic
>>> wouldn't
>>> be provided via the OSGI HttpService) or duplicate much of the servlet
>>> code
>>> in CXFNonSpringJaxrsServlet. In the end, I decided that it just wasn't
>>> worth it.
>>>
>>
>> Sounds right...
>> In 2.5.2 on later we can think of introducing an activator into the jaxrs
>> frontend so that it can discover custom Applications and providers
>> registered as OSGI services
>>
>> thanks, Sergey
>>
>>
>>
>>> Cheers,
>>> kl
>>>
>>> On Mon, Dec 5, 2011 at 9:39 AM, Sergey Beryozkin<sberyozkin@gmail.com**
>>>> wrote:
>>>
>>> Hi KL
>>>>
>>>>
>>>> On 03/12/11 00:50, K Fung wrote:
>>>>
>>>> Hi Sergey,
>>>>>
>>>>> Adding Dynamic-Import: * would likely resolve the issue. It also makes
>>>>> any
>>>>> package/class name resolution a lot slower because all the OSGI bundles
>>>>> will basically now be a gigantic class path. I would not be inclined to
>>>>> go
>>>>> down this route.
>>>>>
>>>>> I've uploaded a new version to CXF-3859. I've updated the code so that
>>>>> it
>>>>> compiles in Java 5 (turns out this wasn't too hard once I figured how
>>>>> ServiceMix got it to work) and now when you compile the samples pom.xml,
>>>>> it'll also compile the JAX-RS Minimal OSGI sample.
>>>>>
>>>>> The final things on my TODO list are to investigate how to avoid using
>>>>> my
>>>>> own special servlet and the removal the snapshot repository. For the
>>>>> latter, I'll likely just comment this out since it turns out that in the
>>>>> samples pom.xml, snapshots are enabled.
>>>>>
>>>>>
>>>> Please try commenting it out. It seems like it's ready for a commit,
>>>>
>>>> thanks, Sergey
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>> kl
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> Sergey Beryozkin
>>
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Activators for individual frontends
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 19/12/11 10:35, Sergey Beryozkin wrote:
> Hi KL, All,
>
> On 16/12/11 22:34, K Fung wrote:
>
>>> In 2.5.2 on later we can think of introducing an activator into the
>>> jaxrs
>> frontend so that it can discover custom Applications and providers
>> registered as OSGI services
>>
>> Perhaps we should have a discussion on a separate thread to discuss
>> how you
>> envision seeing this? In particular, I'm wondering what's the
>> baseline/environment you think this would be running. For example, right
>> now there is no activator in the CXF JAX-RS bundle but what are the
>> consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on
>> the OSGI HttpService or do we use a built-in Jetty? Can we support both?
>>
>> I guess you can see that I'm pretty interested in this topic :-)
>
> I was thinking earlier on that CXF can get a master/root activator which
> will provide BundleContext, etc to individual activators which say JAXWS
> and JAXRS frontends may offer; I think these activators will not act as
> independent activators on its own
I guess they actually may once we get individual modules OSGI-fied. But
when get cxf-bundle or cxf-rs bundle deployed these activators are plain
beans; I think they have to get hold of the root activator, which is
org.apache.cxf.bus.osgi.OSGiExtensionLocator, and get BundleContext from
it and do whatever they need to do - ServiceTrack(er) the Application
interfaces, or in case of JAX-WS listening on bundles with jaxws
annotations, something like that, etc.
IMHO that will be actually cool - will add a lot of dynamism, and it
won't interfere with say the existing deployment model where we create
blueprint or spring contexts
What I don't understand is how say OSGiExtensionLocator will pass
BundleContext to frontend-specific Activator beans.
Sergey
>, they will simply be able to react to
> the information (BundleContext for ex) that the actual root activator
> may offer.
> For example, in case of JAX-RS, this sub-activator will probably
> register ServiceTrackers and start listening for (JAX-RS) Application
> interfaces and then will create an endpoint by using HttpService or
> embedded Jetty, something like that
>
> What do you think ?
> Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Activators for individual frontends
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi KL, All,
On 16/12/11 22:34, K Fung wrote:
>> In 2.5.2 on later we can think of introducing an activator into the jaxrs
> frontend so that it can discover custom Applications and providers
> registered as OSGI services
>
> Perhaps we should have a discussion on a separate thread to discuss how you
> envision seeing this? In particular, I'm wondering what's the
> baseline/environment you think this would be running. For example, right
> now there is no activator in the CXF JAX-RS bundle but what are the
> consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on
> the OSGI HttpService or do we use a built-in Jetty? Can we support both?
>
> I guess you can see that I'm pretty interested in this topic :-)
I was thinking earlier on that CXF can get a master/root activator which
will provide BundleContext, etc to individual activators which say JAXWS
and JAXRS frontends may offer; I think these activators will not act as
independent activators on its own, they will simply be able to react to
the information (BundleContext for ex) that the actual root activator
may offer.
For example, in case of JAX-RS, this sub-activator will probably
register ServiceTrackers and start listening for (JAX-RS) Application
interfaces and then will create an endpoint by using HttpService or
embedded Jetty, something like that
What do you think ?
Sergey
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by K Fung <kf...@gmail.com>.
Hello,
> I'm sorry - I should've put it into 2.5.1 - but it will definitely make
it into 2.5.2 - and I hope it would be of interest to users.
No worries Sergey. Thanks for all your helpful suggestions and guidance
while I worked on this in 2 week spurts.
It took us countless hours and much frustration to figure out how to run
CXF JAX-RS in our OSGI environment. Hopefully this sample will alleviate
the time needed for others to get up to speed with CXF JAX-RS in their own
environments.
> In 2.5.2 on later we can think of introducing an activator into the jaxrs
frontend so that it can discover custom Applications and providers
registered as OSGI services
Perhaps we should have a discussion on a separate thread to discuss how you
envision seeing this? In particular, I'm wondering what's the
baseline/environment you think this would be running. For example, right
now there is no activator in the CXF JAX-RS bundle but what are the
consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on
the OSGI HttpService or do we use a built-in Jetty? Can we support both?
I guess you can see that I'm pretty interested in this topic :-)
On Fri, Dec 16, 2011 at 2:21 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi KL
>
>
> On 16/12/11 22:13, K Fung wrote:
>
>> Hi Sergey,
>>
>> I've uploaded the final version (for now) to CXF-3859. I've bumped up the
>> version to 2.5.2-SNAPSHOT and commented out the Apache Snapshot
>> repository.
>> Hopefully, this meets the quality bar for commit :-)
>>
>
> I'm sorry - I should've put it into 2.5.1 - but it will definitely make it
> into 2.5.2 - and I hope it would be of interest to users.
>
>
>
>> I did investigate creating the JAXRSServerFactoryBean directly (instead of
>> subclassing CXFNonSpringJaxrsServlet). If I went down this route, I would
>> have had to include a dependency on Jetty directly (as the traffic
>> wouldn't
>> be provided via the OSGI HttpService) or duplicate much of the servlet
>> code
>> in CXFNonSpringJaxrsServlet. In the end, I decided that it just wasn't
>> worth it.
>>
>
> Sounds right...
> In 2.5.2 on later we can think of introducing an activator into the jaxrs
> frontend so that it can discover custom Applications and providers
> registered as OSGI services
>
> thanks, Sergey
>
>
>
>> Cheers,
>> kl
>>
>> On Mon, Dec 5, 2011 at 9:39 AM, Sergey Beryozkin<sberyozkin@gmail.com**
>> >wrote:
>>
>> Hi KL
>>>
>>>
>>> On 03/12/11 00:50, K Fung wrote:
>>>
>>> Hi Sergey,
>>>>
>>>> Adding Dynamic-Import: * would likely resolve the issue. It also makes
>>>> any
>>>> package/class name resolution a lot slower because all the OSGI bundles
>>>> will basically now be a gigantic class path. I would not be inclined to
>>>> go
>>>> down this route.
>>>>
>>>> I've uploaded a new version to CXF-3859. I've updated the code so that
>>>> it
>>>> compiles in Java 5 (turns out this wasn't too hard once I figured how
>>>> ServiceMix got it to work) and now when you compile the samples pom.xml,
>>>> it'll also compile the JAX-RS Minimal OSGI sample.
>>>>
>>>> The final things on my TODO list are to investigate how to avoid using
>>>> my
>>>> own special servlet and the removal the snapshot repository. For the
>>>> latter, I'll likely just comment this out since it turns out that in the
>>>> samples pom.xml, snapshots are enabled.
>>>>
>>>>
>>> Please try commenting it out. It seems like it's ready for a commit,
>>>
>>> thanks, Sergey
>>>
>>>
>>>
>>>
>>> Regards,
>>>> kl
>>>>
>>>>
>>>>
>>>
>>
>
> --
> Sergey Beryozkin
>
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi KL
On 16/12/11 22:13, K Fung wrote:
> Hi Sergey,
>
> I've uploaded the final version (for now) to CXF-3859. I've bumped up the
> version to 2.5.2-SNAPSHOT and commented out the Apache Snapshot repository.
> Hopefully, this meets the quality bar for commit :-)
I'm sorry - I should've put it into 2.5.1 - but it will definitely make
it into 2.5.2 - and I hope it would be of interest to users.
>
> I did investigate creating the JAXRSServerFactoryBean directly (instead of
> subclassing CXFNonSpringJaxrsServlet). If I went down this route, I would
> have had to include a dependency on Jetty directly (as the traffic wouldn't
> be provided via the OSGI HttpService) or duplicate much of the servlet code
> in CXFNonSpringJaxrsServlet. In the end, I decided that it just wasn't
> worth it.
Sounds right...
In 2.5.2 on later we can think of introducing an activator into the
jaxrs frontend so that it can discover custom Applications and providers
registered as OSGI services
thanks, Sergey
>
> Cheers,
> kl
>
> On Mon, Dec 5, 2011 at 9:39 AM, Sergey Beryozkin<sb...@gmail.com>wrote:
>
>> Hi KL
>>
>>
>> On 03/12/11 00:50, K Fung wrote:
>>
>>> Hi Sergey,
>>>
>>> Adding Dynamic-Import: * would likely resolve the issue. It also makes any
>>> package/class name resolution a lot slower because all the OSGI bundles
>>> will basically now be a gigantic class path. I would not be inclined to go
>>> down this route.
>>>
>>> I've uploaded a new version to CXF-3859. I've updated the code so that it
>>> compiles in Java 5 (turns out this wasn't too hard once I figured how
>>> ServiceMix got it to work) and now when you compile the samples pom.xml,
>>> it'll also compile the JAX-RS Minimal OSGI sample.
>>>
>>> The final things on my TODO list are to investigate how to avoid using my
>>> own special servlet and the removal the snapshot repository. For the
>>> latter, I'll likely just comment this out since it turns out that in the
>>> samples pom.xml, snapshots are enabled.
>>>
>>
>> Please try commenting it out. It seems like it's ready for a commit,
>>
>> thanks, Sergey
>>
>>
>>
>>
>>> Regards,
>>> kl
>>>
>>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by K Fung <kf...@gmail.com>.
Hi Sergey,
I've uploaded the final version (for now) to CXF-3859. I've bumped up the
version to 2.5.2-SNAPSHOT and commented out the Apache Snapshot repository.
Hopefully, this meets the quality bar for commit :-)
I did investigate creating the JAXRSServerFactoryBean directly (instead of
subclassing CXFNonSpringJaxrsServlet). If I went down this route, I would
have had to include a dependency on Jetty directly (as the traffic wouldn't
be provided via the OSGI HttpService) or duplicate much of the servlet code
in CXFNonSpringJaxrsServlet. In the end, I decided that it just wasn't
worth it.
Cheers,
kl
On Mon, Dec 5, 2011 at 9:39 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi KL
>
>
> On 03/12/11 00:50, K Fung wrote:
>
>> Hi Sergey,
>>
>> Adding Dynamic-Import: * would likely resolve the issue. It also makes any
>> package/class name resolution a lot slower because all the OSGI bundles
>> will basically now be a gigantic class path. I would not be inclined to go
>> down this route.
>>
>> I've uploaded a new version to CXF-3859. I've updated the code so that it
>> compiles in Java 5 (turns out this wasn't too hard once I figured how
>> ServiceMix got it to work) and now when you compile the samples pom.xml,
>> it'll also compile the JAX-RS Minimal OSGI sample.
>>
>> The final things on my TODO list are to investigate how to avoid using my
>> own special servlet and the removal the snapshot repository. For the
>> latter, I'll likely just comment this out since it turns out that in the
>> samples pom.xml, snapshots are enabled.
>>
>
> Please try commenting it out. It seems like it's ready for a commit,
>
> thanks, Sergey
>
>
>
>
>> Regards,
>> kl
>>
>>
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi KL
On 03/12/11 00:50, K Fung wrote:
> Hi Sergey,
>
> Adding Dynamic-Import: * would likely resolve the issue. It also makes any
> package/class name resolution a lot slower because all the OSGI bundles
> will basically now be a gigantic class path. I would not be inclined to go
> down this route.
>
> I've uploaded a new version to CXF-3859. I've updated the code so that it
> compiles in Java 5 (turns out this wasn't too hard once I figured how
> ServiceMix got it to work) and now when you compile the samples pom.xml,
> it'll also compile the JAX-RS Minimal OSGI sample.
>
> The final things on my TODO list are to investigate how to avoid using my
> own special servlet and the removal the snapshot repository. For the
> latter, I'll likely just comment this out since it turns out that in the
> samples pom.xml, snapshots are enabled.
Please try commenting it out. It seems like it's ready for a commit,
thanks, Sergey
>
> Regards,
> kl
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by K Fung <kf...@gmail.com>.
Hi Sergey,
Adding Dynamic-Import: * would likely resolve the issue. It also makes any
package/class name resolution a lot slower because all the OSGI bundles
will basically now be a gigantic class path. I would not be inclined to go
down this route.
I've uploaded a new version to CXF-3859. I've updated the code so that it
compiles in Java 5 (turns out this wasn't too hard once I figured how
ServiceMix got it to work) and now when you compile the samples pom.xml,
it'll also compile the JAX-RS Minimal OSGI sample.
The final things on my TODO list are to investigate how to avoid using my
own special servlet and the removal the snapshot repository. For the
latter, I'll likely just comment this out since it turns out that in the
samples pom.xml, snapshots are enabled.
Regards,
kl
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi KL
On 23/11/11 16:02, K Fung wrote:
> Hi Sergey,
>
>> I'm wondering if 'minimalosgi' has to be exported ?
>
> I tried this before and it didn't work.
>
> minimalosgi has one classloader; the CXF bundle has its own
> classloader. minimalosgi's
> classloader has knowledge about CXF (due to the Import-Package declarations
> in its MANIFEST.MF) but CXF doesn't have knowledge of minimalosgi because
> it doesn't import it. Because CXF uses its own bundle classloader to
> resolve minimalosgi, it won't be able to find minimalosgi.
>
Indeed, I was still thinking about DOSGi where the dsw handler has a
dynamic import.
I'm wondering, is it possible for CXF bundle to Dynamic-Import
everything but those packages which it imports via Import-Package.
That should be safe enough or not ?
> If the JAX-RS Application class had a way to supply the Application via a
> Class<?> parameter it wouldn't be a problem because we could pass the
> Application object directly and not rely on creation via reflection inside
> CXF. Furthermore, if we had used the CXF-specific JAX-RS factory bean, I
> believe this servlet workaround wouldn't have been necessary.
>
> While experimenting with this issue, it may be possible to get around this
> by making the minimalosgi bundle a fragment bundle of the CXF bundle but I
> haven't clearly thought about the consequences of doing so yet.
>
Can be worth experimenting in some time too
Thanks, Sergey
> -kl
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend Community Coders
http://coders.talend.com/
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by K Fung <kf...@gmail.com>.
Hi Sergey,
> I'm wondering if 'minimalosgi' has to be exported ?
I tried this before and it didn't work.
minimalosgi has one classloader; the CXF bundle has its own
classloader. minimalosgi's
classloader has knowledge about CXF (due to the Import-Package declarations
in its MANIFEST.MF) but CXF doesn't have knowledge of minimalosgi because
it doesn't import it. Because CXF uses its own bundle classloader to
resolve minimalosgi, it won't be able to find minimalosgi.
If the JAX-RS Application class had a way to supply the Application via a
Class<?> parameter it wouldn't be a problem because we could pass the
Application object directly and not rely on creation via reflection inside
CXF. Furthermore, if we had used the CXF-specific JAX-RS factory bean, I
believe this servlet workaround wouldn't have been necessary.
While experimenting with this issue, it may be possible to get around this
by making the minimalosgi bundle a fragment bundle of the CXF bundle but I
haven't clearly thought about the consequences of doing so yet.
-kl
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi KL
On 19/11/11 17:20, K Fung wrote:
> Hi Sergey,
>
> I've updated CXF-3859 with my newest iteration of the code :-)
great
>
> Here is what has changed in this version...
>
> + Removed use of java.net repository as mail.jar is no longer a required
> dependency
> + Bump version to 2.5.1-SNAPSHOT
> + Use org.codehaus.mojo:exec-maven-plugin instead of run.*
> + Updated README based on the above
> ++ To compile the sample, use mvn package
> ++ To run the sample, use mvn integration-test
>
> Here are my replies to some of your comments in this month-long old
> thread...
>
> + The Apache snapshot repository remains there to ease development; it'll
> be removed in the final version
> + Yes, it does indeed seem like wsdl4j is no longer a required dependency
> on the server runtime side
OK
> + I could not remove the usage of SampleServlet. When I use just the base
> servlet, I get the following exception (which may be resolved by using
> JAXRSFactory directly but that's against the JSR-311 standard)
>
> javax.servlet.ServletException: No Application class
> minimalosgi.SampleApplication can be found
I'm wondering if 'minimalosgi' has to be exported ?
> at
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.loadClass(CXFNonSpringJaxrsServlet.java:365)
> at
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.createServerFromApplication(CXFNonSpringJaxrsServlet.java:345)
> at
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.init(CXFNonSpringJaxrsServlet.java:78)
> at
> org.apache.felix.http.base.internal.handler.ServletHandler.init(ServletHandler.java:55)
> at
> org.apache.felix.http.base.internal.handler.HandlerRegistry.addServlet(HandlerRegistry.java:65)
> at
> org.apache.felix.http.base.internal.service.HttpServiceImpl.registerServlet(HttpServiceImpl.java:95)
> at minimalosgi.Activator$1.addingService(Activator.java:58)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
> at
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
> at
> org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339)
> at
> org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273)
> at minimalosgi.Activator.start(Activator.java:77)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755)
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1175)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1153)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1146)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:456)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:263)
> Caused by: java.lang.ClassNotFoundException: minimalosgi.SampleApplication
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
> at
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at
> org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass2(ClassLoaderUtils.java:259)
> at
> org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:245)
> at
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.loadClass(CXFNonSpringJaxrsServlet.java:363)
> ... 23 more
>
> Here is where I'm focusing the next round of improvements on...
>
> + Check if code compiles correctly in Java 5 (this one is currently
> stumping me, I'll need to see how ServiceMix makes it work in Java 5)
> + Remove excess repositories from the pom.xml
> + Parent pom.xml should compile JAX-RS OSGi sample
> + Any others?
Sounds good, thanks
Sergey
>
> Regards,
> kl
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend Community Coders
http://coders.talend.com/
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by K Fung <kf...@gmail.com>.
Hi Sergey,
I've updated CXF-3859 with my newest iteration of the code :-)
Here is what has changed in this version...
+ Removed use of java.net repository as mail.jar is no longer a required
dependency
+ Bump version to 2.5.1-SNAPSHOT
+ Use org.codehaus.mojo:exec-maven-plugin instead of run.*
+ Updated README based on the above
++ To compile the sample, use mvn package
++ To run the sample, use mvn integration-test
Here are my replies to some of your comments in this month-long old
thread...
+ The Apache snapshot repository remains there to ease development; it'll
be removed in the final version
+ Yes, it does indeed seem like wsdl4j is no longer a required dependency
on the server runtime side
+ I could not remove the usage of SampleServlet. When I use just the base
servlet, I get the following exception (which may be resolved by using
JAXRSFactory directly but that's against the JSR-311 standard)
javax.servlet.ServletException: No Application class
minimalosgi.SampleApplication can be found
at
org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.loadClass(CXFNonSpringJaxrsServlet.java:365)
at
org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.createServerFromApplication(CXFNonSpringJaxrsServlet.java:345)
at
org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.init(CXFNonSpringJaxrsServlet.java:78)
at
org.apache.felix.http.base.internal.handler.ServletHandler.init(ServletHandler.java:55)
at
org.apache.felix.http.base.internal.handler.HandlerRegistry.addServlet(HandlerRegistry.java:65)
at
org.apache.felix.http.base.internal.service.HttpServiceImpl.registerServlet(HttpServiceImpl.java:95)
at minimalosgi.Activator$1.addingService(Activator.java:58)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
at
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
at
org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339)
at
org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273)
at minimalosgi.Activator.start(Activator.java:77)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1175)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1153)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1146)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:456)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:263)
Caused by: java.lang.ClassNotFoundException: minimalosgi.SampleApplication
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at
org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass2(ClassLoaderUtils.java:259)
at
org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:245)
at
org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.loadClass(CXFNonSpringJaxrsServlet.java:363)
... 23 more
Here is where I'm focusing the next round of improvements on...
+ Check if code compiles correctly in Java 5 (this one is currently
stumping me, I'll need to see how ServiceMix makes it work in Java 5)
+ Remove excess repositories from the pom.xml
+ Parent pom.xml should compile JAX-RS OSGi sample
+ Any others?
Regards,
kl
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi KL,
(sorry if it's not a complete name :-))
On 12/11/11 06:28, K Fung wrote:
> Hi Sergey,
>
> Nope, you haven't discouraged me :-) It was good feedback and I'm taking it
> in for my next round of revision.
>
> Unfortunately, I haven't had a lot of time to put into it but I should be
> able to make another pass at it toward the end of November. I'm keen on
> continuing to work on this as something to deliver in CXF.
>
> One feedback that I did have was instead of using BundleListener to listen
> for incoming bundles and registering JAX-RS things, do you think it makes
> sense for us to use OSGI declarative services (e.g., the Maven SCR bundle)
> instead to have the runtime automatically do this
> registration/deregistration of resources? However, this would be considered
> more of an enhancement to the existing CXF feature set, instead of
> something that illustrates how to use JAX-RS, right?
>
Right, that would overlap quite a bit with what DOSGi can offer, so I'd
postpone dealing with this enhancement until later... I reckon that
having a sync request for available provider services
(MessageBodyReader/Writer, etc) in Activator for them to be provided to
JAXRSServerFactoryBean at a time of creating an endpoint as well as
listening for bundles containing Application info in META-INF/services
would be fine, S META-INF/services would be fine (similarly to the way
Blueprint/Spring can be used to create endpoints when installing the
bundles)
Cheers, Sergey
> Cheers,
> kl
>
>
> On Fri, Nov 11, 2011 at 9:03 AM, Sergey Beryozkin<sb...@gmail.com>wrote:
>
>> Hi,
>>
>> how is your demo going, hope I haven't discouraged with my comments :-)
>>
>> Sergey
>>
>>
>> On 19/10/11 10:28, Sergey Beryozkin wrote:
>>
>>> By the way, at the next stage we can also probably create the Activator
>>> part in the jaxrs fronentend/osgi - this can be optionally enabled and
>>> what it will do it will probably do BundleListener and check which ones
>>> contain Applications, as well as do ServiceTracker on Application,
>>> MessageReaderWriter/Reader services, etc
>>>
>>> Cheers, Sergey
>>>
>>> On 18/10/11 14:18, Sergey Beryozkin wrote:
>>>
>>>> Hi
>>>>
>>>> Thanks for this patch, I think it's a nice interesting example, shows
>>>> the bare Activator and ServiceTracker in action...
>>>>
>>>> Please see comments inline
>>>>
>>>> On 18/10/11 05:28, K Fung wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've uploaded the initial code sample to
>>>>> https://issues.apache.org/**jira/browse/CXF-3859<https://issues.apache.org/jira/browse/CXF-3859>to garner the first
>>>>> round of
>>>>> feedback. Per request, it includes a README to explains how it works.
>>>>>
>>>>> In particular, I'm looking feedback for the following issues:
>>>>>
>>>>> - What's your opinion to using the Application model instead of
>>>>> JAXRSServerFactoryBean directly?
>>>>>
>>>>
>>>> One thing I noted that you introduce a SampleServlet, but
>>>> CXFNonSpringJAXRSServlet can handle it itself. CXFNonSpringJAXRSServlet
>>>> will also make sure Application instances can get JAX-RS contexts
>>>> injected if needed and Applications themselves can be injected into
>>>> resource classes which is all has to be supported in JAX-RS 1.1.
>>>> Using Applications is probably better for the example, but using
>>>> JAXRSServerFactoryBean will provide more options (such as applying
>>>> external models to non-annotated classes).
>>>>
>>>> Actually, I'm seeing the READme, CXFNonSpringJAXRSServlet should still
>>>> be capable though, as it delegates via ResourceUtils to load the
>>>> Application classes, that should work ?
>>>>
>>>>
>>>> - Is it okay not to use the latest Eclipse Equinox? I'm not using the
>>>>> latest
>>>>> Eclipse Equinox at the moment because 1) it has issues with Felix due
>>>>> to use
>>>>> of generics and 2) the required services bundle is not registered in
>>>>> Maven
>>>>>
>>>>
>>>> probably OK for the purpose of the demo, perhaps README can clarify
>>>> that. What about those java.net and snapshots repositories though, can
>>>> we avoid using them ?
>>>>
>>>> - What do you think about using Apache Felix's File Install to install
>>>>> the
>>>>> bundles?
>>>>>
>>>>
>>>> Why not, Karaf is probably using that one too
>>>>
>>>> - Does the README require further enhancement or more description or
>>>>> perhaps
>>>>> more documentation is necessary within the sample itself?
>>>>>
>>>>>
>>>> READMe is fine but I'm wondering if we should make it sound a bit more
>>>> optimistic :-), we just have JAX-RS demos working in Karaf :-). In the
>>>> introduction I'd only have:
>>>>
>>>> "This sample demonstrates the minimal amount of bundles necessary to get
>>>> a sample that uses CXF's JAX-RS implementation to work correctly in most
>>>> OSGI environments", etc...
>>>>
>>>>
>>>> Before I declare it fit for prime time, I would like to work on the
>>>>> following things:
>>>>>
>>>>> - Check if sample runs correctly on Java 5
>>>>> - Check if sample should be compiled with other samples when running
>>>>> maven
>>>>> on the parent pom
>>>>>
>>>>
>>>> Please do...
>>>>
>>>> - Provide a run.sh sample (in addition to the current run.bat)
>>>>>
>>>>
>>>> Can we make that run using a maven profile ? Instead of having
>>>> run.bat/sh ? may be you can copy& paste the relevant "server" profile
>>>> from jaxrs/spring-security or basic
>>>>
>>>> - Provide an enhancement that includes the use of Apache Abdera to
>>>>> show the
>>>>> (optional) import of the Abdera bundles
>>>>>
>>>>> I think the latest Abdera bundle is a bit broken, recall Dan mentioning
>>>> it - may've been fixed already. I would not be worried about Abdera in
>>>> OSGI at the moment.
>>>>
>>>> Actually see that you exclude wsdl4j which does indicate
>>>>
>>>> https://issues.apache.org/**jira/browse/CXF-3021<https://issues.apache.org/jira/browse/CXF-3021>
>>>> may've been fixed after all, re the deps on the server side
>>>>
>>>> I look forward to hearing what all of you have to say ... the good,
>>>>> the bad,
>>>>> and the ugly :-)
>>>>>
>>>>>
>>>> Great stuff, thanks :-).
>>>> One possible enhancement to the sample, get plain WebClient consuming
>>>> the published service, using main() or from another bundle, whatever is
>>>> simpler
>>>>
>>>> Sergey
>>>>
>>>> Regards,
>>>>> kl
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by K Fung <kf...@gmail.com>.
Hi Sergey,
Nope, you haven't discouraged me :-) It was good feedback and I'm taking it
in for my next round of revision.
Unfortunately, I haven't had a lot of time to put into it but I should be
able to make another pass at it toward the end of November. I'm keen on
continuing to work on this as something to deliver in CXF.
One feedback that I did have was instead of using BundleListener to listen
for incoming bundles and registering JAX-RS things, do you think it makes
sense for us to use OSGI declarative services (e.g., the Maven SCR bundle)
instead to have the runtime automatically do this
registration/deregistration of resources? However, this would be considered
more of an enhancement to the existing CXF feature set, instead of
something that illustrates how to use JAX-RS, right?
Cheers,
kl
On Fri, Nov 11, 2011 at 9:03 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi,
>
> how is your demo going, hope I haven't discouraged with my comments :-)
>
> Sergey
>
>
> On 19/10/11 10:28, Sergey Beryozkin wrote:
>
>> By the way, at the next stage we can also probably create the Activator
>> part in the jaxrs fronentend/osgi - this can be optionally enabled and
>> what it will do it will probably do BundleListener and check which ones
>> contain Applications, as well as do ServiceTracker on Application,
>> MessageReaderWriter/Reader services, etc
>>
>> Cheers, Sergey
>>
>> On 18/10/11 14:18, Sergey Beryozkin wrote:
>>
>>> Hi
>>>
>>> Thanks for this patch, I think it's a nice interesting example, shows
>>> the bare Activator and ServiceTracker in action...
>>>
>>> Please see comments inline
>>>
>>> On 18/10/11 05:28, K Fung wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've uploaded the initial code sample to
>>>> https://issues.apache.org/**jira/browse/CXF-3859<https://issues.apache.org/jira/browse/CXF-3859>to garner the first
>>>> round of
>>>> feedback. Per request, it includes a README to explains how it works.
>>>>
>>>> In particular, I'm looking feedback for the following issues:
>>>>
>>>> - What's your opinion to using the Application model instead of
>>>> JAXRSServerFactoryBean directly?
>>>>
>>>
>>> One thing I noted that you introduce a SampleServlet, but
>>> CXFNonSpringJAXRSServlet can handle it itself. CXFNonSpringJAXRSServlet
>>> will also make sure Application instances can get JAX-RS contexts
>>> injected if needed and Applications themselves can be injected into
>>> resource classes which is all has to be supported in JAX-RS 1.1.
>>> Using Applications is probably better for the example, but using
>>> JAXRSServerFactoryBean will provide more options (such as applying
>>> external models to non-annotated classes).
>>>
>>> Actually, I'm seeing the READme, CXFNonSpringJAXRSServlet should still
>>> be capable though, as it delegates via ResourceUtils to load the
>>> Application classes, that should work ?
>>>
>>>
>>> - Is it okay not to use the latest Eclipse Equinox? I'm not using the
>>>> latest
>>>> Eclipse Equinox at the moment because 1) it has issues with Felix due
>>>> to use
>>>> of generics and 2) the required services bundle is not registered in
>>>> Maven
>>>>
>>>
>>> probably OK for the purpose of the demo, perhaps README can clarify
>>> that. What about those java.net and snapshots repositories though, can
>>> we avoid using them ?
>>>
>>> - What do you think about using Apache Felix's File Install to install
>>>> the
>>>> bundles?
>>>>
>>>
>>> Why not, Karaf is probably using that one too
>>>
>>> - Does the README require further enhancement or more description or
>>>> perhaps
>>>> more documentation is necessary within the sample itself?
>>>>
>>>>
>>> READMe is fine but I'm wondering if we should make it sound a bit more
>>> optimistic :-), we just have JAX-RS demos working in Karaf :-). In the
>>> introduction I'd only have:
>>>
>>> "This sample demonstrates the minimal amount of bundles necessary to get
>>> a sample that uses CXF's JAX-RS implementation to work correctly in most
>>> OSGI environments", etc...
>>>
>>>
>>> Before I declare it fit for prime time, I would like to work on the
>>>> following things:
>>>>
>>>> - Check if sample runs correctly on Java 5
>>>> - Check if sample should be compiled with other samples when running
>>>> maven
>>>> on the parent pom
>>>>
>>>
>>> Please do...
>>>
>>> - Provide a run.sh sample (in addition to the current run.bat)
>>>>
>>>
>>> Can we make that run using a maven profile ? Instead of having
>>> run.bat/sh ? may be you can copy & paste the relevant "server" profile
>>> from jaxrs/spring-security or basic
>>>
>>> - Provide an enhancement that includes the use of Apache Abdera to
>>>> show the
>>>> (optional) import of the Abdera bundles
>>>>
>>>> I think the latest Abdera bundle is a bit broken, recall Dan mentioning
>>> it - may've been fixed already. I would not be worried about Abdera in
>>> OSGI at the moment.
>>>
>>> Actually see that you exclude wsdl4j which does indicate
>>>
>>> https://issues.apache.org/**jira/browse/CXF-3021<https://issues.apache.org/jira/browse/CXF-3021>
>>> may've been fixed after all, re the deps on the server side
>>>
>>> I look forward to hearing what all of you have to say ... the good,
>>>> the bad,
>>>> and the ugly :-)
>>>>
>>>>
>>> Great stuff, thanks :-).
>>> One possible enhancement to the sample, get plain WebClient consuming
>>> the published service, using main() or from another bundle, whatever is
>>> simpler
>>>
>>> Sergey
>>>
>>> Regards,
>>>> kl
>>>>
>>>>
>>>
>>
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
how is your demo going, hope I haven't discouraged with my comments :-)
Sergey
On 19/10/11 10:28, Sergey Beryozkin wrote:
> By the way, at the next stage we can also probably create the Activator
> part in the jaxrs fronentend/osgi - this can be optionally enabled and
> what it will do it will probably do BundleListener and check which ones
> contain Applications, as well as do ServiceTracker on Application,
> MessageReaderWriter/Reader services, etc
>
> Cheers, Sergey
>
> On 18/10/11 14:18, Sergey Beryozkin wrote:
>> Hi
>>
>> Thanks for this patch, I think it's a nice interesting example, shows
>> the bare Activator and ServiceTracker in action...
>>
>> Please see comments inline
>>
>> On 18/10/11 05:28, K Fung wrote:
>>> Hi all,
>>>
>>> I've uploaded the initial code sample to
>>> https://issues.apache.org/jira/browse/CXF-3859 to garner the first
>>> round of
>>> feedback. Per request, it includes a README to explains how it works.
>>>
>>> In particular, I'm looking feedback for the following issues:
>>>
>>> - What's your opinion to using the Application model instead of
>>> JAXRSServerFactoryBean directly?
>>
>> One thing I noted that you introduce a SampleServlet, but
>> CXFNonSpringJAXRSServlet can handle it itself. CXFNonSpringJAXRSServlet
>> will also make sure Application instances can get JAX-RS contexts
>> injected if needed and Applications themselves can be injected into
>> resource classes which is all has to be supported in JAX-RS 1.1.
>> Using Applications is probably better for the example, but using
>> JAXRSServerFactoryBean will provide more options (such as applying
>> external models to non-annotated classes).
>>
>> Actually, I'm seeing the READme, CXFNonSpringJAXRSServlet should still
>> be capable though, as it delegates via ResourceUtils to load the
>> Application classes, that should work ?
>>
>>
>>> - Is it okay not to use the latest Eclipse Equinox? I'm not using the
>>> latest
>>> Eclipse Equinox at the moment because 1) it has issues with Felix due
>>> to use
>>> of generics and 2) the required services bundle is not registered in
>>> Maven
>>
>> probably OK for the purpose of the demo, perhaps README can clarify
>> that. What about those java.net and snapshots repositories though, can
>> we avoid using them ?
>>
>>> - What do you think about using Apache Felix's File Install to install
>>> the
>>> bundles?
>>
>> Why not, Karaf is probably using that one too
>>
>>> - Does the README require further enhancement or more description or
>>> perhaps
>>> more documentation is necessary within the sample itself?
>>>
>>
>> READMe is fine but I'm wondering if we should make it sound a bit more
>> optimistic :-), we just have JAX-RS demos working in Karaf :-). In the
>> introduction I'd only have:
>>
>> "This sample demonstrates the minimal amount of bundles necessary to get
>> a sample that uses CXF's JAX-RS implementation to work correctly in most
>> OSGI environments", etc...
>>
>>
>>> Before I declare it fit for prime time, I would like to work on the
>>> following things:
>>>
>>> - Check if sample runs correctly on Java 5
>>> - Check if sample should be compiled with other samples when running
>>> maven
>>> on the parent pom
>>
>> Please do...
>>
>>> - Provide a run.sh sample (in addition to the current run.bat)
>>
>> Can we make that run using a maven profile ? Instead of having
>> run.bat/sh ? may be you can copy & paste the relevant "server" profile
>> from jaxrs/spring-security or basic
>>
>>> - Provide an enhancement that includes the use of Apache Abdera to
>>> show the
>>> (optional) import of the Abdera bundles
>>>
>> I think the latest Abdera bundle is a bit broken, recall Dan mentioning
>> it - may've been fixed already. I would not be worried about Abdera in
>> OSGI at the moment.
>>
>> Actually see that you exclude wsdl4j which does indicate
>>
>> https://issues.apache.org/jira/browse/CXF-3021
>> may've been fixed after all, re the deps on the server side
>>
>>> I look forward to hearing what all of you have to say ... the good,
>>> the bad,
>>> and the ugly :-)
>>>
>>
>> Great stuff, thanks :-).
>> One possible enhancement to the sample, get plain WebClient consuming
>> the published service, using main() or from another bundle, whatever is
>> simpler
>>
>> Sergey
>>
>>> Regards,
>>> kl
>>>
>>
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
By the way, at the next stage we can also probably create the Activator
part in the jaxrs fronentend/osgi - this can be optionally enabled and
what it will do it will probably do BundleListener and check which ones
contain Applications, as well as do ServiceTracker on Application,
MessageReaderWriter/Reader services, etc
Cheers, Sergey
On 18/10/11 14:18, Sergey Beryozkin wrote:
> Hi
>
> Thanks for this patch, I think it's a nice interesting example, shows
> the bare Activator and ServiceTracker in action...
>
> Please see comments inline
>
> On 18/10/11 05:28, K Fung wrote:
>> Hi all,
>>
>> I've uploaded the initial code sample to
>> https://issues.apache.org/jira/browse/CXF-3859 to garner the first
>> round of
>> feedback. Per request, it includes a README to explains how it works.
>>
>> In particular, I'm looking feedback for the following issues:
>>
>> - What's your opinion to using the Application model instead of
>> JAXRSServerFactoryBean directly?
>
> One thing I noted that you introduce a SampleServlet, but
> CXFNonSpringJAXRSServlet can handle it itself. CXFNonSpringJAXRSServlet
> will also make sure Application instances can get JAX-RS contexts
> injected if needed and Applications themselves can be injected into
> resource classes which is all has to be supported in JAX-RS 1.1.
> Using Applications is probably better for the example, but using
> JAXRSServerFactoryBean will provide more options (such as applying
> external models to non-annotated classes).
>
> Actually, I'm seeing the READme, CXFNonSpringJAXRSServlet should still
> be capable though, as it delegates via ResourceUtils to load the
> Application classes, that should work ?
>
>
>> - Is it okay not to use the latest Eclipse Equinox? I'm not using the
>> latest
>> Eclipse Equinox at the moment because 1) it has issues with Felix due
>> to use
>> of generics and 2) the required services bundle is not registered in
>> Maven
>
> probably OK for the purpose of the demo, perhaps README can clarify
> that. What about those java.net and snapshots repositories though, can
> we avoid using them ?
>
>> - What do you think about using Apache Felix's File Install to install
>> the
>> bundles?
>
> Why not, Karaf is probably using that one too
>
>> - Does the README require further enhancement or more description or
>> perhaps
>> more documentation is necessary within the sample itself?
>>
>
> READMe is fine but I'm wondering if we should make it sound a bit more
> optimistic :-), we just have JAX-RS demos working in Karaf :-). In the
> introduction I'd only have:
>
> "This sample demonstrates the minimal amount of bundles necessary to get
> a sample that uses CXF's JAX-RS implementation to work correctly in most
> OSGI environments", etc...
>
>
>> Before I declare it fit for prime time, I would like to work on the
>> following things:
>>
>> - Check if sample runs correctly on Java 5
>> - Check if sample should be compiled with other samples when running
>> maven
>> on the parent pom
>
> Please do...
>
>> - Provide a run.sh sample (in addition to the current run.bat)
>
> Can we make that run using a maven profile ? Instead of having
> run.bat/sh ? may be you can copy & paste the relevant "server" profile
> from jaxrs/spring-security or basic
>
>> - Provide an enhancement that includes the use of Apache Abdera to
>> show the
>> (optional) import of the Abdera bundles
>>
> I think the latest Abdera bundle is a bit broken, recall Dan mentioning
> it - may've been fixed already. I would not be worried about Abdera in
> OSGI at the moment.
>
> Actually see that you exclude wsdl4j which does indicate
>
> https://issues.apache.org/jira/browse/CXF-3021
> may've been fixed after all, re the deps on the server side
>
>> I look forward to hearing what all of you have to say ... the good,
>> the bad,
>> and the ugly :-)
>>
>
> Great stuff, thanks :-).
> One possible enhancement to the sample, get plain WebClient consuming
> the published service, using main() or from another bundle, whatever is
> simpler
>
> Sergey
>
>> Regards,
>> kl
>>
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
Thanks for this patch, I think it's a nice interesting example, shows
the bare Activator and ServiceTracker in action...
Please see comments inline
On 18/10/11 05:28, K Fung wrote:
> Hi all,
>
> I've uploaded the initial code sample to
> https://issues.apache.org/jira/browse/CXF-3859 to garner the first round of
> feedback. Per request, it includes a README to explains how it works.
>
> In particular, I'm looking feedback for the following issues:
>
> - What's your opinion to using the Application model instead of
> JAXRSServerFactoryBean directly?
One thing I noted that you introduce a SampleServlet, but
CXFNonSpringJAXRSServlet can handle it itself. CXFNonSpringJAXRSServlet
will also make sure Application instances can get JAX-RS contexts
injected if needed and Applications themselves can be injected into
resource classes which is all has to be supported in JAX-RS 1.1.
Using Applications is probably better for the example, but using
JAXRSServerFactoryBean will provide more options (such as applying
external models to non-annotated classes).
Actually, I'm seeing the READme, CXFNonSpringJAXRSServlet should still
be capable though, as it delegates via ResourceUtils to load the
Application classes, that should work ?
> - Is it okay not to use the latest Eclipse Equinox? I'm not using the latest
> Eclipse Equinox at the moment because 1) it has issues with Felix due to use
> of generics and 2) the required services bundle is not registered in Maven
probably OK for the purpose of the demo, perhaps README can clarify
that. What about those java.net and snapshots repositories though, can
we avoid using them ?
> - What do you think about using Apache Felix's File Install to install the
> bundles?
Why not, Karaf is probably using that one too
> - Does the README require further enhancement or more description or perhaps
> more documentation is necessary within the sample itself?
>
READMe is fine but I'm wondering if we should make it sound a bit more
optimistic :-), we just have JAX-RS demos working in Karaf :-). In the
introduction I'd only have:
"This sample demonstrates the minimal amount of bundles necessary to get
a sample that uses CXF's JAX-RS implementation to work correctly in
most OSGI environments", etc...
> Before I declare it fit for prime time, I would like to work on the
> following things:
>
> - Check if sample runs correctly on Java 5
> - Check if sample should be compiled with other samples when running maven
> on the parent pom
Please do...
> - Provide a run.sh sample (in addition to the current run.bat)
Can we make that run using a maven profile ? Instead of having
run.bat/sh ? may be you can copy & paste the relevant "server" profile
from jaxrs/spring-security or basic
> - Provide an enhancement that includes the use of Apache Abdera to show the
> (optional) import of the Abdera bundles
>
I think the latest Abdera bundle is a bit broken, recall Dan mentioning
it - may've been fixed already. I would not be worried about Abdera in
OSGI at the moment.
Actually see that you exclude wsdl4j which does indicate
https://issues.apache.org/jira/browse/CXF-3021
may've been fixed after all, re the deps on the server side
> I look forward to hearing what all of you have to say ... the good, the bad,
> and the ugly :-)
>
Great stuff, thanks :-).
One possible enhancement to the sample, get plain WebClient consuming
the published service, using main() or from another bundle, whatever is
simpler
Sergey
> Regards,
> kl
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by K Fung <kf...@gmail.com>.
Hi all,
I've uploaded the initial code sample to
https://issues.apache.org/jira/browse/CXF-3859 to garner the first round of
feedback. Per request, it includes a README to explains how it works.
In particular, I'm looking feedback for the following issues:
- What's your opinion to using the Application model instead of
JAXRSServerFactoryBean directly?
- Is it okay not to use the latest Eclipse Equinox? I'm not using the latest
Eclipse Equinox at the moment because 1) it has issues with Felix due to use
of generics and 2) the required services bundle is not registered in Maven
- What do you think about using Apache Felix's File Install to install the
bundles?
- Does the README require further enhancement or more description or perhaps
more documentation is necessary within the sample itself?
Before I declare it fit for prime time, I would like to work on the
following things:
- Check if sample runs correctly on Java 5
- Check if sample should be compiled with other samples when running maven
on the parent pom
- Provide a run.sh sample (in addition to the current run.bat)
- Provide an enhancement that includes the use of Apache Abdera to show the
(optional) import of the Abdera bundles
I look forward to hearing what all of you have to say ... the good, the bad,
and the ugly :-)
Regards,
kl
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by K Fung <kf...@gmail.com>.
Hi Sergey,
I should clarify that I'm not avoiding the use of Apache ServiceMix
bundles - in fact we do have to use them.
I'm just illustrating what's the minimal set need to get JAX-RS running.
Cheers,
kl
On Sun, Oct 9, 2011 at 8:29 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi -
>
> On 07/10/11 21:53, K Fung wrote:
>>
>> Hi Sergey,
>>
>> Thank you for the feedback.
>>
>> I'll work on getting the code compilable in the examples folder and
>> then submit a JIRA task to track its submission into trunk. I'll
>> definitely include a README to talk about it does (which I presume
>> will be the basis for the wiki page).
>>
>> The initial scope for the the sample code would be to demonstrate a
>> "Hello World" type of application but I would definitely want to
>> extend it to include some of the more common features utilized (e.g.,
>> JAXB) so that consuming teams don't need to go through as much work as
>> I did to initially get this code to work.
>
> Yes, please create a JIRA and attach the contribution there and we can then
> review what is the best way to handle it.
>
>>
>> FYI, this example works fine in both Eclipse Equinox and Apache Felix
>> so it isn't tied to a particular OSGI runtime.
>>
>
> Sounds good. FYI, the demos I mentioned run in Karaf which can use either
> Equinox or Felix. I'm wondering though how the use of ServiceMix bundles can
> be avoided as they are just proper OSGI bundles, so look forward to seeing
> the example :-)
>
> Thanks, Sergey
>
>
>
>> Regards,
>> kl
>>
>> On Fri, Oct 7, 2011 at 1:29 PM, Sergey Beryozkin<sb...@gmail.com>
>> wrote:
>>>
>>> Hi
>>>
>>> I think I like all the options you suggested :-)
>>>
>>> Please see comments inline
>>>
>>> On 07/10/11 19:51, K Fung wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> (long time lurker here ... thought it was about them we started to
>>>> contribute something back)
>>>>
>>>> As everyone who's played with CXF JAX-RS and OSGI knows, it's not too
>>>> easy to get CXF and OSGI to co-operate outside of the Apache
>>>> ServiceMix bundle/example.
>>>>
>>>> I've been sitting on a CXF JAX-RS OSGI example for the last few months
>>>> that illustrates the minimal dependencies needed for CXF JAX-RS OSGI
>>>> to work correctly but I don't know what's the best way to distribute
>>>> it.
>>>>
>>>> As it's a combination of both CXF JAX-RS code and ServiceMix code,
>>>> it's in the middle ground where it neither fits with ServiceMix nor
>>>> CXF perfectly. So I'm looking for feedback about where you think this
>>>> sample would fit best?
>>>>
>>>> Some thoughts I had...
>>>>
>>>> 1) As an example in the CXF distribution
>>>
>>> This one seems like the best candidate initially - we can have a look
>>> then
>>> and see if some of the contribution which is generic enough can be pushed
>>> to
>>> the trunk(s)
>>>
>>>> 2) As an entry in the CXF wiki
>>>> (https://cwiki.apache.org/confluence/display/CXF)
>>>
>>> Sounds good - if the contribution will have a Readme then I can help with
>>> creating a wiki page too
>>>
>>>> 3) As just a blog entry somewhere in the world wide web where it may
>>>> be referenced
>>>>
>>> +1 :-)
>>>
>>>> Do any of you have any thoughts? Would it even be welcomed in the CXF
>>>> trunk?
>>>>
>>> Dan has been doing a lot of work with regard to the OSGI-fication of CXF.
>>> I
>>> think sooner or later most of CXF core modules will be very OSGI
>>> proactive/aware. One thing I hope the jaxrs module will be able to do is
>>> to
>>> discover JAX-RS Application or Provider services (the latter is possible
>>> with DOSGi CXF), and do some other cool dynamic OSGI things. So if we can
>>> identify some generally useful code then we can start pushing it to the
>>> trunk.
>>>
>>> All the JAX-RS demos we ship with the Talend Examples distro are
>>> OSGI-aware
>>> but indeed they all do depend on ServiceMix bundles
>>>
>>> Many thanks, Sergey
>>>
>>>> Regards,
>>>> kl
>>>
>>>
>
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi -
On 07/10/11 21:53, K Fung wrote:
> Hi Sergey,
>
> Thank you for the feedback.
>
> I'll work on getting the code compilable in the examples folder and
> then submit a JIRA task to track its submission into trunk. I'll
> definitely include a README to talk about it does (which I presume
> will be the basis for the wiki page).
>
> The initial scope for the the sample code would be to demonstrate a
> "Hello World" type of application but I would definitely want to
> extend it to include some of the more common features utilized (e.g.,
> JAXB) so that consuming teams don't need to go through as much work as
> I did to initially get this code to work.
Yes, please create a JIRA and attach the contribution there and we can
then review what is the best way to handle it.
>
> FYI, this example works fine in both Eclipse Equinox and Apache Felix
> so it isn't tied to a particular OSGI runtime.
>
Sounds good. FYI, the demos I mentioned run in Karaf which can use
either Equinox or Felix. I'm wondering though how the use of ServiceMix
bundles can be avoided as they are just proper OSGI bundles, so look
forward to seeing the example :-)
Thanks, Sergey
> Regards,
> kl
>
> On Fri, Oct 7, 2011 at 1:29 PM, Sergey Beryozkin<sb...@gmail.com> wrote:
>> Hi
>>
>> I think I like all the options you suggested :-)
>>
>> Please see comments inline
>>
>> On 07/10/11 19:51, K Fung wrote:
>>>
>>> Hi everyone,
>>>
>>> (long time lurker here ... thought it was about them we started to
>>> contribute something back)
>>>
>>> As everyone who's played with CXF JAX-RS and OSGI knows, it's not too
>>> easy to get CXF and OSGI to co-operate outside of the Apache
>>> ServiceMix bundle/example.
>>>
>>> I've been sitting on a CXF JAX-RS OSGI example for the last few months
>>> that illustrates the minimal dependencies needed for CXF JAX-RS OSGI
>>> to work correctly but I don't know what's the best way to distribute
>>> it.
>>>
>>> As it's a combination of both CXF JAX-RS code and ServiceMix code,
>>> it's in the middle ground where it neither fits with ServiceMix nor
>>> CXF perfectly. So I'm looking for feedback about where you think this
>>> sample would fit best?
>>>
>>> Some thoughts I had...
>>>
>>> 1) As an example in the CXF distribution
>>
>> This one seems like the best candidate initially - we can have a look then
>> and see if some of the contribution which is generic enough can be pushed to
>> the trunk(s)
>>
>>> 2) As an entry in the CXF wiki
>>> (https://cwiki.apache.org/confluence/display/CXF)
>>
>> Sounds good - if the contribution will have a Readme then I can help with
>> creating a wiki page too
>>
>>> 3) As just a blog entry somewhere in the world wide web where it may
>>> be referenced
>>>
>> +1 :-)
>>
>>> Do any of you have any thoughts? Would it even be welcomed in the CXF
>>> trunk?
>>>
>> Dan has been doing a lot of work with regard to the OSGI-fication of CXF. I
>> think sooner or later most of CXF core modules will be very OSGI
>> proactive/aware. One thing I hope the jaxrs module will be able to do is to
>> discover JAX-RS Application or Provider services (the latter is possible
>> with DOSGi CXF), and do some other cool dynamic OSGI things. So if we can
>> identify some generally useful code then we can start pushing it to the
>> trunk.
>>
>> All the JAX-RS demos we ship with the Talend Examples distro are OSGI-aware
>> but indeed they all do depend on ServiceMix bundles
>>
>> Many thanks, Sergey
>>
>>> Regards,
>>> kl
>>
>>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by K Fung <kf...@gmail.com>.
Hi Sergey,
Thank you for the feedback.
I'll work on getting the code compilable in the examples folder and
then submit a JIRA task to track its submission into trunk. I'll
definitely include a README to talk about it does (which I presume
will be the basis for the wiki page).
The initial scope for the the sample code would be to demonstrate a
"Hello World" type of application but I would definitely want to
extend it to include some of the more common features utilized (e.g.,
JAXB) so that consuming teams don't need to go through as much work as
I did to initially get this code to work.
FYI, this example works fine in both Eclipse Equinox and Apache Felix
so it isn't tied to a particular OSGI runtime.
Regards,
kl
On Fri, Oct 7, 2011 at 1:29 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi
>
> I think I like all the options you suggested :-)
>
> Please see comments inline
>
> On 07/10/11 19:51, K Fung wrote:
>>
>> Hi everyone,
>>
>> (long time lurker here ... thought it was about them we started to
>> contribute something back)
>>
>> As everyone who's played with CXF JAX-RS and OSGI knows, it's not too
>> easy to get CXF and OSGI to co-operate outside of the Apache
>> ServiceMix bundle/example.
>>
>> I've been sitting on a CXF JAX-RS OSGI example for the last few months
>> that illustrates the minimal dependencies needed for CXF JAX-RS OSGI
>> to work correctly but I don't know what's the best way to distribute
>> it.
>>
>> As it's a combination of both CXF JAX-RS code and ServiceMix code,
>> it's in the middle ground where it neither fits with ServiceMix nor
>> CXF perfectly. So I'm looking for feedback about where you think this
>> sample would fit best?
>>
>> Some thoughts I had...
>>
>> 1) As an example in the CXF distribution
>
> This one seems like the best candidate initially - we can have a look then
> and see if some of the contribution which is generic enough can be pushed to
> the trunk(s)
>
>> 2) As an entry in the CXF wiki
>> (https://cwiki.apache.org/confluence/display/CXF)
>
> Sounds good - if the contribution will have a Readme then I can help with
> creating a wiki page too
>
>> 3) As just a blog entry somewhere in the world wide web where it may
>> be referenced
>>
> +1 :-)
>
>> Do any of you have any thoughts? Would it even be welcomed in the CXF
>> trunk?
>>
> Dan has been doing a lot of work with regard to the OSGI-fication of CXF. I
> think sooner or later most of CXF core modules will be very OSGI
> proactive/aware. One thing I hope the jaxrs module will be able to do is to
> discover JAX-RS Application or Provider services (the latter is possible
> with DOSGi CXF), and do some other cool dynamic OSGI things. So if we can
> identify some generally useful code then we can start pushing it to the
> trunk.
>
> All the JAX-RS demos we ship with the Talend Examples distro are OSGI-aware
> but indeed they all do depend on ServiceMix bundles
>
> Many thanks, Sergey
>
>> Regards,
>> kl
>
>
Re: How to contribue a CXF JAX-RS OSGi Sample?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
I think I like all the options you suggested :-)
Please see comments inline
On 07/10/11 19:51, K Fung wrote:
> Hi everyone,
>
> (long time lurker here ... thought it was about them we started to
> contribute something back)
>
> As everyone who's played with CXF JAX-RS and OSGI knows, it's not too
> easy to get CXF and OSGI to co-operate outside of the Apache
> ServiceMix bundle/example.
>
> I've been sitting on a CXF JAX-RS OSGI example for the last few months
> that illustrates the minimal dependencies needed for CXF JAX-RS OSGI
> to work correctly but I don't know what's the best way to distribute
> it.
>
> As it's a combination of both CXF JAX-RS code and ServiceMix code,
> it's in the middle ground where it neither fits with ServiceMix nor
> CXF perfectly. So I'm looking for feedback about where you think this
> sample would fit best?
>
> Some thoughts I had...
>
> 1) As an example in the CXF distribution
This one seems like the best candidate initially - we can have a look
then and see if some of the contribution which is generic enough can be
pushed to the trunk(s)
> 2) As an entry in the CXF wiki (https://cwiki.apache.org/confluence/display/CXF)
Sounds good - if the contribution will have a Readme then I can help
with creating a wiki page too
> 3) As just a blog entry somewhere in the world wide web where it may
> be referenced
>
+1 :-)
> Do any of you have any thoughts? Would it even be welcomed in the CXF trunk?
>
Dan has been doing a lot of work with regard to the OSGI-fication of
CXF. I think sooner or later most of CXF core modules will be very OSGI
proactive/aware. One thing I hope the jaxrs module will be able to do is
to discover JAX-RS Application or Provider services (the latter is
possible with DOSGi CXF), and do some other cool dynamic OSGI things. So
if we can identify some generally useful code then we can start pushing
it to the trunk.
All the JAX-RS demos we ship with the Talend Examples distro are
OSGI-aware but indeed they all do depend on ServiceMix bundles
Many thanks, Sergey
> Regards,
> kl