On Wed, Sep 16, 2009 at 17:39, Wei Tan <[email protected]> wrote:
> 1. I compiled my plug-in which depends on a.b.c.Interface 0.7-SNAPSHOT.
> When workbench load it, the classloader of the plug-in
> (say urlclassloa...@1239812389) will load the 0.7-SNAPSHOT jar. The
> classloader of the workbench (say urlclassloa...@532143)
> has loaded 0.6 jar and therefore it knows that my plug-in does not
> implement the right interface in 0.6 jar.
Almost correct, except as it is now there is no actual plugin classloader, a
plugin is just a list of independent maven artifacts which are added to the
pool, with one classloader per artifact. If two plugins specify the same
artifact, there will only be one classloader.
The way Tom did this in the platform was one classloader per plugin, which
is much easier to keep track of for the plugin developer, but introduces
other issues, like what happens if a plugin wants to depend on another
plugin, or if a plugin comes with an API that a third plugin can connect
to..
Not sure exactly how this will be with OSGi world yet (Alan has had a deeped
look at this), but the good advantage there is that we would not be alone,
we would have thousands of other developers using the same framework - hence
the current plan is for after 2.1 to move the workbench directly to OSGi -
but picking up things we learnt from the platform work and integrating the
two code bases.
> 2. I compiled my plug-in which depends on a.b.c.Interface 0.6. When
> workbench load this plug-in, since 0.6 jar is already loaded
> by the classloader of the workbench (urlclassloa...@532143) so that the
> plug-in classloader (say urlclassloa...@1239812389 )
> will see and use it. This means that the plug-in classloader will NOT
> load the 0.6 jar again (correct?) but use the 0.6 jar which is already
> loaded (by another classloader).
Correct, as it stands there's only one classloader per artifact, and it will
be reused when possible.
> In this case the workbench knows that the plug-in implements the right
> interface (a.b.c.Interface in urlclassloa...@532143).
Exactly, so you get that advantage when talking about an interface or
superclass. But the downside is that if your plugin is just using some
library, and if it did some messing about with static methods/fields, say
setting some global Axis configuration, the effect would be like in
'classical' Java, that such changes would affect the whole system - or at
least everyone using that version of that library.
> My understanding is from your words saying that " that a classloader
> would also be able to see classes from those classloaders". Suppose
> there is a pom
> tree like this p1-->p2 (i.e., p1 depends on p2). If both p1 and p2
> depends on p3, and the classloader of p1 already loaded the artifact
> defined by p3, then
> p2 will NOT load p3 again but just use the one that is loaded by p1?
> In my case, p1 is the workbench (or some artifacts in the workbench that
> depends on the 0.6 jar), p2 is my plug-in, and p3 is the 0.6 jar.
> Is that correct? :-)
Yes, you would get a classloader tree out of it:
p1 --> p2 ---> p3 \ ^
\______________|
As long as these trees are 'consistent' (ie. don't have the same class name
twice) everything should work be fine.
In addition we have the SPI registries. They work by having interfaces that
plugins and components can implement, and they list their implementation
classname in a resource file
META-INF/services/net.sf.taverna.t2.blah.TheInterface
The way the SPI registries work is that some user of the interface, say the
menu manager, makes an SPI registry for a specific interface. The registry
will then scan through ALL loaded artifacts (ie. from all plugins), and from
each of those classloaders look up that resource file (depending on which
interface the registry is over). It will then attempt to load the listed
classes from that classloader, and the collected list of classes found in
all of these are available to whoever made the registry. If the registry is
an instance registry, for each class a single instance will be made in the
registry, if it is a class registry, only the classes are listed. (Most of
our registries are instance registries)
Typically these registries are singletons so they can be accessed from
several places.
And this is how we find menues, available services, file formats,
perspectives, individual components within the perspectives, contextual
views, etc. - making all of these extensible by plugins.
The main danger here is as we said about the interfaces themselves, Raven
does not know that an artifact 'contains interfaces' and treats them just
like any other class, meaning that if an artifact lists an SPI
implementation of a certain interface, that class will be attempted loaded
for such an SPI registry. Our current registries don't understand these
versions, and so get very confused when an instance comes along that
implements the 'wrong' interface. If you are unlucky you could actually
end up with a full parallel world of two workbench APIs mixed together, only
differing by their Maven version number - but with only one of them shown on
screen - and the developer scratching his head over why his plugin is not
showing up...
> I wonder if there should be a top pom for each Taverna release and it
> defines all the properties that every plug-in should use.
That was the 'top' POM, but it's not on the top Maven-like, because that
would mean that for every time we change anything we would have to change
the version of the parent, and then the version of his parent again, and
then all the children of those parents and so on, rippling through, meaning
that everything would always have to change for any tiny update.
--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
taverna-hackers mailing list
[email protected]
Web site: http://www.taverna.org.uk
Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/
Developers Guide: http://www.mygrid.org.uk/tools/developer-information
