Re: How to contribue a CXF JAX-RS OSGi Sample?

[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: Activators for individual frontends

[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

[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?

[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?

[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

[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

[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?

[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?

[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?

[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?

[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
>