Sorry for my previous email with no actual response! I have sent it by mistake. Please, find my comments below.
Best regards, Stoyan ----- Original Message ----- From: Jan Stette To: Equinox development mailing list Sent: Tuesday, August 07, 2007 8:12 PM Subject: Re: [equinox-dev] Declarative Services questions Hi Stoyan, we have resolved the problem we were having getting configs through the ComponentContext - there was a mismatch between the component name we were using and the PID that the config was registered with in the Config Admin service. So our mistake! How should we go about raising bugs like the synchronous nature of activateComponent/deactivateComponent? (This one isn't important for us now by the way) The bug tracker is here : https://bugs.eclipse.org/bugs/ You should click on "Report new bug" and then follow the instructions. I could report this bug for you if you don't mind :) One more question: what is the status of the equinox.component bundle in the Equinox incubator at the moment, is it undergoing active development? Are there any roadmaps or rough plans for future releases? According to me, the DS implementation is in pretty complete state. It is beeing tested and the bugs found are being fixed. I don't really know what is the procedure for passing the incubator state and when it would be officialy released. Perhaps someone else could put some light on this? Regards, Jan On 07/08/07, Stoyan Boshev <[EMAIL PROTECTED]> wrote: Hi Jan, >Do you instead rely on getting configuration from the ComponentContext in >activate() methods? The OSGi spec suggests this should work, but it doesn't >appear to be the case with the ProSyst DS implementation anyway. Could you be more specific here? Do you mean that you use ComponentContext.locateService(...) to get Config Admin service? There was a bug in DS exactly in this scenario but it is already fixed (committed on 09.07.07). >(Another discrepancy we've seen in this DS implementation is that calls to >ComponentContext.disableComponent() and enabledComponent() cause >deactivation/activation on the named component to happen synchronously, not >asynchronously as the spec states) Agree. This is a bug and should be reported. Cheers, Stoyan Jan Stette-2 wrote: > > Dear all, > > I'd like to ask anyone on this list: is there anyone out there who is > using > Declarative Services with Equinox in anger? On my current project, we > have > tried to introduce it but have come across some problems. > > First of all, we're using the ProSyst implementation. While we realise > this > is classified as "not release-ready" [ > http://www.eclipsezone.com/eclipse/forums/t97348.html], this is the best > implementation we've found so far. Or is there another, better one out > there? > > My main question is: how do you implement services that are both > declarative, and that also rely on config from the Config Admin service? > We've tried making services both DeclaredComponents and ManagedServices > but > the interaction between the two is hard to manage. > Do you instead rely on getting configuration from the ComponentContext in > activate() methods? The OSGi spec suggests this should work, but it > doesn't > appear to be the case with the ProSyst DS implementation anyway. > > (Another discrepancy we've seen in this DS implementation is that calls to > ComponentContext.disableComponent() and enabledComponent() cause > deactivation/activation on the named component to happen synchronously, > not > asynchronously as the spec states) > > Any suggestions would be most welcome. > > Regards, > Jan > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > -- View this message in context: http://www.nabble.com/Declarative-Services-questions-tf4193314.html#a12038051 Sent from the Equinox - Dev mailing list archive at Nabble.com. _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev ------------------------------------------------------------------------------ _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
