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
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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
|
