| Instantiating non-imported classes in OSGi [message #20501] |
Sun, 06 April 2003 16:44 |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
I've been thinking about how to do extensions and extension-points in an
OSGi style environment. I think I am missing something. Worse, it feels like
it is obvious but I just don't get it...
Assume plugin A defines extension point P and plugin B defines an extension
for P called E. Further, assume that E is an "executable extension". That
is, it identifies a class, C, to be run. Note that plugin A in general
does not know about B (i.e., no requires statement). At some point A
decides that it should instantiate the class defined in E. To ground this
in an example, A = UI plugin, P = view extension point E = some view defined
in B.
In OSGi, A does not import any packages from B so it cannot see C. I don't
see any API for getting a bundle's classloader so we can't do a direct call
to load the class. Is there some other explicitly supported way?
Assuming not, one approach might be to have the system define an extension
instantiation Service and then B would provide an implementation of this
service. Since the instantiation implementation is "in" B, it can see C and
instantiate it. Questions:
- does this make sense?
- how do you ensure you get the instantiation service for the bundle/plugin
defining the extension?
- if you use filters for the previous question, is this efficient?
- would it be reasonable for the system to do this (provide an
implementation of the service) automatically?
- does this generalize into something that would be useful to add to OSGi?
I'm thinking of an explicit Extension mechanism which is analogous but
different from the Services mechanism. It would handle the appropriate
lifecycle etc.
Jeff
|
|
|
Powered by
FUDForum. Page generated in 0.02698 seconds
Home