Hi Oleg,
see comments below.
Oleg Besedin wrote:
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]]]
yes, that is right. The dynamic proxy is responsible for the mapping
from IConfigurationElement to the methods of the UserInterface.
I'd rather have:
UserClass <= with data injected at the time
ExtensionRegistry.getObjects() is called
To be honest I do not completely understand what getObjects() is meant
to do and how it should be used.
Are the instances of class ´ofType´ the analogue to Riena's
UserInterface/Proxy that get returned as a Object[]?
Could you probably sketch some uses cases? Including a
´createExecutableExtension()´ use case.
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
What exactly is the upside? The performance degradation?
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.
Yes, the performance degradation is not that much. I did some measuring
and it was much better than I had feared. Once the data has been
received from the extension registry the proxies cache them.
Are there other advantages to the proxy-based approach?
It is very easy to use.
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" :-))?
The main purpose of the annotations are specifying name mappings
(@MapName), i.e. method names to xml element/attibute name. The ´highly
recommended´ is for annotating the UserInterface as used by the
injection. That is crap - I will remove it.
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.
It can obtain the ´root´ UserInterface type from the UserClass type but
it also possible to specify what UserInterface type should be used:
Inject.extension("extpoint").useType(
UserInterface).into(target).bind("configure").andStart(context);
Do you mean extension point schema files? If so, we could not do that.
Relying on schema files means that they have to be available at runtime, or?
But this is currently not necessary, or?
Thanks,
Oleg
Tschüß,
Stefan
*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)_
<http://wiki.eclipse.org/Riena_Getting_started%29> 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]
<mailto:[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]
<mailto:[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
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
