[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Extension registry evolution

Thank you for the comments, lots of good points.

=> IRegistryObject <=

> (2) IRegistryObject is odd - can you not split this into two
> interfaces that we would recommend are being used whenever objects
> need to be initialized, or disposed?

Yes, this makes sense, let's split it into IDisposable and IInitializable.

On the subject of using reflection instead of the IRegistryObject:

+ it would remove dependency on container code [as pointed by Heiko]
- it generally makes code harder to read [as pointed by Gunnar]

Both are good arguments. I think that if we put IDisposable and IInitializable into "org.eclipse.equinox.common" it might help with the arguments of having container-dependent code.

=> Existing DI frameworks <=

> What about existing dependency injection frameworks? ... Wouldn't it
> be good if clients could specify which dependency injection mechanism
> they would like to be used?

One problem with the current DI frameworks is that they are complicated to use (some are better than others). Moreover, frameworks are different enough in the injection styles, bootstrapping, multiplicity and concurrency support that if we try to provide a common meta-DI framework, it will end up being something really complicated. Which would be the opposite of the intention here - providing a simple to use mechanism for simple everyday tasks.

I did play a bit with the idea of having a DI framework added on top of the registry. On a design level that seemed to be overdone as the extension registry in essence is a DI framework that injects data from extensions into extension points. On an implementation level, from about half dozen open-source frameworks I looked at, none seemed to be a good fit. There were multiple reasons, most important being ease of use, support for pre-1.5 VMs, ability to work with OSGi bundles as containers, and active community.

So, interesting idea, but I am not sure how practical it is.

> In Riena we have a simple approach for injecting extensions into target objects. This is similar to DI but not for services but for data.

Yes, thank you, I'll look into this.

=> Single context object <=

> I don't like that clients cannot provide more than just one single
> "context" object.

Good point. I did this for simplicity as having only one argument eliminates the need to match constructor arguments. If we were to support multiple arguments we'd have to add a new construct to the extension point schema - something like
        <argument position = "1" name = "name_of the_attribute_from_plugin_xml"/>
        <argument position = "2" name = "name_of the_attribute_from_plugin_xml"/>

This is probably worth supporting as an option.

=> Annotations and VM support <=

Annotations would be really nice to use. As an example take be the topic above ("single context object"): annotations could have been used to tie constructor arguments to the XML attributes.  

However, Eclipse SDK runs on 1.4 and the position of the extension registry in the Eclipse stack does not give us much freedom. We'll have to support pre-1.5 VMs at least in the 3.x stream, there is no choice. As such any functionality based on annotations would have to be optional.

=> Timeline; E4 <=

> Is there any progress in relation to e4? I understand that this is a work item on the e4 list.

I think that sometime before the end of 3.5M6 we'll look at what's available and how stable that code is. Personally, I'd expect some of the enhancements to get into 3.5, but not all. As for the relation to E4's dependency injection item - yes, I'd consider this to be one of the aspects of it. There are two mechanisms in Eclipse that could use improved DI support: extension registry and OSGi services. I don't think that either one of them is going to go away any time soon. Rather both have their roles. For the dependency injection:

- the extension registry: while it might not look like a conventional DI framework, in spirit it is very similar. The functionality gets obscured by registry artifacts as pieces that gets injected are IConfigurationElements / IExtensions. With this enhancement the actual Java typed objects will be injected using method/field injection; and an optional "context" elements will be injected via constructors.  

- for the OSGi services I believe that Declarative Services would be the best fit in terms of adding DI mechanism. From the mailing lists it seems that there is a fair amount of activity both on PDE tooling support for DS and on the DS itself.