Home » Eclipse Projects » Equinox » When is a plugin a dependency of another...
| When is a plugin a dependency of another... [message #33618] |
Thu, 15 January 2004 17:42  |
Eclipse User |
|
|
|
> I am trying to understand the way in which eclipse supports plugin
> dependencies. I see how a plugin (at least in the old plugin.xml way, not
> sure about the OSGi manner in which this occurs) can require one or more
> plugins. This as I understand somehow takes the "dependent" plugins
> classloader and adds it somehow/somewhere to the plugin that requests them
> as dependencies, within its classloader. This way, if any bit of code in
the
> plugin uses any class from any other plugin that is "required", the
plugin's
> classloader can delegate to the dependent plugin when the class is not
found
> within its classpath. Is this correct?
>
> What about extension points and extensions? When an extension point uses
an
> extension, I take it because each extension implements the interface the
> extension provides, the extension point is NOT dependent, or IS dependent
on
> each extension plugin? In the new dynamic model, if the extension point
> plugin is unloaded or reloaded, shouldn't all extension plugins be
notified
> that an extension point they rely on is being unloaded/reloaded? Some of
> those extensions may be left "hanging around" if the extension point they
> registered to is unloaded. Does the engine determine this as it unloads a
> plugin and thus notifies the extension plugin that the extension is no
> longer needed, so that if that plugin does nothing else (has no
> extensions/extension points, uses no other classes, no other plugins
depend
> on it, etc), it can go back into a "pre-active" state, as if it was never
> activated? Or does it just linger around until the application shuts down?
>
> And the reverse, do extensions depend on an extension point such that each
> extension plugin classloader must have a ref or delegate to the extension
> point classloader? I assume this must be the case. In order for each
> extension to implement the interface of an extension point AND for the
> extension point to use each of those implementations, ALL the classloaders
> involved must see/use a single definition, otherwise they would be seen as
> different Class objects, even if they are using the same .class file on
> disk. So I take it as an extension is resolved to an extension point, the
> engine must somehow notify the extension point that an extension has been
> added (or removed if that occurs), and somehow when the extension point
code
> needs any of the extension classes that implement its interface, it makes
> use of the createExecutableExtension() method. If each classloader doesn't
> maintain a list of "dependent" loaders it will use to find classes from
> dependent plugins, does the createExecutableExtension() method take on the
> responsibility for figuring out the classname and the extension plugin it
> belongs to, then somehow figures out the extension point to delegate the
> lookup to? That is, if plugin A provides extension point EPA, and plugin B
> and C both provide extensions to EPA and implement interface EPAI (EPA
> interface), plugins B's and C's classloader, when resolving the class that
> implements EPAI, needs to find the definition of EPAI in order to resolve
> the class that implements it in each of B and C. So, at runtime, when B's
> classloader finds the BEPAIImpl class, before it can return the Class
> BEPAImpl instance, it needs to find the EPAI interface to resolve
BEPAIIMpl,
> correct? It does this how, exactly?
>
> With all that I have asked, how does OSGi handle the same situation? Does
it
> do similar to Eclipse in that it's bundle manifest indicates other bundles
> it depends on by name/id? How are different versions of the same plugin
> handled if they have the same unique name or ID..which one wins or does it
> support multiple versions of the same plugin?
>
> Thanks.
|
|
|
| Re: When is a plugin a dependency of another... [message #33653 is a reply to message #33618] |
Thu, 15 January 2004 19:01  |
| Eclipse User |
|
|
|
In OSGi, bundles have no concept of direct dependence between bundles.
Instead, each bundle lists the services and packages it expects to be
registered by other bundles via the "Import-Package" and "Import-Service"
headers. On the opposite side, a bundle lists what services and packages
it plans to export via "Export-Package" and "Export-Service". Thus, there
are no hard dependencies between bundle implementations. As long as some
bundle provides your imported packages your bundle will be happy.
As far as classloaders go, each bundle gets its own classloader. If a
bundle has declared a package via "Import-Package", its classloader will
attempt to get those classes from a classloader whose bundle has declared
it via "Export-Package". Collisions are resolved on a first bundle to be
installed basis.
Hope that helps. I couldn't make it through your post without getting
cross-eyed, so you might want to check out the OSGi spec at
http://www.osgi.org.
spiderman wrote:
> > I am trying to understand the way in which eclipse supports plugin
> > dependencies. I see how a plugin (at least in the old plugin.xml way, not
> > sure about the OSGi manner in which this occurs) can require one or more
> > plugins. This as I understand somehow takes the "dependent" plugins
> > classloader and adds it somehow/somewhere to the plugin that requests them
> > as dependencies, within its classloader. This way, if any bit of code in
> the
> > plugin uses any class from any other plugin that is "required", the
> plugin's
> > classloader can delegate to the dependent plugin when the class is not
> found
> > within its classpath. Is this correct?
> >
> > What about extension points and extensions? When an extension point uses
> an
> > extension, I take it because each extension implements the interface the
> > extension provides, the extension point is NOT dependent, or IS dependent
> on
> > each extension plugin? In the new dynamic model, if the extension point
> > plugin is unloaded or reloaded, shouldn't all extension plugins be
> notified
> > that an extension point they rely on is being unloaded/reloaded? Some of
> > those extensions may be left "hanging around" if the extension point they
> > registered to is unloaded. Does the engine determine this as it unloads a
> > plugin and thus notifies the extension plugin that the extension is no
> > longer needed, so that if that plugin does nothing else (has no
> > extensions/extension points, uses no other classes, no other plugins
> depend
> > on it, etc), it can go back into a "pre-active" state, as if it was never
> > activated? Or does it just linger around until the application shuts down?
> >
> > And the reverse, do extensions depend on an extension point such that each
> > extension plugin classloader must have a ref or delegate to the extension
> > point classloader? I assume this must be the case. In order for each
> > extension to implement the interface of an extension point AND for the
> > extension point to use each of those implementations, ALL the classloaders
> > involved must see/use a single definition, otherwise they would be seen as
> > different Class objects, even if they are using the same .class file on
> > disk. So I take it as an extension is resolved to an extension point, the
> > engine must somehow notify the extension point that an extension has been
> > added (or removed if that occurs), and somehow when the extension point
> code
> > needs any of the extension classes that implement its interface, it makes
> > use of the createExecutableExtension() method. If each classloader doesn't
> > maintain a list of "dependent" loaders it will use to find classes from
> > dependent plugins, does the createExecutableExtension() method take on the
> > responsibility for figuring out the classname and the extension plugin it
> > belongs to, then somehow figures out the extension point to delegate the
> > lookup to? That is, if plugin A provides extension point EPA, and plugin B
> > and C both provide extensions to EPA and implement interface EPAI (EPA
> > interface), plugins B's and C's classloader, when resolving the class that
> > implements EPAI, needs to find the definition of EPAI in order to resolve
> > the class that implements it in each of B and C. So, at runtime, when B's
> > classloader finds the BEPAIImpl class, before it can return the Class
> > BEPAImpl instance, it needs to find the EPAI interface to resolve
> BEPAIIMpl,
> > correct? It does this how, exactly?
> >
> > With all that I have asked, how does OSGi handle the same situation? Does
> it
> > do similar to Eclipse in that it's bundle manifest indicates other bundles
> > it depends on by name/id? How are different versions of the same plugin
> > handled if they have the same unique name or ID..which one wins or does it
> > support multiple versions of the same plugin?
> >
> > Thanks.
|
|
|
| Re: When is a plugin a dependency of another... [message #33683 is a reply to message #33653] |
Thu, 15 January 2004 19:49 |
| Eclipse User |
|
|
|
I think that basically means that each bundle classloader somehow maintains
a list of references to other bundle classloaders that are imported? Whether
each bundle classloader has it's own list, or at runtime whenever the
loadClass() is called it does a delegation to the imported bundle
classloaders to find classes within it. I take it this means that a bundle
that imports another bundle can use ANY class within that bundle? Is this
resolved as the loadclass() is called? Or is this resolved at load time so
at runtime as classes are being asked by the JVM to be found, it can quickly
look in any "dependent or delegate" bundle loaders for the classes it needs?
Thanks.
"Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
news:bu79lg$319$1@eclipse.org...
> In OSGi, bundles have no concept of direct dependence between bundles.
> Instead, each bundle lists the services and packages it expects to be
> registered by other bundles via the "Import-Package" and "Import-Service"
> headers. On the opposite side, a bundle lists what services and packages
> it plans to export via "Export-Package" and "Export-Service". Thus, there
> are no hard dependencies between bundle implementations. As long as some
> bundle provides your imported packages your bundle will be happy.
>
> As far as classloaders go, each bundle gets its own classloader. If a
> bundle has declared a package via "Import-Package", its classloader will
> attempt to get those classes from a classloader whose bundle has declared
> it via "Export-Package". Collisions are resolved on a first bundle to be
> installed basis.
>
> Hope that helps. I couldn't make it through your post without getting
> cross-eyed, so you might want to check out the OSGi spec at
> http://www.osgi.org.
>
>
> spiderman wrote:
>
> > > I am trying to understand the way in which eclipse supports plugin
> > > dependencies. I see how a plugin (at least in the old plugin.xml way,
not
> > > sure about the OSGi manner in which this occurs) can require one or
more
> > > plugins. This as I understand somehow takes the "dependent" plugins
> > > classloader and adds it somehow/somewhere to the plugin that requests
them
> > > as dependencies, within its classloader. This way, if any bit of code
in
> > the
> > > plugin uses any class from any other plugin that is "required", the
> > plugin's
> > > classloader can delegate to the dependent plugin when the class is not
> > found
> > > within its classpath. Is this correct?
> > >
> > > What about extension points and extensions? When an extension point
uses
> > an
> > > extension, I take it because each extension implements the interface
the
> > > extension provides, the extension point is NOT dependent, or IS
dependent
> > on
> > > each extension plugin? In the new dynamic model, if the extension
point
> > > plugin is unloaded or reloaded, shouldn't all extension plugins be
> > notified
> > > that an extension point they rely on is being unloaded/reloaded? Some
of
> > > those extensions may be left "hanging around" if the extension point
they
> > > registered to is unloaded. Does the engine determine this as it
unloads a
> > > plugin and thus notifies the extension plugin that the extension is no
> > > longer needed, so that if that plugin does nothing else (has no
> > > extensions/extension points, uses no other classes, no other plugins
> > depend
> > > on it, etc), it can go back into a "pre-active" state, as if it was
never
> > > activated? Or does it just linger around until the application shuts
down?
> > >
> > > And the reverse, do extensions depend on an extension point such that
each
> > > extension plugin classloader must have a ref or delegate to the
extension
> > > point classloader? I assume this must be the case. In order for each
> > > extension to implement the interface of an extension point AND for the
> > > extension point to use each of those implementations, ALL the
classloaders
> > > involved must see/use a single definition, otherwise they would be
seen as
> > > different Class objects, even if they are using the same .class file
on
> > > disk. So I take it as an extension is resolved to an extension point,
the
> > > engine must somehow notify the extension point that an extension has
been
> > > added (or removed if that occurs), and somehow when the extension
point
> > code
> > > needs any of the extension classes that implement its interface, it
makes
> > > use of the createExecutableExtension() method. If each classloader
doesn't
> > > maintain a list of "dependent" loaders it will use to find classes
from
> > > dependent plugins, does the createExecutableExtension() method take on
the
> > > responsibility for figuring out the classname and the extension plugin
it
> > > belongs to, then somehow figures out the extension point to delegate
the
> > > lookup to? That is, if plugin A provides extension point EPA, and
plugin B
> > > and C both provide extensions to EPA and implement interface EPAI (EPA
> > > interface), plugins B's and C's classloader, when resolving the class
that
> > > implements EPAI, needs to find the definition of EPAI in order to
resolve
> > > the class that implements it in each of B and C. So, at runtime, when
B's
> > > classloader finds the BEPAIImpl class, before it can return the Class
> > > BEPAImpl instance, it needs to find the EPAI interface to resolve
> > BEPAIIMpl,
> > > correct? It does this how, exactly?
> > >
> > > With all that I have asked, how does OSGi handle the same situation?
Does
> > it
> > > do similar to Eclipse in that it's bundle manifest indicates other
bundles
> > > it depends on by name/id? How are different versions of the same
plugin
> > > handled if they have the same unique name or ID..which one wins or
does it
> > > support multiple versions of the same plugin?
> > >
> > > Thanks.
>
>
|
|
|
| Re: When is a plugin a dependency of another... [message #33871 is a reply to message #33683] |
Fri, 16 January 2004 10:25 |
| Eclipse User |
|
|
|
Actually, package sharing can only happen with those packages and resource
declared in the Export-Package and Import-Package. Any package not
declared in these headers is local to the bundle. Implementations vary,
but the framework is responsible for managing all of this. You should
check out the spec at http://www.osgi.org/resources/spec_download.asp. It
goes into detail about this and explains it better than I do.
spiderman wrote:
> I think that basically means that each bundle classloader somehow maintains
> a list of references to other bundle classloaders that are imported? Whether
> each bundle classloader has it's own list, or at runtime whenever the
> loadClass() is called it does a delegation to the imported bundle
> classloaders to find classes within it. I take it this means that a bundle
> that imports another bundle can use ANY class within that bundle? Is this
> resolved as the loadclass() is called? Or is this resolved at load time so
> at runtime as classes are being asked by the JVM to be found, it can quickly
> look in any "dependent or delegate" bundle loaders for the classes it needs?
> Thanks.
|
|
|
Goto Forum:
Current Time: Tue Nov 04 11:10:40 EST 2025
Powered by FUDForum. Page generated in 0.08357 seconds |
Home