Page History

 Tuscany

h3. {anchor:component} {bgcolor:#C3CDA1}How to add a new component implementation? {bgcolor}

[Musings on Adding a New Implementation Type by Mike E|Mike Edwards Ramble through Adding a New Implementation Type] 

h3. {anchor:binding} {bgcolor:#C3CDA1}How to add a new binding? {bgcolor}


h3. {anchor:interface} {bgcolor:#C3CDA1}How to add a new interface binding? {bgcolor}


h3. {anchor:databinding} {bgcolor:#C3CDA1}How to add a new databinding? {bgcolor}


h3. {anchor:monitor} {bgcolor:#C3CDA1}How to add a new monitor extension? {bgcolor}

h4. Need for Monitor Extension
The need for monitor extension came as a requirement, to have a customized exception handling on Tuscany runtime especially when the user input errors are determined while reading, resolving and building phase of the contribution within the Tuscany runtime. Here different users/vendors using Tuscany with their products wanted to ignore some of the user input errors and allow the runtime to proceed further, while the others wanted to stop processing when a error is determined at the end of each phase. Another important need for a monitor extension is to validate the user inputs (via contributions) and report all the issues identified in one go (Example: As how the java compiler does for java code).

h4. Understanding message conversion using monitor
1) Errors and warnings are logged with the monitor as problems and the processing continues. Exceptions won't be thrown, where ever possible. Processing here covers any processing of user input, i.e. contributions and the artifacts they contain.
2) After each phase namely read, resolve and build contribution, the problems are read from the monitor for display to the user (currently this will have already happened as our current monitor will just log errors and warnings as it receives them but you can imagine more capable monitors).
3) The controlling logic may look at the errors and warnings it is reporting to the user and prevent further processing occurring. Or it may allow processing to continue. This  depends on which bit of processing we are talking about and what errors have been reported. Sample for the controlling logic is shown below
{code}
private void analyseProblems() throws Exception {        
    for (Problem problem : monitor.getProblems()){
        // look for any reported errors. Schema errors are filtered
        // out as there are several that are generally reported at the
        // moment and we don't want to stop 
        if ((problem.getSeverity() == Severity.ERROR) && (!problem.getMessageId().equals("SchemaError"))) {
            if (problem.getCause() != null){
                throw new Exception(problem.getCause());
            } else {
                throw new Exception(problem.toString());
            }    
        }
    }
}
{code} 

h4. Creating a new monitor extension
NOTE: Please have a look at the interface design of Monitor, Problem and MonitorFactory from monitor module in the Tuscany source code.

Step 1) Create a class MyMonitorImpl.java which implements the Monitor interface.
{code}

public class MyMonitorImpl implements Monitor {
    private static final Logger logger = Logger.getLogger(DefaultMonitorImpl.class.getName());    
    // Cache all the problem reported to monitor for further analysis
    private List<Problem> problemCache = new ArrayList<Problem>();
    public void problem(Problem problem) {
        // Your custom code to handle the problem
    }
    // Returns a list of reported problems.
    public List<Problem> getProblems(){
        return problemCache;
    }
}
{code}

 

h4. Initialize and create an instance of the monitor
Monitors can be initialized using the utility extensions as shown below.
{code}
UtilityExtensionPoint utilities = extensionPoints.getExtensionPoint(UtilityExtensionPoint.class);
MonitorFactory monitorFactory = utilities.getUtility(MonitorFactory.class);
monitor = monitorFactory.createMonitor();
{code}


h3. {anchor:general guide} {bgcolor:#C3CDA1}General guide for developing extensions {bgcolor}

* Familiarize yourself with SCA 1.0 Assembly and the SCA Java 1.0 programming model. Specifications can be found at 

h3. {anchor:details} {bgcolor:#C3CDA1}Detail on extension architecture {bgcolor}


h4. The ExtensionPointRegistry

{code}
package org.apache.tuscany.sca.core;


/**
* The registry for the Tuscany core extension points. As the point of contact
* for all extension artifacts this registry allows loaded extensions to find
* all other parts of the system and register themselves appropriately.
*
* @version $Rev: 539355 $ $Date: 2007-05-18 03:05:14 -0700 (Fri, 18 May 2007) $
*/
public interface ExtensionPointRegistry {

/**
* Add an extension point to the registry
* @param extensionPoint The instance of the extension point
*/
void addExtensionPoint(Object extensionPoint);

/**
* Get the extension point by the interface
* @param extensionPointType The lookup key (extension point interface)
* @return The instance of the extension point
*/
<T> T getExtensionPoint(Class<T> extensionPointType);

/**
* Remove an extension point
* @param extensionPoint The extension point to remove
*/
void removeExtensionPoint(Object extensionPoint);
}

package{code}

h4. The ModuleActivator

{code}
package org.apache.tuscany.sca.core;


/**
* ModuleActivator represents a module that plugs into the Tuscany system. Each
* module should provide an implementation of this interface and register the
* ModuleActivator implementation class by defining a file named
*
* "META-INF/services/org.apache.tuscany.core.ModuleActivator"
*
* The content of the file is the class name of the ModuleActivator 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. Note that the start and stop methods defined by this interface
* take a reference to the Tuscany SCA runtime ExtensionPointRegistry. This
* gives the ModuleActivator the oppotunity to add extension points to the
* registry as it is requested to start up and remove them when it is requested
* to shut down.
*
* @version $Rev: 564429 $ $Date: 2007-08-09 16:49:11 -0700 (Thu, 09 Aug 2007) $
*/
public interface ModuleActivator {

/**
* This method is invoked when the module is started by the Tuscany system.
* It can be used by this module to registr extensions against extension
* points.
*
* @param registry The extension point registry
*/
void start(ExtensionPointRegistry registry);

/**
* This method is invoked when the module is stopped by the Tuscany system.
* It can be used by this module to unregister extensions against the
* extension points.
*
* @param registry The extension point registry
*/
void stop(ExtensionPointRegistry registry);
}
{code}