Re: [eclipse-incubator-e4-dev] Extension registry evolution - cross-post

[Oleg Besedin <obesedin@xxxxxxxxxx>]

Thank you for bringing this up. Riena
definitely has an interesting approach to the extension registry. 

It seems that the basic difference is
in how injected objects are created: Riena creates an interface-based object
instantiated as a proxy to the IConfigurationElement. I am thinking about
creating an actual Java object based on the data in the IConfigurationElement.
>From what I see in Riena's code, it builds:

UserClass 
   [containing UserInterface

      [instantiated as
Proxy 
         [backed
up by IConfigurationElement]]]

I'd rather have:

UserClass <= with data injected at
the time ExtensionRegistry.getObjects() is called

One upside to the "proxy"
approach is that data is lazily populated from the IConfigurationElement
into the UserClass. However, this process should be relatively fast as
the data is already in memory (unless contained elements have expensive
constructors). I'd guess that for simple elements the levels of indirection
added by the proxy likely going to offset performance benefits from the
lazy initialization. Also, the code in the UserClass would have to obtain
data through the UserInterface adding an extra layer.

Are there other advantages to the proxy-based
approach?

Annotations: In my quick search through
the code I was not able to figure out how much Riena’s processing depends
on annotations. It seems that all references to this mechanism use annotations,
but some comments in Javadoc implied that annotations are optional (but
"highly recommended" :-))?

Another interesting difference is that
Riena obtains element types either as arguments (for top-level elements)
or from UserInterface signatures (for child elements). For my proposal,
as it needs to use schema files anyway (can't rely on annotations), I was
thinking about describing types in the schema file.

Thanks,
Oleg

Christian Campo <christian.campo@xxxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

09/30/2008 03:51 AM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To	E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-incubator-e4-dev] Extension registry evolution -        cross-posted from equinox-dev

Hi,

I think having IConfigurationElements mapped to actual
Java objects is a very good idea. The Riena project is using that now for
roughly 4 month with an implementation in its codebase that allows to

- create Java objects from Extensions
- define Interfaces for the ExtensionPoint schema
- inject the Java Objects into any object that is interested
in its information (making the using code independant of extensions but
simply dependant on the interface object)
- automatically re-injects the Objects if extensions are
added or removed (by installing uninstalling bundles)
- create java instances for those attributes where the
type is java

Riena has defined an API that uses Extensions and OSGi
Services in a very similar way. You can inject Services or Extensions using
one API. We have a short not yet complete description in the wiki http://wiki.eclipse.org/Riena_Getting_Started_with_injecting_services_and_extensions

and of course the code is in the latest M4 build of Riena
(http://wiki.eclipse.org/Riena_Getting_started)
and we have quite a number of Testcases to show how injecting Extensions
and Services works using the API.

cheers

christian campo

Am 24.09.2008 um 21:20 schrieb Oleg Besedin:


[Cross-posted from the equinox-dev@xxxxxxxxxxx]

What would you like to see in the extension registry 2010?

If you have an opinion on how the extension registry can be improved, please
visit: 

        http://wiki.eclipse.org/Equinox_Extension_Registry_Work

        https://bugs.eclipse.org/bugs/show_bug.cgi?id=248340

and leave your comments! 

So far we have identified several potential areas:

- Create typed Java objects instead of forcing you to crawl through IConfigurationElements
 (see http://wiki.eclipse.org/Equinox_Extension_Registry_Work_Objects
for details) 
- Expand ability to programmatically modify extension registry
- Add support for non-singleton bundles 

Does this sound like something you'd like to see in Eclipse? 

(Please use this mailing list for general discussions and bug / wiki for
more detailed comments.) 

Thanks, 
Oleg 
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev