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
