Raymond,
I think this is good and simple to understand, but have some further
comments inline :)
Raymond Feng wrote:
Hi,
As the core moves away from using SCA composite to compose the Tuscany
system, we have been working on a simple way to extend the Tuscany
system.
1) Define an ExtensionPointRegistry [1]
public interface ExtensionPointRegistry {
<T> void addExtensionPoint(Class<T> extensionPointType, T
extensionPoint);
<T> T getExtensionPoint(Class<T> extensionPointType);
void removeExtensionPoint(Class extensionPoint);
}
The extension point is identified by the interface. It can be defined
by the Tuscany system or runtime modules. For example,
BuilderRegistry, IntrospectionRegistry are two extension points.
I would suggest to rename these BuilderExtensionPoint and
IntrospectionExtensionPoint. Also it would be good adopt a consistent
pattern for these ExtensionPoints. I already started with some of these
which now have addExtension / removeExtension methods.
2) The pluggability is contracted by the following interface: [2]
public interface ModuleActivator {
Map<Class, Object> getExtensionPoints();
void start(ExtensionPointRegistry registry);
void stop(ExtensionPointRegistry registry);
}
Do we really need a Map? or can this just be an array?
The ModuleActivator represents a module that plugs into the Tuscany
system. Each module should provide an implementation [3] of this
interface and registry the implementation class by defining a file
named as
"META-INF/services/org.apache.tuscany.spi.bootstrp.ModuleActivator"
[4]. The content of the file is the class name of the implementation.
The implementation class must have a no-arg constructor. The same
instance will be used to invoke all the methods during different
phases of the module activation.
Can we rename this package to org.apache.tuscany.bootstrap. I think that
we are currently using *.spi.* inconsistently, for example
ModuleActivator is in an *.spi.* package, but BuilderRegistry is not,
and both are SPIs, and finally all model interfaces are part of the SPIs
too. Since pretty much all these interfaces are SPIs anyway, could we
just remove the *.spi.* fragment?
During bootstraping, the following sequence will happen:
1) All the module activators will be discovered by the presence of
META-INF/services/org.apache.tuscany.spi.bootstrp.ModuleActivator
2) The activator class is instantiated using the no-arg constructor.
3) ModuleActivator.getExtensionPoints() is invoked for all modules and
the extension points contributed by each module are added to the
ExtensionRegistry.
4) ModuleActivator.start(ExtensionRegistry) is invoked for all the
modules. The module can then get interested extension points and
contribute extensions to them. The contract bwteen the extension and
extension point is private to the extension point. The extension point
can follow similar patterns such as Registry. If it happens that one
extension point has a dependency on another extension point, they can
linked at this phase.
During shutting down, the stop() method is invoked for all the modules
to perform cleanups. A module can choose to unregister the extension
from the extension points.
Feedbacks are welcome.
Thanks,
Raymond
[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/spi/bootstrap/ExtensionPointRegistry.java
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/spi/bootstrap/ModuleActivator.java
[3]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/test/java/org/apache/tuscany/container/crud/CRUDModuleActivator.java
[4]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/test/resources/META-INF/services/org.apache.tuscany.spi.bootstrap.ModuleActivator
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
