I am using declarative services for most of my work but I'd like to
keep it simple so I do not have a lot of problems. I had problems with
the original DS from Equinox which related to start ordering but
lately it seems to work fine. However, today I am mostly making
demonstrator code.
Best thing is to file bug reports, I think ProSyst will quickly fix
any reported bugs.
Kind regards,
Peter Kriens
JS> Will do.
JS> In the meantime, does anyone else on this list have experience
JS> with a real life deployment of declarative services?
JS> Thanks,
JS> Jan
JS> On 01/08/07, BJ Hargrave <[EMAIL PROTECTED]> wrote:
JS> I am not aware of the conformance status of the various DS impls. But if
JS> they aren't following the spec, PLEASE open bugs in the appropriate
JS> venues!
JS> --
JS> BJ Hargrave
JS> Senior Technical Staff Member, IBM
JS> OSGi Fellow and CTO of the OSGi Alliance
JS> [EMAIL PROTECTED]
JS> office: +1 386 848 1781
JS> mobile: +1 386 848 3788
JS> "Jan Stette" < [EMAIL PROTECTED]>
JS> Sent by: [EMAIL PROTECTED]
JS> 2007-08-01 17:55
JS> Please respond to
JS> OSGi Developer Mail List < [email protected]>
JS> To
JS> "OSGi Developer Mail List" <[email protected]>
JS> cc
JS> Subject
JS> Re: [osgi-dev] Declarative Services and Configuration Admin
JS> That's interesting, thanks, I hadn't picked up on that section of the
JS> spec.
JS> As far as I can tell, that's not the behaviour we're getting from our
JS> implementation of Declarative Services though. We're using the ProSyst
JS> contributed DS implementation with Equinox. We've had a quick look at
JS> getting the Apache Felix DS implementation going on Equinox as well, but
JS> with no luck so far. Are you aware of any implementations that actually
JS> follows the spec with regards to the points discussed?
JS> Regards,
JS> Jan
JS> On 01/08/07, BJ Hargrave <[EMAIL PROTECTED]> wrote:
JS> The goal with DS and its ConfigAdmin support was to relieve the component
JS> programmer of having to interact directly with ConfigAdmin. The
JS> configuration properties would be present in the component properties when
JS> the component was activated. Thus a component does not have to implement
JS> ManagedService and respond to update calls. If the configuration
JS> information in ConfigAdmin is changed (by some configurator), then SCR (DS
JS> runtime) will deactivate the component and then create and activate the
JS> component again with the new configuration data in the component
JS> properties. From secion 112.7:
JS> "SCR must track changes in the Configuration objects used in the component
JS> properties of a component configuration. If a Configuration object that
JS> is related to a component configuration changes, then SCR must deactivate
JS> that component configuration and, if the Configuration object was not
JS> deleted, SCR must attempt to reactive the component configuration with
JS> the updated component properties."
JS> --
JS> BJ Hargrave
JS> Senior Technical Staff Member, IBM
JS> OSGi Fellow and CTO of the OSGi Alliance
JS> [EMAIL PROTECTED]
JS> office: +1 386 848 1781
JS> mobile: +1 386 848 3788
JS> "Jan Stette" <[EMAIL PROTECTED] >
JS> Sent by: [EMAIL PROTECTED]
JS> 2007-08-01 08:17
JS> Please respond to
JS> OSGi Developer Mail List <[email protected] >
JS> To
JS> [EMAIL PROTECTED]
JS> cc
JS> Subject
JS> [osgi-dev] Declarative Services and Configuration Admin
JS> After we've recently tried to introduce Declarative Services on my current
JS> project, I've got this question: is it possible to implement declarative
JS> services that are also managed services? Specifically, can this be done
JS> in a portable, thread-safe manner that also guarantees no dead-locks?
JS> Some of the issues we have come across are:
JS> - Some services can't meaningfully register until their configuration is
JS> available. Hence they can't declare a service in the DS configuration;
JS> they have to perform registration themselves in response to Configuration
JS> Admin updated() calls.
JS> - Calls from the DS Component Manager (activate and deactivate) and calls
JS> from Config Admin (updated) take place in separate threads. Hence
JS> synchronisation is necessary.
JS> - This is made more difficult by the observation that calls out to the
JS> OSGi framework, say to register services or posting events, can deadlock
JS> if called from within activate() and deactivate(). So we have to dispatch
JS> such operations on separate threads, or carefully limit locking to the
JS> right parts of the activate/deactivate/update methods.
JS> These problems have proved tricky to solve, making the code in services
JS> complex and error-prone. We have now got to the stage where we're
JS> considering ditching Declarative Services as a result, but I would like to
JS> check if there is some way we can make this work before taking that step.
JS> I would be particularly interested to hear from anyone who have
JS> successfully implemented declarative services where the services are
JS> configured through the Configuration Admin service.
JS> There is one approach that I thought may work: The spec seems to suggest
JS> that inital configuration for a service should be passed in through the
JS> ComponentContext in the activate() method. Then, when the updated()
JS> method is called on the service, it can judge whether it should be
JS> restarted or not. If it needs to be restarted, it could call
JS> disableComponent() directly followed by enableComponent() with itself as
JS> argument, to signal to the DS implementation that it should be restarted.
JS> This doesn't work with the implementations we have tried so far though...
JS> the configuration from Config Admin isn't passed in on activate() and
JS> calling disableComponent/enableComponent is executed synchronously, so
JS> ends up calling back to deactivate in the service itself. And it's not
JS> clear to me if the call to disableComponent/enableComponent is a
JS> reasonable way for a declared service to signal that it should be
JS> decativated and re-activated.
JS> On a related note, I'm starting to wonder if the Declarative Services
JS> and/or Config Admin specs are flawed in that these don't really take into
JS> account the interaction between the two. It strikes me that configuration
JS> updates to a declared service ought to be delivered in a way that is
JS> integrated into the Declarative Service lifecycle. But I may be missing
JS> something...
JS> Your comments and suggestions would be most welcome.
JS> Regards,
JS> Jan
JS> _______________________________________________
JS> OSGi Developer Mail List
JS> [email protected]
JS> http://www2.osgi.org/mailman/listinfo/osgi-dev
JS> _______________________________________________
JS> OSGi Developer Mail List
JS> [email protected]
JS> http://www2.osgi.org/mailman/listinfo/osgi-dev
JS> _______________________________________________
JS> OSGi Developer Mail List
JS> [email protected]
JS> http://www2.osgi.org/mailman/listinfo/osgi-dev
JS> _______________________________________________
JS> OSGi Developer Mail List
JS> [email protected]
JS> http://www2.osgi.org/mailman/listinfo/osgi-dev
JS>
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
