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 Wells (Aziz)
jwells@xxxxxxx
From:
equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Olivier Gruber
Sent: Tuesday, November 22, 2005
12:26 PM
To: Equinox development mailing
list
Subject: RE: [equinox-dev]
Roadmap?
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
