Hi Jan, Am Mittwoch, den 01.08.2007, 22:55 +0100 schrieb Jan Stette: > We've had a quick look at getting the Apache Felix DS implementation > going on Equinox as well, but with no luck so far.
As the implementor of the Apache Felix Configuration Admin implementation as well as the respecitve integration into Apache Felix DS, I can tell, that Apache Felix DS works as specified: When a component ist being activated and has an activate method, the Configuration Admin configuration is supplied as part of the ComponentContext properties. As soon as the Configuration is updated in the Configuration Admin, the service component runtime takes down the respective component and recreates it with the new configuration. If you have any Apache Felix specific question regarding the Apache Felix implementations of the Configuration Admin Service and Declarative Components Specifications, please followup on the respective Apache Felix lists. Thank you very much. We are using this combo at our place with great success and I am eager to fix eventual bugs :-) Hope this helps. Regards Felix > > Regards, > Jan > > > On 01/08/07, BJ Hargrave <[EMAIL PROTECTED]> wrote: > The goal with DS and its ConfigAdmin support was to relieve > the component > programmer of having to interact directly with ConfigAdmin. > The > configuration properties would be present in the component > properties when > the component was activated. Thus a component does not have to > implement > ManagedService and respond to update calls. If the > configuration > information in ConfigAdmin is changed (by some configurator), > then SCR (DS > runtime) will deactivate the component and then create and > activate the > component again with the new configuration data in the > component > properties. From secion 112.7: > > "SCR must track changes in the Configuration objects used in > the component > properties of a component configuration. If a Configuration > object that > is related to a component configuration changes, then SCR must > deactivate > that component configuration and, if the Configuration object > was not > deleted, SCR must attempt to reactive the component > configuration with > the updated component properties." > > > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > [EMAIL PROTECTED] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > "Jan Stette" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 2007-08-01 08:17 > Please respond to > OSGi Developer Mail List <[email protected]> > > > To > [EMAIL PROTECTED] > cc > > Subject > [osgi-dev] Declarative Services and Configuration Admin > > > > > > > After we've recently tried to introduce Declarative Services > on my current > project, I've got this question: is it possible to implement > declarative > services that are also managed services? Specifically, can > this be done > in a portable, thread-safe manner that also guarantees no > dead-locks? > > Some of the issues we have come across are: > > - Some services can't meaningfully register until their > configuration is > available. Hence they can't declare a service in the DS > configuration; > they have to perform registration themselves in response to > Configuration > Admin updated() calls. > - Calls from the DS Component Manager (activate and > deactivate) and calls > from Config Admin (updated) take place in separate > threads. Hence > synchronisation is necessary. > - This is made more difficult by the observation that calls > out to the > OSGi framework, say to register services or posting events, > can deadlock > if called from within activate() and deactivate(). So we have > to dispatch > such operations on separate threads, or carefully limit > locking to the > right parts of the activate/deactivate/update methods. > > These problems have proved tricky to solve, making the code in > services > complex and error-prone. We have now got to the stage where > we're > considering ditching Declarative Services as a result, but I > would like to > check if there is some way we can make this work before taking > that step. > I would be particularly interested to hear from anyone who > have > successfully implemented declarative services where the > services are > configured through the Configuration Admin service. > > There is one approach that I thought may work: The spec seems > to suggest > that inital configuration for a service should be passed in > through the > ComponentContext in the activate() method. Then, when the > updated() > method is called on the service, it can judge whether it > should be > restarted or not. If it needs to be restarted, it could call > disableComponent() directly followed by enableComponent() with > itself as > argument, to signal to the DS implementation that it should be > restarted. > > This doesn't work with the implementations we have tried so > far though... > the configuration from Config Admin isn't passed in on > activate() and > calling disableComponent/enableComponent is executed > synchronously, so > ends up calling back to deactivate in the service itself. And > it's not > clear to me if the call to disableComponent/enableComponent is > a > reasonable way for a declared service to signal that it should > be > decativated and re-activated. > > On a related note, I'm starting to wonder if the Declarative > Services > and/or Config Admin specs are flawed in that these don't > really take into > account the interaction between the two. It strikes me that > configuration > updates to a declared service ought to be delivered in a way > that is > integrated into the Declarative Service lifecycle. But I may > be missing > something... > > Your comments and suggestions would be most welcome. > > Regards, > Jan > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
