Thanks for your response Olivier.
In an earlier response I talked about the requirement I would
like to see satisfied that would make the IoC pattern work in both a dynamic
and a static environment. Basically, I want to write code that
dynamically tells the IoC system that it wants to depend on some other type and
I want this to work both in a "client" environment where the classes
are linked together via the system class-loader as well in the dynamic
environment afforded by OSGi. To me what is interesting is to be able to
write code that runs in both a "hosted" and "client"
environment without modification.
What I do not want is for the programmers writing the code to
know the difference between the two environments. Furthermore, I think
that this could be a common programming pattern when writing modular code.
I want the service writers to have simple instructions for how to write their
services, and then I want the framework to do the "correct" thing
based on whether or not we are running in the OSGi framework or on a client
that has not started the OSGi kernel. Yes, I want my cake and I want to
eat it too ;-)
Let's take something as simple as a log service. I want
to have a pojo that says something like:
private LogServer logger;
…
// inside some method of my pojo
IoC.createDependency("com.acme.LogService",
"setLogger", this);
…
public synchronized void setLogger(com.acme.LogService
logger) {
this.logger = logger;
}
When in the OSGi world, the LogService might be satisified by
lots of different implementations. However, in the client world there may
be only the one that is satisfied on the client classpath.. One problem
we run up against right away is that com.acme.LogService is very likely an
interface, and hence cannot be instantiated directly on the client. In order
to solve this problem I was thinking that it would be necessary to define a
generic sort of factory interface like this:
public interface GenericFactory<T> {
public <T> create(…);
public <T> find(…) throws
NotFoundException;
}
(excuse any typo's, I am typing as I write, not pasting from
an IDE ;-)
Now instead our IoC object might look like this:
private LogFactory logFactory = new LogFactory();
// Implements the GenericFactory interface
private LogServer logger;
…
// note this time I must provide the factory to use for this
service
// just in case this is running in a "client"
environment
IoC.createDependency("com.acme.LogService",
"setLogger", this, logFactory);
…
public synchronized void setLogger(com.acme.LogService
logger) {
this.logger = logger;
}
The signature for createDependency would be something like:
public Object createDependency(String serviceName, String
setterName, GenericFactory staticFactory, …);
where the extra arguments are used in the find/create methods
of the factory.
What my IoC controller could do then would be that *if* I was running in OSGi (and could find
the bundle context of this caller) then use the ServiceTracker to hook up the
LogService with the implementation. But *if* I was running in a "client" environment I would
use the factory (first trying to find, then create the service).
Everything above is doable (with a big question mark on how
to get the code's BundleContext) using home-made code. I was wondering if
anyone else has these sorts of requirements or if there is any
"standard" way to accomplish what I am trying to achieve? And
does this clarify what requirements I have?
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
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
