Working on rolling my own...I was thinking of something that used
config.properties as a starting point. Say, for example, I wanted a
bunch of MessageQueues...I might put
messagequeue.names=first,second,third
messagequeue.first.prop1=value1
messagequeue.second.prop1=value2
messagequeue.third.prop1=value3
into config.properties. For every <name> in messagequeue.names, a
generic factory could, on start(), kick off an instance of
MessageQueueImpl, with the name and the per-name properties:
Properties props = new Properties();
props.put("name", name);
props.put("prop1", context.getProperty("messagequeue." + name + ".prop1");
context.registerService
(
MessageQueueService.class.getName(),
new MessageQueueImpl(),
props);
Probably going to use a ServiceFactoryContext interface for <context>,
so that properties can come from BundleContext, an XML file, a JDO,
etc.
Don
On Wed, Apr 28, 2010 at 1:34 AM, Clement Escoffier
<[email protected]> wrote:
> Hi,
>
> On 28.04.2010, at 03:24, Tribon Cheng wrote:
>
>> I am not sure i'v catch your mind.
>>
>> But i also attemp to use service factory to construct various service
>> instance with different runtime configurations.
>
> This is partially doable with ManagedServiceFactories (configuration admin).
>
>>
>> I found it's difficult to do this. How can the configuration be set through
>> blueprint?
>>
>> I mean when you use the "<Reference>" to use a servicefactory service , it's
>> not supported to configure parameters to construct different service
>> instance.
>
> I don't know about blueprint, but iPOJO provides this feature.
> when you declare a component type (with @Component), you can then create
> several instances of this type with different configurations. The
> configurations can impacts properties, service properties, service dependency
> filters...
>
> So, image that you have
> @Component
> @Provides
> public void MyImpl implements MyService {
>
> �...@property
> private String prop1;
>
> //...
>
> }
>
>
> Then, you can declare two instances:
> <ipojo>
> <instance component="...MyImpl">
> <property name="prop1" value="value1"/>
> </instance>
> <instance component="...MyImpl">
> <property name="prop1" value="value2"/>
> </instance>
> </ipojo>
>
>
> At runtime, you will have two instances with different properties. The
> service will be published by the two instances.
>
> Regards,
>
> Clement
>
>>
>> 2010/4/28 Holger Hoffstätte <[email protected]>
>>
>>> Donald Whytock wrote:
>>>> Then it occurred to me that there are multiple types of services I'd
>>>> like to do this with, which seemed to call for an abstract class,
>>>> similar to ServiceBinder.GenericActivator, that could be subclassed
>>>> with the ServiceImpl and the ServiceFactoryImpl. Thus serving as a
>>>> service factory service...factory.
>>>>
>>>> Is there an easy, already-established way to do this?
>>>
>>> Sadly not standardized, which is why there is currently an RFP open for
>>> voting within the OSGi member group - hopefully resulting soon in a proper
>>> RFC and implementation. Until then you will probably have to look at what
>>> iPOJO, SpringDM or Blueprint offer or roll your own.
>>>
>>> -h
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>>
>> --
>> Contribute to Enterprise Integration
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
