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