SMILA/Development Guidelines/Tuscany Integration

Outdated. No integration planned, any more.

This page lists the current state of the Tuscany integration in SMILA and SMILA related issues in Tuscany.

Tuscany OSGi bundles

Tuscany is making good process in creating separate bundles. 3rd party jars are also available as separate bundles now. There are still some classloading issues regarding Dynamic-Imports, Meta-INF/services and OSGi runtime extensions. Here is an overview (either in text or visualized format) of the Tuscany bundle dependencies. For a minimal integration I did a step-by-step analysis of the bundles needed to create a SCADomain and a Contribution that uses implementationtype.osgi and binding.sca within an Equinox OSGi runtime. Below you will find lists of required bundles for certain functionality. These lists will be updated as needed.

Basic set of bundles

required Tuscany jars

• org.apache.tuscany.sca.api_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.assembly.xml_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.assembly_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.contribution.impl_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.contribution.java_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.contribution.namespace_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.contribution.xml_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.contribution_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.core.spi_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.core_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.definitions_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.extensibility.osgi_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.extensibility_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.host.embedded_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.implementation.node_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.interface.java_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.interface_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.monitor_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.node.api_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.node.impl_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.osgi.runtime_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.policy_1.4.0.SNAPSHOT.jar
• tuscany-extensibility-equinox-1.4-SNAPSHOT.jar (this is currently not included in the osgi build and has to be build manually)

required 3rd party jars

• org.apache.tuscany.sca.3rdparty.net.sf.cglib_2.0.0.1_3.jar
• org.apache.tuscany.sca.3rdparty.org.apache.geronimo.specs.geronimo-commonj_1.1_spec_1.0.0.jar
• org.apache.tuscany.sca.3rdparty.org.codehaus.woodstox.wstx-asl_3.2.1.jar
• org.apache.tuscany.sca.3rdparty.org.apache.ws.commons.schema.XmlSchema_1.3.2.jar
• org.apache.tuscany.sca.3rdparty.wsdl4j_1.6.2.jar
• org.apache.tuscany.sca.3rdparty.javax.jws.jsr181-api_1.0.0.MR1.jar
• org.apache.tuscany.sca.3rdparty.org.objectweb.asm.all_3.1.0.jar
• org.apache.tuscany.sca.3rdparty.javax.xml.ws.jaxws-api_2.1.0.jar (Attention: org.apache.tomcat_6.0.16 exports this package, but only with 2 classes !!!)

required 3rd party jars already included in SMILA

• org.apache.tuscany.sca.3rdparty.javax.xml.stream.stax-api_1.0.2.jar -> javax.xml.stream_1.0
• org.apache.tuscany.sca.3rdparty.javax.xml.bind.jaxb-api_2.1.0.jar -> javax.xml.bind_1.0
• org.apache.tuscany.sca.3rdparty.javax.activation_1.1.0.jar -> javax.activation_1.1.0

binding.rmi

These bundles are needed to use binding.rmi:

• org.apache.tuscany.sca.binding.rmi_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.host.rmi_1.4.0.SNAPSHOT.jar
• org.apache.tuscany.sca.extension.helper_1.4.0.SNAPSHOT.jar

binding.ws

These bundles are needed to use binding.ws: t.b.d

Adjustments to Tuscany

The following adjustments where made to Tuscany bundles:

• adapted manifest in org.apache.tuscany.sca.3rdparty.org.codehaus.woodstox.wstx-asl_3.2.1.jar: add Eclipse-RegisterBuddy: javax.xml.stream to allow classloader to find STAX implementation
• added Ivans Fix to org.apache.tuscany.sca.databinding.jaxb.JAXBDataBinding (TUSCANY-2346), this is not included in current Tuscany code
• I provided a contribution for TUSCANY-2281 that solves the problem

Adjustments to SMILA

The following adjustments where made to SMILA classes/configurations:

• enabled @AllowsPassByReference on org.eclipse.eilf.connectivity.framework.crawler.filesystem.FileSystemCrawler
• use classes="..." in <t:implementation.osgi> of .composite file to allow parsing of Annotations
  • as for Crawlers annotations are included in the implementation class and in the abstract base class AbstractCrawler it is important to add both classes to this list
• Annotations are not processed on implementation.osgi, because the method processAnnotations(boolean doWait) of class OSGiImplementationProvider is never called. For testing purpose I just called it in the start() method of the same class. With this fix the annotation are processed successfully.
• adopted method getCrawler(final String crawlerId) of class CrawlerControllerImpl to make use of the fix provided for TUSCANY-2281

Tuscany open issues

This is a list of JIIRA issues in Tuscany that are required by SMILA and should be adressed:

• TUSCANY-2270 - Conversations do not to work with binding.rmi
• TUSCANY-2281 - How to create ServiceReferences for references using multiplicity="1..n"
• TUSCANY-2343 - OSGi bundle design leads to class loading issues Unassigned Georg Schmidt
• TUSCANY-2346 - weaks in databinding-jaxb plug-in
• TUSCANY-2605 - Annotations are not processed for implementation.osgi

SMILA open issues

• (solved) because of TUSCANY-2281 it is not possible to use more than one CrawlerComponent (e.g. Filesystem and Web). It is however possible to crawl multiple datasources on the same CrawlerComponent in parallel
• as long as SMILA is run inside of eclipse IDE everything works fine. I build an application and tried to run SMILA outside of eclipse IDE. I did not manage to get it to run and start a SCADomain.
• In general Component references are initialized on the first method call on a Component. Usually this is done on the SCA service reference. Our JMX management wrappers do not use a SCA service reference but a reference to the underlying DeclarativeService (see in org.eclipse.eilf.management.crawlercontroller.Activator). So SCAServices need to be created "somewhere" so that the references are initialized. Otherwise the underlying DeclarativeService has no references set. This can be achieved by using the Annotation @EagerInit on class CrawlerControllerImpl. This forces reference initialization at initialization time (and not at the first method call). This works with binding.sca. I don't know if this setup also works with binding.rmi. I guess it will fail, as no local DeclarativeService is available. I think we will always have to look up SCAService instead of DeclarativeService references. I will test this when I have finished the list of required bundles for binding.rmi.