Will do. In the meantime, does anyone else on this list have experience with a real life deployment of declarative services?
Thanks, Jan On 01/08/07, BJ Hargrave <[EMAIL PROTECTED]> wrote: > > I am not aware of the conformance status of the various DS impls. But if > they aren't following the spec, PLEASE open bugs in the appropriate > venues! > -- > > 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 17:55 > Please respond to > OSGi Developer Mail List <[email protected]> > > > To > "OSGi Developer Mail List" <[email protected]> > cc > > Subject > Re: [osgi-dev] Declarative Services and Configuration Admin > > > > > > > That's interesting, thanks, I hadn't picked up on that section of the > spec. > > As far as I can tell, that's not the behaviour we're getting from our > implementation of Declarative Services though. We're using the ProSyst > contributed DS implementation with Equinox. We've had a quick look at > getting the Apache Felix DS implementation going on Equinox as well, but > with no luck so far. Are you aware of any implementations that actually > follows the spec with regards to the points discussed? > > 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 >
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
