camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quinn Stevenson <qu...@pronoia-solutions.com>
Subject Re: ServiceFactory
Date Sat, 27 Feb 2016 20:02:14 GMT
I’m pretty sure that’s how the Blueprint proxy works.

You can use Blueprint to reference services exposed via pure OSGi, Declarative Services and
Blueprint - all of them are proxied.  So the proxy would have to be on the caller, not the
server.

You may be able to do what you’re after by registering a factory as a service, and then
calling a method on your factory to return the object you want - just a thought.


> On Feb 27, 2016, at 12:56 PM, Brad Johnson <brad.johnson@mediadriver.com> wrote:
> 
> Your observation about the caller being the proxied side is interesting.  I
> hadn't really thought about it before.  Conceptually I'd always assumed
> that it would be the registration that would proxy the
> interface/implementation and that whomever grabbed got that.  When the
> service would change then the proxy could stay the same but the internally
> delegated class would be different.  Interesting.
> 
> On Sat, Feb 27, 2016 at 1:30 PM, Brad Johnson <brad.johnson@mediadriver.com>
> wrote:
> 
>> I think you're right from what I'm seeing.  I'll probably have to resort
>> to an Activator and register the service. I'm just making this so that I
>> can change the cfg file and switch the internal implementation between
>> three different types: test, impl, or remote.  Test just serves up dummy
>> data, impl is what it sound like and remote is an implementation with a
>> ProducerTemplate that in turn delegates calls to URIs for easy
>> distribution.
>> 
>> I can make that easy enough if I just use a Class.forName on a passed in
>> String and delegate to it but I'm trying to color within the lines.
>> 
>> On Sat, Feb 27, 2016 at 1:18 PM, Quinn Stevenson <
>> quinn@pronoia-solutions.com> wrote:
>> 
>>> I don’t believe the way the service is exposed has any bearing on when a
>>> proxy is created - the proxy is created by the <reference ….>, not the
>>> <service>
>>> 
>>> Also, if you’re trying to achieve a service with the properties of an
>>> OSGi Service Factory (i.e. one service instance per calling bundle), I
>>> don’t think what you have will work - you’ll wind up with a single instance
>>> of the service in the container.  See this JIRA for a little more info as
>>> to why. https://issues.apache.org/jira/browse/KARAF-4284
>>> <https://issues.apache.org/jira/browse/KARAF-4284>
>>> 
>>> <https://issues.apache.org/jira/browse/KARAF-4284?filter=-2>
>>>> On Feb 26, 2016, at 2:35 PM, Brad Johnson <brad.johnson@mediadriver.com>
>>> wrote:
>>>> 
>>>> Just a quick follow up to that question, the class is not proxied in
>>> CBTS
>>>> but that may be an impedance mismatch between the test harness and an
>>>> actual OSGi container and not indicative of how it will be handled by
>>>> blueprint in Karaf.
>>>> 
>>>> On Fri, Feb 26, 2016 at 3:23 PM, Ranx <brad.johnson@mediadriver.com>
>>> wrote:
>>>> 
>>>>> If I create a service factory instantiated in blueprint like this:
>>>>> 
>>>>>       <bean id="service" class="fo.bar.ServiceFactory"
>>>>> factory-method="createService" >
>>>>>               <argument value="${serviceClassImpl}"/>
>>>>> 
>>>>>       </bean>
>>>>>       <service ref="service" interface="foo.api.MyOSGiService" />
>>>>> 
>>>>> And inside the factory just do a Class.forName to instantiate and
>>> return
>>>>> it,
>>>>> will the service reference itself be proxied?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> View this message in context:
>>>>> http://camel.465427.n5.nabble.com/ServiceFactory-tp5778336.html
>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>> 
>>> 
>>> 
>> 


Mime
View raw message