[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [equinox-dev] Roadmap?
|
Here is another reason (requirement) for why I do not want to be
providing the "BundleContext" to the dynamic IoC framework.
(Furthermore, see some verbiage in the DS specification about getting
the BundleContext in an "implementation-defined way" (see 112.8.1). I
would hate to come up with a "general purpose" IoC framework that could
only work in a particular OSGi implementation. Plus it just feels...
wrong).
I want my jar/bundle files to work in both an OSGi "hosted" environment
and in a "client" environment.
In the OSGi hosted environment my "jar" files are normal OSGi bundles
and have the usual OSGi lifecycle. My "jar" files are NOT put on the
system classpath (typically) and my class-loading is managed by OSGi.
This is the "hosted" environment. Furthermore, the OSGi infrastructure
has been properly "launched". (Whether that is done from the "normal"
main or from some other container is moot).
In the "client" environment the "jar" files that had been used as
"Bundles" in the OSGi environment are merely placed on the classpath of
the JVM. Furthermore, the OSGi framework is not "launched" in such an
environment. Yes yes yes, we lose the run-time protection of classes
and all that, and no dynamic updates, but in my environment I don't
particularly care about that. And I gain the ability to create
"libraries" that will work both hosted and unhosted.
Now we get back to my IoC requirement: I want to be able to dynamically
have IoC in both environments, and not have the users write different
code in the different environments. When in the "client" environment
when the user dynamically asked for a certain "type" the IoC framework
would be smart enough to know it was not in a running OSGi environment
and rather than attempting to track the service it would simply do a
"Class.newInstance()" on the object and return that. Obviously, there
are some issues around that (like that services then must have the null
constructor) and that some of the matching that can be done with OSGi
filters could not be performed. However, as long as those restrictions
are "understood" I think such an ability is a requirement in some
scenarios.
The programmer should not care about whether or not they are running
hosted as a bundle in a running OSGi framework or they are running as
part of a client using the system class-loader to get the instances of
the "service".
Do you guys have any thoughts about such a requirement? Have you
thought about anything along these lines?
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:29 AM
To: Equinox development mailing list
Subject: 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
>
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
