Re: [Taverna-hackers] SPIRegistry and SpiRegistry

[Stian Soiland-R. <soi...@cs...>]

On Thu, Nov 27, 2008 at 13:17, Alan Williams <al...@cs...> wrote:
> There are currently two classes:
>
> 1) net.sf.taverna.raven.spi.SpiRegistry
>
> This is a registry of the classes that implement the SPI.
>
> 2) net.sf.taverna.t2.spi.SPIRegistry
>
> This is an instance registry i.e. it is based on the assumption that for
> each class implementing the SPI there will only be one instance.  It
> allows you to get the instances.
>
> Having two classes with such similar names is confusing.  I noticed it
> because I'm looking at

t2.spi.SPIRegistry was initially a clean reimplementation of
raven.spi.SpiRegistry that didn't depend on Raven and which could act
both as a class registry and instance registry. It also initially had
additional checks such as avoiding duplicate entries, had various unit
tests for

As the t2 workbench developed the class registry was never used, and
those methods got removed.

When fully integrating the Taverna 2 workbench with Raven it was
changed to just proxy down to a Raven InstanceRegistry backed by a
Raven SpiRegistry.

Thus the confusion on names.

The class still has a tiny advantage over the Raven InstanceRegistry
in that it autodiscovers the Raven registry. You might remember that
Taverna 1 code required a system property of raven.eclipse=true to
function outside Raven. SPIRegistry hides this so unit tests etc.
still works.

All of these should become obsolete against Tom's new plugin framework
and t2 infrastructure platform. Many of the registries in te Taverna 2
workbenc should also not be needed as they are really just used to
discover a single implementation (which can be injected as a Spring
bean), not a list of extension points such Activities, Perspectives,
etc.


> net.sf.taverna.t2.annotation.spi.AnnotationBeanRegistry extends
> SPIRegistry<AnnotationBeanSPI>
>
> and it seemed wrong that it is assumed that there is (supposed to be)
> only one instance of
> net.sf.taverna.t2.annotation.annotationbeans.HostInstitution - that
> being one of the classes that implements AnnotationBeanSPI.

Yeah, that sounds wrong.. if you want to use the current SPIRegistry
(an instance registry) for this you would need to let it be an SPI
registry over factories instead the actual beans. The advantage of
this is that factories have an interface you can use for creating the
instances and that can provide general info (typical getIcon() etc),
while if you have a SpiRegistry (class only) you would need to use
reflection to call the constructor. It's not possible in Java to put
an interface to describe a class' constructor, so you would have to
rely on good faith that your call would work.

The disadvantage of the factory solution is that you always have to
create implement bot a bean and a factory class. If you have many
beans this becomes quite silly. If you go for the class registry
solution instead, you can always hide the reflection constructor call
behind a method in the registry.


> P.S. I think all the registries in net.sf.taverna.t2.annotation.spi
> extend the wrong SPI registry.

Looks like it.. what we could do as a workaround until we get Tom's
stuff integrated is to bring back the getClasses() method in
SPIRegistry, and have a constructor argument to disable the instance
registry.



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester