You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Carl Hall <ca...@hallwaytech.com> on 2010/04/09 21:54:03 UTC
SCR Service Annotations
When using the @Service annotation and specifying serviceFactory=true,
should I also implement the ServiceFactory interface to make sure the
(get|unget)Service methods are found or are there more annotations to mark
such methods without implementing the interface?
Re: SCR Service Annotations
Posted by Carl Hall <ca...@hallwaytech.com>.
Again, fantastic information. Reminds me just how much more I need to learn
about OSGi. :-)
I'd like to have the central/common configuration be configurable through
the configuration admin console. Should I have a ManagedService for the
common config but also have it implement ManagedServiceFactory?
How do I get a reference in my service consumer to the custom configured
service from a ManagedServiceFactory? The examples I see create services
that don't require a reference (port listeners, etc). Is this where you
suggest using a regular java factory to create the custom versions of the
service? Does that mean the services would not be managed by OSGi but just
regular objects handed out by my factory?
As an aside, can you suggest any examples where I can learn the proper
contexts for each of these magical OSGi factories?
On Sat, Apr 17, 2010 at 3:03 PM, Felix Meschberger <fm...@gmail.com>wrote:
> > My situation is this: I would like to have a single place to configure
> LDAP
> > connection configuration information and have various bundles be able to
> use
> > that, but if a bundle wanted to provide it's own configuration (not use
> the
> > central/default) it should be able to do so. I expect the connections to
> > come from an LDAP bundle. Suggestions?
>
> Your use case sounds like a combination of both approaches: factory
> configuration for the central/default ones and ComponentFactory for the
> special ones.
>
> I would suggest you choose a third approach (which sounds a bit hacky at
> first), but probably comes closest to your requirement:
>
> (1) Your component is actually a factory (in the regular Java sense)
> for connection objects (right?).
> (2) The component implements the ManagedServiceFactory interface and
> is declared to register as such (@Service annotation). To not
> interfere with SCR, the configuration policy on the @Component
> annotation should be set to ConfigurationPolicy.IGNORE. Also,
> ensure the properly set the service.pid and service.factoryPid
> service registration properties as component properties.
> (3) Add factory methods to create (and delete) connection objects
> on demand. Have these methods be part of a service under which
> the component is registered, too. (The component is thus
> actually registered with two service names.
>
> Now, if a central/default configuration is managed with Configuration
> Admin, the respective updated and deleted methods are called. If a
> bundle wants to manage on-demand connnections, the factory service (from
> step 3) is used.
>
> Hope this helps.
>
> Regards
> Felix
>
> >
> >
> > On Fri, Apr 9, 2010 at 4:41 PM, Carl Hall <ca...@hallwaytech.com> wrote:
> >
> >> Thanks again for the fantastic information! It sounds like a component
> >> factory is what I'll want to go with. I'll get to work on this and see
> what
> >> I can come up with.
> >>
> >>
> >> On Fri, Apr 9, 2010 at 4:22 PM, Felix Meschberger <fmeschbe@gmail.com
> >wrote:
> >>
> >>> Hi,
> >>>
> >>> On 09.04.2010 22:11, Carl Hall wrote:
> >>>> Hi Felix, Thanks for the fast response!
> >>>>
> >>>> If the component in question has @Reference fields in it, are they
> >>> carried
> >>>> over to the new instances from the factory?
> >>>
> >>> Yes, references are bound at component activation time just like for
> >>> non-service factory components.
> >>>
> >>>>
> >>>> Is it possible for the requesting component to send up information
> that
> >>> can
> >>>> be used to configure new instances from the factory?
> >>>
> >>> No, all instances of service factory components are configured the
> same.
> >>> Same as all components. Actually to the service consumers service
> >>> factory services look exactly the same as regular services.
> >>>
> >>> If you want your service (or component consumers) to be able to create
> >>> specially crafted objects, you might want to consider using a component
> >>> factory or register a factory service the consumers may call to get the
> >>> actual object.
> >>>
> >>> As for component factory: you declare the component as a component
> >>> factory by setting factory attribute to the @Component annotation. Then
> >>> SCR registers a ComponentFactory service on behalf of the component.
> >>> Consumers then call the newInstance(Dictionary) method on the
> >>> ComponentFactory to actually create an instance of the real component
> >>> which is configured according to the dictionary.
> >>>
> >>> But beware: consumers of the ComponentFactory components must make sure
> >>> to call the ComponentInstance.dispose() method when done using the
> >>> component.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>>>
> >>>>
> >>>> On Fri, Apr 9, 2010 at 4:03 PM, Felix Meschberger <fmeschbe@gmail.com
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> On 09.04.2010 21:54, Carl Hall wrote:
> >>>>>> When using the @Service annotation and specifying
> serviceFactory=true,
> >>>>>> should I also implement the ServiceFactory interface to make sure
> the
> >>>>>> (get|unget)Service methods are found or are there more annotations
> to
> >>>>> mark
> >>>>>> such methods without implementing the interface?
> >>>>>
> >>>>> No, if you mark a component as being a service factory component the
> >>>>> Service Component Runtime registers a ServiceFactory implementation
> on
> >>>>> behalf of the component and when a bundle requests the actual
> service,
> >>>>> the runtime instantiates the component class and activates it to hand
> >>> it
> >>>>> out.
> >>>>>
> >>>>> In short, this is all take care of for the component.
> >>>>>
> >>>>> Regards
> >>>>> Felix
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> 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
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: SCR Service Annotations
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 17.04.2010 00:42, Carl Hall wrote:
> Would it be better to use a ManagedServiceFactory or ComponentFactory for
> this? What would be the benefit/goal of each?
If you want component instances craeted and deleted automatically as
factory configuration is created and deleted with the configuration
admin, you would go for a regular component ensuring factory
configuration will be created.
If you want to manage the lifecycle of the components "manually" and
directly inside your application by calling
ComponentFactory.newInstance() to create instances and
ComponentInstance.dispose() to delete them.
For the regular component case based on factory configurations and using
SCR annotations, you would set the getConfigurationFactory attribute of
the @Component annotation to true. Additionally I suggest to set the
configuration policy (policy attribute) to ConfigurationPolicy.REQUIRE
to ensure component instances are really only created if a (factory)
configuration is present.
>
> My situation is this: I would like to have a single place to configure LDAP
> connection configuration information and have various bundles be able to use
> that, but if a bundle wanted to provide it's own configuration (not use the
> central/default) it should be able to do so. I expect the connections to
> come from an LDAP bundle. Suggestions?
Your use case sounds like a combination of both approaches: factory
configuration for the central/default ones and ComponentFactory for the
special ones.
I would suggest you choose a third approach (which sounds a bit hacky at
first), but probably comes closest to your requirement:
(1) Your component is actually a factory (in the regular Java sense)
for connection objects (right?).
(2) The component implements the ManagedServiceFactory interface and
is declared to register as such (@Service annotation). To not
interfere with SCR, the configuration policy on the @Component
annotation should be set to ConfigurationPolicy.IGNORE. Also,
ensure the properly set the service.pid and service.factoryPid
service registration properties as component properties.
(3) Add factory methods to create (and delete) connection objects
on demand. Have these methods be part of a service under which
the component is registered, too. (The component is thus
actually registered with two service names.
Now, if a central/default configuration is managed with Configuration
Admin, the respective updated and deleted methods are called. If a
bundle wants to manage on-demand connnections, the factory service (from
step 3) is used.
Hope this helps.
Regards
Felix
>
>
> On Fri, Apr 9, 2010 at 4:41 PM, Carl Hall <ca...@hallwaytech.com> wrote:
>
>> Thanks again for the fantastic information! It sounds like a component
>> factory is what I'll want to go with. I'll get to work on this and see what
>> I can come up with.
>>
>>
>> On Fri, Apr 9, 2010 at 4:22 PM, Felix Meschberger <fm...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> On 09.04.2010 22:11, Carl Hall wrote:
>>>> Hi Felix, Thanks for the fast response!
>>>>
>>>> If the component in question has @Reference fields in it, are they
>>> carried
>>>> over to the new instances from the factory?
>>>
>>> Yes, references are bound at component activation time just like for
>>> non-service factory components.
>>>
>>>>
>>>> Is it possible for the requesting component to send up information that
>>> can
>>>> be used to configure new instances from the factory?
>>>
>>> No, all instances of service factory components are configured the same.
>>> Same as all components. Actually to the service consumers service
>>> factory services look exactly the same as regular services.
>>>
>>> If you want your service (or component consumers) to be able to create
>>> specially crafted objects, you might want to consider using a component
>>> factory or register a factory service the consumers may call to get the
>>> actual object.
>>>
>>> As for component factory: you declare the component as a component
>>> factory by setting factory attribute to the @Component annotation. Then
>>> SCR registers a ComponentFactory service on behalf of the component.
>>> Consumers then call the newInstance(Dictionary) method on the
>>> ComponentFactory to actually create an instance of the real component
>>> which is configured according to the dictionary.
>>>
>>> But beware: consumers of the ComponentFactory components must make sure
>>> to call the ComponentInstance.dispose() method when done using the
>>> component.
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>>
>>>> On Fri, Apr 9, 2010 at 4:03 PM, Felix Meschberger <fmeschbe@gmail.com
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 09.04.2010 21:54, Carl Hall wrote:
>>>>>> When using the @Service annotation and specifying serviceFactory=true,
>>>>>> should I also implement the ServiceFactory interface to make sure the
>>>>>> (get|unget)Service methods are found or are there more annotations to
>>>>> mark
>>>>>> such methods without implementing the interface?
>>>>>
>>>>> No, if you mark a component as being a service factory component the
>>>>> Service Component Runtime registers a ServiceFactory implementation on
>>>>> behalf of the component and when a bundle requests the actual service,
>>>>> the runtime instantiates the component class and activates it to hand
>>> it
>>>>> out.
>>>>>
>>>>> In short, this is all take care of for the component.
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: SCR Service Annotations
Posted by Carl Hall <ca...@hallwaytech.com>.
Would it be better to use a ManagedServiceFactory or ComponentFactory for
this? What would be the benefit/goal of each?
My situation is this: I would like to have a single place to configure LDAP
connection configuration information and have various bundles be able to use
that, but if a bundle wanted to provide it's own configuration (not use the
central/default) it should be able to do so. I expect the connections to
come from an LDAP bundle. Suggestions?
On Fri, Apr 9, 2010 at 4:41 PM, Carl Hall <ca...@hallwaytech.com> wrote:
> Thanks again for the fantastic information! It sounds like a component
> factory is what I'll want to go with. I'll get to work on this and see what
> I can come up with.
>
>
> On Fri, Apr 9, 2010 at 4:22 PM, Felix Meschberger <fm...@gmail.com>wrote:
>
>> Hi,
>>
>> On 09.04.2010 22:11, Carl Hall wrote:
>> > Hi Felix, Thanks for the fast response!
>> >
>> > If the component in question has @Reference fields in it, are they
>> carried
>> > over to the new instances from the factory?
>>
>> Yes, references are bound at component activation time just like for
>> non-service factory components.
>>
>> >
>> > Is it possible for the requesting component to send up information that
>> can
>> > be used to configure new instances from the factory?
>>
>> No, all instances of service factory components are configured the same.
>> Same as all components. Actually to the service consumers service
>> factory services look exactly the same as regular services.
>>
>> If you want your service (or component consumers) to be able to create
>> specially crafted objects, you might want to consider using a component
>> factory or register a factory service the consumers may call to get the
>> actual object.
>>
>> As for component factory: you declare the component as a component
>> factory by setting factory attribute to the @Component annotation. Then
>> SCR registers a ComponentFactory service on behalf of the component.
>> Consumers then call the newInstance(Dictionary) method on the
>> ComponentFactory to actually create an instance of the real component
>> which is configured according to the dictionary.
>>
>> But beware: consumers of the ComponentFactory components must make sure
>> to call the ComponentInstance.dispose() method when done using the
>> component.
>>
>> Regards
>> Felix
>>
>> >
>> >
>> > On Fri, Apr 9, 2010 at 4:03 PM, Felix Meschberger <fmeschbe@gmail.com
>> >wrote:
>> >
>> >> Hi,
>> >>
>> >> On 09.04.2010 21:54, Carl Hall wrote:
>> >>> When using the @Service annotation and specifying serviceFactory=true,
>> >>> should I also implement the ServiceFactory interface to make sure the
>> >>> (get|unget)Service methods are found or are there more annotations to
>> >> mark
>> >>> such methods without implementing the interface?
>> >>
>> >> No, if you mark a component as being a service factory component the
>> >> Service Component Runtime registers a ServiceFactory implementation on
>> >> behalf of the component and when a bundle requests the actual service,
>> >> the runtime instantiates the component class and activates it to hand
>> it
>> >> out.
>> >>
>> >> In short, this is all take care of for the component.
>> >>
>> >> Regards
>> >> Felix
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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: SCR Service Annotations
Posted by Carl Hall <ca...@hallwaytech.com>.
Thanks again for the fantastic information! It sounds like a component
factory is what I'll want to go with. I'll get to work on this and see what
I can come up with.
On Fri, Apr 9, 2010 at 4:22 PM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi,
>
> On 09.04.2010 22:11, Carl Hall wrote:
> > Hi Felix, Thanks for the fast response!
> >
> > If the component in question has @Reference fields in it, are they
> carried
> > over to the new instances from the factory?
>
> Yes, references are bound at component activation time just like for
> non-service factory components.
>
> >
> > Is it possible for the requesting component to send up information that
> can
> > be used to configure new instances from the factory?
>
> No, all instances of service factory components are configured the same.
> Same as all components. Actually to the service consumers service
> factory services look exactly the same as regular services.
>
> If you want your service (or component consumers) to be able to create
> specially crafted objects, you might want to consider using a component
> factory or register a factory service the consumers may call to get the
> actual object.
>
> As for component factory: you declare the component as a component
> factory by setting factory attribute to the @Component annotation. Then
> SCR registers a ComponentFactory service on behalf of the component.
> Consumers then call the newInstance(Dictionary) method on the
> ComponentFactory to actually create an instance of the real component
> which is configured according to the dictionary.
>
> But beware: consumers of the ComponentFactory components must make sure
> to call the ComponentInstance.dispose() method when done using the
> component.
>
> Regards
> Felix
>
> >
> >
> > On Fri, Apr 9, 2010 at 4:03 PM, Felix Meschberger <fmeschbe@gmail.com
> >wrote:
> >
> >> Hi,
> >>
> >> On 09.04.2010 21:54, Carl Hall wrote:
> >>> When using the @Service annotation and specifying serviceFactory=true,
> >>> should I also implement the ServiceFactory interface to make sure the
> >>> (get|unget)Service methods are found or are there more annotations to
> >> mark
> >>> such methods without implementing the interface?
> >>
> >> No, if you mark a component as being a service factory component the
> >> Service Component Runtime registers a ServiceFactory implementation on
> >> behalf of the component and when a bundle requests the actual service,
> >> the runtime instantiates the component class and activates it to hand it
> >> out.
> >>
> >> In short, this is all take care of for the component.
> >>
> >> Regards
> >> Felix
> >>
> >> ---------------------------------------------------------------------
> >> 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: SCR Service Annotations
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 09.04.2010 22:11, Carl Hall wrote:
> Hi Felix, Thanks for the fast response!
>
> If the component in question has @Reference fields in it, are they carried
> over to the new instances from the factory?
Yes, references are bound at component activation time just like for
non-service factory components.
>
> Is it possible for the requesting component to send up information that can
> be used to configure new instances from the factory?
No, all instances of service factory components are configured the same.
Same as all components. Actually to the service consumers service
factory services look exactly the same as regular services.
If you want your service (or component consumers) to be able to create
specially crafted objects, you might want to consider using a component
factory or register a factory service the consumers may call to get the
actual object.
As for component factory: you declare the component as a component
factory by setting factory attribute to the @Component annotation. Then
SCR registers a ComponentFactory service on behalf of the component.
Consumers then call the newInstance(Dictionary) method on the
ComponentFactory to actually create an instance of the real component
which is configured according to the dictionary.
But beware: consumers of the ComponentFactory components must make sure
to call the ComponentInstance.dispose() method when done using the
component.
Regards
Felix
>
>
> On Fri, Apr 9, 2010 at 4:03 PM, Felix Meschberger <fm...@gmail.com>wrote:
>
>> Hi,
>>
>> On 09.04.2010 21:54, Carl Hall wrote:
>>> When using the @Service annotation and specifying serviceFactory=true,
>>> should I also implement the ServiceFactory interface to make sure the
>>> (get|unget)Service methods are found or are there more annotations to
>> mark
>>> such methods without implementing the interface?
>>
>> No, if you mark a component as being a service factory component the
>> Service Component Runtime registers a ServiceFactory implementation on
>> behalf of the component and when a bundle requests the actual service,
>> the runtime instantiates the component class and activates it to hand it
>> out.
>>
>> In short, this is all take care of for the component.
>>
>> Regards
>> Felix
>>
>> ---------------------------------------------------------------------
>> 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: SCR Service Annotations
Posted by Carl Hall <ca...@hallwaytech.com>.
Hi Felix, Thanks for the fast response!
If the component in question has @Reference fields in it, are they carried
over to the new instances from the factory?
Is it possible for the requesting component to send up information that can
be used to configure new instances from the factory?
On Fri, Apr 9, 2010 at 4:03 PM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi,
>
> On 09.04.2010 21:54, Carl Hall wrote:
> > When using the @Service annotation and specifying serviceFactory=true,
> > should I also implement the ServiceFactory interface to make sure the
> > (get|unget)Service methods are found or are there more annotations to
> mark
> > such methods without implementing the interface?
>
> No, if you mark a component as being a service factory component the
> Service Component Runtime registers a ServiceFactory implementation on
> behalf of the component and when a bundle requests the actual service,
> the runtime instantiates the component class and activates it to hand it
> out.
>
> In short, this is all take care of for the component.
>
> Regards
> Felix
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: SCR Service Annotations
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 09.04.2010 21:54, Carl Hall wrote:
> When using the @Service annotation and specifying serviceFactory=true,
> should I also implement the ServiceFactory interface to make sure the
> (get|unget)Service methods are found or are there more annotations to mark
> such methods without implementing the interface?
No, if you mark a component as being a service factory component the
Service Component Runtime registers a ServiceFactory implementation on
behalf of the component and when a bundle requests the actual service,
the runtime instantiates the component class and activates it to hand it
out.
In short, this is all take care of for the component.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org