Home » Eclipse Projects » Equinox » How to write plugins with the new OSGi model
| How to write plugins with the new OSGi model [message #31146] |
Sat, 13 December 2003 01:04  |
 Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Alrighty, so I haven't checked yet, but how are plugins to be written? Do we
do the OSGi bundle method, or continue our normal Eclipse extension model
plugin? What I most want to know about is how we write plugins correctly so
they can be unloaded and reloaded? IS there special events we listen for? I
mean, if my plugin depends on plugin B, and B is being reloaded or unloaded,
does my plugin get unloaded automatically (assuming B is unloaded), or does
it get notified that B is no longer available, and somehow in code I have to
adapt to that? This gets more complex. What if my plugin provides
functionality that others depend on, but to provide that functionality, my
plugin depends on one or more plugins, and one or more of those get
unloaded? Does the unloading go all the way across all chains until no
plugin that is dependent on the one (or more) being unloaded is done? What
about reloading? Two cases I see, it reloads a change that does not break my
plugin, or it reloads and breaks my plugins ability to use it, either via a
new version, a method removal that my plugin relies on, or some other
reason. How is this handled now?
Thanks.
|
|
|
| Re: How to write plugins with the new OSGi model [message #31281 is a reply to message #31146] |
Fri, 19 December 2003 04:30  |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.ca.ibm.com
In the new runtime you can supply bundles or traditional plugins. The only
real distinction is whether you supply a plugin.xml or a manifest.mf and a
bit of packaging. Dynamic behaviour of the classloaders is taken care of by
OSGi. The spec details everything you could want to know. For bundles
supplying extensions and extension points there is a new set of API relating
to extension registry changes. Look for
org.eclipse.core.runtime.ExtensionChangeListener and related types.
There are sure to be some rough edges in the dynamic support as it is both
hard and new. Try it out and let us know what you think and of course, if
you find any bugs, please log a bug report. January will see us spending
sigificant effort to make more of Eclipse dynamic aware/enabled as well as
put together some demo apps to show people how it is done.
Note also that currently you cannot install bundles in jars as per normal
OSGi. They have to be in exploded dirs like plugins. This is a temporary
limitation which will be resolved in January as well.
Enjoy
Jeff
"spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
news:brdocp$v0$1@eclipse.org...
> Alrighty, so I haven't checked yet, but how are plugins to be written? Do
we
> do the OSGi bundle method, or continue our normal Eclipse extension model
> plugin? What I most want to know about is how we write plugins correctly
so
> they can be unloaded and reloaded? IS there special events we listen for?
I
> mean, if my plugin depends on plugin B, and B is being reloaded or
unloaded,
> does my plugin get unloaded automatically (assuming B is unloaded), or
does
> it get notified that B is no longer available, and somehow in code I have
to
> adapt to that? This gets more complex. What if my plugin provides
> functionality that others depend on, but to provide that functionality, my
> plugin depends on one or more plugins, and one or more of those get
> unloaded? Does the unloading go all the way across all chains until no
> plugin that is dependent on the one (or more) being unloaded is done? What
> about reloading? Two cases I see, it reloads a change that does not break
my
> plugin, or it reloads and breaks my plugins ability to use it, either via
a
> new version, a method removal that my plugin relies on, or some other
> reason. How is this handled now?
>
> Thanks.
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #31311 is a reply to message #31281] |
Fri, 19 December 2003 18:35 |
Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
That's kewl. I have built my own plugin engine based around extension
points, extensions, etc. I am not sure why the move to OSGi is so paramount
compared to the well thought out extension point mechanism of Eclipse. I
dislike the idea of using manifest.mf as opposed to plugin.xml. The xml
format is much nicer and easier. In my engine, plugins are
unloadable/reloadable (still working out the kinks as well), and I believe
like Eclipse developers have to be aware of referencing other dependent
plugin classes with class variables as opposed to using temporary variables
within methods, otherwise the GC may never reclaim a plugin's resources.
Reloading is no problem, simply replace the repository of the plugin by its
name/version and all lookups/usages go to the newly loaded code. But the
most important part in my mind is the GC able to reclaim unloaded or
previously loaded when reloaded plugins and resources. Still can't figure
out why the GC only runs when its out of memory, that is rather stupid in my
opinion, it should run every few minutes, verify any dead ends and clean
them up!
Does the use of OSGi bundles allow embeded jars/zips and such such that you
can deploy a single .jar file with embeded .jar/.zip files and it finds the
classes within the embeded jar/zip files without them having to be unzipped
to disk? My engine does this, using a single plugin archive file that
doesn't have to be unzipped to disk. Also, I have made dependencies
automagic, in that a plugin doesn't need to specify the plugins it depends
on. Based on extension points and extensions, as well as events and
listeners, it can figure out the plugin(s) that are dependent automatically.
I do this by simply resolving plugins after each plugin loads. My goal,
before I cam across Eclipse, was to build a reloadable archtiecture like
what JBoss and other app servers have, using a simplified plugin model,
something I devised a few years back using C on a cross-platform project.
Had I known Eclipse was going to become "headless" a while back, i don't
know that I would have ventured down this path. Now that I have, I am
thankful because I have a vastly improved understanding of classpaths,
classloaders, the jvm process of loading classes, class space and how
classloaders can delegate to others to find classes so that only one
bytecode is loaded, etc. I admit to borrowing the extension point idea from
Eclipse, it's a great way of connecting plugins. My original engine simply
used "names" and "versions" to find plugins, so more or less the same thing,
just a little more dependent on specific plugin names that might change
across versions and break dependencies.
Is there any idea how big the "engine" of eclipse is, with OSGi, it's
extension point/extension framework, etc? I thought of doing an OSGi
implementation, but another goal is a very small framework. With everything
that my engine does, its only 44K in size including an xml pull parser that
parses the plugin.xml files and can write xml out that any plugin can use as
well. This includes the code for each plugin to have its own loader, be
contained within a single archive file or on disk like how eclipse plugins
reside, lazy creation of plugins as needed (like eclipse and osgi),
automagic resolution of dependencies for both extension points and
extensions, and events/listeners, the ability to specify specific types of
plugins to be loaded based on Class types, and so on. It is a non-GUI
engine, so it can be used for any purpose, but I am building a UI Framework
on top of it using Swing. Forgive me for saying so, but I dislike SWT and I
think the vast majority of java developers are not going to learn SWT given
that Swing is as good in many respects, better in some, and not as good in
others, but comes with every JRE/JDK deployed as opposed to having to ship
swt.jar and platform specific libraries, as well as a new API to learn.
Therefore I didn't want to base my UI framework around SWT, although it
could easily be done by simply replacing the core plugin and using SWT
instead of Swing. The UI framework will provide a similar paradigm to
Eclipse and other IDE's with a workspace, menu/toolbar, status bar, left
side "task" bar, help facility, preference facility, wizard component, file
chooser component and so forth. All of this is open source as well, and the
goal is not to compete with any other IDE, it is to provide a very small,
super easy to develop for, pluggable UI framework using Swing so that
hopefully I can help bring those 10 million java engineers over that Sun
claims will come! "If you build it they will come" comes ot mind. ;) I am
trying to build it, hoping they'll come and use it!
Anyway, I am glad to see Eclipse is finally going headless and unload/reload
of plugins will be possible! I started doing unload/reload a few months back
before I read that OSGi would be integrated into 3.0. I was surprised to see
that I had done a similar way of notifying plugins. That is, if a plugin
that provides an extension is reloaded, it notifes the plugin that owns the
extension point that the extension is being removed, or added, etc.
Basically, all plugins affected get notified of events, such as unload,
destroy, extension removed/added, extension point removed/added, etc.
"Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
news:brtusv$q7$1@eclipse.org...
> In the new runtime you can supply bundles or traditional plugins. The only
> real distinction is whether you supply a plugin.xml or a manifest.mf and a
> bit of packaging. Dynamic behaviour of the classloaders is taken care of
by
> OSGi. The spec details everything you could want to know. For bundles
> supplying extensions and extension points there is a new set of API
relating
> to extension registry changes. Look for
> org.eclipse.core.runtime.ExtensionChangeListener and related types.
>
> There are sure to be some rough edges in the dynamic support as it is both
> hard and new. Try it out and let us know what you think and of course, if
> you find any bugs, please log a bug report. January will see us spending
> sigificant effort to make more of Eclipse dynamic aware/enabled as well as
> put together some demo apps to show people how it is done.
>
> Note also that currently you cannot install bundles in jars as per normal
> OSGi. They have to be in exploded dirs like plugins. This is a temporary
> limitation which will be resolved in January as well.
>
> Enjoy
> Jeff
>
> "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> news:brdocp$v0$1@eclipse.org...
> > Alrighty, so I haven't checked yet, but how are plugins to be written?
Do
> we
> > do the OSGi bundle method, or continue our normal Eclipse extension
model
> > plugin? What I most want to know about is how we write plugins correctly
> so
> > they can be unloaded and reloaded? IS there special events we listen
for?
> I
> > mean, if my plugin depends on plugin B, and B is being reloaded or
> unloaded,
> > does my plugin get unloaded automatically (assuming B is unloaded), or
> does
> > it get notified that B is no longer available, and somehow in code I
have
> to
> > adapt to that? This gets more complex. What if my plugin provides
> > functionality that others depend on, but to provide that functionality,
my
> > plugin depends on one or more plugins, and one or more of those get
> > unloaded? Does the unloading go all the way across all chains until no
> > plugin that is dependent on the one (or more) being unloaded is done?
What
> > about reloading? Two cases I see, it reloads a change that does not
break
> my
> > plugin, or it reloads and breaks my plugins ability to use it, either
via
> a
> > new version, a method removal that my plugin relies on, or some other
> > reason. How is this handled now?
> >
> > Thanks.
> >
> >
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #31338 is a reply to message #31311] |
Sat, 20 December 2003 02:24 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.ca.ibm.com
Thanks for you continuing interest. You have mentioned your engine
previously but have never provided pointers to where someone can download
and try it or get more information. What is its status?
For you and others, I would like to clarify a few things:
- OSGi bundles/classloaders/etc and the Eclipse extension mechanism are
completely separated notions. The new runtime has both and users will
benefit. OSGi brings dynamic behaviour, services, security etc and Eclipse
retains the power of extensions etc. There is no loss of functionality or
generality in the new runtime, only gain.
- plugin.xml and manifest.mf: neither are particularly easy for developers
to manage without tooling support. Note that only the runtime related
elements of plugin.xml (e.g., <runtime>, <requires>) have moved into the
manifest.mf. The extension related tags retain their original form and
position. As such, in most cases the manifest.mf is actually simpler to
define and maintain than the corresponding section of the plugin.xml.
- OSGi implementations typically manage bundles as jars. I'm pretty sure
that the spec does not absolutely require this but it is implied. The
bundles may contain internal jars for code (or other stuff) and the runtime
is able to put these on the classpath. We have extended the model to allow
for running bundles out of directories (as per standard Eclipse). Eclipse
3.0 will likely ship with plugins in jars as opposed to directories. People
have been asking for this for years and we likely would have done it quite
independent of OSGi uptake. Note however that there is no plan to allow for
multiple bundles to be put in one jar. This would complicate update/install
scenarios and serve little purpose.
- Eclipse has always been "headless". Since day one there have been
essential applications which run in this mode. For example, the Eclipse
build mechanism is a headless Eclipse configuration. Anyone can define
"applications" (using extensions of course) and then run them using
eclispe -application <app id>. It just happens that in Eclipse <= 2.1 there
was a default application which opened a GUI.
- Eclipse extensions/extension-points interactions do not represent
dependency specifications. You can contribute an extension to a plugin on
which you do not depend. As such, when a plugin hosting an extension point
is uninstalled or restarted, plugins providing extensions are not
necessarily shutdown. We purposely kept the dependency mechanism out of
htis area to increase flexibility. Plugins which want/need to have a
tighter relationship are free to specify a classloader dependency via the
<requires> tags.
Jeff
"spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
news:brvge3$k9f$1@eclipse.org...
> That's kewl. I have built my own plugin engine based around extension
> points, extensions, etc. I am not sure why the move to OSGi is so
paramount
> compared to the well thought out extension point mechanism of Eclipse. I
> dislike the idea of using manifest.mf as opposed to plugin.xml. The xml
> format is much nicer and easier. In my engine, plugins are
> unloadable/reloadable (still working out the kinks as well), and I believe
> like Eclipse developers have to be aware of referencing other dependent
> plugin classes with class variables as opposed to using temporary
variables
> within methods, otherwise the GC may never reclaim a plugin's resources.
> Reloading is no problem, simply replace the repository of the plugin by
its
> name/version and all lookups/usages go to the newly loaded code. But the
> most important part in my mind is the GC able to reclaim unloaded or
> previously loaded when reloaded plugins and resources. Still can't figure
> out why the GC only runs when its out of memory, that is rather stupid in
my
> opinion, it should run every few minutes, verify any dead ends and clean
> them up!
>
> Does the use of OSGi bundles allow embeded jars/zips and such such that
you
> can deploy a single .jar file with embeded .jar/.zip files and it finds
the
> classes within the embeded jar/zip files without them having to be
unzipped
> to disk? My engine does this, using a single plugin archive file that
> doesn't have to be unzipped to disk. Also, I have made dependencies
> automagic, in that a plugin doesn't need to specify the plugins it depends
> on. Based on extension points and extensions, as well as events and
> listeners, it can figure out the plugin(s) that are dependent
automatically.
> I do this by simply resolving plugins after each plugin loads. My goal,
> before I cam across Eclipse, was to build a reloadable archtiecture like
> what JBoss and other app servers have, using a simplified plugin model,
> something I devised a few years back using C on a cross-platform project.
> Had I known Eclipse was going to become "headless" a while back, i don't
> know that I would have ventured down this path. Now that I have, I am
> thankful because I have a vastly improved understanding of classpaths,
> classloaders, the jvm process of loading classes, class space and how
> classloaders can delegate to others to find classes so that only one
> bytecode is loaded, etc. I admit to borrowing the extension point idea
from
> Eclipse, it's a great way of connecting plugins. My original engine simply
> used "names" and "versions" to find plugins, so more or less the same
thing,
> just a little more dependent on specific plugin names that might change
> across versions and break dependencies.
>
> Is there any idea how big the "engine" of eclipse is, with OSGi, it's
> extension point/extension framework, etc? I thought of doing an OSGi
> implementation, but another goal is a very small framework. With
everything
> that my engine does, its only 44K in size including an xml pull parser
that
> parses the plugin.xml files and can write xml out that any plugin can use
as
> well. This includes the code for each plugin to have its own loader, be
> contained within a single archive file or on disk like how eclipse plugins
> reside, lazy creation of plugins as needed (like eclipse and osgi),
> automagic resolution of dependencies for both extension points and
> extensions, and events/listeners, the ability to specify specific types of
> plugins to be loaded based on Class types, and so on. It is a non-GUI
> engine, so it can be used for any purpose, but I am building a UI
Framework
> on top of it using Swing. Forgive me for saying so, but I dislike SWT and
I
> think the vast majority of java developers are not going to learn SWT
given
> that Swing is as good in many respects, better in some, and not as good in
> others, but comes with every JRE/JDK deployed as opposed to having to ship
> swt.jar and platform specific libraries, as well as a new API to learn.
> Therefore I didn't want to base my UI framework around SWT, although it
> could easily be done by simply replacing the core plugin and using SWT
> instead of Swing. The UI framework will provide a similar paradigm to
> Eclipse and other IDE's with a workspace, menu/toolbar, status bar, left
> side "task" bar, help facility, preference facility, wizard component,
file
> chooser component and so forth. All of this is open source as well, and
the
> goal is not to compete with any other IDE, it is to provide a very small,
> super easy to develop for, pluggable UI framework using Swing so that
> hopefully I can help bring those 10 million java engineers over that Sun
> claims will come! "If you build it they will come" comes ot mind. ;) I am
> trying to build it, hoping they'll come and use it!
>
> Anyway, I am glad to see Eclipse is finally going headless and
unload/reload
> of plugins will be possible! I started doing unload/reload a few months
back
> before I read that OSGi would be integrated into 3.0. I was surprised to
see
> that I had done a similar way of notifying plugins. That is, if a plugin
> that provides an extension is reloaded, it notifes the plugin that owns
the
> extension point that the extension is being removed, or added, etc.
> Basically, all plugins affected get notified of events, such as unload,
> destroy, extension removed/added, extension point removed/added, etc.
>
>
>
> "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> news:brtusv$q7$1@eclipse.org...
> > In the new runtime you can supply bundles or traditional plugins. The
only
> > real distinction is whether you supply a plugin.xml or a manifest.mf and
a
> > bit of packaging. Dynamic behaviour of the classloaders is taken care of
> by
> > OSGi. The spec details everything you could want to know. For bundles
> > supplying extensions and extension points there is a new set of API
> relating
> > to extension registry changes. Look for
> > org.eclipse.core.runtime.ExtensionChangeListener and related types.
> >
> > There are sure to be some rough edges in the dynamic support as it is
both
> > hard and new. Try it out and let us know what you think and of course,
if
> > you find any bugs, please log a bug report. January will see us
spending
> > sigificant effort to make more of Eclipse dynamic aware/enabled as well
as
> > put together some demo apps to show people how it is done.
> >
> > Note also that currently you cannot install bundles in jars as per
normal
> > OSGi. They have to be in exploded dirs like plugins. This is a
temporary
> > limitation which will be resolved in January as well.
> >
> > Enjoy
> > Jeff
> >
> > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > news:brdocp$v0$1@eclipse.org...
> > > Alrighty, so I haven't checked yet, but how are plugins to be written?
> Do
> > we
> > > do the OSGi bundle method, or continue our normal Eclipse extension
> model
> > > plugin? What I most want to know about is how we write plugins
correctly
> > so
> > > they can be unloaded and reloaded? IS there special events we listen
> for?
> > I
> > > mean, if my plugin depends on plugin B, and B is being reloaded or
> > unloaded,
> > > does my plugin get unloaded automatically (assuming B is unloaded), or
> > does
> > > it get notified that B is no longer available, and somehow in code I
> have
> > to
> > > adapt to that? This gets more complex. What if my plugin provides
> > > functionality that others depend on, but to provide that
functionality,
> my
> > > plugin depends on one or more plugins, and one or more of those get
> > > unloaded? Does the unloading go all the way across all chains until no
> > > plugin that is dependent on the one (or more) being unloaded is done?
> What
> > > about reloading? Two cases I see, it reloads a change that does not
> break
> > my
> > > plugin, or it reloads and breaks my plugins ability to use it, either
> via
> > a
> > > new version, a method removal that my plugin relies on, or some other
> > > reason. How is this handled now?
> > >
> > > Thanks.
> > >
> > >
> >
> >
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #31431 is a reply to message #31338] |
Mon, 22 December 2003 18:01 |
Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Hi Jeff,
Thank you for your detailed reply! Very kewl indeed! I won't even bother
competing with that for my engine. I can't recall if I stressed before, but
a few goals of my engine are it's size (55K with xml pull parser embedded),
simplicity, and stability. For simplicity, without offending the
Eclipse/OSGi developers, my thought was that Eclipse, while super powerful,
especially with OSGi now, it was overly complex and as you pointed out, will
generally require a tool to properly maintain the plugin.xml file and such.
My goal in simplicity is to avoid some of the more complex things, such as
dependencies, at the developer level. First, the location of my engine:
www.sourceforge.net/projects/genpluginengine
Please feel free to look at it, and I would love to have feedback especially
from the eclipse/osgi developers!
In a nutshell, I have a container (PluginEngine class) that maintains a
registry of PluginModel objects, one for each plugin, and a registry of
ExtensionPoint objects, one for every extension point. Originally I had all
plugins load in the start() method, but this was self-defeating because
being able to load plugins at runtime would require all plugins to go
through the start() call again, sort of like the "old" eclipse in having to
restart the app to see any new plugins. So I moved it out to a loadPlugin()
call that takes on a URL to a location and loads/parses the plugin into a
PluginModel object. The "meta" info, such as vendor, copyright, etc (which
is not fully defined at this time) is not read in. One thing I read from the
Eclipse forums a ways back was how to avoid all the String objects that
every plugin creates with all the ids, names, class names, etc. I figured,
try to reduce this by not reading in all meta info that would seldom be
displayed, at least to reduce the resource usage. There is a call in the
engine to get meta info for a specific plugin that will reparse the nodes
for that info at call time.
At parse time I actually create the PluginClassLoader for each plugin. I do
this so that I can resolve all dependencies as each plugin is parsed.
Actually, after parsing and a PluginModel created and added, at the end of
the loadPlugin() call there is a resolvePlugins() call that will go through
any unresolved extensions and see if their extension points have now been
added after the last plugin was loaded. In testing loading over 30 plugins,
I have not had 1 extension stay unresolved so long as all extension points
are loaded. It works pretty well and avoid a "requires" type of statement by
the developer, so they don't necessarily need to specify both the plugin id
as well as the extension point id, the resolving can figure out the plugin
owner of the extension point and automatically handle the dependencies.
I have been asking how Eclipse handles events and listeners. It is a common
thing, especially in UI apps, for plugins to want to fire their own events,
and other plugins may want to listen for them. In my engine we have a
<listeners> and <events> section that will also allow automatic
configuration and dependency resolution. How does Eclipse handle this? Is it
programatic in that if a plugin wants to listen to another plugins events,
it has to do so at runtime/activation time? Our dilema was mostly when to
create a plugin that listens for events. If a plugin is not yet created, and
listens for an event, should it get created then? What if the plugin
provides a UI window, that until displayed should not listen for events? Is
there a mechanism to delay the creation even if an event it wants to listen
for is fired?
Anyway, have a look see, let me know what ya'll think. I am working on a
milestone 1 release of the engine hopefully within a couple of weeks.
Thanks.
"Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
news:bs0bsg$b6c$1@eclipse.org...
> Thanks for you continuing interest. You have mentioned your engine
> previously but have never provided pointers to where someone can download
> and try it or get more information. What is its status?
>
> For you and others, I would like to clarify a few things:
>
> - OSGi bundles/classloaders/etc and the Eclipse extension mechanism are
> completely separated notions. The new runtime has both and users will
> benefit. OSGi brings dynamic behaviour, services, security etc and
Eclipse
> retains the power of extensions etc. There is no loss of functionality or
> generality in the new runtime, only gain.
>
> - plugin.xml and manifest.mf: neither are particularly easy for developers
> to manage without tooling support. Note that only the runtime related
> elements of plugin.xml (e.g., <runtime>, <requires>) have moved into the
> manifest.mf. The extension related tags retain their original form and
> position. As such, in most cases the manifest.mf is actually simpler to
> define and maintain than the corresponding section of the plugin.xml.
>
> - OSGi implementations typically manage bundles as jars. I'm pretty sure
> that the spec does not absolutely require this but it is implied. The
> bundles may contain internal jars for code (or other stuff) and the
runtime
> is able to put these on the classpath. We have extended the model to allow
> for running bundles out of directories (as per standard Eclipse). Eclipse
> 3.0 will likely ship with plugins in jars as opposed to directories.
People
> have been asking for this for years and we likely would have done it quite
> independent of OSGi uptake. Note however that there is no plan to allow
for
> multiple bundles to be put in one jar. This would complicate
update/install
> scenarios and serve little purpose.
>
> - Eclipse has always been "headless". Since day one there have been
> essential applications which run in this mode. For example, the Eclipse
> build mechanism is a headless Eclipse configuration. Anyone can define
> "applications" (using extensions of course) and then run them using
> eclispe -application <app id>. It just happens that in Eclipse <= 2.1
there
> was a default application which opened a GUI.
>
> - Eclipse extensions/extension-points interactions do not represent
> dependency specifications. You can contribute an extension to a plugin on
> which you do not depend. As such, when a plugin hosting an extension
point
> is uninstalled or restarted, plugins providing extensions are not
> necessarily shutdown. We purposely kept the dependency mechanism out of
> htis area to increase flexibility. Plugins which want/need to have a
> tighter relationship are free to specify a classloader dependency via the
> <requires> tags.
>
> Jeff
>
> "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> news:brvge3$k9f$1@eclipse.org...
> > That's kewl. I have built my own plugin engine based around extension
> > points, extensions, etc. I am not sure why the move to OSGi is so
> paramount
> > compared to the well thought out extension point mechanism of Eclipse. I
> > dislike the idea of using manifest.mf as opposed to plugin.xml. The xml
> > format is much nicer and easier. In my engine, plugins are
> > unloadable/reloadable (still working out the kinks as well), and I
believe
> > like Eclipse developers have to be aware of referencing other dependent
> > plugin classes with class variables as opposed to using temporary
> variables
> > within methods, otherwise the GC may never reclaim a plugin's resources.
> > Reloading is no problem, simply replace the repository of the plugin by
> its
> > name/version and all lookups/usages go to the newly loaded code. But the
> > most important part in my mind is the GC able to reclaim unloaded or
> > previously loaded when reloaded plugins and resources. Still can't
figure
> > out why the GC only runs when its out of memory, that is rather stupid
in
> my
> > opinion, it should run every few minutes, verify any dead ends and clean
> > them up!
> >
> > Does the use of OSGi bundles allow embeded jars/zips and such such that
> you
> > can deploy a single .jar file with embeded .jar/.zip files and it finds
> the
> > classes within the embeded jar/zip files without them having to be
> unzipped
> > to disk? My engine does this, using a single plugin archive file that
> > doesn't have to be unzipped to disk. Also, I have made dependencies
> > automagic, in that a plugin doesn't need to specify the plugins it
depends
> > on. Based on extension points and extensions, as well as events and
> > listeners, it can figure out the plugin(s) that are dependent
> automatically.
> > I do this by simply resolving plugins after each plugin loads. My goal,
> > before I cam across Eclipse, was to build a reloadable archtiecture like
> > what JBoss and other app servers have, using a simplified plugin model,
> > something I devised a few years back using C on a cross-platform
project.
> > Had I known Eclipse was going to become "headless" a while back, i don't
> > know that I would have ventured down this path. Now that I have, I am
> > thankful because I have a vastly improved understanding of classpaths,
> > classloaders, the jvm process of loading classes, class space and how
> > classloaders can delegate to others to find classes so that only one
> > bytecode is loaded, etc. I admit to borrowing the extension point idea
> from
> > Eclipse, it's a great way of connecting plugins. My original engine
simply
> > used "names" and "versions" to find plugins, so more or less the same
> thing,
> > just a little more dependent on specific plugin names that might change
> > across versions and break dependencies.
> >
> > Is there any idea how big the "engine" of eclipse is, with OSGi, it's
> > extension point/extension framework, etc? I thought of doing an OSGi
> > implementation, but another goal is a very small framework. With
> everything
> > that my engine does, its only 44K in size including an xml pull parser
> that
> > parses the plugin.xml files and can write xml out that any plugin can
use
> as
> > well. This includes the code for each plugin to have its own loader, be
> > contained within a single archive file or on disk like how eclipse
plugins
> > reside, lazy creation of plugins as needed (like eclipse and osgi),
> > automagic resolution of dependencies for both extension points and
> > extensions, and events/listeners, the ability to specify specific types
of
> > plugins to be loaded based on Class types, and so on. It is a non-GUI
> > engine, so it can be used for any purpose, but I am building a UI
> Framework
> > on top of it using Swing. Forgive me for saying so, but I dislike SWT
and
> I
> > think the vast majority of java developers are not going to learn SWT
> given
> > that Swing is as good in many respects, better in some, and not as good
in
> > others, but comes with every JRE/JDK deployed as opposed to having to
ship
> > swt.jar and platform specific libraries, as well as a new API to learn.
> > Therefore I didn't want to base my UI framework around SWT, although it
> > could easily be done by simply replacing the core plugin and using SWT
> > instead of Swing. The UI framework will provide a similar paradigm to
> > Eclipse and other IDE's with a workspace, menu/toolbar, status bar, left
> > side "task" bar, help facility, preference facility, wizard component,
> file
> > chooser component and so forth. All of this is open source as well, and
> the
> > goal is not to compete with any other IDE, it is to provide a very
small,
> > super easy to develop for, pluggable UI framework using Swing so that
> > hopefully I can help bring those 10 million java engineers over that Sun
> > claims will come! "If you build it they will come" comes ot mind. ;) I
am
> > trying to build it, hoping they'll come and use it!
> >
> > Anyway, I am glad to see Eclipse is finally going headless and
> unload/reload
> > of plugins will be possible! I started doing unload/reload a few months
> back
> > before I read that OSGi would be integrated into 3.0. I was surprised to
> see
> > that I had done a similar way of notifying plugins. That is, if a plugin
> > that provides an extension is reloaded, it notifes the plugin that owns
> the
> > extension point that the extension is being removed, or added, etc.
> > Basically, all plugins affected get notified of events, such as unload,
> > destroy, extension removed/added, extension point removed/added, etc.
> >
> >
> >
> > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > news:brtusv$q7$1@eclipse.org...
> > > In the new runtime you can supply bundles or traditional plugins. The
> only
> > > real distinction is whether you supply a plugin.xml or a manifest.mf
and
> a
> > > bit of packaging. Dynamic behaviour of the classloaders is taken care
of
> > by
> > > OSGi. The spec details everything you could want to know. For
bundles
> > > supplying extensions and extension points there is a new set of API
> > relating
> > > to extension registry changes. Look for
> > > org.eclipse.core.runtime.ExtensionChangeListener and related types.
> > >
> > > There are sure to be some rough edges in the dynamic support as it is
> both
> > > hard and new. Try it out and let us know what you think and of
course,
> if
> > > you find any bugs, please log a bug report. January will see us
> spending
> > > sigificant effort to make more of Eclipse dynamic aware/enabled as
well
> as
> > > put together some demo apps to show people how it is done.
> > >
> > > Note also that currently you cannot install bundles in jars as per
> normal
> > > OSGi. They have to be in exploded dirs like plugins. This is a
> temporary
> > > limitation which will be resolved in January as well.
> > >
> > > Enjoy
> > > Jeff
> > >
> > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > news:brdocp$v0$1@eclipse.org...
> > > > Alrighty, so I haven't checked yet, but how are plugins to be
written?
> > Do
> > > we
> > > > do the OSGi bundle method, or continue our normal Eclipse extension
> > model
> > > > plugin? What I most want to know about is how we write plugins
> correctly
> > > so
> > > > they can be unloaded and reloaded? IS there special events we listen
> > for?
> > > I
> > > > mean, if my plugin depends on plugin B, and B is being reloaded or
> > > unloaded,
> > > > does my plugin get unloaded automatically (assuming B is unloaded),
or
> > > does
> > > > it get notified that B is no longer available, and somehow in code I
> > have
> > > to
> > > > adapt to that? This gets more complex. What if my plugin provides
> > > > functionality that others depend on, but to provide that
> functionality,
> > my
> > > > plugin depends on one or more plugins, and one or more of those get
> > > > unloaded? Does the unloading go all the way across all chains until
no
> > > > plugin that is dependent on the one (or more) being unloaded is
done?
> > What
> > > > about reloading? Two cases I see, it reloads a change that does not
> > break
> > > my
> > > > plugin, or it reloads and breaks my plugins ability to use it,
either
> > via
> > > a
> > > > new version, a method removal that my plugin relies on, or some
other
> > > > reason. How is this handled now?
> > > >
> > > > Thanks.
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #31536 is a reply to message #31338] |
Tue, 23 December 2003 00:18 |
Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Hi Jeff,
Sorry to post two back to back posts in regards to your reply, but something
you mentioned in your reply, after re-reading it, struck me with interest. I
am hoping you don't mind answering a few questions.
First, I have posted a few times in other groups with no success on reply,
and in my previous reply indicated this question, how do plugins/bundles in
Eclipse/RCP handle resolution of event listeners to events? Is this done on
a per extension point basis, where by if an extension point, as part of its
schema, requires a class that represents a listener to an event the
extension point may fire, it is defined in the schema and every extension is
required (or optional) and thus the extension point code, when executed,
then creates all extension plugins so that it can create instances of the
listener class and add them as listeners? Is there perhaps another mechanism
for doing this, or is it left up to each extension plugin to be activated
and at that point programatically add it's listener to an event it wishes to
listen for?
In regards to what you wrote about how an extension to an extension point
does not necessitate a dependency, I am confused? In order for the
classloader of an extension point to "see" a class within another plugins
classloader that extends the extension point, doesn't the extension point
plugin require a reference to the extensions classloader in order to
delegate the lookup of the extension class to find it? I am fairly versed on
classloaders. My engine's PluginClassLoader keeps a List of dependent loader
references for faster lookup of classes that may not be contained within its
own classpath. So you don't have to spend a lot of time looking at how I
have done this, I'll tell you how here. Basically, there are a few scenarios
I can see where "dependencies" may occur. Any extension of an extension
point would require the extension point plugin to "depend" on the extension
plugins in that it needs to grab each extension plugin classloader to ask it
to find the extension class so the extension point can use it. Now, that
said, if the extension point defines an interface, as is usually the case, I
may be wrong on this but generally you would NOT need to "see" each
extension classloader because the common interface would mean that the
extension point code can call into the interface without specific
"visiblility" to each extension implementation of that interface... or am I
wrong on this and it is required to "see" every implementation of the
extension point interface through each extension plugins classloader? If it
IS required, then as I see it, the extension point plugin "depends" on each
extension plugin. If this is the case, then if the extension point plugin is
unloaded or reloaded, while not necessary my engine would send an event to
every extension letting them at least know that the extension point is no
longer available. Some plugins may only extend this one point, and thus may
not need to stay resident as well if they only contribute to that one
extension point, and thus should also be unloaded, or at least put in in
"inactive" state. My engine would simply destroy them but not unload them,
so that the GC may reclaim any resources they used. Basically, they go into
a state as if they were loaded/parsed but never activated, so that should
the plugin with the extension point get reloaded at some point, they can
once again be resolved against it and come to life if requested.
Another scenario that I see is if the extension point interface provides for
a callback, where by a specific implementation the extension point provides
may be passed to each extension, and each extension can then make calls via
the interface callback, into the extension point. How to handle this?
Lastly, what if an extension point plugin is to provide an interface AND an
implementation of that interface so that extension plugins can directly use
the one implementation instead of the normal manner in which an extension
point makes use of any one or all extension implementations of an interface
the extension point provides? In this case, each extension now depends on
the extension point, and each extensions classloader must "see" into the
extension point.
In all these scenarios, my engine simply sets a ciruclar dependency, that is
A's loader has B's loader as a dependency, and B's loader has A's loader as
a dependency. If you look at my code, there is something I do though (an
maybe it isn't all good, but it seems to work well). I ran into a
Circularity problem before where by if A looks in B's loader and happens to
look in B's ref to A's loader, it could loop forever (hence the Circularity
problem I had). So, to prevent this, I define a rule, in that a plugin's
loader can ONLY look within a dependent plugins classpath, not any of its
dependent loaders. This avoids A looking at B's dependent of A. The drawback
is that if A depends on B, B depends on C and C wraps ant.jar, A can not use
ant.jar, only B can. So A would have to extend C as well. One thing I did
add is a "shareable" parent loader, sort of like how JBoss has a single
repository it first checks. Any plugin can add a "shareable" URL to a
library of their's so that ALL plugins can access it. There can be pros/cons
to this approach, but generally this is application specific, not plugin
defined. An application using the engine would perhaps specify specific
libraries it wishes that all plugins would use. Of course you can run in to
version issues this way, as does occur with JBoss where you are limited to
the "parent" version of a library regardless if each plugin has their own
version. But I see this as a small factor as this should be used on an
application level anyway.
So, having said all that, how does Eclipse allow extension points to not
depend on extensions via their classloader? Keep in mind, if you look at my
code, I am not only shooting for small size, but optimum speed. If any java.
or javax. class is asked to be loaded in the loadClass(), I simply delegate
it directly to the system loader. As well, if any of the plugin engine's
classes are asked, it goes directly to the parent loader. This is to avoid
having to go through the list of lookup possibilities (the cache, shareable
loader, classpath, dependent loaders and finally the parent, if configured).
Thanks for your time, I look forward to your thoughts.
"Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
news:bs0bsg$b6c$1@eclipse.org...
> Thanks for you continuing interest. You have mentioned your engine
> previously but have never provided pointers to where someone can download
> and try it or get more information. What is its status?
>
> For you and others, I would like to clarify a few things:
>
> - OSGi bundles/classloaders/etc and the Eclipse extension mechanism are
> completely separated notions. The new runtime has both and users will
> benefit. OSGi brings dynamic behaviour, services, security etc and
Eclipse
> retains the power of extensions etc. There is no loss of functionality or
> generality in the new runtime, only gain.
>
> - plugin.xml and manifest.mf: neither are particularly easy for developers
> to manage without tooling support. Note that only the runtime related
> elements of plugin.xml (e.g., <runtime>, <requires>) have moved into the
> manifest.mf. The extension related tags retain their original form and
> position. As such, in most cases the manifest.mf is actually simpler to
> define and maintain than the corresponding section of the plugin.xml.
>
> - OSGi implementations typically manage bundles as jars. I'm pretty sure
> that the spec does not absolutely require this but it is implied. The
> bundles may contain internal jars for code (or other stuff) and the
runtime
> is able to put these on the classpath. We have extended the model to allow
> for running bundles out of directories (as per standard Eclipse). Eclipse
> 3.0 will likely ship with plugins in jars as opposed to directories.
People
> have been asking for this for years and we likely would have done it quite
> independent of OSGi uptake. Note however that there is no plan to allow
for
> multiple bundles to be put in one jar. This would complicate
update/install
> scenarios and serve little purpose.
>
> - Eclipse has always been "headless". Since day one there have been
> essential applications which run in this mode. For example, the Eclipse
> build mechanism is a headless Eclipse configuration. Anyone can define
> "applications" (using extensions of course) and then run them using
> eclispe -application <app id>. It just happens that in Eclipse <= 2.1
there
> was a default application which opened a GUI.
>
> - Eclipse extensions/extension-points interactions do not represent
> dependency specifications. You can contribute an extension to a plugin on
> which you do not depend. As such, when a plugin hosting an extension
point
> is uninstalled or restarted, plugins providing extensions are not
> necessarily shutdown. We purposely kept the dependency mechanism out of
> htis area to increase flexibility. Plugins which want/need to have a
> tighter relationship are free to specify a classloader dependency via the
> <requires> tags.
>
> Jeff
>
> "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> news:brvge3$k9f$1@eclipse.org...
> > That's kewl. I have built my own plugin engine based around extension
> > points, extensions, etc. I am not sure why the move to OSGi is so
> paramount
> > compared to the well thought out extension point mechanism of Eclipse. I
> > dislike the idea of using manifest.mf as opposed to plugin.xml. The xml
> > format is much nicer and easier. In my engine, plugins are
> > unloadable/reloadable (still working out the kinks as well), and I
believe
> > like Eclipse developers have to be aware of referencing other dependent
> > plugin classes with class variables as opposed to using temporary
> variables
> > within methods, otherwise the GC may never reclaim a plugin's resources.
> > Reloading is no problem, simply replace the repository of the plugin by
> its
> > name/version and all lookups/usages go to the newly loaded code. But the
> > most important part in my mind is the GC able to reclaim unloaded or
> > previously loaded when reloaded plugins and resources. Still can't
figure
> > out why the GC only runs when its out of memory, that is rather stupid
in
> my
> > opinion, it should run every few minutes, verify any dead ends and clean
> > them up!
> >
> > Does the use of OSGi bundles allow embeded jars/zips and such such that
> you
> > can deploy a single .jar file with embeded .jar/.zip files and it finds
> the
> > classes within the embeded jar/zip files without them having to be
> unzipped
> > to disk? My engine does this, using a single plugin archive file that
> > doesn't have to be unzipped to disk. Also, I have made dependencies
> > automagic, in that a plugin doesn't need to specify the plugins it
depends
> > on. Based on extension points and extensions, as well as events and
> > listeners, it can figure out the plugin(s) that are dependent
> automatically.
> > I do this by simply resolving plugins after each plugin loads. My goal,
> > before I cam across Eclipse, was to build a reloadable archtiecture like
> > what JBoss and other app servers have, using a simplified plugin model,
> > something I devised a few years back using C on a cross-platform
project.
> > Had I known Eclipse was going to become "headless" a while back, i don't
> > know that I would have ventured down this path. Now that I have, I am
> > thankful because I have a vastly improved understanding of classpaths,
> > classloaders, the jvm process of loading classes, class space and how
> > classloaders can delegate to others to find classes so that only one
> > bytecode is loaded, etc. I admit to borrowing the extension point idea
> from
> > Eclipse, it's a great way of connecting plugins. My original engine
simply
> > used "names" and "versions" to find plugins, so more or less the same
> thing,
> > just a little more dependent on specific plugin names that might change
> > across versions and break dependencies.
> >
> > Is there any idea how big the "engine" of eclipse is, with OSGi, it's
> > extension point/extension framework, etc? I thought of doing an OSGi
> > implementation, but another goal is a very small framework. With
> everything
> > that my engine does, its only 44K in size including an xml pull parser
> that
> > parses the plugin.xml files and can write xml out that any plugin can
use
> as
> > well. This includes the code for each plugin to have its own loader, be
> > contained within a single archive file or on disk like how eclipse
plugins
> > reside, lazy creation of plugins as needed (like eclipse and osgi),
> > automagic resolution of dependencies for both extension points and
> > extensions, and events/listeners, the ability to specify specific types
of
> > plugins to be loaded based on Class types, and so on. It is a non-GUI
> > engine, so it can be used for any purpose, but I am building a UI
> Framework
> > on top of it using Swing. Forgive me for saying so, but I dislike SWT
and
> I
> > think the vast majority of java developers are not going to learn SWT
> given
> > that Swing is as good in many respects, better in some, and not as good
in
> > others, but comes with every JRE/JDK deployed as opposed to having to
ship
> > swt.jar and platform specific libraries, as well as a new API to learn.
> > Therefore I didn't want to base my UI framework around SWT, although it
> > could easily be done by simply replacing the core plugin and using SWT
> > instead of Swing. The UI framework will provide a similar paradigm to
> > Eclipse and other IDE's with a workspace, menu/toolbar, status bar, left
> > side "task" bar, help facility, preference facility, wizard component,
> file
> > chooser component and so forth. All of this is open source as well, and
> the
> > goal is not to compete with any other IDE, it is to provide a very
small,
> > super easy to develop for, pluggable UI framework using Swing so that
> > hopefully I can help bring those 10 million java engineers over that Sun
> > claims will come! "If you build it they will come" comes ot mind. ;) I
am
> > trying to build it, hoping they'll come and use it!
> >
> > Anyway, I am glad to see Eclipse is finally going headless and
> unload/reload
> > of plugins will be possible! I started doing unload/reload a few months
> back
> > before I read that OSGi would be integrated into 3.0. I was surprised to
> see
> > that I had done a similar way of notifying plugins. That is, if a plugin
> > that provides an extension is reloaded, it notifes the plugin that owns
> the
> > extension point that the extension is being removed, or added, etc.
> > Basically, all plugins affected get notified of events, such as unload,
> > destroy, extension removed/added, extension point removed/added, etc.
> >
> >
> >
> > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > news:brtusv$q7$1@eclipse.org...
> > > In the new runtime you can supply bundles or traditional plugins. The
> only
> > > real distinction is whether you supply a plugin.xml or a manifest.mf
and
> a
> > > bit of packaging. Dynamic behaviour of the classloaders is taken care
of
> > by
> > > OSGi. The spec details everything you could want to know. For
bundles
> > > supplying extensions and extension points there is a new set of API
> > relating
> > > to extension registry changes. Look for
> > > org.eclipse.core.runtime.ExtensionChangeListener and related types.
> > >
> > > There are sure to be some rough edges in the dynamic support as it is
> both
> > > hard and new. Try it out and let us know what you think and of
course,
> if
> > > you find any bugs, please log a bug report. January will see us
> spending
> > > sigificant effort to make more of Eclipse dynamic aware/enabled as
well
> as
> > > put together some demo apps to show people how it is done.
> > >
> > > Note also that currently you cannot install bundles in jars as per
> normal
> > > OSGi. They have to be in exploded dirs like plugins. This is a
> temporary
> > > limitation which will be resolved in January as well.
> > >
> > > Enjoy
> > > Jeff
> > >
> > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > news:brdocp$v0$1@eclipse.org...
> > > > Alrighty, so I haven't checked yet, but how are plugins to be
written?
> > Do
> > > we
> > > > do the OSGi bundle method, or continue our normal Eclipse extension
> > model
> > > > plugin? What I most want to know about is how we write plugins
> correctly
> > > so
> > > > they can be unloaded and reloaded? IS there special events we listen
> > for?
> > > I
> > > > mean, if my plugin depends on plugin B, and B is being reloaded or
> > > unloaded,
> > > > does my plugin get unloaded automatically (assuming B is unloaded),
or
> > > does
> > > > it get notified that B is no longer available, and somehow in code I
> > have
> > > to
> > > > adapt to that? This gets more complex. What if my plugin provides
> > > > functionality that others depend on, but to provide that
> functionality,
> > my
> > > > plugin depends on one or more plugins, and one or more of those get
> > > > unloaded? Does the unloading go all the way across all chains until
no
> > > > plugin that is dependent on the one (or more) being unloaded is
done?
> > What
> > > > about reloading? Two cases I see, it reloads a change that does not
> > break
> > > my
> > > > plugin, or it reloads and breaks my plugins ability to use it,
either
> > via
> > > a
> > > > new version, a method removal that my plugin relies on, or some
other
> > > > reason. How is this handled now?
> > > >
> > > > Thanks.
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #31796 is a reply to message #31281] |
Thu, 01 January 2004 16:49 |
Peter Kriens
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
Jeff (or anybody else),
Can you give a hint how the plugin directory should look like for a
dynamic plugin? I can't figure out how to get a simple hello/goodbye world
to run. I could load my own debugger bundle in Eclipse which is pretty
cool!
An example would be fantastic.
Kind regards,
Peter Kriens
Jeff McAffer wrote:
> In the new runtime you can supply bundles or traditional plugins. The only
> real distinction is whether you supply a plugin.xml or a manifest.mf and a
> bit of packaging. Dynamic behaviour of the classloaders is taken care of by
> OSGi. The spec details everything you could want to know. For bundles
> supplying extensions and extension points there is a new set of API relating
> to extension registry changes. Look for
> org.eclipse.core.runtime.ExtensionChangeListener and related types.
> There are sure to be some rough edges in the dynamic support as it is both
> hard and new. Try it out and let us know what you think and of course, if
> you find any bugs, please log a bug report. January will see us spending
> sigificant effort to make more of Eclipse dynamic aware/enabled as well as
> put together some demo apps to show people how it is done.
> Note also that currently you cannot install bundles in jars as per normal
> OSGi. They have to be in exploded dirs like plugins. This is a temporary
> limitation which will be resolved in January as well.
> Enjoy
> Jeff
> "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> news:brdocp$v0$1@eclipse.org...
> > Alrighty, so I haven't checked yet, but how are plugins to be written? Do
> we
> > do the OSGi bundle method, or continue our normal Eclipse extension model
> > plugin? What I most want to know about is how we write plugins correctly
> so
> > they can be unloaded and reloaded? IS there special events we listen for?
> I
> > mean, if my plugin depends on plugin B, and B is being reloaded or
> unloaded,
> > does my plugin get unloaded automatically (assuming B is unloaded), or
> does
> > it get notified that B is no longer available, and somehow in code I have
> to
> > adapt to that? This gets more complex. What if my plugin provides
> > functionality that others depend on, but to provide that functionality, my
> > plugin depends on one or more plugins, and one or more of those get
> > unloaded? Does the unloading go all the way across all chains until no
> > plugin that is dependent on the one (or more) being unloaded is done? What
> > about reloading? Two cases I see, it reloads a change that does not break
> my
> > plugin, or it reloads and breaks my plugins ability to use it, either via
> a
> > new version, a method removal that my plugin relies on, or some other
> > reason. How is this handled now?
> >
> > Thanks.
> >
> >
|
|
|
| Re: How to write plugins with the new OSGi model [message #31936 is a reply to message #31536] |
Tue, 06 January 2004 19:16 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
The plugin hosting the extension point cannot require the ones providing the
extensions since it does not know about them (a priori). At runtime when a
host goes to instantiate a contributed extension, it simply asks the plugin
providing the extension to load the specified class. This is analogous to
adding a dependency from the host to the contributor but the host only wants
to see the contributed class not all the classes that happen to be in the
contributing plugin.
Jeff
"spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
news:bs82vo$jjs$1@eclipse.org...
> Hi Jeff,
>
> Sorry to post two back to back posts in regards to your reply, but
something
> you mentioned in your reply, after re-reading it, struck me with interest.
I
> am hoping you don't mind answering a few questions.
>
> First, I have posted a few times in other groups with no success on reply,
> and in my previous reply indicated this question, how do plugins/bundles
in
> Eclipse/RCP handle resolution of event listeners to events? Is this done
on
> a per extension point basis, where by if an extension point, as part of
its
> schema, requires a class that represents a listener to an event the
> extension point may fire, it is defined in the schema and every extension
is
> required (or optional) and thus the extension point code, when executed,
> then creates all extension plugins so that it can create instances of the
> listener class and add them as listeners? Is there perhaps another
mechanism
> for doing this, or is it left up to each extension plugin to be activated
> and at that point programatically add it's listener to an event it wishes
to
> listen for?
>
> In regards to what you wrote about how an extension to an extension point
> does not necessitate a dependency, I am confused? In order for the
> classloader of an extension point to "see" a class within another plugins
> classloader that extends the extension point, doesn't the extension point
> plugin require a reference to the extensions classloader in order to
> delegate the lookup of the extension class to find it? I am fairly versed
on
> classloaders. My engine's PluginClassLoader keeps a List of dependent
loader
> references for faster lookup of classes that may not be contained within
its
> own classpath. So you don't have to spend a lot of time looking at how I
> have done this, I'll tell you how here. Basically, there are a few
scenarios
> I can see where "dependencies" may occur. Any extension of an extension
> point would require the extension point plugin to "depend" on the
extension
> plugins in that it needs to grab each extension plugin classloader to ask
it
> to find the extension class so the extension point can use it. Now, that
> said, if the extension point defines an interface, as is usually the case,
I
> may be wrong on this but generally you would NOT need to "see" each
> extension classloader because the common interface would mean that the
> extension point code can call into the interface without specific
> "visiblility" to each extension implementation of that interface... or am
I
> wrong on this and it is required to "see" every implementation of the
> extension point interface through each extension plugins classloader? If
it
> IS required, then as I see it, the extension point plugin "depends" on
each
> extension plugin. If this is the case, then if the extension point plugin
is
> unloaded or reloaded, while not necessary my engine would send an event to
> every extension letting them at least know that the extension point is no
> longer available. Some plugins may only extend this one point, and thus
may
> not need to stay resident as well if they only contribute to that one
> extension point, and thus should also be unloaded, or at least put in in
> "inactive" state. My engine would simply destroy them but not unload them,
> so that the GC may reclaim any resources they used. Basically, they go
into
> a state as if they were loaded/parsed but never activated, so that should
> the plugin with the extension point get reloaded at some point, they can
> once again be resolved against it and come to life if requested.
>
> Another scenario that I see is if the extension point interface provides
for
> a callback, where by a specific implementation the extension point
provides
> may be passed to each extension, and each extension can then make calls
via
> the interface callback, into the extension point. How to handle this?
>
> Lastly, what if an extension point plugin is to provide an interface AND
an
> implementation of that interface so that extension plugins can directly
use
> the one implementation instead of the normal manner in which an extension
> point makes use of any one or all extension implementations of an
interface
> the extension point provides? In this case, each extension now depends on
> the extension point, and each extensions classloader must "see" into the
> extension point.
>
> In all these scenarios, my engine simply sets a ciruclar dependency, that
is
> A's loader has B's loader as a dependency, and B's loader has A's loader
as
> a dependency. If you look at my code, there is something I do though (an
> maybe it isn't all good, but it seems to work well). I ran into a
> Circularity problem before where by if A looks in B's loader and happens
to
> look in B's ref to A's loader, it could loop forever (hence the
Circularity
> problem I had). So, to prevent this, I define a rule, in that a plugin's
> loader can ONLY look within a dependent plugins classpath, not any of its
> dependent loaders. This avoids A looking at B's dependent of A. The
drawback
> is that if A depends on B, B depends on C and C wraps ant.jar, A can not
use
> ant.jar, only B can. So A would have to extend C as well. One thing I did
> add is a "shareable" parent loader, sort of like how JBoss has a single
> repository it first checks. Any plugin can add a "shareable" URL to a
> library of their's so that ALL plugins can access it. There can be
pros/cons
> to this approach, but generally this is application specific, not plugin
> defined. An application using the engine would perhaps specify specific
> libraries it wishes that all plugins would use. Of course you can run in
to
> version issues this way, as does occur with JBoss where you are limited to
> the "parent" version of a library regardless if each plugin has their own
> version. But I see this as a small factor as this should be used on an
> application level anyway.
>
> So, having said all that, how does Eclipse allow extension points to not
> depend on extensions via their classloader? Keep in mind, if you look at
my
> code, I am not only shooting for small size, but optimum speed. If any
java.
> or javax. class is asked to be loaded in the loadClass(), I simply
delegate
> it directly to the system loader. As well, if any of the plugin engine's
> classes are asked, it goes directly to the parent loader. This is to avoid
> having to go through the list of lookup possibilities (the cache,
shareable
> loader, classpath, dependent loaders and finally the parent, if
configured).
>
> Thanks for your time, I look forward to your thoughts.
>
>
> "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> news:bs0bsg$b6c$1@eclipse.org...
> > Thanks for you continuing interest. You have mentioned your engine
> > previously but have never provided pointers to where someone can
download
> > and try it or get more information. What is its status?
> >
> > For you and others, I would like to clarify a few things:
> >
> > - OSGi bundles/classloaders/etc and the Eclipse extension mechanism are
> > completely separated notions. The new runtime has both and users will
> > benefit. OSGi brings dynamic behaviour, services, security etc and
> Eclipse
> > retains the power of extensions etc. There is no loss of functionality
or
> > generality in the new runtime, only gain.
> >
> > - plugin.xml and manifest.mf: neither are particularly easy for
developers
> > to manage without tooling support. Note that only the runtime related
> > elements of plugin.xml (e.g., <runtime>, <requires>) have moved into the
> > manifest.mf. The extension related tags retain their original form and
> > position. As such, in most cases the manifest.mf is actually simpler to
> > define and maintain than the corresponding section of the plugin.xml.
> >
> > - OSGi implementations typically manage bundles as jars. I'm pretty
sure
> > that the spec does not absolutely require this but it is implied. The
> > bundles may contain internal jars for code (or other stuff) and the
> runtime
> > is able to put these on the classpath. We have extended the model to
allow
> > for running bundles out of directories (as per standard Eclipse).
Eclipse
> > 3.0 will likely ship with plugins in jars as opposed to directories.
> People
> > have been asking for this for years and we likely would have done it
quite
> > independent of OSGi uptake. Note however that there is no plan to allow
> for
> > multiple bundles to be put in one jar. This would complicate
> update/install
> > scenarios and serve little purpose.
> >
> > - Eclipse has always been "headless". Since day one there have been
> > essential applications which run in this mode. For example, the Eclipse
> > build mechanism is a headless Eclipse configuration. Anyone can define
> > "applications" (using extensions of course) and then run them using
> > eclispe -application <app id>. It just happens that in Eclipse <= 2.1
> there
> > was a default application which opened a GUI.
> >
> > - Eclipse extensions/extension-points interactions do not represent
> > dependency specifications. You can contribute an extension to a plugin
on
> > which you do not depend. As such, when a plugin hosting an extension
> point
> > is uninstalled or restarted, plugins providing extensions are not
> > necessarily shutdown. We purposely kept the dependency mechanism out of
> > htis area to increase flexibility. Plugins which want/need to have a
> > tighter relationship are free to specify a classloader dependency via
the
> > <requires> tags.
> >
> > Jeff
> >
> > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > news:brvge3$k9f$1@eclipse.org...
> > > That's kewl. I have built my own plugin engine based around extension
> > > points, extensions, etc. I am not sure why the move to OSGi is so
> > paramount
> > > compared to the well thought out extension point mechanism of Eclipse.
I
> > > dislike the idea of using manifest.mf as opposed to plugin.xml. The
xml
> > > format is much nicer and easier. In my engine, plugins are
> > > unloadable/reloadable (still working out the kinks as well), and I
> believe
> > > like Eclipse developers have to be aware of referencing other
dependent
> > > plugin classes with class variables as opposed to using temporary
> > variables
> > > within methods, otherwise the GC may never reclaim a plugin's
resources.
> > > Reloading is no problem, simply replace the repository of the plugin
by
> > its
> > > name/version and all lookups/usages go to the newly loaded code. But
the
> > > most important part in my mind is the GC able to reclaim unloaded or
> > > previously loaded when reloaded plugins and resources. Still can't
> figure
> > > out why the GC only runs when its out of memory, that is rather stupid
> in
> > my
> > > opinion, it should run every few minutes, verify any dead ends and
clean
> > > them up!
> > >
> > > Does the use of OSGi bundles allow embeded jars/zips and such such
that
> > you
> > > can deploy a single .jar file with embeded .jar/.zip files and it
finds
> > the
> > > classes within the embeded jar/zip files without them having to be
> > unzipped
> > > to disk? My engine does this, using a single plugin archive file that
> > > doesn't have to be unzipped to disk. Also, I have made dependencies
> > > automagic, in that a plugin doesn't need to specify the plugins it
> depends
> > > on. Based on extension points and extensions, as well as events and
> > > listeners, it can figure out the plugin(s) that are dependent
> > automatically.
> > > I do this by simply resolving plugins after each plugin loads. My
goal,
> > > before I cam across Eclipse, was to build a reloadable archtiecture
like
> > > what JBoss and other app servers have, using a simplified plugin
model,
> > > something I devised a few years back using C on a cross-platform
> project.
> > > Had I known Eclipse was going to become "headless" a while back, i
don't
> > > know that I would have ventured down this path. Now that I have, I am
> > > thankful because I have a vastly improved understanding of classpaths,
> > > classloaders, the jvm process of loading classes, class space and how
> > > classloaders can delegate to others to find classes so that only one
> > > bytecode is loaded, etc. I admit to borrowing the extension point idea
> > from
> > > Eclipse, it's a great way of connecting plugins. My original engine
> simply
> > > used "names" and "versions" to find plugins, so more or less the same
> > thing,
> > > just a little more dependent on specific plugin names that might
change
> > > across versions and break dependencies.
> > >
> > > Is there any idea how big the "engine" of eclipse is, with OSGi, it's
> > > extension point/extension framework, etc? I thought of doing an OSGi
> > > implementation, but another goal is a very small framework. With
> > everything
> > > that my engine does, its only 44K in size including an xml pull parser
> > that
> > > parses the plugin.xml files and can write xml out that any plugin can
> use
> > as
> > > well. This includes the code for each plugin to have its own loader,
be
> > > contained within a single archive file or on disk like how eclipse
> plugins
> > > reside, lazy creation of plugins as needed (like eclipse and osgi),
> > > automagic resolution of dependencies for both extension points and
> > > extensions, and events/listeners, the ability to specify specific
types
> of
> > > plugins to be loaded based on Class types, and so on. It is a non-GUI
> > > engine, so it can be used for any purpose, but I am building a UI
> > Framework
> > > on top of it using Swing. Forgive me for saying so, but I dislike SWT
> and
> > I
> > > think the vast majority of java developers are not going to learn SWT
> > given
> > > that Swing is as good in many respects, better in some, and not as
good
> in
> > > others, but comes with every JRE/JDK deployed as opposed to having to
> ship
> > > swt.jar and platform specific libraries, as well as a new API to
learn.
> > > Therefore I didn't want to base my UI framework around SWT, although
it
> > > could easily be done by simply replacing the core plugin and using SWT
> > > instead of Swing. The UI framework will provide a similar paradigm to
> > > Eclipse and other IDE's with a workspace, menu/toolbar, status bar,
left
> > > side "task" bar, help facility, preference facility, wizard component,
> > file
> > > chooser component and so forth. All of this is open source as well,
and
> > the
> > > goal is not to compete with any other IDE, it is to provide a very
> small,
> > > super easy to develop for, pluggable UI framework using Swing so that
> > > hopefully I can help bring those 10 million java engineers over that
Sun
> > > claims will come! "If you build it they will come" comes ot mind. ;) I
> am
> > > trying to build it, hoping they'll come and use it!
> > >
> > > Anyway, I am glad to see Eclipse is finally going headless and
> > unload/reload
> > > of plugins will be possible! I started doing unload/reload a few
months
> > back
> > > before I read that OSGi would be integrated into 3.0. I was surprised
to
> > see
> > > that I had done a similar way of notifying plugins. That is, if a
plugin
> > > that provides an extension is reloaded, it notifes the plugin that
owns
> > the
> > > extension point that the extension is being removed, or added, etc.
> > > Basically, all plugins affected get notified of events, such as
unload,
> > > destroy, extension removed/added, extension point removed/added, etc.
> > >
> > >
> > >
> > > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > > news:brtusv$q7$1@eclipse.org...
> > > > In the new runtime you can supply bundles or traditional plugins.
The
> > only
> > > > real distinction is whether you supply a plugin.xml or a manifest.mf
> and
> > a
> > > > bit of packaging. Dynamic behaviour of the classloaders is taken
care
> of
> > > by
> > > > OSGi. The spec details everything you could want to know. For
> bundles
> > > > supplying extensions and extension points there is a new set of API
> > > relating
> > > > to extension registry changes. Look for
> > > > org.eclipse.core.runtime.ExtensionChangeListener and related types.
> > > >
> > > > There are sure to be some rough edges in the dynamic support as it
is
> > both
> > > > hard and new. Try it out and let us know what you think and of
> course,
> > if
> > > > you find any bugs, please log a bug report. January will see us
> > spending
> > > > sigificant effort to make more of Eclipse dynamic aware/enabled as
> well
> > as
> > > > put together some demo apps to show people how it is done.
> > > >
> > > > Note also that currently you cannot install bundles in jars as per
> > normal
> > > > OSGi. They have to be in exploded dirs like plugins. This is a
> > temporary
> > > > limitation which will be resolved in January as well.
> > > >
> > > > Enjoy
> > > > Jeff
> > > >
> > > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > > news:brdocp$v0$1@eclipse.org...
> > > > > Alrighty, so I haven't checked yet, but how are plugins to be
> written?
> > > Do
> > > > we
> > > > > do the OSGi bundle method, or continue our normal Eclipse
extension
> > > model
> > > > > plugin? What I most want to know about is how we write plugins
> > correctly
> > > > so
> > > > > they can be unloaded and reloaded? IS there special events we
listen
> > > for?
> > > > I
> > > > > mean, if my plugin depends on plugin B, and B is being reloaded or
> > > > unloaded,
> > > > > does my plugin get unloaded automatically (assuming B is
unloaded),
> or
> > > > does
> > > > > it get notified that B is no longer available, and somehow in code
I
> > > have
> > > > to
> > > > > adapt to that? This gets more complex. What if my plugin provides
> > > > > functionality that others depend on, but to provide that
> > functionality,
> > > my
> > > > > plugin depends on one or more plugins, and one or more of those
get
> > > > > unloaded? Does the unloading go all the way across all chains
until
> no
> > > > > plugin that is dependent on the one (or more) being unloaded is
> done?
> > > What
> > > > > about reloading? Two cases I see, it reloads a change that does
not
> > > break
> > > > my
> > > > > plugin, or it reloads and breaks my plugins ability to use it,
> either
> > > via
> > > > a
> > > > > new version, a method removal that my plugin relies on, or some
> other
> > > > > reason. How is this handled now?
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #31972 is a reply to message #31936] |
Tue, 06 January 2004 21:59 |
Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Yup, got that. Basically, the dependency resolution is done at runtime, when
the extension point asks to load the extension class. I see the call to
getExecutableExtension() but I don't see where you are passing in the
calling plugins descriptor. Meaning, within the plugin code of the extension
point, when it tries to find an extension class for use, how does the
extension point classloader know to use the extension classloader to find
the class, and when found is the extension classloader then added as a
dependency so future lookups are faster?
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:btf1ih$b5f$1@eclipse.org...
> The plugin hosting the extension point cannot require the ones providing
the
> extensions since it does not know about them (a priori). At runtime when
a
> host goes to instantiate a contributed extension, it simply asks the
plugin
> providing the extension to load the specified class. This is analogous to
> adding a dependency from the host to the contributor but the host only
wants
> to see the contributed class not all the classes that happen to be in the
> contributing plugin.
>
> Jeff
>
> "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> news:bs82vo$jjs$1@eclipse.org...
> > Hi Jeff,
> >
> > Sorry to post two back to back posts in regards to your reply, but
> something
> > you mentioned in your reply, after re-reading it, struck me with
interest.
> I
> > am hoping you don't mind answering a few questions.
> >
> > First, I have posted a few times in other groups with no success on
reply,
> > and in my previous reply indicated this question, how do plugins/bundles
> in
> > Eclipse/RCP handle resolution of event listeners to events? Is this done
> on
> > a per extension point basis, where by if an extension point, as part of
> its
> > schema, requires a class that represents a listener to an event the
> > extension point may fire, it is defined in the schema and every
extension
> is
> > required (or optional) and thus the extension point code, when executed,
> > then creates all extension plugins so that it can create instances of
the
> > listener class and add them as listeners? Is there perhaps another
> mechanism
> > for doing this, or is it left up to each extension plugin to be
activated
> > and at that point programatically add it's listener to an event it
wishes
> to
> > listen for?
> >
> > In regards to what you wrote about how an extension to an extension
point
> > does not necessitate a dependency, I am confused? In order for the
> > classloader of an extension point to "see" a class within another
plugins
> > classloader that extends the extension point, doesn't the extension
point
> > plugin require a reference to the extensions classloader in order to
> > delegate the lookup of the extension class to find it? I am fairly
versed
> on
> > classloaders. My engine's PluginClassLoader keeps a List of dependent
> loader
> > references for faster lookup of classes that may not be contained within
> its
> > own classpath. So you don't have to spend a lot of time looking at how I
> > have done this, I'll tell you how here. Basically, there are a few
> scenarios
> > I can see where "dependencies" may occur. Any extension of an extension
> > point would require the extension point plugin to "depend" on the
> extension
> > plugins in that it needs to grab each extension plugin classloader to
ask
> it
> > to find the extension class so the extension point can use it. Now, that
> > said, if the extension point defines an interface, as is usually the
case,
> I
> > may be wrong on this but generally you would NOT need to "see" each
> > extension classloader because the common interface would mean that the
> > extension point code can call into the interface without specific
> > "visiblility" to each extension implementation of that interface... or
am
> I
> > wrong on this and it is required to "see" every implementation of the
> > extension point interface through each extension plugins classloader? If
> it
> > IS required, then as I see it, the extension point plugin "depends" on
> each
> > extension plugin. If this is the case, then if the extension point
plugin
> is
> > unloaded or reloaded, while not necessary my engine would send an event
to
> > every extension letting them at least know that the extension point is
no
> > longer available. Some plugins may only extend this one point, and thus
> may
> > not need to stay resident as well if they only contribute to that one
> > extension point, and thus should also be unloaded, or at least put in in
> > "inactive" state. My engine would simply destroy them but not unload
them,
> > so that the GC may reclaim any resources they used. Basically, they go
> into
> > a state as if they were loaded/parsed but never activated, so that
should
> > the plugin with the extension point get reloaded at some point, they can
> > once again be resolved against it and come to life if requested.
> >
> > Another scenario that I see is if the extension point interface provides
> for
> > a callback, where by a specific implementation the extension point
> provides
> > may be passed to each extension, and each extension can then make calls
> via
> > the interface callback, into the extension point. How to handle this?
> >
> > Lastly, what if an extension point plugin is to provide an interface AND
> an
> > implementation of that interface so that extension plugins can directly
> use
> > the one implementation instead of the normal manner in which an
extension
> > point makes use of any one or all extension implementations of an
> interface
> > the extension point provides? In this case, each extension now depends
on
> > the extension point, and each extensions classloader must "see" into the
> > extension point.
> >
> > In all these scenarios, my engine simply sets a ciruclar dependency,
that
> is
> > A's loader has B's loader as a dependency, and B's loader has A's loader
> as
> > a dependency. If you look at my code, there is something I do though (an
> > maybe it isn't all good, but it seems to work well). I ran into a
> > Circularity problem before where by if A looks in B's loader and happens
> to
> > look in B's ref to A's loader, it could loop forever (hence the
> Circularity
> > problem I had). So, to prevent this, I define a rule, in that a plugin's
> > loader can ONLY look within a dependent plugins classpath, not any of
its
> > dependent loaders. This avoids A looking at B's dependent of A. The
> drawback
> > is that if A depends on B, B depends on C and C wraps ant.jar, A can not
> use
> > ant.jar, only B can. So A would have to extend C as well. One thing I
did
> > add is a "shareable" parent loader, sort of like how JBoss has a single
> > repository it first checks. Any plugin can add a "shareable" URL to a
> > library of their's so that ALL plugins can access it. There can be
> pros/cons
> > to this approach, but generally this is application specific, not plugin
> > defined. An application using the engine would perhaps specify specific
> > libraries it wishes that all plugins would use. Of course you can run in
> to
> > version issues this way, as does occur with JBoss where you are limited
to
> > the "parent" version of a library regardless if each plugin has their
own
> > version. But I see this as a small factor as this should be used on an
> > application level anyway.
> >
> > So, having said all that, how does Eclipse allow extension points to not
> > depend on extensions via their classloader? Keep in mind, if you look at
> my
> > code, I am not only shooting for small size, but optimum speed. If any
> java.
> > or javax. class is asked to be loaded in the loadClass(), I simply
> delegate
> > it directly to the system loader. As well, if any of the plugin engine's
> > classes are asked, it goes directly to the parent loader. This is to
avoid
> > having to go through the list of lookup possibilities (the cache,
> shareable
> > loader, classpath, dependent loaders and finally the parent, if
> configured).
> >
> > Thanks for your time, I look forward to your thoughts.
> >
> >
> > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > news:bs0bsg$b6c$1@eclipse.org...
> > > Thanks for you continuing interest. You have mentioned your engine
> > > previously but have never provided pointers to where someone can
> download
> > > and try it or get more information. What is its status?
> > >
> > > For you and others, I would like to clarify a few things:
> > >
> > > - OSGi bundles/classloaders/etc and the Eclipse extension mechanism
are
> > > completely separated notions. The new runtime has both and users will
> > > benefit. OSGi brings dynamic behaviour, services, security etc and
> > Eclipse
> > > retains the power of extensions etc. There is no loss of
functionality
> or
> > > generality in the new runtime, only gain.
> > >
> > > - plugin.xml and manifest.mf: neither are particularly easy for
> developers
> > > to manage without tooling support. Note that only the runtime related
> > > elements of plugin.xml (e.g., <runtime>, <requires>) have moved into
the
> > > manifest.mf. The extension related tags retain their original form and
> > > position. As such, in most cases the manifest.mf is actually simpler
to
> > > define and maintain than the corresponding section of the plugin.xml.
> > >
> > > - OSGi implementations typically manage bundles as jars. I'm pretty
> sure
> > > that the spec does not absolutely require this but it is implied. The
> > > bundles may contain internal jars for code (or other stuff) and the
> > runtime
> > > is able to put these on the classpath. We have extended the model to
> allow
> > > for running bundles out of directories (as per standard Eclipse).
> Eclipse
> > > 3.0 will likely ship with plugins in jars as opposed to directories.
> > People
> > > have been asking for this for years and we likely would have done it
> quite
> > > independent of OSGi uptake. Note however that there is no plan to
allow
> > for
> > > multiple bundles to be put in one jar. This would complicate
> > update/install
> > > scenarios and serve little purpose.
> > >
> > > - Eclipse has always been "headless". Since day one there have been
> > > essential applications which run in this mode. For example, the
Eclipse
> > > build mechanism is a headless Eclipse configuration. Anyone can
define
> > > "applications" (using extensions of course) and then run them using
> > > eclispe -application <app id>. It just happens that in Eclipse <= 2.1
> > there
> > > was a default application which opened a GUI.
> > >
> > > - Eclipse extensions/extension-points interactions do not represent
> > > dependency specifications. You can contribute an extension to a
plugin
> on
> > > which you do not depend. As such, when a plugin hosting an extension
> > point
> > > is uninstalled or restarted, plugins providing extensions are not
> > > necessarily shutdown. We purposely kept the dependency mechanism out
of
> > > htis area to increase flexibility. Plugins which want/need to have a
> > > tighter relationship are free to specify a classloader dependency via
> the
> > > <requires> tags.
> > >
> > > Jeff
> > >
> > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > news:brvge3$k9f$1@eclipse.org...
> > > > That's kewl. I have built my own plugin engine based around
extension
> > > > points, extensions, etc. I am not sure why the move to OSGi is so
> > > paramount
> > > > compared to the well thought out extension point mechanism of
Eclipse.
> I
> > > > dislike the idea of using manifest.mf as opposed to plugin.xml. The
> xml
> > > > format is much nicer and easier. In my engine, plugins are
> > > > unloadable/reloadable (still working out the kinks as well), and I
> > believe
> > > > like Eclipse developers have to be aware of referencing other
> dependent
> > > > plugin classes with class variables as opposed to using temporary
> > > variables
> > > > within methods, otherwise the GC may never reclaim a plugin's
> resources.
> > > > Reloading is no problem, simply replace the repository of the plugin
> by
> > > its
> > > > name/version and all lookups/usages go to the newly loaded code. But
> the
> > > > most important part in my mind is the GC able to reclaim unloaded or
> > > > previously loaded when reloaded plugins and resources. Still can't
> > figure
> > > > out why the GC only runs when its out of memory, that is rather
stupid
> > in
> > > my
> > > > opinion, it should run every few minutes, verify any dead ends and
> clean
> > > > them up!
> > > >
> > > > Does the use of OSGi bundles allow embeded jars/zips and such such
> that
> > > you
> > > > can deploy a single .jar file with embeded .jar/.zip files and it
> finds
> > > the
> > > > classes within the embeded jar/zip files without them having to be
> > > unzipped
> > > > to disk? My engine does this, using a single plugin archive file
that
> > > > doesn't have to be unzipped to disk. Also, I have made dependencies
> > > > automagic, in that a plugin doesn't need to specify the plugins it
> > depends
> > > > on. Based on extension points and extensions, as well as events and
> > > > listeners, it can figure out the plugin(s) that are dependent
> > > automatically.
> > > > I do this by simply resolving plugins after each plugin loads. My
> goal,
> > > > before I cam across Eclipse, was to build a reloadable archtiecture
> like
> > > > what JBoss and other app servers have, using a simplified plugin
> model,
> > > > something I devised a few years back using C on a cross-platform
> > project.
> > > > Had I known Eclipse was going to become "headless" a while back, i
> don't
> > > > know that I would have ventured down this path. Now that I have, I
am
> > > > thankful because I have a vastly improved understanding of
classpaths,
> > > > classloaders, the jvm process of loading classes, class space and
how
> > > > classloaders can delegate to others to find classes so that only one
> > > > bytecode is loaded, etc. I admit to borrowing the extension point
idea
> > > from
> > > > Eclipse, it's a great way of connecting plugins. My original engine
> > simply
> > > > used "names" and "versions" to find plugins, so more or less the
same
> > > thing,
> > > > just a little more dependent on specific plugin names that might
> change
> > > > across versions and break dependencies.
> > > >
> > > > Is there any idea how big the "engine" of eclipse is, with OSGi,
it's
> > > > extension point/extension framework, etc? I thought of doing an OSGi
> > > > implementation, but another goal is a very small framework. With
> > > everything
> > > > that my engine does, its only 44K in size including an xml pull
parser
> > > that
> > > > parses the plugin.xml files and can write xml out that any plugin
can
> > use
> > > as
> > > > well. This includes the code for each plugin to have its own loader,
> be
> > > > contained within a single archive file or on disk like how eclipse
> > plugins
> > > > reside, lazy creation of plugins as needed (like eclipse and osgi),
> > > > automagic resolution of dependencies for both extension points and
> > > > extensions, and events/listeners, the ability to specify specific
> types
> > of
> > > > plugins to be loaded based on Class types, and so on. It is a
non-GUI
> > > > engine, so it can be used for any purpose, but I am building a UI
> > > Framework
> > > > on top of it using Swing. Forgive me for saying so, but I dislike
SWT
> > and
> > > I
> > > > think the vast majority of java developers are not going to learn
SWT
> > > given
> > > > that Swing is as good in many respects, better in some, and not as
> good
> > in
> > > > others, but comes with every JRE/JDK deployed as opposed to having
to
> > ship
> > > > swt.jar and platform specific libraries, as well as a new API to
> learn.
> > > > Therefore I didn't want to base my UI framework around SWT, although
> it
> > > > could easily be done by simply replacing the core plugin and using
SWT
> > > > instead of Swing. The UI framework will provide a similar paradigm
to
> > > > Eclipse and other IDE's with a workspace, menu/toolbar, status bar,
> left
> > > > side "task" bar, help facility, preference facility, wizard
component,
> > > file
> > > > chooser component and so forth. All of this is open source as well,
> and
> > > the
> > > > goal is not to compete with any other IDE, it is to provide a very
> > small,
> > > > super easy to develop for, pluggable UI framework using Swing so
that
> > > > hopefully I can help bring those 10 million java engineers over that
> Sun
> > > > claims will come! "If you build it they will come" comes ot mind. ;)
I
> > am
> > > > trying to build it, hoping they'll come and use it!
> > > >
> > > > Anyway, I am glad to see Eclipse is finally going headless and
> > > unload/reload
> > > > of plugins will be possible! I started doing unload/reload a few
> months
> > > back
> > > > before I read that OSGi would be integrated into 3.0. I was
surprised
> to
> > > see
> > > > that I had done a similar way of notifying plugins. That is, if a
> plugin
> > > > that provides an extension is reloaded, it notifes the plugin that
> owns
> > > the
> > > > extension point that the extension is being removed, or added, etc.
> > > > Basically, all plugins affected get notified of events, such as
> unload,
> > > > destroy, extension removed/added, extension point removed/added,
etc.
> > > >
> > > >
> > > >
> > > > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > > > news:brtusv$q7$1@eclipse.org...
> > > > > In the new runtime you can supply bundles or traditional plugins.
> The
> > > only
> > > > > real distinction is whether you supply a plugin.xml or a
manifest.mf
> > and
> > > a
> > > > > bit of packaging. Dynamic behaviour of the classloaders is taken
> care
> > of
> > > > by
> > > > > OSGi. The spec details everything you could want to know. For
> > bundles
> > > > > supplying extensions and extension points there is a new set of
API
> > > > relating
> > > > > to extension registry changes. Look for
> > > > > org.eclipse.core.runtime.ExtensionChangeListener and related
types.
> > > > >
> > > > > There are sure to be some rough edges in the dynamic support as it
> is
> > > both
> > > > > hard and new. Try it out and let us know what you think and of
> > course,
> > > if
> > > > > you find any bugs, please log a bug report. January will see us
> > > spending
> > > > > sigificant effort to make more of Eclipse dynamic aware/enabled as
> > well
> > > as
> > > > > put together some demo apps to show people how it is done.
> > > > >
> > > > > Note also that currently you cannot install bundles in jars as per
> > > normal
> > > > > OSGi. They have to be in exploded dirs like plugins. This is a
> > > temporary
> > > > > limitation which will be resolved in January as well.
> > > > >
> > > > > Enjoy
> > > > > Jeff
> > > > >
> > > > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > > > news:brdocp$v0$1@eclipse.org...
> > > > > > Alrighty, so I haven't checked yet, but how are plugins to be
> > written?
> > > > Do
> > > > > we
> > > > > > do the OSGi bundle method, or continue our normal Eclipse
> extension
> > > > model
> > > > > > plugin? What I most want to know about is how we write plugins
> > > correctly
> > > > > so
> > > > > > they can be unloaded and reloaded? IS there special events we
> listen
> > > > for?
> > > > > I
> > > > > > mean, if my plugin depends on plugin B, and B is being reloaded
or
> > > > > unloaded,
> > > > > > does my plugin get unloaded automatically (assuming B is
> unloaded),
> > or
> > > > > does
> > > > > > it get notified that B is no longer available, and somehow in
code
> I
> > > > have
> > > > > to
> > > > > > adapt to that? This gets more complex. What if my plugin
provides
> > > > > > functionality that others depend on, but to provide that
> > > functionality,
> > > > my
> > > > > > plugin depends on one or more plugins, and one or more of those
> get
> > > > > > unloaded? Does the unloading go all the way across all chains
> until
> > no
> > > > > > plugin that is dependent on the one (or more) being unloaded is
> > done?
> > > > What
> > > > > > about reloading? Two cases I see, it reloads a change that does
> not
> > > > break
> > > > > my
> > > > > > plugin, or it reloads and breaks my plugins ability to use it,
> > either
> > > > via
> > > > > a
> > > > > > new version, a method removal that my plugin relies on, or some
> > other
> > > > > > reason. How is this handled now?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #32186 is a reply to message #31936] |
Fri, 09 January 2004 17:15 |
Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
I think I missed your point in my last reply, it makes sense now. You are
correct in that a host extension point plugin doesn't care to see the rest
of the classes of extension plugins, only the extension class itself.
What I am not sure of though, is if a host plugin needs to pass an instance
of an object it creates so that each extension plugin can use it
(hypothetically speaking), each extension plugin needs to see the host
plugin as well, in order to see the definition of the class being passed to
it. I realize this is an odd situation, but you can't prevent developers
from doing this. So how is such handled? In this case, how does each
extension get to use the extension point classloader to find the class
definition being passed as an instance? Or is this not even possible?
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:btf1ih$b5f$1@eclipse.org...
> The plugin hosting the extension point cannot require the ones providing
the
> extensions since it does not know about them (a priori). At runtime when
a
> host goes to instantiate a contributed extension, it simply asks the
plugin
> providing the extension to load the specified class. This is analogous to
> adding a dependency from the host to the contributor but the host only
wants
> to see the contributed class not all the classes that happen to be in the
> contributing plugin.
>
> Jeff
>
> "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> news:bs82vo$jjs$1@eclipse.org...
> > Hi Jeff,
> >
> > Sorry to post two back to back posts in regards to your reply, but
> something
> > you mentioned in your reply, after re-reading it, struck me with
interest.
> I
> > am hoping you don't mind answering a few questions.
> >
> > First, I have posted a few times in other groups with no success on
reply,
> > and in my previous reply indicated this question, how do plugins/bundles
> in
> > Eclipse/RCP handle resolution of event listeners to events? Is this done
> on
> > a per extension point basis, where by if an extension point, as part of
> its
> > schema, requires a class that represents a listener to an event the
> > extension point may fire, it is defined in the schema and every
extension
> is
> > required (or optional) and thus the extension point code, when executed,
> > then creates all extension plugins so that it can create instances of
the
> > listener class and add them as listeners? Is there perhaps another
> mechanism
> > for doing this, or is it left up to each extension plugin to be
activated
> > and at that point programatically add it's listener to an event it
wishes
> to
> > listen for?
> >
> > In regards to what you wrote about how an extension to an extension
point
> > does not necessitate a dependency, I am confused? In order for the
> > classloader of an extension point to "see" a class within another
plugins
> > classloader that extends the extension point, doesn't the extension
point
> > plugin require a reference to the extensions classloader in order to
> > delegate the lookup of the extension class to find it? I am fairly
versed
> on
> > classloaders. My engine's PluginClassLoader keeps a List of dependent
> loader
> > references for faster lookup of classes that may not be contained within
> its
> > own classpath. So you don't have to spend a lot of time looking at how I
> > have done this, I'll tell you how here. Basically, there are a few
> scenarios
> > I can see where "dependencies" may occur. Any extension of an extension
> > point would require the extension point plugin to "depend" on the
> extension
> > plugins in that it needs to grab each extension plugin classloader to
ask
> it
> > to find the extension class so the extension point can use it. Now, that
> > said, if the extension point defines an interface, as is usually the
case,
> I
> > may be wrong on this but generally you would NOT need to "see" each
> > extension classloader because the common interface would mean that the
> > extension point code can call into the interface without specific
> > "visiblility" to each extension implementation of that interface... or
am
> I
> > wrong on this and it is required to "see" every implementation of the
> > extension point interface through each extension plugins classloader? If
> it
> > IS required, then as I see it, the extension point plugin "depends" on
> each
> > extension plugin. If this is the case, then if the extension point
plugin
> is
> > unloaded or reloaded, while not necessary my engine would send an event
to
> > every extension letting them at least know that the extension point is
no
> > longer available. Some plugins may only extend this one point, and thus
> may
> > not need to stay resident as well if they only contribute to that one
> > extension point, and thus should also be unloaded, or at least put in in
> > "inactive" state. My engine would simply destroy them but not unload
them,
> > so that the GC may reclaim any resources they used. Basically, they go
> into
> > a state as if they were loaded/parsed but never activated, so that
should
> > the plugin with the extension point get reloaded at some point, they can
> > once again be resolved against it and come to life if requested.
> >
> > Another scenario that I see is if the extension point interface provides
> for
> > a callback, where by a specific implementation the extension point
> provides
> > may be passed to each extension, and each extension can then make calls
> via
> > the interface callback, into the extension point. How to handle this?
> >
> > Lastly, what if an extension point plugin is to provide an interface AND
> an
> > implementation of that interface so that extension plugins can directly
> use
> > the one implementation instead of the normal manner in which an
extension
> > point makes use of any one or all extension implementations of an
> interface
> > the extension point provides? In this case, each extension now depends
on
> > the extension point, and each extensions classloader must "see" into the
> > extension point.
> >
> > In all these scenarios, my engine simply sets a ciruclar dependency,
that
> is
> > A's loader has B's loader as a dependency, and B's loader has A's loader
> as
> > a dependency. If you look at my code, there is something I do though (an
> > maybe it isn't all good, but it seems to work well). I ran into a
> > Circularity problem before where by if A looks in B's loader and happens
> to
> > look in B's ref to A's loader, it could loop forever (hence the
> Circularity
> > problem I had). So, to prevent this, I define a rule, in that a plugin's
> > loader can ONLY look within a dependent plugins classpath, not any of
its
> > dependent loaders. This avoids A looking at B's dependent of A. The
> drawback
> > is that if A depends on B, B depends on C and C wraps ant.jar, A can not
> use
> > ant.jar, only B can. So A would have to extend C as well. One thing I
did
> > add is a "shareable" parent loader, sort of like how JBoss has a single
> > repository it first checks. Any plugin can add a "shareable" URL to a
> > library of their's so that ALL plugins can access it. There can be
> pros/cons
> > to this approach, but generally this is application specific, not plugin
> > defined. An application using the engine would perhaps specify specific
> > libraries it wishes that all plugins would use. Of course you can run in
> to
> > version issues this way, as does occur with JBoss where you are limited
to
> > the "parent" version of a library regardless if each plugin has their
own
> > version. But I see this as a small factor as this should be used on an
> > application level anyway.
> >
> > So, having said all that, how does Eclipse allow extension points to not
> > depend on extensions via their classloader? Keep in mind, if you look at
> my
> > code, I am not only shooting for small size, but optimum speed. If any
> java.
> > or javax. class is asked to be loaded in the loadClass(), I simply
> delegate
> > it directly to the system loader. As well, if any of the plugin engine's
> > classes are asked, it goes directly to the parent loader. This is to
avoid
> > having to go through the list of lookup possibilities (the cache,
> shareable
> > loader, classpath, dependent loaders and finally the parent, if
> configured).
> >
> > Thanks for your time, I look forward to your thoughts.
> >
> >
> > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > news:bs0bsg$b6c$1@eclipse.org...
> > > Thanks for you continuing interest. You have mentioned your engine
> > > previously but have never provided pointers to where someone can
> download
> > > and try it or get more information. What is its status?
> > >
> > > For you and others, I would like to clarify a few things:
> > >
> > > - OSGi bundles/classloaders/etc and the Eclipse extension mechanism
are
> > > completely separated notions. The new runtime has both and users will
> > > benefit. OSGi brings dynamic behaviour, services, security etc and
> > Eclipse
> > > retains the power of extensions etc. There is no loss of
functionality
> or
> > > generality in the new runtime, only gain.
> > >
> > > - plugin.xml and manifest.mf: neither are particularly easy for
> developers
> > > to manage without tooling support. Note that only the runtime related
> > > elements of plugin.xml (e.g., <runtime>, <requires>) have moved into
the
> > > manifest.mf. The extension related tags retain their original form and
> > > position. As such, in most cases the manifest.mf is actually simpler
to
> > > define and maintain than the corresponding section of the plugin.xml.
> > >
> > > - OSGi implementations typically manage bundles as jars. I'm pretty
> sure
> > > that the spec does not absolutely require this but it is implied. The
> > > bundles may contain internal jars for code (or other stuff) and the
> > runtime
> > > is able to put these on the classpath. We have extended the model to
> allow
> > > for running bundles out of directories (as per standard Eclipse).
> Eclipse
> > > 3.0 will likely ship with plugins in jars as opposed to directories.
> > People
> > > have been asking for this for years and we likely would have done it
> quite
> > > independent of OSGi uptake. Note however that there is no plan to
allow
> > for
> > > multiple bundles to be put in one jar. This would complicate
> > update/install
> > > scenarios and serve little purpose.
> > >
> > > - Eclipse has always been "headless". Since day one there have been
> > > essential applications which run in this mode. For example, the
Eclipse
> > > build mechanism is a headless Eclipse configuration. Anyone can
define
> > > "applications" (using extensions of course) and then run them using
> > > eclispe -application <app id>. It just happens that in Eclipse <= 2.1
> > there
> > > was a default application which opened a GUI.
> > >
> > > - Eclipse extensions/extension-points interactions do not represent
> > > dependency specifications. You can contribute an extension to a
plugin
> on
> > > which you do not depend. As such, when a plugin hosting an extension
> > point
> > > is uninstalled or restarted, plugins providing extensions are not
> > > necessarily shutdown. We purposely kept the dependency mechanism out
of
> > > htis area to increase flexibility. Plugins which want/need to have a
> > > tighter relationship are free to specify a classloader dependency via
> the
> > > <requires> tags.
> > >
> > > Jeff
> > >
> > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > news:brvge3$k9f$1@eclipse.org...
> > > > That's kewl. I have built my own plugin engine based around
extension
> > > > points, extensions, etc. I am not sure why the move to OSGi is so
> > > paramount
> > > > compared to the well thought out extension point mechanism of
Eclipse.
> I
> > > > dislike the idea of using manifest.mf as opposed to plugin.xml. The
> xml
> > > > format is much nicer and easier. In my engine, plugins are
> > > > unloadable/reloadable (still working out the kinks as well), and I
> > believe
> > > > like Eclipse developers have to be aware of referencing other
> dependent
> > > > plugin classes with class variables as opposed to using temporary
> > > variables
> > > > within methods, otherwise the GC may never reclaim a plugin's
> resources.
> > > > Reloading is no problem, simply replace the repository of the plugin
> by
> > > its
> > > > name/version and all lookups/usages go to the newly loaded code. But
> the
> > > > most important part in my mind is the GC able to reclaim unloaded or
> > > > previously loaded when reloaded plugins and resources. Still can't
> > figure
> > > > out why the GC only runs when its out of memory, that is rather
stupid
> > in
> > > my
> > > > opinion, it should run every few minutes, verify any dead ends and
> clean
> > > > them up!
> > > >
> > > > Does the use of OSGi bundles allow embeded jars/zips and such such
> that
> > > you
> > > > can deploy a single .jar file with embeded .jar/.zip files and it
> finds
> > > the
> > > > classes within the embeded jar/zip files without them having to be
> > > unzipped
> > > > to disk? My engine does this, using a single plugin archive file
that
> > > > doesn't have to be unzipped to disk. Also, I have made dependencies
> > > > automagic, in that a plugin doesn't need to specify the plugins it
> > depends
> > > > on. Based on extension points and extensions, as well as events and
> > > > listeners, it can figure out the plugin(s) that are dependent
> > > automatically.
> > > > I do this by simply resolving plugins after each plugin loads. My
> goal,
> > > > before I cam across Eclipse, was to build a reloadable archtiecture
> like
> > > > what JBoss and other app servers have, using a simplified plugin
> model,
> > > > something I devised a few years back using C on a cross-platform
> > project.
> > > > Had I known Eclipse was going to become "headless" a while back, i
> don't
> > > > know that I would have ventured down this path. Now that I have, I
am
> > > > thankful because I have a vastly improved understanding of
classpaths,
> > > > classloaders, the jvm process of loading classes, class space and
how
> > > > classloaders can delegate to others to find classes so that only one
> > > > bytecode is loaded, etc. I admit to borrowing the extension point
idea
> > > from
> > > > Eclipse, it's a great way of connecting plugins. My original engine
> > simply
> > > > used "names" and "versions" to find plugins, so more or less the
same
> > > thing,
> > > > just a little more dependent on specific plugin names that might
> change
> > > > across versions and break dependencies.
> > > >
> > > > Is there any idea how big the "engine" of eclipse is, with OSGi,
it's
> > > > extension point/extension framework, etc? I thought of doing an OSGi
> > > > implementation, but another goal is a very small framework. With
> > > everything
> > > > that my engine does, its only 44K in size including an xml pull
parser
> > > that
> > > > parses the plugin.xml files and can write xml out that any plugin
can
> > use
> > > as
> > > > well. This includes the code for each plugin to have its own loader,
> be
> > > > contained within a single archive file or on disk like how eclipse
> > plugins
> > > > reside, lazy creation of plugins as needed (like eclipse and osgi),
> > > > automagic resolution of dependencies for both extension points and
> > > > extensions, and events/listeners, the ability to specify specific
> types
> > of
> > > > plugins to be loaded based on Class types, and so on. It is a
non-GUI
> > > > engine, so it can be used for any purpose, but I am building a UI
> > > Framework
> > > > on top of it using Swing. Forgive me for saying so, but I dislike
SWT
> > and
> > > I
> > > > think the vast majority of java developers are not going to learn
SWT
> > > given
> > > > that Swing is as good in many respects, better in some, and not as
> good
> > in
> > > > others, but comes with every JRE/JDK deployed as opposed to having
to
> > ship
> > > > swt.jar and platform specific libraries, as well as a new API to
> learn.
> > > > Therefore I didn't want to base my UI framework around SWT, although
> it
> > > > could easily be done by simply replacing the core plugin and using
SWT
> > > > instead of Swing. The UI framework will provide a similar paradigm
to
> > > > Eclipse and other IDE's with a workspace, menu/toolbar, status bar,
> left
> > > > side "task" bar, help facility, preference facility, wizard
component,
> > > file
> > > > chooser component and so forth. All of this is open source as well,
> and
> > > the
> > > > goal is not to compete with any other IDE, it is to provide a very
> > small,
> > > > super easy to develop for, pluggable UI framework using Swing so
that
> > > > hopefully I can help bring those 10 million java engineers over that
> Sun
> > > > claims will come! "If you build it they will come" comes ot mind. ;)
I
> > am
> > > > trying to build it, hoping they'll come and use it!
> > > >
> > > > Anyway, I am glad to see Eclipse is finally going headless and
> > > unload/reload
> > > > of plugins will be possible! I started doing unload/reload a few
> months
> > > back
> > > > before I read that OSGi would be integrated into 3.0. I was
surprised
> to
> > > see
> > > > that I had done a similar way of notifying plugins. That is, if a
> plugin
> > > > that provides an extension is reloaded, it notifes the plugin that
> owns
> > > the
> > > > extension point that the extension is being removed, or added, etc.
> > > > Basically, all plugins affected get notified of events, such as
> unload,
> > > > destroy, extension removed/added, extension point removed/added,
etc.
> > > >
> > > >
> > > >
> > > > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > > > news:brtusv$q7$1@eclipse.org...
> > > > > In the new runtime you can supply bundles or traditional plugins.
> The
> > > only
> > > > > real distinction is whether you supply a plugin.xml or a
manifest.mf
> > and
> > > a
> > > > > bit of packaging. Dynamic behaviour of the classloaders is taken
> care
> > of
> > > > by
> > > > > OSGi. The spec details everything you could want to know. For
> > bundles
> > > > > supplying extensions and extension points there is a new set of
API
> > > > relating
> > > > > to extension registry changes. Look for
> > > > > org.eclipse.core.runtime.ExtensionChangeListener and related
types.
> > > > >
> > > > > There are sure to be some rough edges in the dynamic support as it
> is
> > > both
> > > > > hard and new. Try it out and let us know what you think and of
> > course,
> > > if
> > > > > you find any bugs, please log a bug report. January will see us
> > > spending
> > > > > sigificant effort to make more of Eclipse dynamic aware/enabled as
> > well
> > > as
> > > > > put together some demo apps to show people how it is done.
> > > > >
> > > > > Note also that currently you cannot install bundles in jars as per
> > > normal
> > > > > OSGi. They have to be in exploded dirs like plugins. This is a
> > > temporary
> > > > > limitation which will be resolved in January as well.
> > > > >
> > > > > Enjoy
> > > > > Jeff
> > > > >
> > > > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > > > news:brdocp$v0$1@eclipse.org...
> > > > > > Alrighty, so I haven't checked yet, but how are plugins to be
> > written?
> > > > Do
> > > > > we
> > > > > > do the OSGi bundle method, or continue our normal Eclipse
> extension
> > > > model
> > > > > > plugin? What I most want to know about is how we write plugins
> > > correctly
> > > > > so
> > > > > > they can be unloaded and reloaded? IS there special events we
> listen
> > > > for?
> > > > > I
> > > > > > mean, if my plugin depends on plugin B, and B is being reloaded
or
> > > > > unloaded,
> > > > > > does my plugin get unloaded automatically (assuming B is
> unloaded),
> > or
> > > > > does
> > > > > > it get notified that B is no longer available, and somehow in
code
> I
> > > > have
> > > > > to
> > > > > > adapt to that? This gets more complex. What if my plugin
provides
> > > > > > functionality that others depend on, but to provide that
> > > functionality,
> > > > my
> > > > > > plugin depends on one or more plugins, and one or more of those
> get
> > > > > > unloaded? Does the unloading go all the way across all chains
> until
> > no
> > > > > > plugin that is dependent on the one (or more) being unloaded is
> > done?
> > > > What
> > > > > > about reloading? Two cases I see, it reloads a change that does
> not
> > > > break
> > > > > my
> > > > > > plugin, or it reloads and breaks my plugins ability to use it,
> > either
> > > > via
> > > > > a
> > > > > > new version, a method removal that my plugin relies on, or some
> > other
> > > > > > reason. How is this handled now?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #32326 is a reply to message #31796] |
Sun, 11 January 2004 02:00 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.ca.ibm.com
Peter,
Best bet is to look at the org.eclipse.core.runtime bundle/plugin as an
example. As you will notice, currently regular eclipse only works with
bundle jars exploded into directories. This will be fixed soon.
Plugins/bundles can be pretty much anywhere but the easiest/default way is
to put them in eclipse/plugins. In there you should have the same structure
that you would have in your bundle jar file (including the manifest.mf etc).
Note that if you just have a plugin.xml we will generate a manifest.mf for
you.
Dynamic plugins are no differnet then regular plugins, they are just
installed after Eclipse is running. Due to the nature of the boot sequence,
technically speaking, all plugins are dynamic plugins since they are all
installed after the runtime is up and running.
If you are concerned about your UI elements not showing up, this is because
the UI is not yet dynamic aware. That is, it does not respond to the
extension registry change events that the runtime broadcasts. This too is
being worked on and should be in place in the next week or so.
If this does not answer your questions, can you be more specific about what
is not working?
Jeff
"Peter Kriens" <Peter.Kriens@aQute.biz> wrote in message
news:bt1j2l$5ot$1@eclipse.org...
> Jeff (or anybody else),
> Can you give a hint how the plugin directory should look like for a
> dynamic plugin? I can't figure out how to get a simple hello/goodbye world
> to run. I could load my own debugger bundle in Eclipse which is pretty
> cool!
>
> An example would be fantastic.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>
> Jeff McAffer wrote:
>
> > In the new runtime you can supply bundles or traditional plugins. The
only
> > real distinction is whether you supply a plugin.xml or a manifest.mf and
a
> > bit of packaging. Dynamic behaviour of the classloaders is taken care of
by
> > OSGi. The spec details everything you could want to know. For bundles
> > supplying extensions and extension points there is a new set of API
relating
> > to extension registry changes. Look for
> > org.eclipse.core.runtime.ExtensionChangeListener and related types.
>
> > There are sure to be some rough edges in the dynamic support as it is
both
> > hard and new. Try it out and let us know what you think and of course,
if
> > you find any bugs, please log a bug report. January will see us
spending
> > sigificant effort to make more of Eclipse dynamic aware/enabled as well
as
> > put together some demo apps to show people how it is done.
>
> > Note also that currently you cannot install bundles in jars as per
normal
> > OSGi. They have to be in exploded dirs like plugins. This is a
temporary
> > limitation which will be resolved in January as well.
>
> > Enjoy
> > Jeff
>
> > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > news:brdocp$v0$1@eclipse.org...
> > > Alrighty, so I haven't checked yet, but how are plugins to be written?
Do
> > we
> > > do the OSGi bundle method, or continue our normal Eclipse extension
model
> > > plugin? What I most want to know about is how we write plugins
correctly
> > so
> > > they can be unloaded and reloaded? IS there special events we listen
for?
> > I
> > > mean, if my plugin depends on plugin B, and B is being reloaded or
> > unloaded,
> > > does my plugin get unloaded automatically (assuming B is unloaded), or
> > does
> > > it get notified that B is no longer available, and somehow in code I
have
> > to
> > > adapt to that? This gets more complex. What if my plugin provides
> > > functionality that others depend on, but to provide that
functionality, my
> > > plugin depends on one or more plugins, and one or more of those get
> > > unloaded? Does the unloading go all the way across all chains until no
> > > plugin that is dependent on the one (or more) being unloaded is done?
What
> > > about reloading? Two cases I see, it reloads a change that does not
break
> > my
> > > plugin, or it reloads and breaks my plugins ability to use it, either
via
> > a
> > > new version, a method removal that my plugin relies on, or some other
> > > reason. How is this handled now?
> > >
> > > Thanks.
> > >
> > >
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #32364 is a reply to message #32186] |
Sun, 11 January 2004 02:08 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.ca.ibm.com
The case you outline is in fact the one that is supported. Make it
concrete. The UI has an extension point for views. view extensions must
specify a class which implements IView (making up this example so don't take
it too literally). IView is defined in the UI plugin. You have a plugin P
which wants to supply a view. As such is has an extension that identifies a
class MyView which implements IView. For P to do this, it must "require"
the UI.
Note that the UI does not need ot know about P. When the UI wants to
"createExectuableExtension", it is in effect telling the extension to
instantiate itself. Since the extension knows which plugin it came from
(i.e., P), it knows wihch classloader to use to load the defined class
(e.g., MyView).
Note also that in this case the plugin (P) defining the extension needed to
require the plugin (UI) since it needed ot reference a class. This is only
becuase it needed ot reference a class from UI. NOT because it defined an
extension for one of UI's extension points. There are lots of extension
points wihch do not require class specifications (doc, markers, ...).
Jeff
"spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
news:btmnhm$2p8$1@eclipse.org...
> I think I missed your point in my last reply, it makes sense now. You are
> correct in that a host extension point plugin doesn't care to see the rest
> of the classes of extension plugins, only the extension class itself.
>
> What I am not sure of though, is if a host plugin needs to pass an
instance
> of an object it creates so that each extension plugin can use it
> (hypothetically speaking), each extension plugin needs to see the host
> plugin as well, in order to see the definition of the class being passed
to
> it. I realize this is an odd situation, but you can't prevent developers
> from doing this. So how is such handled? In this case, how does each
> extension get to use the extension point classloader to find the class
> definition being passed as an instance? Or is this not even possible?
>
>
>
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> news:btf1ih$b5f$1@eclipse.org...
> > The plugin hosting the extension point cannot require the ones providing
> the
> > extensions since it does not know about them (a priori). At runtime
when
> a
> > host goes to instantiate a contributed extension, it simply asks the
> plugin
> > providing the extension to load the specified class. This is analogous
to
> > adding a dependency from the host to the contributor but the host only
> wants
> > to see the contributed class not all the classes that happen to be in
the
> > contributing plugin.
> >
> > Jeff
> >
> > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > news:bs82vo$jjs$1@eclipse.org...
> > > Hi Jeff,
> > >
> > > Sorry to post two back to back posts in regards to your reply, but
> > something
> > > you mentioned in your reply, after re-reading it, struck me with
> interest.
> > I
> > > am hoping you don't mind answering a few questions.
> > >
> > > First, I have posted a few times in other groups with no success on
> reply,
> > > and in my previous reply indicated this question, how do
plugins/bundles
> > in
> > > Eclipse/RCP handle resolution of event listeners to events? Is this
done
> > on
> > > a per extension point basis, where by if an extension point, as part
of
> > its
> > > schema, requires a class that represents a listener to an event the
> > > extension point may fire, it is defined in the schema and every
> extension
> > is
> > > required (or optional) and thus the extension point code, when
executed,
> > > then creates all extension plugins so that it can create instances of
> the
> > > listener class and add them as listeners? Is there perhaps another
> > mechanism
> > > for doing this, or is it left up to each extension plugin to be
> activated
> > > and at that point programatically add it's listener to an event it
> wishes
> > to
> > > listen for?
> > >
> > > In regards to what you wrote about how an extension to an extension
> point
> > > does not necessitate a dependency, I am confused? In order for the
> > > classloader of an extension point to "see" a class within another
> plugins
> > > classloader that extends the extension point, doesn't the extension
> point
> > > plugin require a reference to the extensions classloader in order to
> > > delegate the lookup of the extension class to find it? I am fairly
> versed
> > on
> > > classloaders. My engine's PluginClassLoader keeps a List of dependent
> > loader
> > > references for faster lookup of classes that may not be contained
within
> > its
> > > own classpath. So you don't have to spend a lot of time looking at how
I
> > > have done this, I'll tell you how here. Basically, there are a few
> > scenarios
> > > I can see where "dependencies" may occur. Any extension of an
extension
> > > point would require the extension point plugin to "depend" on the
> > extension
> > > plugins in that it needs to grab each extension plugin classloader to
> ask
> > it
> > > to find the extension class so the extension point can use it. Now,
that
> > > said, if the extension point defines an interface, as is usually the
> case,
> > I
> > > may be wrong on this but generally you would NOT need to "see" each
> > > extension classloader because the common interface would mean that the
> > > extension point code can call into the interface without specific
> > > "visiblility" to each extension implementation of that interface... or
> am
> > I
> > > wrong on this and it is required to "see" every implementation of the
> > > extension point interface through each extension plugins classloader?
If
> > it
> > > IS required, then as I see it, the extension point plugin "depends" on
> > each
> > > extension plugin. If this is the case, then if the extension point
> plugin
> > is
> > > unloaded or reloaded, while not necessary my engine would send an
event
> to
> > > every extension letting them at least know that the extension point is
> no
> > > longer available. Some plugins may only extend this one point, and
thus
> > may
> > > not need to stay resident as well if they only contribute to that one
> > > extension point, and thus should also be unloaded, or at least put in
in
> > > "inactive" state. My engine would simply destroy them but not unload
> them,
> > > so that the GC may reclaim any resources they used. Basically, they go
> > into
> > > a state as if they were loaded/parsed but never activated, so that
> should
> > > the plugin with the extension point get reloaded at some point, they
can
> > > once again be resolved against it and come to life if requested.
> > >
> > > Another scenario that I see is if the extension point interface
provides
> > for
> > > a callback, where by a specific implementation the extension point
> > provides
> > > may be passed to each extension, and each extension can then make
calls
> > via
> > > the interface callback, into the extension point. How to handle this?
> > >
> > > Lastly, what if an extension point plugin is to provide an interface
AND
> > an
> > > implementation of that interface so that extension plugins can
directly
> > use
> > > the one implementation instead of the normal manner in which an
> extension
> > > point makes use of any one or all extension implementations of an
> > interface
> > > the extension point provides? In this case, each extension now depends
> on
> > > the extension point, and each extensions classloader must "see" into
the
> > > extension point.
> > >
> > > In all these scenarios, my engine simply sets a ciruclar dependency,
> that
> > is
> > > A's loader has B's loader as a dependency, and B's loader has A's
loader
> > as
> > > a dependency. If you look at my code, there is something I do though
(an
> > > maybe it isn't all good, but it seems to work well). I ran into a
> > > Circularity problem before where by if A looks in B's loader and
happens
> > to
> > > look in B's ref to A's loader, it could loop forever (hence the
> > Circularity
> > > problem I had). So, to prevent this, I define a rule, in that a
plugin's
> > > loader can ONLY look within a dependent plugins classpath, not any of
> its
> > > dependent loaders. This avoids A looking at B's dependent of A. The
> > drawback
> > > is that if A depends on B, B depends on C and C wraps ant.jar, A can
not
> > use
> > > ant.jar, only B can. So A would have to extend C as well. One thing I
> did
> > > add is a "shareable" parent loader, sort of like how JBoss has a
single
> > > repository it first checks. Any plugin can add a "shareable" URL to a
> > > library of their's so that ALL plugins can access it. There can be
> > pros/cons
> > > to this approach, but generally this is application specific, not
plugin
> > > defined. An application using the engine would perhaps specify
specific
> > > libraries it wishes that all plugins would use. Of course you can run
in
> > to
> > > version issues this way, as does occur with JBoss where you are
limited
> to
> > > the "parent" version of a library regardless if each plugin has their
> own
> > > version. But I see this as a small factor as this should be used on an
> > > application level anyway.
> > >
> > > So, having said all that, how does Eclipse allow extension points to
not
> > > depend on extensions via their classloader? Keep in mind, if you look
at
> > my
> > > code, I am not only shooting for small size, but optimum speed. If any
> > java.
> > > or javax. class is asked to be loaded in the loadClass(), I simply
> > delegate
> > > it directly to the system loader. As well, if any of the plugin
engine's
> > > classes are asked, it goes directly to the parent loader. This is to
> avoid
> > > having to go through the list of lookup possibilities (the cache,
> > shareable
> > > loader, classpath, dependent loaders and finally the parent, if
> > configured).
> > >
> > > Thanks for your time, I look forward to your thoughts.
> > >
> > >
> > > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > > news:bs0bsg$b6c$1@eclipse.org...
> > > > Thanks for you continuing interest. You have mentioned your engine
> > > > previously but have never provided pointers to where someone can
> > download
> > > > and try it or get more information. What is its status?
> > > >
> > > > For you and others, I would like to clarify a few things:
> > > >
> > > > - OSGi bundles/classloaders/etc and the Eclipse extension mechanism
> are
> > > > completely separated notions. The new runtime has both and users
will
> > > > benefit. OSGi brings dynamic behaviour, services, security etc and
> > > Eclipse
> > > > retains the power of extensions etc. There is no loss of
> functionality
> > or
> > > > generality in the new runtime, only gain.
> > > >
> > > > - plugin.xml and manifest.mf: neither are particularly easy for
> > developers
> > > > to manage without tooling support. Note that only the runtime
related
> > > > elements of plugin.xml (e.g., <runtime>, <requires>) have moved into
> the
> > > > manifest.mf. The extension related tags retain their original form
and
> > > > position. As such, in most cases the manifest.mf is actually
simpler
> to
> > > > define and maintain than the corresponding section of the
plugin.xml.
> > > >
> > > > - OSGi implementations typically manage bundles as jars. I'm pretty
> > sure
> > > > that the spec does not absolutely require this but it is implied.
The
> > > > bundles may contain internal jars for code (or other stuff) and the
> > > runtime
> > > > is able to put these on the classpath. We have extended the model to
> > allow
> > > > for running bundles out of directories (as per standard Eclipse).
> > Eclipse
> > > > 3.0 will likely ship with plugins in jars as opposed to directories.
> > > People
> > > > have been asking for this for years and we likely would have done it
> > quite
> > > > independent of OSGi uptake. Note however that there is no plan to
> allow
> > > for
> > > > multiple bundles to be put in one jar. This would complicate
> > > update/install
> > > > scenarios and serve little purpose.
> > > >
> > > > - Eclipse has always been "headless". Since day one there have been
> > > > essential applications which run in this mode. For example, the
> Eclipse
> > > > build mechanism is a headless Eclipse configuration. Anyone can
> define
> > > > "applications" (using extensions of course) and then run them using
> > > > eclispe -application <app id>. It just happens that in Eclipse <=
2.1
> > > there
> > > > was a default application which opened a GUI.
> > > >
> > > > - Eclipse extensions/extension-points interactions do not represent
> > > > dependency specifications. You can contribute an extension to a
> plugin
> > on
> > > > which you do not depend. As such, when a plugin hosting an
extension
> > > point
> > > > is uninstalled or restarted, plugins providing extensions are not
> > > > necessarily shutdown. We purposely kept the dependency mechanism
out
> of
> > > > htis area to increase flexibility. Plugins which want/need to have
a
> > > > tighter relationship are free to specify a classloader dependency
via
> > the
> > > > <requires> tags.
> > > >
> > > > Jeff
> > > >
> > > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > > news:brvge3$k9f$1@eclipse.org...
> > > > > That's kewl. I have built my own plugin engine based around
> extension
> > > > > points, extensions, etc. I am not sure why the move to OSGi is so
> > > > paramount
> > > > > compared to the well thought out extension point mechanism of
> Eclipse.
> > I
> > > > > dislike the idea of using manifest.mf as opposed to plugin.xml.
The
> > xml
> > > > > format is much nicer and easier. In my engine, plugins are
> > > > > unloadable/reloadable (still working out the kinks as well), and I
> > > believe
> > > > > like Eclipse developers have to be aware of referencing other
> > dependent
> > > > > plugin classes with class variables as opposed to using temporary
> > > > variables
> > > > > within methods, otherwise the GC may never reclaim a plugin's
> > resources.
> > > > > Reloading is no problem, simply replace the repository of the
plugin
> > by
> > > > its
> > > > > name/version and all lookups/usages go to the newly loaded code.
But
> > the
> > > > > most important part in my mind is the GC able to reclaim unloaded
or
> > > > > previously loaded when reloaded plugins and resources. Still can't
> > > figure
> > > > > out why the GC only runs when its out of memory, that is rather
> stupid
> > > in
> > > > my
> > > > > opinion, it should run every few minutes, verify any dead ends and
> > clean
> > > > > them up!
> > > > >
> > > > > Does the use of OSGi bundles allow embeded jars/zips and such such
> > that
> > > > you
> > > > > can deploy a single .jar file with embeded .jar/.zip files and it
> > finds
> > > > the
> > > > > classes within the embeded jar/zip files without them having to be
> > > > unzipped
> > > > > to disk? My engine does this, using a single plugin archive file
> that
> > > > > doesn't have to be unzipped to disk. Also, I have made
dependencies
> > > > > automagic, in that a plugin doesn't need to specify the plugins it
> > > depends
> > > > > on. Based on extension points and extensions, as well as events
and
> > > > > listeners, it can figure out the plugin(s) that are dependent
> > > > automatically.
> > > > > I do this by simply resolving plugins after each plugin loads. My
> > goal,
> > > > > before I cam across Eclipse, was to build a reloadable
archtiecture
> > like
> > > > > what JBoss and other app servers have, using a simplified plugin
> > model,
> > > > > something I devised a few years back using C on a cross-platform
> > > project.
> > > > > Had I known Eclipse was going to become "headless" a while back, i
> > don't
> > > > > know that I would have ventured down this path. Now that I have, I
> am
> > > > > thankful because I have a vastly improved understanding of
> classpaths,
> > > > > classloaders, the jvm process of loading classes, class space and
> how
> > > > > classloaders can delegate to others to find classes so that only
one
> > > > > bytecode is loaded, etc. I admit to borrowing the extension point
> idea
> > > > from
> > > > > Eclipse, it's a great way of connecting plugins. My original
engine
> > > simply
> > > > > used "names" and "versions" to find plugins, so more or less the
> same
> > > > thing,
> > > > > just a little more dependent on specific plugin names that might
> > change
> > > > > across versions and break dependencies.
> > > > >
> > > > > Is there any idea how big the "engine" of eclipse is, with OSGi,
> it's
> > > > > extension point/extension framework, etc? I thought of doing an
OSGi
> > > > > implementation, but another goal is a very small framework. With
> > > > everything
> > > > > that my engine does, its only 44K in size including an xml pull
> parser
> > > > that
> > > > > parses the plugin.xml files and can write xml out that any plugin
> can
> > > use
> > > > as
> > > > > well. This includes the code for each plugin to have its own
loader,
> > be
> > > > > contained within a single archive file or on disk like how eclipse
> > > plugins
> > > > > reside, lazy creation of plugins as needed (like eclipse and
osgi),
> > > > > automagic resolution of dependencies for both extension points and
> > > > > extensions, and events/listeners, the ability to specify specific
> > types
> > > of
> > > > > plugins to be loaded based on Class types, and so on. It is a
> non-GUI
> > > > > engine, so it can be used for any purpose, but I am building a UI
> > > > Framework
> > > > > on top of it using Swing. Forgive me for saying so, but I dislike
> SWT
> > > and
> > > > I
> > > > > think the vast majority of java developers are not going to learn
> SWT
> > > > given
> > > > > that Swing is as good in many respects, better in some, and not as
> > good
> > > in
> > > > > others, but comes with every JRE/JDK deployed as opposed to having
> to
> > > ship
> > > > > swt.jar and platform specific libraries, as well as a new API to
> > learn.
> > > > > Therefore I didn't want to base my UI framework around SWT,
although
> > it
> > > > > could easily be done by simply replacing the core plugin and using
> SWT
> > > > > instead of Swing. The UI framework will provide a similar paradigm
> to
> > > > > Eclipse and other IDE's with a workspace, menu/toolbar, status
bar,
> > left
> > > > > side "task" bar, help facility, preference facility, wizard
> component,
> > > > file
> > > > > chooser component and so forth. All of this is open source as
well,
> > and
> > > > the
> > > > > goal is not to compete with any other IDE, it is to provide a very
> > > small,
> > > > > super easy to develop for, pluggable UI framework using Swing so
> that
> > > > > hopefully I can help bring those 10 million java engineers over
that
> > Sun
> > > > > claims will come! "If you build it they will come" comes ot mind.
;)
> I
> > > am
> > > > > trying to build it, hoping they'll come and use it!
> > > > >
> > > > > Anyway, I am glad to see Eclipse is finally going headless and
> > > > unload/reload
> > > > > of plugins will be possible! I started doing unload/reload a few
> > months
> > > > back
> > > > > before I read that OSGi would be integrated into 3.0. I was
> surprised
> > to
> > > > see
> > > > > that I had done a similar way of notifying plugins. That is, if a
> > plugin
> > > > > that provides an extension is reloaded, it notifes the plugin that
> > owns
> > > > the
> > > > > extension point that the extension is being removed, or added,
etc.
> > > > > Basically, all plugins affected get notified of events, such as
> > unload,
> > > > > destroy, extension removed/added, extension point removed/added,
> etc.
> > > > >
> > > > >
> > > > >
> > > > > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > > > > news:brtusv$q7$1@eclipse.org...
> > > > > > In the new runtime you can supply bundles or traditional
plugins.
> > The
> > > > only
> > > > > > real distinction is whether you supply a plugin.xml or a
> manifest.mf
> > > and
> > > > a
> > > > > > bit of packaging. Dynamic behaviour of the classloaders is taken
> > care
> > > of
> > > > > by
> > > > > > OSGi. The spec details everything you could want to know. For
> > > bundles
> > > > > > supplying extensions and extension points there is a new set of
> API
> > > > > relating
> > > > > > to extension registry changes. Look for
> > > > > > org.eclipse.core.runtime.ExtensionChangeListener and related
> types.
> > > > > >
> > > > > > There are sure to be some rough edges in the dynamic support as
it
> > is
> > > > both
> > > > > > hard and new. Try it out and let us know what you think and of
> > > course,
> > > > if
> > > > > > you find any bugs, please log a bug report. January will see us
> > > > spending
> > > > > > sigificant effort to make more of Eclipse dynamic aware/enabled
as
> > > well
> > > > as
> > > > > > put together some demo apps to show people how it is done.
> > > > > >
> > > > > > Note also that currently you cannot install bundles in jars as
per
> > > > normal
> > > > > > OSGi. They have to be in exploded dirs like plugins. This is a
> > > > temporary
> > > > > > limitation which will be resolved in January as well.
> > > > > >
> > > > > > Enjoy
> > > > > > Jeff
> > > > > >
> > > > > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > > > > news:brdocp$v0$1@eclipse.org...
> > > > > > > Alrighty, so I haven't checked yet, but how are plugins to be
> > > written?
> > > > > Do
> > > > > > we
> > > > > > > do the OSGi bundle method, or continue our normal Eclipse
> > extension
> > > > > model
> > > > > > > plugin? What I most want to know about is how we write plugins
> > > > correctly
> > > > > > so
> > > > > > > they can be unloaded and reloaded? IS there special events we
> > listen
> > > > > for?
> > > > > > I
> > > > > > > mean, if my plugin depends on plugin B, and B is being
reloaded
> or
> > > > > > unloaded,
> > > > > > > does my plugin get unloaded automatically (assuming B is
> > unloaded),
> > > or
> > > > > > does
> > > > > > > it get notified that B is no longer available, and somehow in
> code
> > I
> > > > > have
> > > > > > to
> > > > > > > adapt to that? This gets more complex. What if my plugin
> provides
> > > > > > > functionality that others depend on, but to provide that
> > > > functionality,
> > > > > my
> > > > > > > plugin depends on one or more plugins, and one or more of
those
> > get
> > > > > > > unloaded? Does the unloading go all the way across all chains
> > until
> > > no
> > > > > > > plugin that is dependent on the one (or more) being unloaded
is
> > > done?
> > > > > What
> > > > > > > about reloading? Two cases I see, it reloads a change that
does
> > not
> > > > > break
> > > > > > my
> > > > > > > plugin, or it reloads and breaks my plugins ability to use it,
> > > either
> > > > > via
> > > > > > a
> > > > > > > new version, a method removal that my plugin relies on, or
some
> > > other
> > > > > > > reason. How is this handled now?
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: How to write plugins with the new OSGi model [message #32504 is a reply to message #32364] |
Sun, 11 January 2004 07:04 |
Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Jeff,
I am finally making sense of all this. In my plugin engine I did things a
bit differently and it worked alright, but I found some issues. I was
automatically making any extension add a "dependency" to the extension point
it was registered to. I think Eclipse could still do this. I am not sure why
a <requires> is necessary. At load time, you look for the extension point
when parsing the extension plugin. If found, you already have a ref to its
classloader, so you can assign that ref directly to the extension plugins
classloader as a "quick" dependency loader lookup. At runtime, when the
extension code is resovled through the classloader, it will try to find the
interface it implements from the extension point plugin. It wont find it in
the cache or its classpath, so the next step is to find it in a dependent
plugin. In my engine, I have a List of dependent loaders that are searched.
As plugins are loaded, they are resolved. If an extension point is not yet
loaded, extensions are put in a "unresolved" list, and as each plugin is
loaded, this list is checked to see if any extensions can be resolved. In my
engine, this works well.
However, after what you and a few others said, some searching, some looking
in my code and also recent bugs with circularity errors and private field
access problems, I decided to revamp my engine a bit. I do not wish to
implement OSGi, nor copy near the complexity Eclipse has. My framework uses
a single classloader to do all the work, including the plugin archive file
for finding embeded classs, libraries, etc (something Eclipse doesn't do
yet, but you just mentioned in reply to Peter that it will be implemented
soon). What I do wish to do is provide a very simple, small, faster, and
very easy to develop for plugin engine that achieves "similar" results. I
have been working on this for years, but only the past year or so with
Eclipse, OSGi, and a few other engines, and some ideas/help from the forums,
have I come up with this. The notion of an extension point and extension is
ingenious. I borrow the same names simply because I can't think of a better
way of describing how to identify where two unknown runtime modules will
intersect each other to contribute functionality, to extend it. As such,
including embede xml pull parser, my engine is about 55K with debug info. It
supports what we have talked about a few times here, along with allowing
plugins to have different extension names (their file name that is), allow
an application to specify specific types of plugins allowed to load (so that
the "generic" plugin type is not allowed to be loaded, only subclasses of
it). It supports dynamic xml for extensions as well, only no dtd/xml schema
validation support, so extension points can't enforce the validity of xml
being parsed. My goal is a very small, fast, resource wary engine. I am also
working with the developer of Novaworx to build their UI around my engine to
provide a pretty slick pluggable UI framework. I still think the Eclipse RCP
will garner far more support and usage than anything we can muster up in the
next year or so, but I also believe competition is not only good, it also
helps others learn. With all that I have learned I would love nothing more
than help the Eclipse team in some manner. I have already said I would help
implement xml pull parsing for Eclipse, although frankly I gave it a shot
and had a hell of a time seeing anything work very well!! That was some time
ago. My project is also open-source, BSD license.
Anyway, I appreciate your replies. They have helped me understand some
things that I was not aware of.
Question for you. Eclipse "promotes" the notion of plugins providing a
static getInstance() method so that other plugins can get the instance, make
use of public methods, etc at runtime. How then will you handle dynamic
unload/reload if other plugins may make use of a class variable to keep a
reference to a plugin through that mechanism? I strongly discourage this
idea, and would rather plugin developers grab an instance in each method,
use it locally and have it discarded, or passed around from method to method
as needed. Is this something you guys will be changing in your docs,
discouraging this type of usage? Something else you mentioned to Peter, the
abiltiy for notification of the extension registry is something I have been
doing for some time to allow my engine to unload/reload plugins, although I
am still working on the unload code. Basically, every plugin implements the
generic PluginListener, gets events to activate, deactivate, and also when
extensions have been added/removed to any extension point they own. It is
not entirely done at this point and may still change, but I assume Eclipse
will do something similar. I did have a simple "ui" framework that would
allow extensions to contribute menu items that when clicked would trigger
the specified class in the plugin owner of the menu item. It was working
well enough that when aplugin was loaded after the app started, it's menu
item would show up properly. That was as far as I got when I came across
Novaworx.
"Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
news:btqb58$cnn$1@eclipse.org...
> The case you outline is in fact the one that is supported. Make it
> concrete. The UI has an extension point for views. view extensions must
> specify a class which implements IView (making up this example so don't
take
> it too literally). IView is defined in the UI plugin. You have a plugin
P
> which wants to supply a view. As such is has an extension that identifies
a
> class MyView which implements IView. For P to do this, it must "require"
> the UI.
>
> Note that the UI does not need ot know about P. When the UI wants to
> "createExectuableExtension", it is in effect telling the extension to
> instantiate itself. Since the extension knows which plugin it came from
> (i.e., P), it knows wihch classloader to use to load the defined class
> (e.g., MyView).
>
> Note also that in this case the plugin (P) defining the extension needed
to
> require the plugin (UI) since it needed ot reference a class. This is
only
> becuase it needed ot reference a class from UI. NOT because it defined an
> extension for one of UI's extension points. There are lots of extension
> points wihch do not require class specifications (doc, markers, ...).
>
> Jeff
>
> "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> news:btmnhm$2p8$1@eclipse.org...
> > I think I missed your point in my last reply, it makes sense now. You
are
> > correct in that a host extension point plugin doesn't care to see the
rest
> > of the classes of extension plugins, only the extension class itself.
> >
> > What I am not sure of though, is if a host plugin needs to pass an
> instance
> > of an object it creates so that each extension plugin can use it
> > (hypothetically speaking), each extension plugin needs to see the host
> > plugin as well, in order to see the definition of the class being passed
> to
> > it. I realize this is an odd situation, but you can't prevent developers
> > from doing this. So how is such handled? In this case, how does each
> > extension get to use the extension point classloader to find the class
> > definition being passed as an instance? Or is this not even possible?
> >
> >
> >
> > "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> > news:btf1ih$b5f$1@eclipse.org...
> > > The plugin hosting the extension point cannot require the ones
providing
> > the
> > > extensions since it does not know about them (a priori). At runtime
> when
> > a
> > > host goes to instantiate a contributed extension, it simply asks the
> > plugin
> > > providing the extension to load the specified class. This is
analogous
> to
> > > adding a dependency from the host to the contributor but the host only
> > wants
> > > to see the contributed class not all the classes that happen to be in
> the
> > > contributing plugin.
> > >
> > > Jeff
> > >
> > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > news:bs82vo$jjs$1@eclipse.org...
> > > > Hi Jeff,
> > > >
> > > > Sorry to post two back to back posts in regards to your reply, but
> > > something
> > > > you mentioned in your reply, after re-reading it, struck me with
> > interest.
> > > I
> > > > am hoping you don't mind answering a few questions.
> > > >
> > > > First, I have posted a few times in other groups with no success on
> > reply,
> > > > and in my previous reply indicated this question, how do
> plugins/bundles
> > > in
> > > > Eclipse/RCP handle resolution of event listeners to events? Is this
> done
> > > on
> > > > a per extension point basis, where by if an extension point, as part
> of
> > > its
> > > > schema, requires a class that represents a listener to an event the
> > > > extension point may fire, it is defined in the schema and every
> > extension
> > > is
> > > > required (or optional) and thus the extension point code, when
> executed,
> > > > then creates all extension plugins so that it can create instances
of
> > the
> > > > listener class and add them as listeners? Is there perhaps another
> > > mechanism
> > > > for doing this, or is it left up to each extension plugin to be
> > activated
> > > > and at that point programatically add it's listener to an event it
> > wishes
> > > to
> > > > listen for?
> > > >
> > > > In regards to what you wrote about how an extension to an extension
> > point
> > > > does not necessitate a dependency, I am confused? In order for the
> > > > classloader of an extension point to "see" a class within another
> > plugins
> > > > classloader that extends the extension point, doesn't the extension
> > point
> > > > plugin require a reference to the extensions classloader in order to
> > > > delegate the lookup of the extension class to find it? I am fairly
> > versed
> > > on
> > > > classloaders. My engine's PluginClassLoader keeps a List of
dependent
> > > loader
> > > > references for faster lookup of classes that may not be contained
> within
> > > its
> > > > own classpath. So you don't have to spend a lot of time looking at
how
> I
> > > > have done this, I'll tell you how here. Basically, there are a few
> > > scenarios
> > > > I can see where "dependencies" may occur. Any extension of an
> extension
> > > > point would require the extension point plugin to "depend" on the
> > > extension
> > > > plugins in that it needs to grab each extension plugin classloader
to
> > ask
> > > it
> > > > to find the extension class so the extension point can use it. Now,
> that
> > > > said, if the extension point defines an interface, as is usually the
> > case,
> > > I
> > > > may be wrong on this but generally you would NOT need to "see" each
> > > > extension classloader because the common interface would mean that
the
> > > > extension point code can call into the interface without specific
> > > > "visiblility" to each extension implementation of that interface...
or
> > am
> > > I
> > > > wrong on this and it is required to "see" every implementation of
the
> > > > extension point interface through each extension plugins
classloader?
> If
> > > it
> > > > IS required, then as I see it, the extension point plugin "depends"
on
> > > each
> > > > extension plugin. If this is the case, then if the extension point
> > plugin
> > > is
> > > > unloaded or reloaded, while not necessary my engine would send an
> event
> > to
> > > > every extension letting them at least know that the extension point
is
> > no
> > > > longer available. Some plugins may only extend this one point, and
> thus
> > > may
> > > > not need to stay resident as well if they only contribute to that
one
> > > > extension point, and thus should also be unloaded, or at least put
in
> in
> > > > "inactive" state. My engine would simply destroy them but not unload
> > them,
> > > > so that the GC may reclaim any resources they used. Basically, they
go
> > > into
> > > > a state as if they were loaded/parsed but never activated, so that
> > should
> > > > the plugin with the extension point get reloaded at some point, they
> can
> > > > once again be resolved against it and come to life if requested.
> > > >
> > > > Another scenario that I see is if the extension point interface
> provides
> > > for
> > > > a callback, where by a specific implementation the extension point
> > > provides
> > > > may be passed to each extension, and each extension can then make
> calls
> > > via
> > > > the interface callback, into the extension point. How to handle
this?
> > > >
> > > > Lastly, what if an extension point plugin is to provide an interface
> AND
> > > an
> > > > implementation of that interface so that extension plugins can
> directly
> > > use
> > > > the one implementation instead of the normal manner in which an
> > extension
> > > > point makes use of any one or all extension implementations of an
> > > interface
> > > > the extension point provides? In this case, each extension now
depends
> > on
> > > > the extension point, and each extensions classloader must "see" into
> the
> > > > extension point.
> > > >
> > > > In all these scenarios, my engine simply sets a ciruclar dependency,
> > that
> > > is
> > > > A's loader has B's loader as a dependency, and B's loader has A's
> loader
> > > as
> > > > a dependency. If you look at my code, there is something I do though
> (an
> > > > maybe it isn't all good, but it seems to work well). I ran into a
> > > > Circularity problem before where by if A looks in B's loader and
> happens
> > > to
> > > > look in B's ref to A's loader, it could loop forever (hence the
> > > Circularity
> > > > problem I had). So, to prevent this, I define a rule, in that a
> plugin's
> > > > loader can ONLY look within a dependent plugins classpath, not any
of
> > its
> > > > dependent loaders. This avoids A looking at B's dependent of A. The
> > > drawback
> > > > is that if A depends on B, B depends on C and C wraps ant.jar, A can
> not
> > > use
> > > > ant.jar, only B can. So A would have to extend C as well. One thing
I
> > did
> > > > add is a "shareable" parent loader, sort of like how JBoss has a
> single
> > > > repository it first checks. Any plugin can add a "shareable" URL to
a
> > > > library of their's so that ALL plugins can access it. There can be
> > > pros/cons
> > > > to this approach, but generally this is application specific, not
> plugin
> > > > defined. An application using the engine would perhaps specify
> specific
> > > > libraries it wishes that all plugins would use. Of course you can
run
> in
> > > to
> > > > version issues this way, as does occur with JBoss where you are
> limited
> > to
> > > > the "parent" version of a library regardless if each plugin has
their
> > own
> > > > version. But I see this as a small factor as this should be used on
an
> > > > application level anyway.
> > > >
> > > > So, having said all that, how does Eclipse allow extension points to
> not
> > > > depend on extensions via their classloader? Keep in mind, if you
look
> at
> > > my
> > > > code, I am not only shooting for small size, but optimum speed. If
any
> > > java.
> > > > or javax. class is asked to be loaded in the loadClass(), I simply
> > > delegate
> > > > it directly to the system loader. As well, if any of the plugin
> engine's
> > > > classes are asked, it goes directly to the parent loader. This is to
> > avoid
> > > > having to go through the list of lookup possibilities (the cache,
> > > shareable
> > > > loader, classpath, dependent loaders and finally the parent, if
> > > configured).
> > > >
> > > > Thanks for your time, I look forward to your thoughts.
> > > >
> > > >
> > > > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > > > news:bs0bsg$b6c$1@eclipse.org...
> > > > > Thanks for you continuing interest. You have mentioned your
engine
> > > > > previously but have never provided pointers to where someone can
> > > download
> > > > > and try it or get more information. What is its status?
> > > > >
> > > > > For you and others, I would like to clarify a few things:
> > > > >
> > > > > - OSGi bundles/classloaders/etc and the Eclipse extension
mechanism
> > are
> > > > > completely separated notions. The new runtime has both and users
> will
> > > > > benefit. OSGi brings dynamic behaviour, services, security etc
and
> > > > Eclipse
> > > > > retains the power of extensions etc. There is no loss of
> > functionality
> > > or
> > > > > generality in the new runtime, only gain.
> > > > >
> > > > > - plugin.xml and manifest.mf: neither are particularly easy for
> > > developers
> > > > > to manage without tooling support. Note that only the runtime
> related
> > > > > elements of plugin.xml (e.g., <runtime>, <requires>) have moved
into
> > the
> > > > > manifest.mf. The extension related tags retain their original form
> and
> > > > > position. As such, in most cases the manifest.mf is actually
> simpler
> > to
> > > > > define and maintain than the corresponding section of the
> plugin.xml.
> > > > >
> > > > > - OSGi implementations typically manage bundles as jars. I'm
pretty
> > > sure
> > > > > that the spec does not absolutely require this but it is implied.
> The
> > > > > bundles may contain internal jars for code (or other stuff) and
the
> > > > runtime
> > > > > is able to put these on the classpath. We have extended the model
to
> > > allow
> > > > > for running bundles out of directories (as per standard Eclipse).
> > > Eclipse
> > > > > 3.0 will likely ship with plugins in jars as opposed to
directories.
> > > > People
> > > > > have been asking for this for years and we likely would have done
it
> > > quite
> > > > > independent of OSGi uptake. Note however that there is no plan to
> > allow
> > > > for
> > > > > multiple bundles to be put in one jar. This would complicate
> > > > update/install
> > > > > scenarios and serve little purpose.
> > > > >
> > > > > - Eclipse has always been "headless". Since day one there have
been
> > > > > essential applications which run in this mode. For example, the
> > Eclipse
> > > > > build mechanism is a headless Eclipse configuration. Anyone can
> > define
> > > > > "applications" (using extensions of course) and then run them
using
> > > > > eclispe -application <app id>. It just happens that in Eclipse <=
> 2.1
> > > > there
> > > > > was a default application which opened a GUI.
> > > > >
> > > > > - Eclipse extensions/extension-points interactions do not
represent
> > > > > dependency specifications. You can contribute an extension to a
> > plugin
> > > on
> > > > > which you do not depend. As such, when a plugin hosting an
> extension
> > > > point
> > > > > is uninstalled or restarted, plugins providing extensions are not
> > > > > necessarily shutdown. We purposely kept the dependency mechanism
> out
> > of
> > > > > htis area to increase flexibility. Plugins which want/need to
have
> a
> > > > > tighter relationship are free to specify a classloader dependency
> via
> > > the
> > > > > <requires> tags.
> > > > >
> > > > > Jeff
> > > > >
> > > > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > > > news:brvge3$k9f$1@eclipse.org...
> > > > > > That's kewl. I have built my own plugin engine based around
> > extension
> > > > > > points, extensions, etc. I am not sure why the move to OSGi is
so
> > > > > paramount
> > > > > > compared to the well thought out extension point mechanism of
> > Eclipse.
> > > I
> > > > > > dislike the idea of using manifest.mf as opposed to plugin.xml.
> The
> > > xml
> > > > > > format is much nicer and easier. In my engine, plugins are
> > > > > > unloadable/reloadable (still working out the kinks as well), and
I
> > > > believe
> > > > > > like Eclipse developers have to be aware of referencing other
> > > dependent
> > > > > > plugin classes with class variables as opposed to using
temporary
> > > > > variables
> > > > > > within methods, otherwise the GC may never reclaim a plugin's
> > > resources.
> > > > > > Reloading is no problem, simply replace the repository of the
> plugin
> > > by
> > > > > its
> > > > > > name/version and all lookups/usages go to the newly loaded code.
> But
> > > the
> > > > > > most important part in my mind is the GC able to reclaim
unloaded
> or
> > > > > > previously loaded when reloaded plugins and resources. Still
can't
> > > > figure
> > > > > > out why the GC only runs when its out of memory, that is rather
> > stupid
> > > > in
> > > > > my
> > > > > > opinion, it should run every few minutes, verify any dead ends
and
> > > clean
> > > > > > them up!
> > > > > >
> > > > > > Does the use of OSGi bundles allow embeded jars/zips and such
such
> > > that
> > > > > you
> > > > > > can deploy a single .jar file with embeded .jar/.zip files and
it
> > > finds
> > > > > the
> > > > > > classes within the embeded jar/zip files without them having to
be
> > > > > unzipped
> > > > > > to disk? My engine does this, using a single plugin archive file
> > that
> > > > > > doesn't have to be unzipped to disk. Also, I have made
> dependencies
> > > > > > automagic, in that a plugin doesn't need to specify the plugins
it
> > > > depends
> > > > > > on. Based on extension points and extensions, as well as events
> and
> > > > > > listeners, it can figure out the plugin(s) that are dependent
> > > > > automatically.
> > > > > > I do this by simply resolving plugins after each plugin loads.
My
> > > goal,
> > > > > > before I cam across Eclipse, was to build a reloadable
> archtiecture
> > > like
> > > > > > what JBoss and other app servers have, using a simplified plugin
> > > model,
> > > > > > something I devised a few years back using C on a cross-platform
> > > > project.
> > > > > > Had I known Eclipse was going to become "headless" a while back,
i
> > > don't
> > > > > > know that I would have ventured down this path. Now that I have,
I
> > am
> > > > > > thankful because I have a vastly improved understanding of
> > classpaths,
> > > > > > classloaders, the jvm process of loading classes, class space
and
> > how
> > > > > > classloaders can delegate to others to find classes so that only
> one
> > > > > > bytecode is loaded, etc. I admit to borrowing the extension
point
> > idea
> > > > > from
> > > > > > Eclipse, it's a great way of connecting plugins. My original
> engine
> > > > simply
> > > > > > used "names" and "versions" to find plugins, so more or less the
> > same
> > > > > thing,
> > > > > > just a little more dependent on specific plugin names that might
> > > change
> > > > > > across versions and break dependencies.
> > > > > >
> > > > > > Is there any idea how big the "engine" of eclipse is, with OSGi,
> > it's
> > > > > > extension point/extension framework, etc? I thought of doing an
> OSGi
> > > > > > implementation, but another goal is a very small framework. With
> > > > > everything
> > > > > > that my engine does, its only 44K in size including an xml pull
> > parser
> > > > > that
> > > > > > parses the plugin.xml files and can write xml out that any
plugin
> > can
> > > > use
> > > > > as
> > > > > > well. This includes the code for each plugin to have its own
> loader,
> > > be
> > > > > > contained within a single archive file or on disk like how
eclipse
> > > > plugins
> > > > > > reside, lazy creation of plugins as needed (like eclipse and
> osgi),
> > > > > > automagic resolution of dependencies for both extension points
and
> > > > > > extensions, and events/listeners, the ability to specify
specific
> > > types
> > > > of
> > > > > > plugins to be loaded based on Class types, and so on. It is a
> > non-GUI
> > > > > > engine, so it can be used for any purpose, but I am building a
UI
> > > > > Framework
> > > > > > on top of it using Swing. Forgive me for saying so, but I
dislike
> > SWT
> > > > and
> > > > > I
> > > > > > think the vast majority of java developers are not going to
learn
> > SWT
> > > > > given
> > > > > > that Swing is as good in many respects, better in some, and not
as
> > > good
> > > > in
> > > > > > others, but comes with every JRE/JDK deployed as opposed to
having
> > to
> > > > ship
> > > > > > swt.jar and platform specific libraries, as well as a new API to
> > > learn.
> > > > > > Therefore I didn't want to base my UI framework around SWT,
> although
> > > it
> > > > > > could easily be done by simply replacing the core plugin and
using
> > SWT
> > > > > > instead of Swing. The UI framework will provide a similar
paradigm
> > to
> > > > > > Eclipse and other IDE's with a workspace, menu/toolbar, status
> bar,
> > > left
> > > > > > side "task" bar, help facility, preference facility, wizard
> > component,
> > > > > file
> > > > > > chooser component and so forth. All of this is open source as
> well,
> > > and
> > > > > the
> > > > > > goal is not to compete with any other IDE, it is to provide a
very
> > > > small,
> > > > > > super easy to develop for, pluggable UI framework using Swing so
> > that
> > > > > > hopefully I can help bring those 10 million java engineers over
> that
> > > Sun
> > > > > > claims will come! "If you build it they will come" comes ot
mind.
> ;)
> > I
> > > > am
> > > > > > trying to build it, hoping they'll come and use it!
> > > > > >
> > > > > > Anyway, I am glad to see Eclipse is finally going headless and
> > > > > unload/reload
> > > > > > of plugins will be possible! I started doing unload/reload a few
> > > months
> > > > > back
> > > > > > before I read that OSGi would be integrated into 3.0. I was
> > surprised
> > > to
> > > > > see
> > > > > > that I had done a similar way of notifying plugins. That is, if
a
> > > plugin
> > > > > > that provides an extension is reloaded, it notifes the plugin
that
> > > owns
> > > > > the
> > > > > > extension point that the extension is being removed, or added,
> etc.
> > > > > > Basically, all plugins affected get notified of events, such as
> > > unload,
> > > > > > destroy, extension removed/added, extension point removed/added,
> > etc.
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Jeff McAffer" <jeff_mcaffer@ca.ibm.com> wrote in message
> > > > > > news:brtusv$q7$1@eclipse.org...
> > > > > > > In the new runtime you can supply bundles or traditional
> plugins.
> > > The
> > > > > only
> > > > > > > real distinction is whether you supply a plugin.xml or a
> > manifest.mf
> > > > and
> > > > > a
> > > > > > > bit of packaging. Dynamic behaviour of the classloaders is
taken
> > > care
> > > > of
> > > > > > by
> > > > > > > OSGi. The spec details everything you could want to know.
For
> > > > bundles
> > > > > > > supplying extensions and extension points there is a new set
of
> > API
> > > > > > relating
> > > > > > > to extension registry changes. Look for
> > > > > > > org.eclipse.core.runtime.ExtensionChangeListener and related
> > types.
> > > > > > >
> > > > > > > There are sure to be some rough edges in the dynamic support
as
> it
> > > is
> > > > > both
> > > > > > > hard and new. Try it out and let us know what you think and
of
> > > > course,
> > > > > if
> > > > > > > you find any bugs, please log a bug report. January will see
us
> > > > > spending
> > > > > > > sigificant effort to make more of Eclipse dynamic
aware/enabled
> as
> > > > well
> > > > > as
> > > > > > > put together some demo apps to show people how it is done.
> > > > > > >
> > > > > > > Note also that currently you cannot install bundles in jars as
> per
> > > > > normal
> > > > > > > OSGi. They have to be in exploded dirs like plugins. This is
a
> > > > > temporary
> > > > > > > limitation which will be resolved in January as well.
> > > > > > >
> > > > > > > Enjoy
> > > > > > > Jeff
> > > > > > >
> > > > > > > "spiderman" <supreme_java_guru_1@yahoo.com> wrote in message
> > > > > > > news:brdocp$v0$1@eclipse.org...
> > > > > > > > Alrighty, so I haven't checked yet, but how are plugins to
be
> > > > written?
> > > > > > Do
> > > > > > > we
> > > > > > > > do the OSGi bundle method, or continue our normal Eclipse
> > > extension
> > > > > > model
> > > > > > > > plugin? What I most want to know about is how we write
plugins
> > > > > correctly
> > > > > > > so
> > > > > > > > they can be unloaded and reloaded? IS there special events
we
> > > listen
> > > > > > for?
> > > > > > > I
> > > > > > > > mean, if my plugin depends on plugin B, and B is being
> reloaded
> > or
> > > > > > > unloaded,
> > > > > > > > does my plugin get unloaded automatically (assuming B is
> > > unloaded),
> > > > or
> > > > > > > does
> > > > > > > > it get notified that B is no longer available, and somehow
in
> > code
> > > I
> > > > > > have
> > > > > > > to
> > > > > > > > adapt to that? This gets more complex. What if my plugin
> > provides
> > > > > > > > functionality that others depend on, but to provide that
> > > > > functionality,
> > > > > > my
> > > > > > > > plugin depends on one or more plugins, and one or more of
> those
> > > get
> > > > > > > > unloaded? Does the unloading go all the way across all
chains
> > > until
> > > > no
> > > > > > > > plugin that is dependent on the one (or more) being unloaded
> is
> > > > done?
> > > > > > What
> > > > > > > > about reloading? Two cases I see, it reloads a change that
> does
> > > not
> > > > > > break
> > > > > > > my
> > > > > > > > plugin, or it reloads and breaks my plugins ability to use
it,
> > > > either
> > > > > > via
> > > > > > > a
> > > > > > > > new version, a method removal that my plugin relies on, or
> some
> > > > other
> > > > > > > > reason. How is this handled now?
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 00:50:32 GMT 2024
Powered by FUDForum. Page generated in 0.04235 seconds |
] 
Search
Help
Register
Login
Home
