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

In my previous mail I outlined two requirements I am shooting for.  They were:

1.  Dynamic IoC
2.  Running in non-hosted environments

In this e-mail I want to talk about my second requirement (I talked about the first a lot in my previous e-mail).

Mr. Gruber in a previous e-mail talked about two possible ways to use code the developers were writing in both a running OSGi framework and on a client, where it might not be feasible to start the OSGi core.  He suggested the following:

> So to me, there may be two avenues we haven't talked about yet. 

>        - a slave approach, where OSGi is embedded in a larger context  (mentioned above) 
>        - shell OSGi (where APIs are available but with simplistic implementation) 

The problem with the slave approach is that core OSGi (by the book) must maintain the set of services and bundles that are used so that upon subsequent "reboot" of the framework the bundles that were loaded when the framework went down will be the bundles that are loaded when the framework comes back up.  This requires that the framework have access to a physical store etc.  I *like* the idea of having a "special" purpose (and non-compliant) OSGi container that would *not* save this sort of information, but which would base its operations purely on how it was "launched" (via a non-standard API);  getting a hold of that sort of OSGi-"like" container would solve many of my problems.  I'm thinking that Equinox is not focusing on this sort of requirement right now though ;-(

There are several reasons I don't like having data stored on my clients.  For one thing, my clients *may* live in storage-challenged places (cell-phones are only the most obvious example).  For another thing, in large systems there may be thousands up to millions of clients, and some customers do not like the idea of having configuration information on their clients that may need to be managed in order to ensure the client is running properly.  They want these sort of clients to have a URL as configuration and not much else.

So, now lets think about the "shell" OSGi option, which is to have the OSGi libraries themselves "available" on the client (though, actually, they may not *need* to be) but working in a manner which does not require the framework to be running.

If the developers were all using dynamic IoC along with DS (see my previous e-mail) then I think this would be possible.  The part that would be strange is that the dynamic IoC implementation itself (be it PicoContainer, UI IoC or DIoCe) would have to be smart enough to handle the case where the OSGi framework is *not* started.  This is easy enough.  Simply put the dynamic IoC hanlder into a bundle.  When that bundle is started (make sure its start level is appropriate - so that it is started before anything that might use it) you can tell the IoC handler you are running in the framework and then voila, you can use OSGi as it was intended OR if you are not running in OSGi you can do other things (reflection, etc. - assuming the dependencies/versions/etc have been resolved through the magic of classpath).

Now, under the covers I can use OSGi services when they are available, or I can use simple reflection when they are not available.  Unfortunately, this all breaks down when I use DS.  I am not exactly sure what to do about that, except perhaps try to have an implementation of DS that works properly in a non-OSGi booted environment.  Surely, since the core of DS is the XML file that describes the services and their dependencies, it should be possible to have a IoC framework that does not depend on OSGi being booted, but which can still read the XML file and "create" the services (except, of course, in this scenario the "creation" would not be of OSGi services but would use reflection instead).  There would also have to be some way of "starting" the DS outside the scope of OSGi (i.e., some non-standard API).

Anyway, I've got to start doing something like this soon, so I'm going to end up doing something in this space.  Please stay tuned...

And thanks everyone for thinking about these requirements with me...

John Wells (Aziz)

-----Original Message-----
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Kriens
Sent: Friday, November 25, 2005 3:20 AM
To: Stefan Xenos
Cc: equinox-dev@xxxxxxxxxxx
Subject: Re[2]: [equinox-dev] Roadmap?

Isnt this what the PicoContainer is doing?

Kind regards,

     Peter Kriens

SX> That's correct. The UI component framework is not UI
SX> specific.  Generally speaking, it provides a loosely-coupled way
SX> to instantiate and destroy objects.

SX> Concretely, here was our driving use-case:
SX> - API Clients are allowed to implement views and editors (or "parts").
SX> - We wanted to add API such that clients could host parts.
SX> - Parts have a number of local APIs available to them,
SX> provided by their containing context. We called these local API
SX> "services", but they are more like Eclipse adapters than OSGi
SX> services.
SX> - These service APIs change over time.
SX> - Clients that host parts can offer an extended set of
SX> services to the parts they host.
SX> - All parts need to work in all contexts. For example: 
SX>      - If a part updates itself to use the latest APIs, it
SX> should continue to work when hosted in a context that still
SX> implements the old API.
SX>      - If a host is updated to implement the latest APIs, it
SX> should continue to be able to host parts that expect the old
SX> version.
SX>      - If a part uses an extended set of features, it should
SX> still work in a context that does not know about the extended
SX> features.
SX> - We wanted to be able to act on an open-ended set of
SX> services. For example, it should be possible to write a wrapper
SX> part that overrides a closed set of services and delegates
SX> everything else to another part.

SX> Put simply, we wanted to make all parts interchangeable, but
SX> still leave avenues open for API evolution. These are issues that
SX> apply to any object that gets created from an extension point, and
SX> our implementation was similarly generic. Although the IoC
SX> framework works with any POJO, I will continue using the word
SX> "part" since I find the UI metaphor easiest to visualize.

SX> We wanted our implementation to have the following properties:
SX> - It must be simpler (require less code + XML) to implement a
SX> component-based part than a traditional part.
SX> - There must not be a significant memory or CPU cost to using IoC.
SX> - It must be self-documenting in the following sense: given a
SX> set of plugins, a developer should be able to generate the list of
SX> services that they could use in the implementation of their part.
SX> - Services can depend on other services. Since all are
SX> created through the framework, there is no real distinction
SX> between the implementation of a "part" and a "service".

SX> Although the framework was originally intended for views and
SX> editors, it is very well suited for any extension point that calls
SX> createExecutableExtension and I have used it for many non-UI
SX> extension points. I do not believe it would work as a replacement
SX> for OSGi's DS, as DS is mainly concerned with dynamic connections
SX> between singletons, whereas the UI IoC stuff is concerned with
SX> creating static connections to objects that can be instantiated
SX> anywhere.

SX> Here's how our implementation works:
SX> - Our implementation does NOT require dependencies to be
SX> declared anywhere (no need for a prereqs extension point). 
SX> - You only need to say "when someone asks for service X,
SX> create it using factory Y". When it comes time to create an X, the
SX> factory will ask for any services it needs, which get created
SX> dynamically.
SX> - One standard factory, "ReflectionFactory" creates objects
SX> using constructor injection. It would also be possible to write a
SX> setter-injection factory or factories that are specific to a
SX> particular service.
SX> - Although the factories are framework-aware, the objects
SX> they create can truly be POJOs with no framework awareness. 

SX> I hope that explains what it can and can't do. If you want to
SX> play with it, you'll find the main IoC container in
SX> org.eclipse.ui.internal.components.framework.Container.

SX> My two cents:

SX> I would not suggest trying to use the same IoC framework for
SX> OSGi services and for createExecutableExtension. The former are
SX> dynamic, so it makes sense to formally declare dependencies
SX> between services in order to defer creation of a service until all
SX> of its dependancies exist. In the case of
SX> createExecutableExtension, everything the object needs will be
SX> available immediately if the code is correctly written. This means
SX> that an IoC framework for createExecutableExtension wouldn't need
SX> all the tiresome metadata for describing service dependencies.
SX> Services can just ask for their dependencies the first time they
SX> need them.

SX> If this were to be seriously considered for inclusion in
SX> core, I would want to trim a lot of fat first.

SX> Example usage:

SX> class Cat {
SX>       String catName;
SX>       Cat(String name) {
SX>           catName = name;
SX>       };
SX>  }
SX>  class Dog {
SX>       Cat theCat;
SX>       Dog(Cat toChase) {
SX>           theCat = toChase;
SX>       }
SX>       public chaseCat() {
SX>           System.out.println("Chasing " + theCat.getName());
SX>       }
SX>  }
SX>  ...
SX> public static void main(String[] args) {
SX>       // Create a context that knows how to create Dogs. Any time it needs a Cat,
SX>       // it will refer to poor Fluffy.
SX>       FactoryMap context = new FactoryMap()
SX>           .add(Dog.class, new ReflectionFactory(Dog.class))
SX>           .addInstance(Cat.class, new Cat("Fluffy"));
SX>       // Create a container for a particular Dog 
SX>       Container container = new Container(context);
SX>       try {
SX>           // Create a Dog
SX>           Dog myDog = (Dog)container.getService(Dog.class);
SX>           // Chase Fluffy around
SX>           myDog.chaseCat();
SX>       } catch (ComponentException e) {
SX>           // We weren't able to create the Dog
SX>           System.out.println(e.toString());
SX>       } finally {
SX>           // Clean up the container when no longer needed
SX>           container.dispose();
SX>       }
SX>  }

SX> Pascal Rapicault/Ottawa/IBM
SX> 11/22/2005 10:04 PM
SX> To
SX> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
SX> Stefan Xenos/Ottawa/IBM@IBMCAcc
SX> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
SX> equinox-dev-bounces@xxxxxxxxxxxxxxxxxx
SX> RE: [equinox-dev] Roadmap?Link

SX> If I remember correctly, the design of the support for
SX> nesting UI component was based of an IoC container and it had
SX> nothing UI specific.
SX> It would be good to see if we could actually reuse some of
SX> the work that had been done there.
SX> Stephan, am I completly smoking? Would you be able to provide
SX> us with some usefull pointers so people can explore?

SX> Thanks, 

SX> PaScaL

SX> Jeff McAffer/Ottawa/IBM@IBMCA
SX> Sent by: equinox-dev-bounces@xxxxxxxxxxx
SX> 11/22/2005 09:52 PM
SX> Please respond to
SX>  Equinox development mailing list

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

SX>  First an answer to your last questions.  Yes, anything that
SX> makes writing components easier is very much of interest here.
SX>  Rather than creating new programming idioms and mechanisms it
SX> would be interesting, as you have been doing, to investigate all
SX> possible avenues.  If in the end there is truly something new
SX> here, it may make sense to supply a library/bundle.

SX>  I will offer an alternative that *may* make sense. It is
SX> something that we have been playing with.  In the Eclipse
SX> extension registry it is possible to create executable extensions
SX> via a factory (see
SX> IConfigurationElement.createExecutableExtension() and
SX> IExecutableExtensionFactory).  So your IoC framework could publish
SX> an extension point "prereqs" (for lack of a better name).  People
SX> who have prereqs (services in your example) to register can then
SX> supply extensions that identify either the actual class to
SX> instantiate (if the simple no-arg constructor is enough) or an
SX> IExecutableExtensionFactory (with args) if more complicated
SX> construction is needed.  

SX>  In the IoC mechanism (com.example.ioc)
SX>  <extension-point id="prereqs"/>

SX>  In the provider JAR (org.example.provider).
SX>  <extension id="prereq1" point="com.example.ioc.prereqs">
SX>   <prereq
SX>       class="org.example.Factory:coolObject"
SX>   ...

SX>  This extension says run the org.example.Factory and tell it
SX> to create the thing called "coolObject".  The factory can be as
SX> simple or as complicated as you like.  You can make some generic
SX> factories and share them or make one per thingie you want to
SX> create.  You can also pass in an arbitrary number of args
SX> statically declared on in the extension (see the Javadoc for
SX> details).

SX>  You then have two choices for when the contributed
SX> prerequisites are actually instantiated and supplied to consumers;
SX> lazily or aggressively.  If you go for the lazy approach then your
SX> POJO could access the prereq on demand using something like
SX>         Object IoC.getPrereq(String prereqName, Object objectToInject)
SX>  where the prereqName is the id of the extension to
SX> instantiate (org.example.provider.prereq1 in the above example).
SX>  (not really a POJO if it is referencing IoC but you seemed fine
SX> with this in your example...)  This ends up being implemented as a
SX> call to IConfigurationElement.createExecutableExtension().  The
SX> prereq object is only instantiated as needed.  When you stop using
SX> it, just drop the pointer. I believe previously you stated that
SX> lifecycle was not important so the disappearance of the provider
SX> should not be an issue.

SX>  If you want to create the instances aggressively then the
SX> IoC mechanism should have the sort of registerDependency method
SX> you outlined.  It should also implement an IRegistryChangeListener
SX> that listens for new extensions being added to the "prereqs"
SX> extension point.  When it sees one that someone has registered an
SX> interest in, it calls createExecutableExtension and uses the
SX> supplied setter.  If it later sees the extension going away, it
SX> can unset the value.  See IExtensionTracker for some utilities to
SX> help manage this.

SX>  Some notes:
SX>  - You are probably thinking that this is crazy, the
SX> extension registry is buried deep in Eclipse.  Wrong!  As of
SX> today's integration build it is actually broken out in its own
SX> bundle (org.eclipse.equinox.registry) and the intention it that it
SX> run on any OSGi R4 implementation (we've not tested that part yet).

SX>  - So you are still thinking, "but its based on OSGi".  Yes
SX> and No.  It is pluggable.  You can customize the implementation of
SX> the registry to suite different sources of declarations (e.g.,
SX> something other than plugin.xml), different namespace management
SX> policies and different mechanisms for implementing
SX> createExecutableExtension.  We supply an OSGi registry strategy
SX> but you can supply one of your own.  The usecases that are driving
SX> this new structure are quite similar to your hosted and client
SX> scenarios.

SX>  - The ability to supply dynamic context objects to
SX> createExecutableExtension is currently not implemented.  We
SX> discussed this late in 3.1 but opted out.  This topic has been
SX> raised again and we are certainly open to adding it.

SX>  - I've thought about this exact problem for about as long as
SX> it took me to write this response so I could be completely out to
SX> lunch here...

SX>  Jeff

SX> "John Wells" <jwells@xxxxxxx>
SX>  Sent by: equinox-dev-bounces@xxxxxxxxxxx
SX> 11/22/2005 04:00 PM

SX> Please respond to
SX>  Equinox development mailing list

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

SX>  Yes, the code using the LogService would have to explicitly
SX> check (with a synchronized block) whether or not the logger
SX> exists.  The code would be something like:
SX>  LogService localLogger;
SX>  synchronized (this) {
SX>   localLogger = logService;
SX>  }
SX>  If (localLogger != null) {
SX>   localLogger("This is fun!!!");
SX>  }
SX>  This will work whether or not we are in the OSGi environment.
SX>  Also very interesting "trick" to getting the bundle.
SX>  Thanks.  I wish there was a more "framework independent" way to
SX> do this.
SX>  My more general question remains though:  is this a
SX> requirement that more people than me have faced?  Would a Dynamic
SX> IoC utility be of interest to the OSGi community?  At this point
SX> I'm writing this thing anyway, I just want to know if people here
SX> would be interested in me contributing the code?  Since this is a
SX> utility (of course it would be a Bundle as well) I'm not exactly
SX> sure where the proper place would be to put such a thing, or if
SX> people are even interested in such a facility. 
SX>  John Wells (Aziz)
SX>  jwells@xxxxxxx

SX>  From: equinox-dev-bounces@xxxxxxxxxxx
SX> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeremy
SX> Volkman
SX>  Sent: Tuesday, November 22, 2005 2:57 PM
SX>  To: Equinox development mailing list
SX>  Subject: Re: [equinox-dev] Roadmap?
SX>  John,

SX>  When writing a component to be environment-agnostic, how do
SX> you handle the case when LogService may not be available at the
SX> time of your POJO's instantiation (only in the OSGi environment,
SX> of course)?  Will the programmer have to explicitly check the
SX> value of the logger member before attempting to use it?   If so,
SX> doesn't this go against your wishes that the programmer not care
SX> what environment he/she is writing for? 

SX>  Also, on getting a caller's BundleContext: it is possible,
SX> but it get ugly.  I had to do something similar to get per-bundle
SX> logging working with the Apache Commons Logging API.  Commons
SX> Logging provides the static LogFactory class to get Log instances,
SX> and I wanted Log instances to know which Bundle had created them
SX> (so I could print out the name of the Bundle logging a message).  

SX>  One way would be to include a separate copy of my modified
SX> LogFactory class with each bundle, and provide the Bundle's
SX> personal LogFactory instance with a reference to the Bundle at
SX> start up, but this seemed like a maintenance nightmare, and it
SX> negated OSGi's nifty code sharing feature. 

SX>  So i went with the following approach:

SX>  1. Subclass SecurityManager and gain access to the getClassContext() method
SX>  2. Pick the Class of the caller off the stack
SX>  3. Use OSGi's PackageAdmin and its getBundle(
SX> java.lang.Class) method to get the Bundle containing a particular
SX> class

SX>  Since the BundleContext instance is supposed to be private
SX> to its associated Bundle, OSGi provides no way of getting a
SX> BundleContext for a given Bundle (the DS spec mentions this).
SX>  With Equinox, this can be done through reflection, as Equniox's
SX> AbstractBundle class defines a method "getContext": 
SX>   Bundle bundle = ...
SX>   Method contextMethod =
SX> bundle.getClass().getDeclaredMethod("getContext", (Class[]) null);
SX>   contextMethod.setAccessible(true);
SX>   BundleContext context = (BundleContext)
SX> contextMethod.invoke(bundle, (Object[]) null);

SX>  Of course there are numerous possible issues with this
SX> method (can't create new SecurityManagers, can't change Method
SX> accessibility, etc.), but perhaps it will be food for thought. 

SX>  Jeremy Volkman

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

SX> From:equinox-dev-bounces@xxxxxxxxxxx [mailto:
SX> equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Olivier Gruber
SX>  Sent: Tuesday, November 22, 2005 12:26 PM
SX>  To: Equinox development mailing list
SX>  Subject: RE: [equinox-dev] Roadmap?

SX>  John,

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

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

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

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

SX>  Just trying to understand. 
SX>  Best regards,

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

SX>  "John Wells" < jwells@xxxxxxx>
SX>  Sent by: equinox-dev-bounces@xxxxxxxxxxx
SX> 11/22/2005 05:25 PM
SX>  Please respond to Equinox development mailing list
SX>        To:        "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
SX>        cc:        
SX>        Subject:        RE: [equinox-dev] Roadmap?

SX>  Yeah I had thought of that too.  I guess I wanted it to be sort of
SX>  "standardized" rather than having to write a layer.  But that's ok.

SX>  So...  then I also need to know if/when the "ServiceTracker" will be
SX>  implemented in Equinox.  Or perhaps it already is, since I can remember
SX>  ServiceTracker from r3?

SX>  John Wells (Aziz)
SX> jwells@xxxxxxx

SX>  -----Original Message-----
SX>  From: equinox-dev-bounces@xxxxxxxxxxx
SX>  [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeremy Volkman
SX>  Sent: Tuesday, November 22, 2005 11:21 AM
SX>  To: Equinox development mailing list
SX>  Subject: Re: [equinox-dev] Roadmap?

SX>  It seems as though you may be able to realize your DDS needs right now
SX>  by using the already-available ServiceTracker.  When
SX>  registerDependency() is called, create a new ServiceTracker with the
SX>  given service information and start it.  Override the addingService()
SX>  and removedService() methods (or provide a ServiceTrackerCustomizer)
SX>  and make these methods call your POJO's setter/unsetter (remember that
SX>  this is a dynamic environment, so you'll probably want an unsetter).
SX>  The only issue is that you'll need to provide ServiceTracker with a
SX>  BundleContext for it to get a ServiceReference.

SX>  Jeremy Volkman

SX>  On 11/22/05, John Wells <jwells@xxxxxxx> wrote:
 >> Yes, I do like the delayed activation part of DS.  Here are some
SX>  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
 >> would instantiate, what I want is something more dynamic.  I want to
SX>  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
SX>  it.
 >> This class would *not* be under the lifecycle control of DS, but would
 >> still be getting the dependent service injected into it appropriately
SX>  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
SX>  appropriate
 >>  * service becomes "available", but objectToInject is *not* under the
 >>  * specific control of the DS framework
 >>  * Note:  There are likely other "registerDependency" verbs that
SX>  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
SX>  on
 >>  * @param setterName The name of the setter - a public void method
SX>  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
SX>  Services
 >> :-) I am also not very familiar with GBeans. But DS does fully
SX>  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
SX>  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
SX>  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
SX>  _______________________________________________
SX>  equinox-dev mailing list
SX> equinox-dev@xxxxxxxxxxx
SX> https://dev.eclipse.org/mailman/listinfo/equinox-dev

SX>  _______________________________________________
SX>  equinox-dev mailing list
SX> equinox-dev@xxxxxxxxxxx
SX> https://dev.eclipse.org/mailman/listinfo/equinox-dev

SX>  _______________________________________________
SX>  equinox-dev mailing list
SX> equinox-dev@xxxxxxxxxxx
SX> https://dev.eclipse.org/mailman/listinfo/equinox-dev

SX>   _______________________________________________
SX>  equinox-dev mailing list
SX>  equinox-dev@xxxxxxxxxxx
SX>  https://dev.eclipse.org/mailman/listinfo/equinox-dev
SX> _______________________________________________
SX>  equinox-dev mailing list
SX>  equinox-dev@xxxxxxxxxxx
SX>  https://dev.eclipse.org/mailman/listinfo/equinox-dev


Peter Kriens                              Tel +33870447986
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599

equinox-dev mailing list