[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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>       
SX>       Cat(String name) {
SX>           catName = name;
SX>       };
SX>  }
SX>   
SX>  class Dog {
SX>       Cat theCat;
SX>  
SX>       Dog(Cat toChase) {
SX>           theCat = toChase;
SX>       }
SX>       
SX>       public chaseCat() {
SX>           System.out.println("Chasing " + theCat.getName());
SX>       }
SX>  }
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>       
SX>       // Create a container for a particular Dog 
SX>       Container container = new Container(context);
SX>       
SX>       try {
SX>           // Create a Dog
SX>           Dog myDog = (Dog)container.getService(Dog.class);
SX>       
SX>           // Chase Fluffy around
SX>           myDog.chaseCat();
SX>           
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>    
SX>  LogService localLogger;
SX>  synchronized (this) {
SX>   localLogger = logService;
SX>  }
SX>    
SX>  If (localLogger != null) {
SX>   localLogger(?This is fun!!!?);
SX>  }
SX>    
SX>    
SX>  This will work whether or not we are in the OSGi environment.
SX>    
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>    
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>    
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>    
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>            
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>  
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>  
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>  
SX> Let's take something as simple as a log service.  I want to
SX> have a pojo that says something like:
SX>  
SX> private LogServer logger;
SX>  
SX> ?
SX>  
SX> // inside some method of my pojo
SX> IoC.createDependency("com.acme.LogService", "setLogger", this);
SX>  
SX> ?
SX>  
SX> public synchronized void setLogger(com.acme.LogService logger) {
SX>   this.logger = logger;
SX> } 
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>  
SX> public interface GenericFactory<T> {
SX>   public <T> create(?);
SX>   public <T> find(?) throws NotFoundException;
SX> }
SX>  
SX> (excuse any typo's, I am typing as I write, not pasting from an IDE ;-)
SX>  
SX> Now instead our IoC object might look like this:
SX>  
SX> private LogFactory logFactory = new LogFactory();   //
SX> Implements the GenericFactory interface
SX> private LogServer logger;
SX>  
SX> ?
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> ?
SX>  
SX> public synchronized void setLogger(com.acme.LogService logger) {
SX>   this.logger = logger;
SX> } 
SX>  
SX> The signature for createDependency would be something like:
SX>  
SX> public Object createDependency(String serviceName, String
SX> setterName, GenericFactory staticFactory, ?);
SX>  
SX> where the extra arguments are used in the find/create methods of the factory.
SX>  
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>  
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>  
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>  

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>         
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
SX>  DS
 >> 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