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) 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? 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
