Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Declarative Services questions

 
---------------------------------------------------------
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 -----
From: Jan Stette
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

Back to the top