camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: CXFRS: Share port number across bundles
Date Wed, 16 Jan 2013 13:57:06 GMT
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<raul@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>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>



Mime
View raw message