felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: Lazy component activation and service registration
Date Sat, 04 Aug 2012 15:56:40 GMT
Not really. The problem is this part: "FooClient is created as
required". When is that exactly?

With any lazy component, you need some kind of signal that says "stop
being lazy now, the component is needed". With a service component,
that signal is the act of a client trying to use the service. If your
component is not a service then there is no such signal, so DS is
forced to immediately activate the component.

So you need to think about what kind of event would cause the
component to move from lazy to active state.


On Sat, Aug 4, 2012 at 3:48 PM, Chetan Mehrotra
<chetan.mehrotra@gmail.com> wrote:
> In my project I need to wrap certain client jars of remote servoce as OSGi
> bundles. These bundles would register services which provide Java client to
> invoke remote services.
> For example BundleA would have a component
> @Component(immediate = true)
> public class BundleAComponent {
>     @Activate
>     private void activate(BundleContext context){
>         ServiceRegistration sr =
> context.registerService(Foo.class.getName(),new FooClient(),null);
>         ...
>     }
>     ...
> }
> The BundleAComponent would register a service against Foo interface. This
> works fine and other bundles which require this service are able to get it.
> Now I am looking for a way to make this registration lazy such that service
> instance is only instantiated when another bundles ask for it. For example
> had this been a Service then DS would allow lazy activation and I can omit
> immediate=true. Is there any way to achieve the same with Component such
> that it can be activated lazily and FooClient is created as required.
> One way might be I register a Service lookup hook which then registers the
> service as a lookup is performed (possibly the way OSGi Remoting works).
> But that would require more work ... and something I would like to avoid if
> DS provides me some mechanism to achieve that in a simple way!!
> Chetan Mehrotra

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message