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 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
09/30/2008 03:51 AM
Please respond to
E4 developer list <[email protected]>
To
E4 developer list <[email protected]>
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 [EMAIL PROTECTED]
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
