You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Raul Kripalani <ra...@evosent.com> on 2013/01/11 13:53:09 UTC
CXFRS: Share port number across bundles
Hi all,
Quick question.
Has anyone tried to run several CXFRS consumers on different bundles
binding to the same port (e.g. 9007), where each consumer has a different
root resource stemming from a different path?
*Bundle A:*
<cxf:rsServer id="rsServer"
address="http://0.0.0.0:9007"
serviceClass="com.mycompany.ResourceA" />
*Bundle B:*
<cxf:rsServer id="rsServer"
address="http://0.0.0.0:9007"
serviceClass="com.mycompany.ResourceB" />
*ResourceA* annotated with @Path("/resourceA")
*ResourceB* annotated with @Path("/resourceB")
It looks like the latest bundle to initialise gets ownership of the port,
i.e. they become mutually exclusive.
Any ideas on how to make this work? Do you think this question is more on
the Camel or CXF side of the fence?
Thanks!
*Raúl Kripalani*
Apache Camel Committer
Enterprise Architect, Program Manager, Open Source Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>
Re: CXFRS: Share port number across bundles
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 15/01/13 16:46, Martin Stiborský wrote:
> Hi,
> thanks for answers and the idea, it sounds really good, I'll go this way
> definitelly.
> Right now, I have done that static - hardcoded, in my blueprint.xml:
>
> <camel-cxf:rsServer id="rootServer" address="${server.rest.base}/"
> serviceClass="com.foo.contextA"/>
> <camel-cxf:rsServer id="fooServer" address="${server.rest.base}/contextA/"
> serviceClass="com.foo.contextB"/>
> <camel-cxf:rsServer id="barServer" address="${server.rest.base}/contextB/"
> serviceClass="com.foo.contextC" />
>
> But the "dynamic" solution sound quite better and I like it and it's
> logical, thanks to the nature of a OSGi module.
Indeed, the above looks quite static, so having the master resource
ServiceTracker-listening for subresource objects would work nicely, so
you'd only have
<camel-cxf:rsServer id="rootServer" address="${server.rest.base}/"
serviceClass="com.foo.contextA"/>
with 'com.foo.contextA' implementation working with subresources
(possibly indirectly via some helper which will simply add new instances
as soon as they appear to com.foo.contextA) as well handling some base
URI requests, the actual OSGI Service subresources can implement some
base interface and if that is not possible then simply set a property
for 'com.foo.contextA' be able to filter properly,
Cheers, Sergey
> Thanks!
>
>
> On Tue, Jan 15, 2013 at 11:36 AM, Raul Kripalani<ra...@evosent.com> wrote:
>
>> Hi,
>>
>> At last we implemented option 1, to avoid introducing more complexity into
>> our scenario.
>>
>> But yes, the idea is exactly as Sergey mentioned. You'd probably use OSGi
>> services, where the master resource is exposed under "/" and implements an
>> OSGi Service Listener to receive callbacks every time a new JAX-RS resource
>> appears in the OSGi environment.
>>
>> Keeping an internal map of available subresources which is queried from a
>> Subresource Locator would be the way to go in my opinion (off the top of my
>> head).
>>
>> Regards,
>>
>> *Raúl Kripalani*
>> Apache Camel Committer
>> Enterprise Architect, Program Manager, Open Source Integration specialist
>> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
>> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/raulvk>
>>
>> On Tue, Jan 15, 2013 at 10:01 AM, Sergey Beryozkin<sberyozkin@gmail.com
>>> wrote:
>>
>>> Hi
>>>
>>> On 12/01/13 14:53, Martin Stiborský wrote:
>>>
>>>> Hi Raul and Sergey,
>>>> Guys please, could you explain more for me the "second option" ?
>>>> I missed the point I guess.
>>>>
>>>> I thought the idea around sharing the port was actually to do with
>>> dynamically attaching new contexts to the base address like
>>> "localhost:9007", with every new custom bundle introducing a new context
>>> like "/a". etc. I guess in OSGI one can address this task by having a
>>> master JAX-RS root resource listening for new bundles and registering
>> them
>>> as JAX-RS subresources in the internal map and then removing them once
>> the
>>> corresponding bundles have been removed
>>>
>>> HTH
>>> Sergey
>>>
>>>
>>> Thanks!
>>>> On Jan 11, 2013 3:00 PM, "Sergey Beryozkin"<sberyozkin@gmail.**com<
>> sberyozkin@gmail.com>>
>>>> wrote:
>>>>
>>>> Hi Raúl
>>>>> On 11/01/13 13:28, Raul Kripalani wrote:
>>>>>
>>>>> Hi Sergey,
>>>>>>
>>>>>> Thanks for the quick answer. We were already on our way to implement
>> the
>>>>>> second option!
>>>>>>
>>>>>> Just a thought off the top of my head... Does it make sense to enhance
>>>>>> CXF
>>>>>> or the Jetty CXF Transport so that it's able to figure out this
>>>>>> situation
>>>>>> transparently and build the servlet mappings accordingly?
>>>>>>
>>>>>> This is possible when CXF Servlet transport is used (with default
>>>>>>
>>>>> context /cxf which is configurable and relative endpoint address
>> values)
>>>>> but not when every endpoint with an absolute address is powered by
>> (CXF)
>>>>> Jetty transport.
>>>>> Besides, the URI path starting from a given root resource's @Path value
>>>>> is
>>>>> not visible to CXF transports given that this @Path value does not
>>>>> represent the final URI path segment in most cases.
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>> Regards,
>>>>>
>>>>>>
>>>>>> *Raúl Kripalani*
>>>>>> Apache Camel Committer
>>>>>> Enterprise Architect, Program Manager, Open Source Integration
>>>>>> specialist
>>>>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>>>>>> raulkripalani<http://www.**linkedin.com/in/raulkripalani<
>> http://www.linkedin.com/in/raulkripalani>
>>>>>>>
>>>>>> http://blog.raulkr.net | twitter: @raulvk<
>> http://twitter.com/****raulvk<http://twitter.com/**raulvk>
>>>>>> <http://twitter.com/**raulvk<http://twitter.com/raulvk>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> On Fri, Jan 11, 2013 at 1:13 PM, Sergey Beryozkin<
>> sberyozkin@gmail.com*
>>>>>> ***
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>>>
>>>>>>> On 11/01/13 12:53, Raul Kripalani wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>>>
>>>>>>>> Quick question.
>>>>>>>>
>>>>>>>> Has anyone tried to run several CXFRS consumers on different bundles
>>>>>>>> binding to the same port (e.g. 9007), where each consumer has a
>>>>>>>> different
>>>>>>>> root resource stemming from a different path?
>>>>>>>>
>>>>>>>> *Bundle A:*
>>>>>>>>
>>>>>>>>
>>>>>>>> <cxf:rsServer id="rsServer"
>>>>>>>> address="http://0.0.0.0:9007"
>>>>>>>> serviceClass="com.mycompany.******ResourceA" />
>>>>>>>>
>>>>>>>> *Bundle B:*
>>>>>>>>
>>>>>>>>
>>>>>>>> <cxf:rsServer id="rsServer"
>>>>>>>> address="http://0.0.0.0:9007"
>>>>>>>> serviceClass="com.mycompany.******ResourceB" />
>>>>>>>>
>>>>>>>> *ResourceA* annotated with @Path("/resourceA")
>>>>>>>> *ResourceB* annotated with @Path("/resourceB")
>>>>>>>>
>>>>>>>>
>>>>>>>> It looks like the latest bundle to initialise gets ownership of the
>>>>>>>> port,
>>>>>>>> i.e. they become mutually exclusive.
>>>>>>>>
>>>>>>>>
>>>>>>>> will cxf:rsServer work with relative addresses, example, the first
>>>>>>>> one
>>>>>>>>
>>>>>>> with "/resourceA", second - with "/resourceB", and both ResourceA&
>>>>>>> ResourceB root resources having @Path("/") ?
>>>>>>>
>>>>>>> May be another option is to have a single cxf:rsServer listening on "
>>>>>>> http://0.0.0.0:9007", with it root resource listening on "/" and
>>>>>>> dynamically managing subresources which in turn can handle
>>>>>>> "/resourceA",
>>>>>>> "/resourceB", etc, where every subresource is provided or removed
>>>>>>> externally via different bundles ?
>>>>>>>
>>>>>>> Cheers, Sergey
>>>>>>>
>>>>>>> Any ideas on how to make this work? Do you think this question is
>>>>>>> more
>>>>>>> on
>>>>>>>
>>>>>>> the Camel or CXF side of the fence?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> *Raúl Kripalani*
>>>>>>>>
>>>>>>>> Apache Camel Committer
>>>>>>>> Enterprise Architect, Program Manager, Open Source Integration
>>>>>>>> specialist
>>>>>>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>>>>>>>> raulkripalani<http://www.**lin**kedin.com/in/raulkripalani<
>> http://linkedin.com/in/raulkripalani>
>>>>>>>> <htt**p://www.linkedin.com/in/**raulkripalani<
>> http://www.linkedin.com/in/raulkripalani>
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://blog.raulkr.net | twitter: @raulvk<
>> http://twitter.com/*****
>>>>>>>> *raulvk<http://twitter.com/****raulvk><
>> http://twitter.com/****raulvk<http://twitter.com/**raulvk>
>>>>>>>>>
>>>>>>>> <http://twitter.com/**raulvk<h**ttp://twitter.com/raulvk<
>> http://twitter.com/raulvk>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
Re: CXFRS: Share port number across bundles
Posted by Martin Stiborský <ma...@gmail.com>.
Hi,
thanks for answers and the idea, it sounds really good, I'll go this way
definitelly.
Right now, I have done that static - hardcoded, in my blueprint.xml:
<camel-cxf:rsServer id="rootServer" address="${server.rest.base}/"
serviceClass="com.foo.contextA"/>
<camel-cxf:rsServer id="fooServer" address="${server.rest.base}/contextA/"
serviceClass="com.foo.contextB"/>
<camel-cxf:rsServer id="barServer" address="${server.rest.base}/contextB/"
serviceClass="com.foo.contextC" />
But the "dynamic" solution sound quite better and I like it and it's
logical, thanks to the nature of a OSGi module.
Thanks!
On Tue, Jan 15, 2013 at 11:36 AM, Raul Kripalani <ra...@evosent.com> wrote:
> Hi,
>
> At last we implemented option 1, to avoid introducing more complexity into
> our scenario.
>
> But yes, the idea is exactly as Sergey mentioned. You'd probably use OSGi
> services, where the master resource is exposed under "/" and implements an
> OSGi Service Listener to receive callbacks every time a new JAX-RS resource
> appears in the OSGi environment.
>
> Keeping an internal map of available subresources which is queried from a
> Subresource Locator would be the way to go in my opinion (off the top of my
> head).
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel Committer
> Enterprise Architect, Program Manager, Open Source Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>
>
> On Tue, Jan 15, 2013 at 10:01 AM, Sergey Beryozkin <sberyozkin@gmail.com
> >wrote:
>
> > Hi
> >
> > On 12/01/13 14:53, Martin Stiborský wrote:
> >
> >> Hi Raul and Sergey,
> >> Guys please, could you explain more for me the "second option" ?
> >> I missed the point I guess.
> >>
> >> I thought the idea around sharing the port was actually to do with
> > dynamically attaching new contexts to the base address like
> > "localhost:9007", with every new custom bundle introducing a new context
> > like "/a". etc. I guess in OSGI one can address this task by having a
> > master JAX-RS root resource listening for new bundles and registering
> them
> > as JAX-RS subresources in the internal map and then removing them once
> the
> > corresponding bundles have been removed
> >
> > HTH
> > Sergey
> >
> >
> > Thanks!
> >> On Jan 11, 2013 3:00 PM, "Sergey Beryozkin"<sberyozkin@gmail.**com<
> sberyozkin@gmail.com>>
> >> wrote:
> >>
> >> Hi Raúl
> >>> On 11/01/13 13:28, Raul Kripalani wrote:
> >>>
> >>> Hi Sergey,
> >>>>
> >>>> Thanks for the quick answer. We were already on our way to implement
> the
> >>>> second option!
> >>>>
> >>>> Just a thought off the top of my head... Does it make sense to enhance
> >>>> CXF
> >>>> or the Jetty CXF Transport so that it's able to figure out this
> >>>> situation
> >>>> transparently and build the servlet mappings accordingly?
> >>>>
> >>>> This is possible when CXF Servlet transport is used (with default
> >>>>
> >>> context /cxf which is configurable and relative endpoint address
> values)
> >>> but not when every endpoint with an absolute address is powered by
> (CXF)
> >>> Jetty transport.
> >>> Besides, the URI path starting from a given root resource's @Path value
> >>> is
> >>> not visible to CXF transports given that this @Path value does not
> >>> represent the final URI path segment in most cases.
> >>>
> >>> Cheers, Sergey
> >>>
> >>> Regards,
> >>>
> >>>>
> >>>> *Raúl Kripalani*
> >>>> Apache Camel Committer
> >>>> Enterprise Architect, Program Manager, Open Source Integration
> >>>> specialist
> >>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
> >>>> raulkripalani<http://www.**linkedin.com/in/raulkripalani<
> http://www.linkedin.com/in/raulkripalani>
> >>>> >
> >>>> http://blog.raulkr.net | twitter: @raulvk<
> http://twitter.com/****raulvk<http://twitter.com/**raulvk>
> >>>> <http://twitter.com/**raulvk <http://twitter.com/raulvk>>
> >>>>
> >>>>>
> >>>>>
> >>>> On Fri, Jan 11, 2013 at 1:13 PM, Sergey Beryozkin<
> sberyozkin@gmail.com*
> >>>> ***
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>
> >>>> Hi
> >>>>
> >>>>>
> >>>>> On 11/01/13 12:53, Raul Kripalani wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>>>
> >>>>>> Quick question.
> >>>>>>
> >>>>>> Has anyone tried to run several CXFRS consumers on different bundles
> >>>>>> binding to the same port (e.g. 9007), where each consumer has a
> >>>>>> different
> >>>>>> root resource stemming from a different path?
> >>>>>>
> >>>>>> *Bundle A:*
> >>>>>>
> >>>>>>
> >>>>>> <cxf:rsServer id="rsServer"
> >>>>>> address="http://0.0.0.0:9007"
> >>>>>> serviceClass="com.mycompany.******ResourceA" />
> >>>>>>
> >>>>>> *Bundle B:*
> >>>>>>
> >>>>>>
> >>>>>> <cxf:rsServer id="rsServer"
> >>>>>> address="http://0.0.0.0:9007"
> >>>>>> serviceClass="com.mycompany.******ResourceB" />
> >>>>>>
> >>>>>> *ResourceA* annotated with @Path("/resourceA")
> >>>>>> *ResourceB* annotated with @Path("/resourceB")
> >>>>>>
> >>>>>>
> >>>>>> It looks like the latest bundle to initialise gets ownership of the
> >>>>>> port,
> >>>>>> i.e. they become mutually exclusive.
> >>>>>>
> >>>>>>
> >>>>>> will cxf:rsServer work with relative addresses, example, the first
> >>>>>> one
> >>>>>>
> >>>>> with "/resourceA", second - with "/resourceB", and both ResourceA&
> >>>>> ResourceB root resources having @Path("/") ?
> >>>>>
> >>>>> May be another option is to have a single cxf:rsServer listening on "
> >>>>> http://0.0.0.0:9007", with it root resource listening on "/" and
> >>>>> dynamically managing subresources which in turn can handle
> >>>>> "/resourceA",
> >>>>> "/resourceB", etc, where every subresource is provided or removed
> >>>>> externally via different bundles ?
> >>>>>
> >>>>> Cheers, Sergey
> >>>>>
> >>>>> Any ideas on how to make this work? Do you think this question is
> >>>>> more
> >>>>> on
> >>>>>
> >>>>> the Camel or CXF side of the fence?
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> *Raúl Kripalani*
> >>>>>>
> >>>>>> Apache Camel Committer
> >>>>>> Enterprise Architect, Program Manager, Open Source Integration
> >>>>>> specialist
> >>>>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
> >>>>>> raulkripalani<http://www.**lin**kedin.com/in/raulkripalani<
> http://linkedin.com/in/raulkripalani>
> >>>>>> <htt**p://www.linkedin.com/in/**raulkripalani<
> http://www.linkedin.com/in/raulkripalani>
> >>>>>> >
> >>>>>>
> >>>>>>>
> >>>>>>> http://blog.raulkr.net | twitter: @raulvk<
> http://twitter.com/*****
> >>>>>> *raulvk <http://twitter.com/****raulvk><
> http://twitter.com/****raulvk<http://twitter.com/**raulvk>
> >>>>>> >
> >>>>>> <http://twitter.com/**raulvk<h**ttp://twitter.com/raulvk<
> http://twitter.com/raulvk>
> >>>>>> >>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
--
S pozdravem / Best regards
Martin Stiborský
Jabber: stibi@njs.netlab.cz
Twitter: http://www.twitter.com/stibi
Re: CXFRS: Share port number across bundles
Posted by Raul Kripalani <ra...@evosent.com>.
Hi,
At last we implemented option 1, to avoid introducing more complexity into
our scenario.
But yes, the idea is exactly as Sergey mentioned. You'd probably use OSGi
services, where the master resource is exposed under "/" and implements an
OSGi Service Listener to receive callbacks every time a new JAX-RS resource
appears in the OSGi environment.
Keeping an internal map of available subresources which is queried from a
Subresource Locator would be the way to go in my opinion (off the top of my
head).
Regards,
*Raúl Kripalani*
Apache Camel Committer
Enterprise Architect, Program Manager, Open Source Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>
On Tue, Jan 15, 2013 at 10:01 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi
>
> On 12/01/13 14:53, Martin Stiborský wrote:
>
>> Hi Raul and Sergey,
>> Guys please, could you explain more for me the "second option" ?
>> I missed the point I guess.
>>
>> I thought the idea around sharing the port was actually to do with
> dynamically attaching new contexts to the base address like
> "localhost:9007", with every new custom bundle introducing a new context
> like "/a". etc. I guess in OSGI one can address this task by having a
> master JAX-RS root resource listening for new bundles and registering them
> as JAX-RS subresources in the internal map and then removing them once the
> corresponding bundles have been removed
>
> HTH
> Sergey
>
>
> Thanks!
>> On Jan 11, 2013 3:00 PM, "Sergey Beryozkin"<sb...@gmail.com>>
>> wrote:
>>
>> Hi Raúl
>>> On 11/01/13 13:28, Raul Kripalani wrote:
>>>
>>> Hi Sergey,
>>>>
>>>> Thanks for the quick answer. We were already on our way to implement the
>>>> second option!
>>>>
>>>> Just a thought off the top of my head... Does it make sense to enhance
>>>> CXF
>>>> or the Jetty CXF Transport so that it's able to figure out this
>>>> situation
>>>> transparently and build the servlet mappings accordingly?
>>>>
>>>> This is possible when CXF Servlet transport is used (with default
>>>>
>>> context /cxf which is configurable and relative endpoint address values)
>>> but not when every endpoint with an absolute address is powered by (CXF)
>>> Jetty transport.
>>> Besides, the URI path starting from a given root resource's @Path value
>>> is
>>> not visible to CXF transports given that this @Path value does not
>>> represent the final URI path segment in most cases.
>>>
>>> Cheers, Sergey
>>>
>>> Regards,
>>>
>>>>
>>>> *Raúl Kripalani*
>>>> Apache Camel Committer
>>>> Enterprise Architect, Program Manager, Open Source Integration
>>>> specialist
>>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>>>> raulkripalani<http://www.**linkedin.com/in/raulkripalani<http://www.linkedin.com/in/raulkripalani>
>>>> >
>>>> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/****raulvk<http://twitter.com/**raulvk>
>>>> <http://twitter.com/**raulvk <http://twitter.com/raulvk>>
>>>>
>>>>>
>>>>>
>>>> On Fri, Jan 11, 2013 at 1:13 PM, Sergey Beryozkin<sberyozkin@gmail.com*
>>>> ***
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>> Hi
>>>>
>>>>>
>>>>> On 11/01/13 12:53, Raul Kripalani wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>>>
>>>>>> Quick question.
>>>>>>
>>>>>> Has anyone tried to run several CXFRS consumers on different bundles
>>>>>> binding to the same port (e.g. 9007), where each consumer has a
>>>>>> different
>>>>>> root resource stemming from a different path?
>>>>>>
>>>>>> *Bundle A:*
>>>>>>
>>>>>>
>>>>>> <cxf:rsServer id="rsServer"
>>>>>> address="http://0.0.0.0:9007"
>>>>>> serviceClass="com.mycompany.******ResourceA" />
>>>>>>
>>>>>> *Bundle B:*
>>>>>>
>>>>>>
>>>>>> <cxf:rsServer id="rsServer"
>>>>>> address="http://0.0.0.0:9007"
>>>>>> serviceClass="com.mycompany.******ResourceB" />
>>>>>>
>>>>>> *ResourceA* annotated with @Path("/resourceA")
>>>>>> *ResourceB* annotated with @Path("/resourceB")
>>>>>>
>>>>>>
>>>>>> It looks like the latest bundle to initialise gets ownership of the
>>>>>> port,
>>>>>> i.e. they become mutually exclusive.
>>>>>>
>>>>>>
>>>>>> will cxf:rsServer work with relative addresses, example, the first
>>>>>> one
>>>>>>
>>>>> with "/resourceA", second - with "/resourceB", and both ResourceA&
>>>>> ResourceB root resources having @Path("/") ?
>>>>>
>>>>> May be another option is to have a single cxf:rsServer listening on "
>>>>> http://0.0.0.0:9007", with it root resource listening on "/" and
>>>>> dynamically managing subresources which in turn can handle
>>>>> "/resourceA",
>>>>> "/resourceB", etc, where every subresource is provided or removed
>>>>> externally via different bundles ?
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>> Any ideas on how to make this work? Do you think this question is
>>>>> more
>>>>> on
>>>>>
>>>>> the Camel or CXF side of the fence?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> *Raúl Kripalani*
>>>>>>
>>>>>> Apache Camel Committer
>>>>>> Enterprise Architect, Program Manager, Open Source Integration
>>>>>> specialist
>>>>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>>>>>> raulkripalani<http://www.**lin**kedin.com/in/raulkripalani<http://linkedin.com/in/raulkripalani>
>>>>>> <htt**p://www.linkedin.com/in/**raulkripalani<http://www.linkedin.com/in/raulkripalani>
>>>>>> >
>>>>>>
>>>>>>>
>>>>>>> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/*****
>>>>>> *raulvk <http://twitter.com/****raulvk><http://twitter.com/****raulvk<http://twitter.com/**raulvk>
>>>>>> >
>>>>>> <http://twitter.com/**raulvk<h**ttp://twitter.com/raulvk<http://twitter.com/raulvk>
>>>>>> >>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
Re: CXFRS: Share port number across bundles
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 12/01/13 14:53, Martin Stiborský wrote:
> Hi Raul and Sergey,
> Guys please, could you explain more for me the "second option" ?
> I missed the point I guess.
>
I thought the idea around sharing the port was actually to do with
dynamically attaching new contexts to the base address like
"localhost:9007", with every new custom bundle introducing a new context
like "/a". etc. I guess in OSGI one can address this task by having a
master JAX-RS root resource listening for new bundles and registering
them as JAX-RS subresources in the internal map and then removing them
once the corresponding bundles have been removed
HTH
Sergey
> Thanks!
> On Jan 11, 2013 3:00 PM, "Sergey Beryozkin"<sb...@gmail.com> wrote:
>
>> Hi Raúl
>> On 11/01/13 13:28, Raul Kripalani wrote:
>>
>>> Hi Sergey,
>>>
>>> Thanks for the quick answer. We were already on our way to implement the
>>> second option!
>>>
>>> Just a thought off the top of my head... Does it make sense to enhance CXF
>>> or the Jetty CXF Transport so that it's able to figure out this situation
>>> transparently and build the servlet mappings accordingly?
>>>
>>> This is possible when CXF Servlet transport is used (with default
>> context /cxf which is configurable and relative endpoint address values)
>> but not when every endpoint with an absolute address is powered by (CXF)
>> Jetty transport.
>> Besides, the URI path starting from a given root resource's @Path value is
>> not visible to CXF transports given that this @Path value does not
>> represent the final URI path segment in most cases.
>>
>> Cheers, Sergey
>>
>> Regards,
>>>
>>> *Raúl Kripalani*
>>> Apache Camel Committer
>>> Enterprise Architect, Program Manager, Open Source Integration specialist
>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>>> raulkripalani<http://www.linkedin.com/in/raulkripalani>
>>> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/**raulvk<http://twitter.com/raulvk>
>>>>
>>>
>>> On Fri, Jan 11, 2013 at 1:13 PM, Sergey Beryozkin<sberyozkin@gmail.com**
>>>> wrote:
>>>
>>> Hi
>>>>
>>>> On 11/01/13 12:53, Raul Kripalani wrote:
>>>>
>>>> Hi all,
>>>>>
>>>>> Quick question.
>>>>>
>>>>> Has anyone tried to run several CXFRS consumers on different bundles
>>>>> binding to the same port (e.g. 9007), where each consumer has a
>>>>> different
>>>>> root resource stemming from a different path?
>>>>>
>>>>> *Bundle A:*
>>>>>
>>>>>
>>>>> <cxf:rsServer id="rsServer"
>>>>> address="http://0.0.0.0:9007"
>>>>> serviceClass="com.mycompany.****ResourceA" />
>>>>>
>>>>> *Bundle B:*
>>>>>
>>>>>
>>>>> <cxf:rsServer id="rsServer"
>>>>> address="http://0.0.0.0:9007"
>>>>> serviceClass="com.mycompany.****ResourceB" />
>>>>>
>>>>> *ResourceA* annotated with @Path("/resourceA")
>>>>> *ResourceB* annotated with @Path("/resourceB")
>>>>>
>>>>>
>>>>> It looks like the latest bundle to initialise gets ownership of the
>>>>> port,
>>>>> i.e. they become mutually exclusive.
>>>>>
>>>>>
>>>>> will cxf:rsServer work with relative addresses, example, the first one
>>>> with "/resourceA", second - with "/resourceB", and both ResourceA&
>>>> ResourceB root resources having @Path("/") ?
>>>>
>>>> May be another option is to have a single cxf:rsServer listening on "
>>>> http://0.0.0.0:9007", with it root resource listening on "/" and
>>>> dynamically managing subresources which in turn can handle "/resourceA",
>>>> "/resourceB", etc, where every subresource is provided or removed
>>>> externally via different bundles ?
>>>>
>>>> Cheers, Sergey
>>>>
>>>> Any ideas on how to make this work? Do you think this question is more
>>>> on
>>>>
>>>>> the Camel or CXF side of the fence?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> *Raúl Kripalani*
>>>>>
>>>>> Apache Camel Committer
>>>>> Enterprise Architect, Program Manager, Open Source Integration
>>>>> specialist
>>>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>>>>> raulkripalani<http://www.**linkedin.com/in/raulkripalani<http://www.linkedin.com/in/raulkripalani>
>>>>>>
>>>>> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/****raulvk<http://twitter.com/**raulvk>
>>>>> <http://twitter.com/**raulvk<http://twitter.com/raulvk>>
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: CXFRS: Share port number across bundles
Posted by Martin Stiborský <ma...@gmail.com>.
Hi Raul and Sergey,
Guys please, could you explain more for me the "second option" ?
I missed the point I guess.
Thanks!
On Jan 11, 2013 3:00 PM, "Sergey Beryozkin" <sb...@gmail.com> wrote:
> Hi Raúl
> On 11/01/13 13:28, Raul Kripalani wrote:
>
>> Hi Sergey,
>>
>> Thanks for the quick answer. We were already on our way to implement the
>> second option!
>>
>> Just a thought off the top of my head... Does it make sense to enhance CXF
>> or the Jetty CXF Transport so that it's able to figure out this situation
>> transparently and build the servlet mappings accordingly?
>>
>> This is possible when CXF Servlet transport is used (with default
> context /cxf which is configurable and relative endpoint address values)
> but not when every endpoint with an absolute address is powered by (CXF)
> Jetty transport.
> Besides, the URI path starting from a given root resource's @Path value is
> not visible to CXF transports given that this @Path value does not
> represent the final URI path segment in most cases.
>
> Cheers, Sergey
>
> Regards,
>>
>> *Raúl Kripalani*
>> Apache Camel Committer
>> Enterprise Architect, Program Manager, Open Source Integration specialist
>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>> raulkripalani <http://www.linkedin.com/in/raulkripalani>
>> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/**raulvk<http://twitter.com/raulvk>
>> >
>>
>> On Fri, Jan 11, 2013 at 1:13 PM, Sergey Beryozkin<sberyozkin@gmail.com**
>> >wrote:
>>
>> Hi
>>>
>>> On 11/01/13 12:53, Raul Kripalani wrote:
>>>
>>> Hi all,
>>>>
>>>> Quick question.
>>>>
>>>> Has anyone tried to run several CXFRS consumers on different bundles
>>>> binding to the same port (e.g. 9007), where each consumer has a
>>>> different
>>>> root resource stemming from a different path?
>>>>
>>>> *Bundle A:*
>>>>
>>>>
>>>> <cxf:rsServer id="rsServer"
>>>> address="http://0.0.0.0:9007"
>>>> serviceClass="com.mycompany.****ResourceA" />
>>>>
>>>> *Bundle B:*
>>>>
>>>>
>>>> <cxf:rsServer id="rsServer"
>>>> address="http://0.0.0.0:9007"
>>>> serviceClass="com.mycompany.****ResourceB" />
>>>>
>>>> *ResourceA* annotated with @Path("/resourceA")
>>>> *ResourceB* annotated with @Path("/resourceB")
>>>>
>>>>
>>>> It looks like the latest bundle to initialise gets ownership of the
>>>> port,
>>>> i.e. they become mutually exclusive.
>>>>
>>>>
>>>> will cxf:rsServer work with relative addresses, example, the first one
>>> with "/resourceA", second - with "/resourceB", and both ResourceA&
>>> ResourceB root resources having @Path("/") ?
>>>
>>> May be another option is to have a single cxf:rsServer listening on "
>>> http://0.0.0.0:9007", with it root resource listening on "/" and
>>> dynamically managing subresources which in turn can handle "/resourceA",
>>> "/resourceB", etc, where every subresource is provided or removed
>>> externally via different bundles ?
>>>
>>> Cheers, Sergey
>>>
>>> Any ideas on how to make this work? Do you think this question is more
>>> on
>>>
>>>> the Camel or CXF side of the fence?
>>>>
>>>> Thanks!
>>>>
>>>> *Raúl Kripalani*
>>>>
>>>> Apache Camel Committer
>>>> Enterprise Architect, Program Manager, Open Source Integration
>>>> specialist
>>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>>>> raulkripalani<http://www.**linkedin.com/in/raulkripalani<http://www.linkedin.com/in/raulkripalani>
>>>> >
>>>> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/****raulvk<http://twitter.com/**raulvk>
>>>> <http://twitter.com/**raulvk <http://twitter.com/raulvk>>
>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
Re: CXFRS: Share port number across bundles
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Raúl
On 11/01/13 13:28, Raul Kripalani wrote:
> Hi Sergey,
>
> Thanks for the quick answer. We were already on our way to implement the
> second option!
>
> Just a thought off the top of my head... Does it make sense to enhance CXF
> or the Jetty CXF Transport so that it's able to figure out this situation
> transparently and build the servlet mappings accordingly?
>
This is possible when CXF Servlet transport is used (with default
context /cxf which is configurable and relative endpoint address values)
but not when every endpoint with an absolute address is powered by (CXF)
Jetty transport.
Besides, the URI path starting from a given root resource's @Path value
is not visible to CXF transports given that this @Path value does not
represent the final URI path segment in most cases.
Cheers, Sergey
> Regards,
>
> *Raúl Kripalani*
> Apache Camel Committer
> Enterprise Architect, Program Manager, Open Source Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/raulvk>
>
> On Fri, Jan 11, 2013 at 1:13 PM, Sergey Beryozkin<sb...@gmail.com>wrote:
>
>> Hi
>>
>> On 11/01/13 12:53, Raul Kripalani wrote:
>>
>>> Hi all,
>>>
>>> Quick question.
>>>
>>> Has anyone tried to run several CXFRS consumers on different bundles
>>> binding to the same port (e.g. 9007), where each consumer has a different
>>> root resource stemming from a different path?
>>>
>>> *Bundle A:*
>>>
>>>
>>> <cxf:rsServer id="rsServer"
>>> address="http://0.0.0.0:9007"
>>> serviceClass="com.mycompany.**ResourceA" />
>>>
>>> *Bundle B:*
>>>
>>>
>>> <cxf:rsServer id="rsServer"
>>> address="http://0.0.0.0:9007"
>>> serviceClass="com.mycompany.**ResourceB" />
>>>
>>> *ResourceA* annotated with @Path("/resourceA")
>>> *ResourceB* annotated with @Path("/resourceB")
>>>
>>>
>>> It looks like the latest bundle to initialise gets ownership of the port,
>>> i.e. they become mutually exclusive.
>>>
>>>
>> will cxf:rsServer work with relative addresses, example, the first one
>> with "/resourceA", second - with "/resourceB", and both ResourceA&
>> ResourceB root resources having @Path("/") ?
>>
>> May be another option is to have a single cxf:rsServer listening on "
>> http://0.0.0.0:9007", with it root resource listening on "/" and
>> dynamically managing subresources which in turn can handle "/resourceA",
>> "/resourceB", etc, where every subresource is provided or removed
>> externally via different bundles ?
>>
>> Cheers, Sergey
>>
>> Any ideas on how to make this work? Do you think this question is more on
>>> the Camel or CXF side of the fence?
>>>
>>> Thanks!
>>>
>>> *Raúl Kripalani*
>>>
>>> Apache Camel Committer
>>> Enterprise Architect, Program Manager, Open Source Integration specialist
>>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>>> raulkripalani<http://www.linkedin.com/in/raulkripalani>
>>> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/**raulvk<http://twitter.com/raulvk>
>>>>
>>>
>>>
>>
>
Re: CXFRS: Share port number across bundles
Posted by Raul Kripalani <ra...@evosent.com>.
Hi Sergey,
Thanks for the quick answer. We were already on our way to implement the
second option!
Just a thought off the top of my head... Does it make sense to enhance CXF
or the Jetty CXF Transport so that it's able to figure out this situation
transparently and build the servlet mappings accordingly?
Regards,
*Raúl Kripalani*
Apache Camel Committer
Enterprise Architect, Program Manager, Open Source Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>
On Fri, Jan 11, 2013 at 1:13 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi
>
> On 11/01/13 12:53, Raul Kripalani wrote:
>
>> Hi all,
>>
>> Quick question.
>>
>> Has anyone tried to run several CXFRS consumers on different bundles
>> binding to the same port (e.g. 9007), where each consumer has a different
>> root resource stemming from a different path?
>>
>> *Bundle A:*
>>
>>
>> <cxf:rsServer id="rsServer"
>> address="http://0.0.0.0:9007"
>> serviceClass="com.mycompany.**ResourceA" />
>>
>> *Bundle B:*
>>
>>
>> <cxf:rsServer id="rsServer"
>> address="http://0.0.0.0:9007"
>> serviceClass="com.mycompany.**ResourceB" />
>>
>> *ResourceA* annotated with @Path("/resourceA")
>> *ResourceB* annotated with @Path("/resourceB")
>>
>>
>> It looks like the latest bundle to initialise gets ownership of the port,
>> i.e. they become mutually exclusive.
>>
>>
> will cxf:rsServer work with relative addresses, example, the first one
> with "/resourceA", second - with "/resourceB", and both ResourceA &
> ResourceB root resources having @Path("/") ?
>
> May be another option is to have a single cxf:rsServer listening on "
> http://0.0.0.0:9007", with it root resource listening on "/" and
> dynamically managing subresources which in turn can handle "/resourceA",
> "/resourceB", etc, where every subresource is provided or removed
> externally via different bundles ?
>
> Cheers, Sergey
>
> Any ideas on how to make this work? Do you think this question is more on
>> the Camel or CXF side of the fence?
>>
>> Thanks!
>>
>> *Raúl Kripalani*
>>
>> Apache Camel Committer
>> Enterprise Architect, Program Manager, Open Source Integration specialist
>> http://about.me/raulkripalani | http://www.linkedin.com/in/**
>> raulkripalani <http://www.linkedin.com/in/raulkripalani>
>> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/**raulvk<http://twitter.com/raulvk>
>> >
>>
>>
>
Re: CXFRS: Share port number across bundles
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 11/01/13 12:53, Raul Kripalani wrote:
> Hi all,
>
> Quick question.
>
> Has anyone tried to run several CXFRS consumers on different bundles
> binding to the same port (e.g. 9007), where each consumer has a different
> root resource stemming from a different path?
>
> *Bundle A:*
>
> <cxf:rsServer id="rsServer"
> address="http://0.0.0.0:9007"
> serviceClass="com.mycompany.ResourceA" />
>
> *Bundle B:*
>
> <cxf:rsServer id="rsServer"
> address="http://0.0.0.0:9007"
> serviceClass="com.mycompany.ResourceB" />
>
> *ResourceA* annotated with @Path("/resourceA")
> *ResourceB* annotated with @Path("/resourceB")
>
> It looks like the latest bundle to initialise gets ownership of the port,
> i.e. they become mutually exclusive.
>
will cxf:rsServer work with relative addresses, example, the first one
with "/resourceA", second - with "/resourceB", and both ResourceA &
ResourceB root resources having @Path("/") ?
May be another option is to have a single cxf:rsServer listening on
"http://0.0.0.0:9007", with it root resource listening on "/" and
dynamically managing subresources which in turn can handle "/resourceA",
"/resourceB", etc, where every subresource is provided or removed
externally via different bundles ?
Cheers, Sergey
> Any ideas on how to make this work? Do you think this question is more on
> the Camel or CXF side of the fence?
>
> Thanks!
>
> *Raúl Kripalani*
> Apache Camel Committer
> Enterprise Architect, Program Manager, Open Source Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk<http://twitter.com/raulvk>
>