Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Roadmap?

It's provided in the framework jar:

org.osgi.util.tracker.ServiceTracker
org.osgi.util.tracker.ServiceTrackerCustomizer

Jeremy Volkman

On 11/22/05, John Wells <jwells@xxxxxxx> wrote:
> 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
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>


Back to the top