On Fri, Aug 15, 2008 at 18:50, Simon J Archer <[EMAIL PROTECTED]> wrote: > If you're after something more complicated than that it might be worth > considering this: A bundle can have more than one service component. You > could have your primary service component enable your secondary service > component at runtime. To create a disabled secondary service component you > set the <component> element's 'enabled' attribute to "false". Your primary > service component will be enabled by default and activated on first use, > upon which it will programmatically enable the secondary service component > by using the ComponentContext API enableComponent(String) that takes a > component name. Likewise, the primary service component can disable the > secondary service component using the ComponentContext API > disableComponent(String).
This is roughly equivalent to manually registering the services in the service registry, although, I must say, it's a bit more convenient, as it'll also result in a clean shutdown (unregistration). I think I can live with the enable-/disableComponent lines in activate and deactivate, although I would've preferred not having to. > I hope this helps, It did, thanks. > Simon > > > > "Fredrik Alströmer" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > > 08/15/2008 11:46 AM > > Please respond to > OSGi Developer Mail List <[email protected]> > To > "OSGi Developer Mail List" <[email protected]> > cc > Subject > [osgi-dev] Delayed publishing of services with Declarative Services > > > > > Hi, > > got another question regarding Declarative Services. Is there anyway > for a component to provide an interface which is NOT published to the > service registry before the component is activated? Let's say I have a > component which provides, among other things, some kind of an event > handler, however, the very fact that events are generated should not > cause the component to be activated, but should only be registered in > the service registry whenever the SCR activates the component (i.e. > when one of the 'other things' is requested). > > I realize that this is of course possible by registering the services > upon activation (and unregistering on deactivation), I also realize > that this is probably the best solution when considering race > conditions. I am, however, currently more concerned with if it's > possible without referencing OSGi classes to any larger extent in the > code. > > Is this be possible? Eventing when the component is > activated/deactivated and letting another component do the work would > probably also do the trick, however, I found no reference to any > events in those situations, did I miss something? > > Greetings, > Fredrik. > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
