RE: [equinox-dev] Roadmap?

[Olivier Gruber <ogruber@xxxxxxxxxx>]

John,

Declarative services are mostly about
lifecycle and injection. 
It is the combination of both that is
powerful, especially regarding the linkage with the bundle lifecycle underneath.
That is, a service is created only when
its dependencies are available... 
and this means that the creations of
class loaders are also delayed.

Without lifecycle, injection becomes
service tracking with the use of setter/getter methods, 
especially if you are not using a constructor-based
injection.

What I am curious about is that inversion
of control becomes really interesting when used with a lifecycle.
The goal is that a service code does
not have to deal with the dynamic nature of its environment. 
When it is activated, it has all the
references it needs because they have been injected. 
Before loosing  a reference, it
will be deactivated.

But you are stating that you have no
lifecycle, does this mean that you have injection but your code is also
fully
responsible for dynamically appearing/disappearing
references? Who controls that lifecyle? That is, who creates
your POJO and why.

Just trying to understand. 
Best regards,

Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center

"John Wells" <jwells@xxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx 11/22/2005 05:25 PM Please respond to Equinox development mailing list

To:        "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>         cc:                 Subject:        RE: [equinox-dev] Roadmap?

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