Tuscany SCA Java - FAQ (TUSCANY) edited by Simon Laws
Page:
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+Java+-+FAQ
Changes:
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=35040&originalVersion=18&revisedVersion=19
Content:
---------------------------------------------------------------------
{section:border=true}
{column:width=15%}
{include: SCA Java Subproject Menu}
{column}
{column:width=85%}
Welcome to the Apache Tuscany Java SCA FAQ page. Please help to keep the
information on this page current.
\\
{panel:title=Apache Tuscany SCA Frequently Asked
Questions|borderStyle=solid|borderColor=#C3CDA1|titleBGColor=#C3CDA1|bgColor=#ECF4D1}
* [Build Questions|#Build Questions]
** [What version of Java do I need? |#BuildA]
** [What version of Maven do I need? |#BuildB]
** [Why does the Tuscany code I checked out of Subversion not build? |#BuildC]
** [Java Heap Error during compilation|#BuildD]
* [Implementation Java Questions|#Implementation JavaQuestions]
** [What is the format for specifying multiple interfaces with the @Service
annotation? |#ImplementationJavaA]
* [Binding Questions|#Binding Questions]
** [Can I use the EJB binding to publish an SCA services as an SLSB?
|#BindingA]
* [DataBinding Questions|#DataBinding Questions]
** [What is the difference between Logical Type and Physical
Type?|#DataBindingA]
* [Contribution Questions|#Contribution Questions]
** [What is META-INF/sca-contribution.xml for?|#ContributionA]
** [What is What is META-INF/sca-deployables/ for?|#ContributionB]
\\
{panel}
h2. {anchor:Build Questions}{bgcolor:#C3CDA1}Build Questions{bgcolor}
h3. {anchor:BuildA}{bgcolor:#C3CDA1}What version of Java do I need? {bgcolor}
Both IBM and Sun JDK 1.5 are known to work and are used regularly by our
development community.
JDK1.4 will not work as the Tuscany SCA code base relies on some of the
features of JDK1.5 such as generics and annotations.
JDK1.6 has proven problematic due to some issues with bundled XML stream
parsing support that clashes with the support that Tuscany gets from elsewhere.
This issue is under investigation. If you are getting errors starting with the
following stack trace this is likely to be because you are using JDK 1.6
javax.xml.stream.FactoryConfigurationError: Provider
javax.xml.stream.XMLInputFactory could not be
instantiated: java.lang.InstantiationException
at
javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158)
h3. {anchor:BuildB}{bgcolor:#C3CDA1}What version of Maven do I need? {bgcolor}
To build the Apache Tuscany source code that you have checked out of subversion
you need to install Maven. The build is know to work relatively reliably with
Maven 2.0.5. People have had it working with later versions but it you are
encountering unpredicatbility in the build then give 2.0.5 a go.
h3. {anchor:BuildC}{bgcolor:#C3CDA1}Why does the Tuscany code I checked out of
Subversion not build? {bgcolor}
If you are taking code out of the trunk of the Tuscany Subversion repository
then you may have been unlucky and picked up a revision of the code where the
build is broken. As trunk is where the development takes place this happens now
and again although the development community tries to avoid build breaks if at
all possible and tries to fix them quickly when they do happen.
There are may and various other things that can cause your build to break. Its
worth checking on the mail list that the trunk is building. Assuming that it is
we will usually ask you to do the following as a basic level set.
Stop any ide you may have running
Check out the latest trunk revision
cd mytuscanydir
svn checkout https://svn.apache.org/repos/asf/incubator/tuscany/java/
or (if you already have a version of the code)
svn update https://svn.apache.org/repos/asf/incubator/tuscany/java/
Clean all the maven projects
cd mytuscanydir/sca
mvn clean
Remove all the sca artifacts from the local maven repository by removing (or
renaming) all of the directories under
.m2\repository\org\apache\tuscany\sca
Rebuild sca
cd mytuscanydir/sca
mvn
If it still doesn't work then get back on the mail list
h3. {anchor:BuildD}{bgcolor:#C3CDA1}Java Heap error during compilation {bgcolor}
I always get a "Java heap space" error during the build while the itests are
running these days. Runs fine if i build from within the itests folder but
building from the top sca folder always fails.
try "MAVEN_OPTS="-Xmx1024m -Xms512m" or You can also increase the memory
options in the sca pom, in the
surefire plugin configuration section.
[1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/pom.xml
h2. {anchor:Implementation JavaQuestions}{bgcolor:#C3CDA1}Implementation Java
Questions{bgcolor}
h3. {anchor:ImplementationJavaA}{bgcolor:#C3CDA1}What is the format for
specifying multiple interfaces with the @Service annotation?{bgcolor}
{code}
@Service(interfaces={Interface1.class, Interface2.class, Interface3.class} )
public class ServiceImpl implements Interface1, Interface2, Interface3{
...
}
{code}
h2. {anchor:Binding Questions}{bgcolor:#C3CDA1}Binding Questions{bgcolor}
h3. {anchor:BindingA}{bgcolor:#C3CDA1}Can I use the EJB binding to publish an
SCA services as an SLSB?
{bgcolor}
Unfortunately, we only have the reference binding support for SLSB (call
SLSB from SCA) in Tuscany at this moment. Any contribution to support SLSB
service binding is welcome. :-)
h2. {anchor:DataBinding Questions}{bgcolor:#C3CDA1}DataBinding
Questions{bgcolor}
h3. {anchor:DataBindingA}{bgcolor:#C3CDA1}What is he difference between Logical
Type and Physical Type? {bgcolor}
The logical type represents the data type the user thinks is flowing
across a wire. This could be a Java type, a XML type, a CORBA type, whatever
depending on the /logical/ service contract defined in the assembly.
The physical type is the actual representation of that type that is flowed
by the runtime. In the Java runtime this will always be a Java type (i.e. some
subclass of Object). In some cases it will be the same as the logical type -
e.g. when a Java component calls another Java component over a local wire using
a Java interface then both logical and physical types will be the same. In many
cases though they will be different - for example, if the service contract was
WSDL then the logical type would be the XML type used by the WSDL.
Within the runtime the same logical type may have different physical
forms. For example, the same XML document could be represented physically as a
DOM, a StAX stream, an SDO, a JAXB object, or an AXIOM stream. The framework
supports conversion between these different physical forms. {quote}
# *What is the role of a data mediator interceptor? Can you cite an example of
how mediation works say for a component A with reference R that references a
service S in component B.?*
The interceptor gets added by the connector. A's outbound wire and B's
inbound wire describe the datatypes their implementations can support. When the
wire ends are connected the connector adds the interceptor if mediation is
needed.
One job of a transport binding is to convert an in-memory physical
representation to a suitable set of bits on the network (aka serialization and
deserialization). Rather than reinvent the different transports we reuse
existing implementations such as Axis2 or RMI. As such we need to convert the
physical representation on our internal wire with that used by the transport.
So, for example, Axis2 only understands AXIOM so in a reference we need to
convert the user's physical representation to AXIOM and in a service we need to
convert the AXIOM generated by the transport into the form the user's
implementation requires. The steps could be described as follows:
## A calls reference R with physical Java object X(java)
## X is placed on R's outbound wire
## data mediation converts X(java) to AXIOM object X(axiom)
## X(axiom) is placed on inbound wire for the Axis2 binding
## Axis2 binding serializes X(axiom) onto the network as XML
## Axis2 binding on the target deserializes the XML from the network to X(axiom)
## X(axiom) is placed on the outbound wire from the Axis2 binding
## data mediation converts X(axiom) to X(java) as needed by the target component
## X(java) is placed on B's inbound wire
## the target instance for B is invoked passing in X(java)
. An important thing to note here is that from the fabric's perspective we are
dealing with two physical wires: the wire on the client connecting the source
component A to the outbound Axis2 transport and the wire on the server
connecting the inbound Axis2 transport to the target component B.
>From a global perspective there is one logical wire from A to B but because A
>and B are located on two different runtimes that logical wire gets split into
>two physical wires A->net and net->B.
h2. {anchor:Contribution Questions}{bgcolor:#C3CDA1}Contribution
Questions{bgcolor}
h3. {anchor:ContributionA}{bgcolor:#C3CDA1}What is
META-INF/sca-contribution.xml for?{bgcolor}
The [SCA Assembly Model Specification
V1.00|http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications]
describes this file in section 1.10.2.3. Any composites that are named in the
sca-contribution.xml file will be automatically be included in the deployable
list maintained by the contribution.
If you have a contribution in a directory say.
/my/contribution/dir
Then all composites, along with any other resources, under this directory will
be located by the contribution service. For example, assume we have
/my/contribution/dir/META-INF/sca-contribution.xml
/my/contribution/dir/mycomposite.composite
Where sca-contribution.xml is
<contribution xmlns="http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://mycomposite";
xmlns:management="http://mycomposite";>
<deployable composite="mycomposite:MyComposite"/>
</contribution>
So in this case the contribution service will locate the file
mycomposite.composite and, assuming it contains a composite called
mycomposite:MyComposite, will present it as being deployable based on the
information in sca-contribution.xml.
h3. {anchor:ContributionB}{bgcolor:#C3CDA1}What is META-INF/sca-deployables/
for?{bgcolor}
This is a Tuscany specific shorthand for defining deployable components, i.e.
you won't find it in the SCA specifications.
If you have a contribution in a directory say.
/my/contribution/dir
Then all components in composites under this directory will be located by the
contribution service and any components in composites under the directory
/META-INF/sca-deployables/ will automatically be included in the deployable
list maintained by the contribution, for example
/my/contribution/dir/META-INF/sca-deployables/mycomposite.composite
{column}
{section}
---------------------------------------------------------------------
CONFLUENCE INFORMATION
This message is automatically generated by Confluence
Unsubscribe or edit your notifications preferences
http://cwiki.apache.org/confluence/users/viewnotifications.action
If you think it was sent incorrectly contact one of the administrators
http://cwiki.apache.org/confluence/administrators.action
If you want more information on Confluence, or have a bug to report see
http://www.atlassian.com/software/confluence
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
