Community
Participate
Working Groups
Created attachment 120983 [details] Draft patch for the equinox.registry and core.tests.runtime It would be useful to be able to create a hierarchical contexts and inject them into user objects. The attached patch shows draft implementation split into a "genric" context and, based on it, the extension-registry specific override. Of particular interests are the following APIs: + public interface IContext public void [add/remove/get/has]Object(String objectName) public void injectInto(Object userObject); public IContext newChild(...); (describes functionality of the context objects and allows generation of encolsed contexts) + class ContextFactory public static IContext createContext() (creates a top-level context) + class RegistryContextFactory public static Object createObject(IConfigurationElement confElement, Object[] constructorArgs, IContext context, Map javaClassNames) (creates a user-specified class and injects into it contents of the configuration element and, optionally, the supplied context)
I wonder if the name of the IContext could be more specific to better reflect its anticipated usage, for example, there is a BundleContext, a ServletContext, etc. At CloudFree, we also use IContext but actually mean a runtime dynamic configuration thing. A context delivers different adapters and extensions. Thus, we are thinking about renaming it as well.
Created attachment 121434 [details] Updated patch This is the updated patch. Yes, I agree witht the comment about the IContext name. Highligh from changes from the previous patch: - The generic part of the injections moved into org.eclipse.equinox.common - The IContext is renamed to IEquinoxContext - JUnits added for the registry-specific version - Number of Javadocs added to APIs - Some small fixes mostly around dynamic behavor Still needs to be done: - create an IEquinoxContext subclass that would work with OSGi services - check injecting null values -> see if we can differentiate them from "no values" - add conversion of "-": convert next char in the name to uppercase - add debug options: element injected sucessfully element injection failed due to ... - API cleanup: consider taking Class args rather than class names for mapping (will help with class loading too) add an injection override that takes all arguments but one class name
Note ConfigurationElementFinder uses String.split(), which doesn't match the EE of the registry bundle.
I made some comments directly to Oleg, but I'll mention one here so it doesn't get lost. One limitation of the current implementation is that contexts are relatively dumb objects - someone externally needs to insert all the necessary parameters into the context. It would be nice to be able to have intelligent contexts like a "service registry context", which consists of all registered OSGi services, without requiring anyone to manually build up the contents of the context.
Is it also planned to have an extension registry context which would create objects from extensions? (Does that make any sense at all?) I have one comment regarding IContextAware. The JavaDoc of IEquinoxContext states they they only need to define the method signature but do not need to implement the interface. I wonder if they should be required to implement the interface. They need to import org.eclipse.equinox.context anyway so they already have "polluted" their POJO with IEquinoxContext. If the goal really is to keep the POJO clean from Equinox context injection mechanism then a more generic method name and signature should be used. For example: --- /** * Notifies the receiver that the specified context has been injected. * @param context the injected context */ public void contextInjected(Object context); /** * Notifies the receiver that a previously injected context has been disposed. * @param context the context being disposed */ public void contextDisposed(Object context); --- While writing this I recognized another thing regarding context disposal. Should there be the possibility to unset all the injected "services"? Additionally, what if the context is a smart OSGi service registry context? Shouldn't it be able to inject and remove service objects as they come and go at runtime? Or is the context injection meant to be a one-time/initialization thing?
(In reply to comment #5) > While writing this I recognized another thing regarding context disposal. > Should there be the possibility to unset all the injected "services"? > Additionally, what if the context is a smart OSGi service registry context? > Shouldn't it be able to inject and remove service objects as they come and go > at runtime? Or is the context injection meant to be a one-time/initialization > thing? Ok, scratch that paragraph. After looking at the patch further I realized that it is dynamic already. I got confused by the JavaDoc which says "User objects that want to have an ability to finalize the injected data [...] might want to place such calculations into a method <code>public void equinoxContextSet(IEquinoxContext context) {...}</code>." Because of this I interpreted "equinoxContextDisposed" as a method to "un-finalize" the injected data but it's not. The individual setters need to reconcile an object.
what is the status of this wrt Galileo?
(In reply to comment #7) > what is the status of this wrt Galileo? Due to the workload, unless we have a spark of interest from the community, this looks like e4 item. The code is mostly completed, aside from the items in the comment 2. APIs need polish and, as a result, implementation might need to be restructured (for instance, to separate contexts from injection). Also, John's suggestion (the context lazily filled with OSGi services) would be a very practical addition.
(In reply to comment #5) > Is it also planned to have an extension registry context which would create > objects from extensions? (Does that make any sense at all?) Create objects from extensions - yes, see RegistryContextFactory methods: RegistryContextFactory#createObjects(...,[IEquinoxContext context, ]...) Internally they construct a child context, add into it information from the registry and inject it in the object being created. The child context created in this process is not exposed as API. > I have one comment regarding IContextAware. ... > public void contextInjected(Object context); > public void contextDisposed(Object context); Absolutely! Good catch, I'll change it. > Shouldn't it be able to inject and remove service objects as they come and go > at runtime? Or is the context injection meant to be a one-time/initialization > thing? Yes, contexts support dynamic events. They keep track of objects in which they have been injected (via WeakReference's) and update those objects. So the context can be injected into an object, then a "log" serivice can be removed from the context and another "log" service can be added.
(In reply to comment #8) > [...] implementation might need to be restructured (for > instance, to separate contexts from injection). Are you talking about moving injection related code out of ContextImpl?
Just FYI - I posted some code on bug 257429 yesterday that is related to this exploration. I implemented two extensions to the "tree of key->value maps with prototypical inheritance" model: (1) support for functions, not just values (think JavaScript object model), and (2) a mechanism for propagating updated values automatically, using a two-phase model that solves the "event storm" problem.
A derivative of Oleg's original work implementing his ideas in this bug are now found in e4. Moving this bug accordingly.
Oleg, can this be marked fixed with the context work now in e4? I suppose the missing part from this bug is the extension registry integration. We can either keep this open to track extension registry integration, or enter a separate bug for that.
Marking fixed. Most of this was implemented in e4 long ago. The one missing piece is the RegistryContextFactory that injects a context into an extension during construction. I have entered bug 284357 for this.
