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 <dwhyt...@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 <tribon1...@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.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 >>> >>> >> >> >> -- >> Contribute to Enterprise Integration >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org