RE: [equinox-dev] Roadmap?

["John Wells" <jwells@xxxxxxx>]

Yeah I had thought of that too.  I guess I wanted it to be sort of
"standardized" rather than having to write a layer.  But that's ok.

So...  then I also need to know if/when the "ServiceTracker" will be
implemented in Equinox.  Or perhaps it already is, since I can remember
ServiceTracker from r3?

John Wells (Aziz)
jwells@xxxxxxx

-----Original Message-----
From: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeremy Volkman
Sent: Tuesday, November 22, 2005 11:21 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Roadmap?

It seems as though you may be able to realize your DDS needs right now
by using the already-available ServiceTracker.  When
registerDependency() is called, create a new ServiceTracker with the
given service information and start it.  Override the addingService()
and removedService() methods (or provide a ServiceTrackerCustomizer)
and make these methods call your POJO's setter/unsetter (remember that
this is a dynamic environment, so you'll probably want an unsetter). 
The only issue is that you'll need to provide ServiceTracker with a
BundleContext for it to get a ServiceReference.

Jeremy Volkman

On 11/22/05, John Wells <jwells@xxxxxxx> wrote:
> Yes, I do like the delayed activation part of DS.  Here are some
issues
> I have with DS (since you asked - didn't you?  ;-)
>
> I would like to be able to have a POJO that uses a service which gets
> injected.  While I think that with DS I can declare a class that the
DS
> would instantiate, what I want is something more dynamic.  I want to
be
> able to have my own class (that I instantiated myself in whatever way)
> declare that it wants a service (e.g. "com.acme.Foo") injected into
it.
> This class would *not* be under the lifecycle control of DS, but would
> still be getting the dependent service injected into it appropriately
as
> the class is available in the OSGi framework.
>
> In my mind I have been calling such a facility "Dynamic DS" or DDS for
> short.  It would be a service or a class with static methods that had
> methods like the following:
>
> /**
>  * This method would call the setter on the object when the
appropriate
>  * service becomes "available", but objectToInject is *not* under the
>  * specific control of the DS framework
>  * Note:  There are likely other "registerDependency" verbs that
specify
>  * all the options available in the DS configuration file and OSGi
>  * service filters
>  * @param serviceName The name of the service I would like to depend
on
>  * @param setterName The name of the setter - a public void method
that
>  *    takes the type as the argument
>  * @param objectToInject The object (not under the control of DS) to
>  *    "inject"
>  */
> public static void registerDependency(String serviceName, String
> setterName, Object objectToInject) throws WhateverException;
>
> /**
>  * This method removes the dependency, for when the object is done
> needing
>  * the service.
>  */
> public static void unregisterDependency(String serviceName, Object
> objectToInject) throws WhateverException;
>
> Obviously, the above is pseudo-code and I wouldn't mind having the
> "registerDependency" return some form of object that can be used to
> unregister the dependency later.  I also wouldn't mind having the
> registerDependency take some form of other object (e.g. BundleContext)
> that it might need in order to make it work in OSGi.  (However, one of
> the design goals I have is to make any OSGi specific imports not
> visible, so I would almost prefer some sort of wrapper or even
> name-based mechanism).
>
> The basic idea is that independent object can register for injection
> dynamically, and would not have to muck about in the OSGi API in order
> to do service tracking or the like.
>
> Or perhaps there is already a way to do this with the current DS?  I
> looked at the spec and the API, but it is possible I missed something?
> Thanks for helping me understand this a bit more.
>
> And of course, I still need the DS like yesterday ;-).
>
> Anyway, have a nice day.
>
> John Wells (Aziz)
> jwells@xxxxxxx
> -----Original Message-----
> From: equinox-dev-bounces@xxxxxxxxxxx
> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of BJ Hargrave
> Sent: Tuesday, November 22, 2005 10:34 AM
> To: Equinox development mailing list
> Subject: Re: [equinox-dev] Roadmap?
>
> IBM is in the process of preparing a contribution of a Declarative
> Services implementation (among other selected services). Stay tuned...
>
> I would have to say Declarative Service is the best to use. But in the
> interest of full disclosure, I was the designer of Declarative
Services
> :-) I am also not very familiar with GBeans. But DS does fully
integrate
>
> with the OSGi service model and has certain desirable performance
> characteristics such as delayed activation.
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> hargrave@xxxxxxxxxx
> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>
>
>
> "John Wells" <jwells@xxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 2005-11-22 10:00 AM
> Please respond to
> Equinox development mailing list
>
>
> To
> <equinox-dev@xxxxxxxxxxx>
> cc
>
> Subject
> [equinox-dev] Roadmap?
>
>
>
>
>
>
> Is there a roadmap for Equinox, especially where it concerns the
> compendium services of r4?  In particular, I am interested in using
the
> Declarative Services Specification?
>
> I have been looking around to see if I could find information about it
> (dss), but haven?t found anything other than a handful of mail in the
> archive.  In particular, I need to have a good idea when (if) dss is
> going
> to be implemented.  I?ve even considered just implementing that part
of
> the specification myself in order to get it quicker.
>
> Also:
>
> Both DSS and GBeans are IoC frameworks.  Does anyone have any opinions
> on
> which are easier to use? Better?  Any pros/cons?
>
> John Wells (Aziz)
> jwells@xxxxxxx
>  _______________________________________________
> 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
>
> _______________________________________________
> 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