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
