---------------------------------------------------------
dipl. eng.
Stoyan Boshev . Department manager
ProSyst Labs EOOD
1606 Sofia, Bulgaria
. 48 Vladajska Str.
Tel. +359 2 953 05 88; Fax +359 2 953 26 17
Mobile:
+359 88 898 29 17
http://www.prosyst.com
.
s.boshev@xxxxxxxxxxx---------------------------------------------------------
stay
in touch with your
product
---------------------------------------------------------
----- 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)
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 <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
