This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • How Tuscany starts components from a contribution
Skip to end of metadata
Go to start of metadata

How does Tuscany start components from a contribution?

Contributed by Giorgio Zoppi <giorgio.zoppi@gmail.com>

This document describes how a composite file (i.e.
MyComposite.composite) gets processed for a simple composite. When
the XML parser sees a composite element, create a composite, it checks
if it is autowired and if it has an item autowire, it sets the
composite to be autowired, then it checks if it's local and if it has
constrainting types. If the composite has constrainting types, they
are processed.
Then the parser reads, if they are present, the policies for the
composite. Suppose that in my simple example i have no constrain or
policy.
At a given point the parser sees an <component> item, in this case, the runtime:

  • It creates a RuntimeComponent by the RuntimeComponentFactory,
    sets its name, it looks if the component needs to be autowired,
    then it checks if it has constrainting types. If the composite has
    constrainting types, they are processed.
    Then the parser reads, if they are present, the policies for the component.
    At other point the runtime sees an extension point, which it could be
    a service, a binding, an implementation type and so on..In this
    document we suppose, that the runtime sees:

<implementation.java .....>

The runtime at this point gets the extension processor. The extension
processor has in input the component, and the reader from the XML
Parser. From the XML document, the extension processor recognize the
extension type and it gets the needed factory.
For example, inside the read method of JavaImplementationProcessor we have:

JavaImplementation javaImplementation = javaFactory.createJavaImplementation();
javaImplementation.setUnresolved(true);

From the CLASS attribute, the runtime understand the kind of interface.

        javaImplementation.setName(reader.getAttributeValue(null, CLASS));

Then it reads the policies:

        // Read policies
        policyProcessor.readPolicies(javaImplementation, reader);

        // Skip to end element
        while (reader.hasNext()) {
            if (reader.next() == END_ELEMENT &&
IMPLEMENTATION_JAVA_QNAME.equals(reader.getName())) {
                break;
            }
        }
        return javaImplementation;

At this point, the runtime adds the implementation to the component with:

   component.setImplementation(...)

and it adds the component to the composite.

Until now we're processing a MyComposite.composite like this:

<composite>
<component name="MyName">
<implementation.java class="package.MyClass"/>
</component>
</composite>

Suppose now to find a service(<service>) item, what happens?
The runtime:

  • creates a RuntimeComponentService
  • sets the Contract (service contract) to RuntimeComponentService
  • sets RuntimeComponentService's name
  • adds RuntimeComponentService instance to Component's Services.
  • it seeks for services policies.

Now a service has an interface (<interface>), and it could be a java
interface. At this point the runtime creates a
JavaInterfaceContractImpl by a JavaInterfaceFactory and sets it to the
service contract (call: contract.setInterfaceContract(...)).