You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Donald Whytock <dw...@gmail.com> on 2010/04/27 18:10:38 UTC
service factory service factory
Hi...
This is probably (hopefully) a newbie question. I have a need for
multiple instances of a service, that codewise are identical but have
different runtime configurations -- names, files accessed, etc. So my
thought was to create a service factory that kicked off as many
instances of the ServiceImpl as needed based on the config properties.
Then it occurred to me that it would also be useful to be able to kick
off instances of the service at runtime, based on the needs of a given
bundle. So that meant a service factory service.
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?
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: service factory service factory
Posted by Donald Whytock <dw...@gmail.com>.
Generic service factory done, source and jar available at
http://www.imtower.net/chatterbot/doku.php?id=servicefactory_bundle
Feedback welcome.
Don
On Fri, Apr 30, 2010 at 12:11 PM, Donald Whytock <dw...@gmail.com> wrote:
> Okay, I've got a basic idea for a service factory service factory
> (SFSF?). My initial idea was to create a generic activator to
> subclass, and just override the pieces needed, except (unless I'm
> missing something in core Java) the subclass has to at least override
> the start() for any overridden method to be called, and if the
> parent's doing any instantiating it can't be on internal classes of
> the subclass.
>
> Here's my idea of basic:
>
> public class Activator extends GenericActivator
> {
> public void start(BundleContext context)
> {
> setStartupProps(new BundleContextToProperties(context));
> setServiceFactoryName("myfactory");
> setServiceClass(MyServiceImpl.class);
> super.start(context);
> }
> }
>
> class MyServiceImpl implements GenericService
> {
> public void setProperties(Properties props)
> {
> /* do stuff with properties */
> }
>
> /* do service stuff */
> }
>
> By default, GenericActivator pretty much does nothing.
> setStartupProps(PropertyMask props) causes services to be kicked off
> from the start using properties in props; otherwise services aren't
> automatically started. setServiceFactoryName(String name) causes a
> service factory to be set up; otherwise there's no factory.
> setServiceClass(Class serviceClass) is meant to tell the
> GenericActivator what to instantiate.
>
> Running into problems with scope. Even in standard Java, you can't
> pass an internal class to an outside class for instantiation; it has
> to be public. Trying it in Felix, I find the GenericServiceFactory
> can't instantiate even a public class if it can't reach the .jar, and
> having it import all the needed .jars is a bit of a coupling issue. I
> could pass some object to the GenericServiceFactory to do the
> instantiating, but that starts to creep up the level of effort in
> using it that one might as well write one's own factory.
>
> Thoughts?
>
> Don
>
> On Wed, Apr 28, 2010 at 8:48 PM, Tribon Cheng <tr...@gmail.com> wrote:
>> I am really grateful to your answer,
>>
>> but there is still some subtle difference between your exampe with what i
>> want indeed.
>>
>> Blueprint also support to create different instances with respective private
>> properties,
>>
>> however, this properties should be configured inside the service bean
>> defination.
>> (otherwise using the configuration admin?i am not familiar with
>> configuration admin.)
>>
>> I want to configure the properties in the calling(consumer) side, not the
>> service instance inside.
>>
>> New service instance will be created with the incoming properties provided
>> by the consumer.
>>
>> As far i have considered, the only way is to set the properties by code,
>> when the consumer side
>>
>> get the service instance, properties can be set for the serive instance in
>> programming way.
>>
>>
>>
>> On Wed, Apr 28, 2010 at 1:34 PM, Clement Escoffier <
>> clement.escoffier@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 <ho...@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-unsubscribe@felix.apache.org
>>> >> For additional commands, e-mail: users-help@felix.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Contribute to Enterprise Integration
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>> --
>> Contribute to Enterprise Integration
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: service factory service factory
Posted by Donald Whytock <dw...@gmail.com>.
Okay, I've got a basic idea for a service factory service factory
(SFSF?). My initial idea was to create a generic activator to
subclass, and just override the pieces needed, except (unless I'm
missing something in core Java) the subclass has to at least override
the start() for any overridden method to be called, and if the
parent's doing any instantiating it can't be on internal classes of
the subclass.
Here's my idea of basic:
public class Activator extends GenericActivator
{
public void start(BundleContext context)
{
setStartupProps(new BundleContextToProperties(context));
setServiceFactoryName("myfactory");
setServiceClass(MyServiceImpl.class);
super.start(context);
}
}
class MyServiceImpl implements GenericService
{
public void setProperties(Properties props)
{
/* do stuff with properties */
}
/* do service stuff */
}
By default, GenericActivator pretty much does nothing.
setStartupProps(PropertyMask props) causes services to be kicked off
from the start using properties in props; otherwise services aren't
automatically started. setServiceFactoryName(String name) causes a
service factory to be set up; otherwise there's no factory.
setServiceClass(Class serviceClass) is meant to tell the
GenericActivator what to instantiate.
Running into problems with scope. Even in standard Java, you can't
pass an internal class to an outside class for instantiation; it has
to be public. Trying it in Felix, I find the GenericServiceFactory
can't instantiate even a public class if it can't reach the .jar, and
having it import all the needed .jars is a bit of a coupling issue. I
could pass some object to the GenericServiceFactory to do the
instantiating, but that starts to creep up the level of effort in
using it that one might as well write one's own factory.
Thoughts?
Don
On Wed, Apr 28, 2010 at 8:48 PM, Tribon Cheng <tr...@gmail.com> wrote:
> I am really grateful to your answer,
>
> but there is still some subtle difference between your exampe with what i
> want indeed.
>
> Blueprint also support to create different instances with respective private
> properties,
>
> however, this properties should be configured inside the service bean
> defination.
> (otherwise using the configuration admin?i am not familiar with
> configuration admin.)
>
> I want to configure the properties in the calling(consumer) side, not the
> service instance inside.
>
> New service instance will be created with the incoming properties provided
> by the consumer.
>
> As far i have considered, the only way is to set the properties by code,
> when the consumer side
>
> get the service instance, properties can be set for the serive instance in
> programming way.
>
>
>
> On Wed, Apr 28, 2010 at 1:34 PM, Clement Escoffier <
> clement.escoffier@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 <ho...@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-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Contribute to Enterprise Integration
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Contribute to Enterprise Integration
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: service factory service factory
Posted by Tribon Cheng <tr...@gmail.com>.
I am really grateful to your answer,
but there is still some subtle difference between your exampe with what i
want indeed.
Blueprint also support to create different instances with respective private
properties,
however, this properties should be configured inside the service bean
defination.
(otherwise using the configuration admin?i am not familiar with
configuration admin.)
I want to configure the properties in the calling(consumer) side, not the
service instance inside.
New service instance will be created with the incoming properties provided
by the consumer.
As far i have considered, the only way is to set the properties by code,
when the consumer side
get the service instance, properties can be set for the serive instance in
programming way.
On Wed, Apr 28, 2010 at 1:34 PM, Clement Escoffier <
clement.escoffier@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 <ho...@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-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> >
> > --
> > Contribute to Enterprise Integration
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Contribute to Enterprise Integration
Re: service factory service factory
Posted by Donald Whytock <dw...@gmail.com>.
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 <dw...@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
> <cl...@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 <ho...@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-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Contribute to Enterprise Integration
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: service factory service factory
Posted by Donald Whytock <dw...@gmail.com>.
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
<cl...@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 <ho...@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>> --
>> Contribute to Enterprise Integration
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: service factory service factory
Posted by Clement Escoffier <cl...@gmail.com>.
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 <ho...@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Contribute to Enterprise Integration
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: service factory service factory
Posted by Tribon Cheng <tr...@gmail.com>.
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.
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.
2010/4/28 Holger Hoffstätte <ho...@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Contribute to Enterprise Integration
Re: service factory service factory
Posted by Holger Hoffstätte <ho...@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org