----- Original Message -----
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)
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 <s_boshev@xxxxxxxxxx> 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
> equinox-dev@xxxxxxxxxxx
> 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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing
list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
