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
