Actually...
Properties props = new Properties();
props.put("name", name);
props.put("prop1", context.getProperty("messagequeue." + name + ".prop1"));
context.registerService
(
MessageQueueService.class.getName(),
new MessageQueueImpl(props),
props);
On Wed, Apr 28, 2010 at 9:38 AM, Donald Whytock <dwhyt...@gmail.com> wrote:
> 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
> <clement.escoff...@gmail.com> 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 <holger.hoffstae...@googlemail.com>
>>>
>>>> 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: users-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Contribute to Enterprise Integration
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
