You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by "Koganti, Naga" <Na...@ca.com> on 2010/02/01 09:01:19 UTC
Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
Re: Using Interfaces as parameter types of SCA service composite operation
Posted by Raymond Feng <en...@gmail.com>.
Check this out if you want to use interface with JAXB:
https://jaxb.dev.java.net/guide/
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Thursday, February 04, 2010 8:04 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
BTW, what is needed to use plain java interface as a argument to the APIs defined in Remotable SCA interface? Because we faced similar error like "xxxx is an interface, and JAXB can't handle interfaces." error for plain Java interfaces also.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
I would like to simplify the following issue and glad to receive suggestion from this team. Issue is ..
If a Remotable interface has an API and that API takes DataObject as a parameter (commonj.sdo.DataObject) and composite binds a service based this interface to JMS binding. Is this supported usecase? To avoid below exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving following exception
If I try to change the DataObject to org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its implementation type it start working.
Can anyone explain why the server side service operation parameter types have to concrete classes instead of Interface types. Is this a constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of Interface needs to be used as part of composite xml file?
Exception in thread "main" org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:60)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:181)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:432)
at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:70)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConnectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:135)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(UnifiedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:138)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(JAXBContextCache.java:127)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:276)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:203)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:235)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:98)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:58)
... 25 more
RE: Using Interfaces as parameter types of SCA service composite operation
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
BTW, what is needed to use plain java interface as a argument to the
APIs defined in Remotable SCA interface? Because we faced similar error
like "xxxx is an interface, and JAXB can't handle interfaces." error for
plain Java interfaces also.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
Re: Using Interfaces as parameter types of SCA service composite operation
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Thanks! I'll look into it.
BTW, a better approach than attaching the patch to the ML is to create a JIRA and add the code there.
[1] http://issues.apache.org/jira/browse/Tuscany
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Tuesday, February 09, 2010 10:06 PM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
I have modified databinding-sdo module, it is compiling successfully now. However, I could not get sample helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code appropriately. Please review and provide comments so that I can make any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start with the 1st one.
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo/
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built with Tuscany 2.x.
3) Port the sdo sample into 2.x:
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/helloworld-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
Yes I want to give a try. We don't have any components developed with 1.x, this is the first time we started using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am looking for SDO feature in 2.0. If you provide me guidance, I can contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It might require a bit work to support OSGi well. If you would like to try, I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1 schema files, yes they are different. I think mostly "assembly-xsd" module is the one dealing with schemas. Also, I found "databinding-sdo" module in 1.x has references to XSDs. If we can make this (databinding-sdo") module to work with SCA 1.1 schema file, that would be enough?
Could you define scope of the work more detail? Are you just looking for XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations) between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or package name changes. If somebody can contribute an XSLT script to "transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version 1.1 specifications. We'll port most of the existing features from 1.x into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
I would like to simplify the following issue and glad to receive suggestion from this team. Issue is ..
If a Remotable interface has an API and that API takes DataObject as a parameter (commonj.sdo.DataObject) and composite binds a service based this interface to JMS binding. Is this supported usecase? To avoid below exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving following exception
If I try to change the DataObject to org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its implementation type it start working.
Can anyone explain why the server side service operation parameter types have to concrete classes instead of Interface types. Is this a constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of Interface needs to be used as part of composite xml file?
Exception in thread "main" org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:60)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:181)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:432)
at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:70)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConnectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:135)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(UnifiedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:138)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(JAXBContextCache.java:127)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:276)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:203)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:235)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:98)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:58)
... 25 more
RE: databinding-sdo - contribution
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
Hi Raymond,
I have created two issues and attached
patch.
TUSCANY-3469 - helloworld-ws-sdo.zip
TUSCANY-3470 - databinding-jaxb-axiom.zip
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 20 February 2010 11:51 PM
To: Malisetti, Ramanjaneyulu
Cc: user@tuscany.apache.org
Subject: Re: databinding-sdo - contribution
That's great!
Can you open a JIRA and attach the patch to it? I can help fix the
SCATestCaseRunner dependency.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Saturday, February 20, 2010 10:13 AM
To: enjoyjava@gmail.com
Cc: user@tuscany.apache.org
Subject: RE: databinding-sdo - contribution
Hi Raymond,
I am trying to port SDO samples to 2.0. I
made all changes except changes related to SCATestCaseRunner in
HelloWorldClientTestCase.java.
org.apache.tuscany.sca.host.embedded.SCATestCaseRunner;
Any suggestions on what should be done?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Monday, 15 February 2010 1:11 AM
To: tuscany-user
Subject: Re: databinding-sdo-axiom - contribution
Hi,
Did you see the module I checked in at
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/data
binding-sdo/? It already has the correct MANIFEST.MF for OSGi. All the
test cases are passing. I have a feeling that you didn't see this
module.
We only add the packages to Import-Package header if it's necessary to
access such APIs/SPIs and developers are responsible for maintaining
that with modularity in mind.
I think it's time to bring up the SDO related samples into 2.x with both
non-OSGi and OSGi.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Saturday, February 13, 2010 11:02 AM
To: Raymond Feng <ma...@gmail.com>
Subject: databinding-sdo-axiom - contribution
Hi Raymond,
I don't find any changes to the module
"databinding-sdo-axiom" to get into SCA 2.0. It compiled fine without
any problems. I think I should make MANIFEST-INF file for both
databinding-sdo and databinding-sdo-axiom.
What are the guidelines to list out import packages in manifest? Is it
just identifying dependent packages by go through manually or is there
any process?
Also, I found ImportSDOProcessorTestCase is not running in module
databinding-sdo. It is something related to using FactoryExtensionPoint
at around line 86.
I can contribute to few more modules if I get some guidance from you.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 13 February 2010 12:17 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
I did the changes before I checked in databinding-sdo. The
ProcessorContext is used to pass in some context (such as the Monitor)
to the processors during XML processing.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 12, 2010 2:35 AM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
I'll make changes for databinding-sdo-axiom
also.
If you had observed changes I made for databinding-sdo are around
ProcessorContext. How this object is created and used by SCA runtime.
Could you throw some light here?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 11 February 2010 11:21 PM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
I have checked in the databinding-sdo into 2.x stream [1] based on your
patch. I also made some fixes to get it built.
To test the sameples, you need to make some adjustments:
1) Use tuscany-host-jetty (We need to port tuscany-host-tomcat into 2.x
too)
2) Use tuscany-node-api (NodeFactory/Node to replace host-embedded)
[1] http://svn.apache.org/viewvc?rev=909092&view=rev
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Tuesday, February 09, 2010 10:06 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
I have modified databinding-sdo module, it is
compiling successfully now. However, I could not get sample
helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following
source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code
appropriately. Please review and provide comments so that I can make
any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start
with the 1st one.
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo/
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built
with Tuscany 2.x.
3) Port the sdo sample into 2.x:
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/hello
world-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
Yes I want to give a try. We don't have
any components developed with 1.x, this is the first time we started
using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am
looking for SDO feature in 2.0. If you provide me guidance, I can
contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need
to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType
files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used
in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It
might require a bit work to support OSGi well. If you would like to try,
I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng <ma...@gmail.com>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1
schema files, yes they are different. I think mostly "assembly-xsd"
module is the one dealing with schemas. Also, I found "databinding-sdo"
module in 1.x has references to XSDs. If we can make this
(databinding-sdo") module to work with SCA 1.1 schema file, that would
be enough?
Could you define scope of the work more detail? Are you just looking for
XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations)
between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or
package name changes. If somebody can contribute an XSLT script to
"transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you
think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version
1.1 specifications. We'll port most of the existing features from 1.x
into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the
difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
RE: databinding-sdo - contribution
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
BTW, for module databinding-jaxb-axiom, MANIFEST.MF to be created. I
leave it to you (expert).
Regards
Raman
From: Malisetti, Ramanjaneyulu
Sent: Sunday, 21 February 2010 12:09 AM
To: 'Raymond Feng'
Cc: user@tuscany.apache.org
Subject: RE: databinding-sdo - contribution
Hi Raymond,
I have created two issues and attached
patch.
TUSCANY-3469 - helloworld-ws-sdo.zip
TUSCANY-3470 - databinding-jaxb-axiom.zip
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 20 February 2010 11:51 PM
To: Malisetti, Ramanjaneyulu
Cc: user@tuscany.apache.org
Subject: Re: databinding-sdo - contribution
That's great!
Can you open a JIRA and attach the patch to it? I can help fix the
SCATestCaseRunner dependency.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Saturday, February 20, 2010 10:13 AM
To: enjoyjava@gmail.com
Cc: user@tuscany.apache.org
Subject: RE: databinding-sdo - contribution
Hi Raymond,
I am trying to port SDO samples to 2.0. I
made all changes except changes related to SCATestCaseRunner in
HelloWorldClientTestCase.java.
org.apache.tuscany.sca.host.embedded.SCATestCaseRunner;
Any suggestions on what should be done?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Monday, 15 February 2010 1:11 AM
To: tuscany-user
Subject: Re: databinding-sdo-axiom - contribution
Hi,
Did you see the module I checked in at
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/data
binding-sdo/? It already has the correct MANIFEST.MF for OSGi. All the
test cases are passing. I have a feeling that you didn't see this
module.
We only add the packages to Import-Package header if it's necessary to
access such APIs/SPIs and developers are responsible for maintaining
that with modularity in mind.
I think it's time to bring up the SDO related samples into 2.x with both
non-OSGi and OSGi.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Saturday, February 13, 2010 11:02 AM
To: Raymond Feng <ma...@gmail.com>
Subject: databinding-sdo-axiom - contribution
Hi Raymond,
I don't find any changes to the module
"databinding-sdo-axiom" to get into SCA 2.0. It compiled fine without
any problems. I think I should make MANIFEST-INF file for both
databinding-sdo and databinding-sdo-axiom.
What are the guidelines to list out import packages in manifest? Is it
just identifying dependent packages by go through manually or is there
any process?
Also, I found ImportSDOProcessorTestCase is not running in module
databinding-sdo. It is something related to using FactoryExtensionPoint
at around line 86.
I can contribute to few more modules if I get some guidance from you.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 13 February 2010 12:17 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
I did the changes before I checked in databinding-sdo. The
ProcessorContext is used to pass in some context (such as the Monitor)
to the processors during XML processing.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 12, 2010 2:35 AM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
I'll make changes for databinding-sdo-axiom
also.
If you had observed changes I made for databinding-sdo are around
ProcessorContext. How this object is created and used by SCA runtime.
Could you throw some light here?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 11 February 2010 11:21 PM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
I have checked in the databinding-sdo into 2.x stream [1] based on your
patch. I also made some fixes to get it built.
To test the sameples, you need to make some adjustments:
1) Use tuscany-host-jetty (We need to port tuscany-host-tomcat into 2.x
too)
2) Use tuscany-node-api (NodeFactory/Node to replace host-embedded)
[1] http://svn.apache.org/viewvc?rev=909092&view=rev
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Tuesday, February 09, 2010 10:06 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
I have modified databinding-sdo module, it is
compiling successfully now. However, I could not get sample
helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following
source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code
appropriately. Please review and provide comments so that I can make
any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start
with the 1st one.
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo/
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built
with Tuscany 2.x.
3) Port the sdo sample into 2.x:
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/hello
world-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
Yes I want to give a try. We don't have
any components developed with 1.x, this is the first time we started
using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am
looking for SDO feature in 2.0. If you provide me guidance, I can
contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need
to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType
files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used
in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It
might require a bit work to support OSGi well. If you would like to try,
I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng <ma...@gmail.com>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1
schema files, yes they are different. I think mostly "assembly-xsd"
module is the one dealing with schemas. Also, I found "databinding-sdo"
module in 1.x has references to XSDs. If we can make this
(databinding-sdo") module to work with SCA 1.1 schema file, that would
be enough?
Could you define scope of the work more detail? Are you just looking for
XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations)
between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or
package name changes. If somebody can contribute an XSLT script to
"transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you
think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version
1.1 specifications. We'll port most of the existing features from 1.x
into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the
difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
Re: databinding-sdo - contribution
Posted by Raymond Feng <en...@gmail.com>.
That's great!
Can you open a JIRA and attach the patch to it? I can help fix the SCATestCaseRunner dependency.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Saturday, February 20, 2010 10:13 AM
To: enjoyjava@gmail.com
Cc: user@tuscany.apache.org
Subject: RE: databinding-sdo - contribution
Hi Raymond,
I am trying to port SDO samples to 2.0. I made all changes except changes related to SCATestCaseRunner in HelloWorldClientTestCase.java.
org.apache.tuscany.sca.host.embedded.SCATestCaseRunner;
Any suggestions on what should be done?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Monday, 15 February 2010 1:11 AM
To: tuscany-user
Subject: Re: databinding-sdo-axiom - contribution
Hi,
Did you see the module I checked in at https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/databinding-sdo/? It already has the correct MANIFEST.MF for OSGi. All the test cases are passing. I have a feeling that you didn't see this module.
We only add the packages to Import-Package header if it's necessary to access such APIs/SPIs and developers are responsible for maintaining that with modularity in mind.
I think it's time to bring up the SDO related samples into 2.x with both non-OSGi and OSGi.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Saturday, February 13, 2010 11:02 AM
To: Raymond Feng
Subject: databinding-sdo-axiom - contribution
Hi Raymond,
I don't find any changes to the module "databinding-sdo-axiom" to get into SCA 2.0. It compiled fine without any problems. I think I should make MANIFEST-INF file for both databinding-sdo and databinding-sdo-axiom.
What are the guidelines to list out import packages in manifest? Is it just identifying dependent packages by go through manually or is there any process?
Also, I found ImportSDOProcessorTestCase is not running in module databinding-sdo. It is something related to using FactoryExtensionPoint at around line 86.
I can contribute to few more modules if I get some guidance from you.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 13 February 2010 12:17 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
I did the changes before I checked in databinding-sdo. The ProcessorContext is used to pass in some context (such as the Monitor) to the processors during XML processing.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 12, 2010 2:35 AM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
I'll make changes for databinding-sdo-axiom also.
If you had observed changes I made for databinding-sdo are around ProcessorContext. How this object is created and used by SCA runtime. Could you throw some light here?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 11 February 2010 11:21 PM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have checked in the databinding-sdo into 2.x stream [1] based on your patch. I also made some fixes to get it built.
To test the sameples, you need to make some adjustments:
1) Use tuscany-host-jetty (We need to port tuscany-host-tomcat into 2.x too)
2) Use tuscany-node-api (NodeFactory/Node to replace host-embedded)
[1] http://svn.apache.org/viewvc?rev=909092&view=rev
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Tuesday, February 09, 2010 10:06 PM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
I have modified databinding-sdo module, it is compiling successfully now. However, I could not get sample helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code appropriately. Please review and provide comments so that I can make any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start with the 1st one.
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo/
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built with Tuscany 2.x.
3) Port the sdo sample into 2.x:
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/helloworld-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
Yes I want to give a try. We don't have any components developed with 1.x, this is the first time we started using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am looking for SDO feature in 2.0. If you provide me guidance, I can contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It might require a bit work to support OSGi well. If you would like to try, I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1 schema files, yes they are different. I think mostly "assembly-xsd" module is the one dealing with schemas. Also, I found "databinding-sdo" module in 1.x has references to XSDs. If we can make this (databinding-sdo") module to work with SCA 1.1 schema file, that would be enough?
Could you define scope of the work more detail? Are you just looking for XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations) between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or package name changes. If somebody can contribute an XSLT script to "transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version 1.1 specifications. We'll port most of the existing features from 1.x into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
I would like to simplify the following issue and glad to receive suggestion from this team. Issue is ..
If a Remotable interface has an API and that API takes DataObject as a parameter (commonj.sdo.DataObject) and composite binds a service based this interface to JMS binding. Is this supported usecase? To avoid below exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving following exception
If I try to change the DataObject to org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its implementation type it start working.
Can anyone explain why the server side service operation parameter types have to concrete classes instead of Interface types. Is this a constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of Interface needs to be used as part of composite xml file?
Exception in thread "main" org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:60)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:181)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:432)
at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:70)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConnectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:135)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(UnifiedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:138)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(JAXBContextCache.java:127)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:276)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:203)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:235)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:98)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:58)
... 25 more
RE: databinding-sdo - contribution
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
Hi Raymond,
I am trying to port SDO samples to 2.0. I
made all changes except changes related to SCATestCaseRunner in
HelloWorldClientTestCase.java.
org.apache.tuscany.sca.host.embedded.SCATestCaseRunner;
Any suggestions on what should be done?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Monday, 15 February 2010 1:11 AM
To: tuscany-user
Subject: Re: databinding-sdo-axiom - contribution
Hi,
Did you see the module I checked in at
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/data
binding-sdo/? It already has the correct MANIFEST.MF for OSGi. All the
test cases are passing. I have a feeling that you didn't see this
module.
We only add the packages to Import-Package header if it's necessary to
access such APIs/SPIs and developers are responsible for maintaining
that with modularity in mind.
I think it's time to bring up the SDO related samples into 2.x with both
non-OSGi and OSGi.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Saturday, February 13, 2010 11:02 AM
To: Raymond Feng <ma...@gmail.com>
Subject: databinding-sdo-axiom - contribution
Hi Raymond,
I don't find any changes to the module
"databinding-sdo-axiom" to get into SCA 2.0. It compiled fine without
any problems. I think I should make MANIFEST-INF file for both
databinding-sdo and databinding-sdo-axiom.
What are the guidelines to list out import packages in manifest? Is it
just identifying dependent packages by go through manually or is there
any process?
Also, I found ImportSDOProcessorTestCase is not running in module
databinding-sdo. It is something related to using FactoryExtensionPoint
at around line 86.
I can contribute to few more modules if I get some guidance from you.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 13 February 2010 12:17 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
I did the changes before I checked in databinding-sdo. The
ProcessorContext is used to pass in some context (such as the Monitor)
to the processors during XML processing.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 12, 2010 2:35 AM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
I'll make changes for databinding-sdo-axiom
also.
If you had observed changes I made for databinding-sdo are around
ProcessorContext. How this object is created and used by SCA runtime.
Could you throw some light here?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 11 February 2010 11:21 PM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
I have checked in the databinding-sdo into 2.x stream [1] based on your
patch. I also made some fixes to get it built.
To test the sameples, you need to make some adjustments:
1) Use tuscany-host-jetty (We need to port tuscany-host-tomcat into 2.x
too)
2) Use tuscany-node-api (NodeFactory/Node to replace host-embedded)
[1] http://svn.apache.org/viewvc?rev=909092&view=rev
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Tuesday, February 09, 2010 10:06 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
I have modified databinding-sdo module, it is
compiling successfully now. However, I could not get sample
helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following
source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code
appropriately. Please review and provide comments so that I can make
any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start
with the 1st one.
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo/
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built
with Tuscany 2.x.
3) Port the sdo sample into 2.x:
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/hello
world-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
Yes I want to give a try. We don't have
any components developed with 1.x, this is the first time we started
using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am
looking for SDO feature in 2.0. If you provide me guidance, I can
contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need
to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType
files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used
in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It
might require a bit work to support OSGi well. If you would like to try,
I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng <ma...@gmail.com>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1
schema files, yes they are different. I think mostly "assembly-xsd"
module is the one dealing with schemas. Also, I found "databinding-sdo"
module in 1.x has references to XSDs. If we can make this
(databinding-sdo") module to work with SCA 1.1 schema file, that would
be enough?
Could you define scope of the work more detail? Are you just looking for
XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations)
between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or
package name changes. If somebody can contribute an XSLT script to
"transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you
think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version
1.1 specifications. We'll port most of the existing features from 1.x
into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the
difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
RE: databinding-sdo-axiom - contribution
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
I did see your check-in, but I downloaded only testcases and tried to
run with patch that I have. With that I found one test case in not
running. I agree I should have get complete pactch. I'll work with
getting samples to 2.x.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Monday, 15 February 2010 1:11 AM
To: tuscany-user
Subject: Re: databinding-sdo-axiom - contribution
Hi,
Did you see the module I checked in at
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/data
binding-sdo/? It already has the correct MANIFEST.MF for OSGi. All the
test cases are passing. I have a feeling that you didn't see this
module.
We only add the packages to Import-Package header if it's necessary to
access such APIs/SPIs and developers are responsible for maintaining
that with modularity in mind.
I think it's time to bring up the SDO related samples into 2.x with both
non-OSGi and OSGi.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Saturday, February 13, 2010 11:02 AM
To: Raymond Feng <ma...@gmail.com>
Subject: databinding-sdo-axiom - contribution
Hi Raymond,
I don't find any changes to the module
"databinding-sdo-axiom" to get into SCA 2.0. It compiled fine without
any problems. I think I should make MANIFEST-INF file for both
databinding-sdo and databinding-sdo-axiom.
What are the guidelines to list out import packages in manifest? Is it
just identifying dependent packages by go through manually or is there
any process?
Also, I found ImportSDOProcessorTestCase is not running in module
databinding-sdo. It is something related to using FactoryExtensionPoint
at around line 86.
I can contribute to few more modules if I get some guidance from you.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 13 February 2010 12:17 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
I did the changes before I checked in databinding-sdo. The
ProcessorContext is used to pass in some context (such as the Monitor)
to the processors during XML processing.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 12, 2010 2:35 AM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
I'll make changes for databinding-sdo-axiom
also.
If you had observed changes I made for databinding-sdo are around
ProcessorContext. How this object is created and used by SCA runtime.
Could you throw some light here?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 11 February 2010 11:21 PM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
I have checked in the databinding-sdo into 2.x stream [1] based on your
patch. I also made some fixes to get it built.
To test the sameples, you need to make some adjustments:
1) Use tuscany-host-jetty (We need to port tuscany-host-tomcat into 2.x
too)
2) Use tuscany-node-api (NodeFactory/Node to replace host-embedded)
[1] http://svn.apache.org/viewvc?rev=909092&view=rev
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Tuesday, February 09, 2010 10:06 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
I have modified databinding-sdo module, it is
compiling successfully now. However, I could not get sample
helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following
source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code
appropriately. Please review and provide comments so that I can make
any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start
with the 1st one.
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo/
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built
with Tuscany 2.x.
3) Port the sdo sample into 2.x:
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/hello
world-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
Yes I want to give a try. We don't have
any components developed with 1.x, this is the first time we started
using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am
looking for SDO feature in 2.0. If you provide me guidance, I can
contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need
to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType
files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used
in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It
might require a bit work to support OSGi well. If you would like to try,
I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng <ma...@gmail.com>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1
schema files, yes they are different. I think mostly "assembly-xsd"
module is the one dealing with schemas. Also, I found "databinding-sdo"
module in 1.x has references to XSDs. If we can make this
(databinding-sdo") module to work with SCA 1.1 schema file, that would
be enough?
Could you define scope of the work more detail? Are you just looking for
XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations)
between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or
package name changes. If somebody can contribute an XSLT script to
"transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you
think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version
1.1 specifications. We'll port most of the existing features from 1.x
into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the
difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
Re: databinding-sdo-axiom - contribution
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Did you see the module I checked in at https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/databinding-sdo/? It already has the correct MANIFEST.MF for OSGi. All the test cases are passing. I have a feeling that you didn't see this module.
We only add the packages to Import-Package header if it's necessary to access such APIs/SPIs and developers are responsible for maintaining that with modularity in mind.
I think it's time to bring up the SDO related samples into 2.x with both non-OSGi and OSGi.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Saturday, February 13, 2010 11:02 AM
To: Raymond Feng
Subject: databinding-sdo-axiom - contribution
Hi Raymond,
I don't find any changes to the module "databinding-sdo-axiom" to get into SCA 2.0. It compiled fine without any problems. I think I should make MANIFEST-INF file for both databinding-sdo and databinding-sdo-axiom.
What are the guidelines to list out import packages in manifest? Is it just identifying dependent packages by go through manually or is there any process?
Also, I found ImportSDOProcessorTestCase is not running in module databinding-sdo. It is something related to using FactoryExtensionPoint at around line 86.
I can contribute to few more modules if I get some guidance from you.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 13 February 2010 12:17 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
I did the changes before I checked in databinding-sdo. The ProcessorContext is used to pass in some context (such as the Monitor) to the processors during XML processing.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 12, 2010 2:35 AM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
I'll make changes for databinding-sdo-axiom also.
If you had observed changes I made for databinding-sdo are around ProcessorContext. How this object is created and used by SCA runtime. Could you throw some light here?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 11 February 2010 11:21 PM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have checked in the databinding-sdo into 2.x stream [1] based on your patch. I also made some fixes to get it built.
To test the sameples, you need to make some adjustments:
1) Use tuscany-host-jetty (We need to port tuscany-host-tomcat into 2.x too)
2) Use tuscany-node-api (NodeFactory/Node to replace host-embedded)
[1] http://svn.apache.org/viewvc?rev=909092&view=rev
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Tuesday, February 09, 2010 10:06 PM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
I have modified databinding-sdo module, it is compiling successfully now. However, I could not get sample helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code appropriately. Please review and provide comments so that I can make any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start with the 1st one.
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo/
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built with Tuscany 2.x.
3) Port the sdo sample into 2.x:
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/helloworld-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
Yes I want to give a try. We don't have any components developed with 1.x, this is the first time we started using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am looking for SDO feature in 2.0. If you provide me guidance, I can contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It might require a bit work to support OSGi well. If you would like to try, I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1 schema files, yes they are different. I think mostly "assembly-xsd" module is the one dealing with schemas. Also, I found "databinding-sdo" module in 1.x has references to XSDs. If we can make this (databinding-sdo") module to work with SCA 1.1 schema file, that would be enough?
Could you define scope of the work more detail? Are you just looking for XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations) between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or package name changes. If somebody can contribute an XSLT script to "transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version 1.1 specifications. We'll port most of the existing features from 1.x into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
I would like to simplify the following issue and glad to receive suggestion from this team. Issue is ..
If a Remotable interface has an API and that API takes DataObject as a parameter (commonj.sdo.DataObject) and composite binds a service based this interface to JMS binding. Is this supported usecase? To avoid below exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving following exception
If I try to change the DataObject to org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its implementation type it start working.
Can anyone explain why the server side service operation parameter types have to concrete classes instead of Interface types. Is this a constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of Interface needs to be used as part of composite xml file?
Exception in thread "main" org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:60)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:181)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:432)
at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:70)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConnectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:135)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(UnifiedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:138)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(JAXBContextCache.java:127)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:276)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:203)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:235)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:98)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:58)
... 25 more
RE: Using Interfaces as parameter types of SCA service composite operation
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
Hi Raymond,
I'll make changes for databinding-sdo-axiom
also.
If you had observed changes I made for databinding-sdo are around
ProcessorContext. How this object is created and used by SCA runtime.
Could you throw some light here?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 11 February 2010 11:21 PM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
I have checked in the databinding-sdo into 2.x stream [1] based on your
patch. I also made some fixes to get it built.
To test the sameples, you need to make some adjustments:
1) Use tuscany-host-jetty (We need to port tuscany-host-tomcat into 2.x
too)
2) Use tuscany-node-api (NodeFactory/Node to replace host-embedded)
[1] http://svn.apache.org/viewvc?rev=909092&view=rev
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Tuesday, February 09, 2010 10:06 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
I have modified databinding-sdo module, it is
compiling successfully now. However, I could not get sample
helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following
source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code
appropriately. Please review and provide comments so that I can make
any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start
with the 1st one.
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo/
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built
with Tuscany 2.x.
3) Port the sdo sample into 2.x:
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/hello
world-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
Yes I want to give a try. We don't have
any components developed with 1.x, this is the first time we started
using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am
looking for SDO feature in 2.0. If you provide me guidance, I can
contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need
to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType
files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used
in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It
might require a bit work to support OSGi well. If you would like to try,
I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng <ma...@gmail.com>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1
schema files, yes they are different. I think mostly "assembly-xsd"
module is the one dealing with schemas. Also, I found "databinding-sdo"
module in 1.x has references to XSDs. If we can make this
(databinding-sdo") module to work with SCA 1.1 schema file, that would
be enough?
Could you define scope of the work more detail? Are you just looking for
XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations)
between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or
package name changes. If somebody can contribute an XSLT script to
"transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you
think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version
1.1 specifications. We'll port most of the existing features from 1.x
into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the
difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
Re: Using Interfaces as parameter types of SCA service composite operation
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I have checked in the databinding-sdo into 2.x stream [1] based on your patch. I also made some fixes to get it built.
To test the sameples, you need to make some adjustments:
1) Use tuscany-host-jetty (We need to port tuscany-host-tomcat into 2.x too)
2) Use tuscany-node-api (NodeFactory/Node to replace host-embedded)
[1] http://svn.apache.org/viewvc?rev=909092&view=rev
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Tuesday, February 09, 2010 10:06 PM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
I have modified databinding-sdo module, it is compiling successfully now. However, I could not get sample helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code appropriately. Please review and provide comments so that I can make any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start with the 1st one.
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo/
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built with Tuscany 2.x.
3) Port the sdo sample into 2.x:
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/helloworld-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
Yes I want to give a try. We don't have any components developed with 1.x, this is the first time we started using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am looking for SDO feature in 2.0. If you provide me guidance, I can contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It might require a bit work to support OSGi well. If you would like to try, I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1 schema files, yes they are different. I think mostly "assembly-xsd" module is the one dealing with schemas. Also, I found "databinding-sdo" module in 1.x has references to XSDs. If we can make this (databinding-sdo") module to work with SCA 1.1 schema file, that would be enough?
Could you define scope of the work more detail? Are you just looking for XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations) between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or package name changes. If somebody can contribute an XSLT script to "transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version 1.1 specifications. We'll port most of the existing features from 1.x into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
I would like to simplify the following issue and glad to receive suggestion from this team. Issue is ..
If a Remotable interface has an API and that API takes DataObject as a parameter (commonj.sdo.DataObject) and composite binds a service based this interface to JMS binding. Is this supported usecase? To avoid below exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving following exception
If I try to change the DataObject to org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its implementation type it start working.
Can anyone explain why the server side service operation parameter types have to concrete classes instead of Interface types. Is this a constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of Interface needs to be used as part of composite xml file?
Exception in thread "main" org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:60)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:181)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:432)
at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:70)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConnectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:135)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(UnifiedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:138)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(JAXBContextCache.java:127)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:276)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:203)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:235)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:98)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:58)
... 25 more
RE: Using Interfaces as parameter types of SCA service composite operation
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
Hi Raymond,
I have modified databinding-sdo module, it is
compiling successfully now. However, I could not get sample
helloworld-ws-sdo to 2.0.M4 due to following missing dependencies.
tuscany-host-tomcat
tuscany-binding-ws-axis2
tuscany-host-embedded
Here, I attached modified source code for your review and the following
source files are modified.
org.apache.tuscany.sca.databinding.sdo.xml.SDOTypesModelResolver.java
org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.java
org.apache.tuscany.sca.databinding.sdo.DataObject2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject.java
org.apache.tuscany.sca.databinding.sdo.SDOSimpleTypeMapper.java
org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor.java
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.java
org.apache.tuscany.sca.databinding.sdo. SDOTypes.java
I didn't understand how we get ProcessorContext context, I modified code
appropriately. Please review and provide comments so that I can make
any other changes if require.
Note: please rename attached file from .dat to .zip.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 10 February 2010 12:19 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start
with the 1st one.
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo/
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/datab
inding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built
with Tuscany 2.x.
3) Port the sdo sample into 2.x:
*
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/hello
world-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng <ma...@gmail.com>
Cc: tuscany-user <ma...@tuscany.apache.org>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond,
Yes I want to give a try. We don't have
any components developed with 1.x, this is the first time we started
using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am
looking for SDO feature in 2.0. If you provide me guidance, I can
contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need
to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType
files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used
in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It
might require a bit work to support OSGi well. If you would like to try,
I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng <ma...@gmail.com>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1
schema files, yes they are different. I think mostly "assembly-xsd"
module is the one dealing with schemas. Also, I found "databinding-sdo"
module in 1.x has references to XSDs. If we can make this
(databinding-sdo") module to work with SCA 1.1 schema file, that would
be enough?
Could you define scope of the work more detail? Are you just looking for
XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations)
between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or
package name changes. If somebody can contribute an XSLT script to
"transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you
think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version
1.1 specifications. We'll port most of the existing features from 1.x
into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the
difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
Re: Using Interfaces as parameter types of SCA service composite operation
Posted by Raymond Feng <en...@gmail.com>.
Hi, Malisetti.
It's great that you can help. Let me give you a few pointers:
1) There are two modules in 1.x related to SDO databinding. We can start with the 1st one.
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo/
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/databinding-sdo-axiom/
2) We can start to update the pom.xml so that the module will be built with Tuscany 2.x.
3) Port the sdo sample into 2.x:
* http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/samples/helloworld-ws-sdo/
We need to change the composite namespace, Java APIs etc.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 8:04 PM
To: Raymond Feng
Cc: tuscany-user
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond,
Yes I want to give a try. We don't have any components developed with 1.x, this is the first time we started using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am looking for SDO feature in 2.0. If you provide me guidance, I can contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It might require a bit work to support OSGi well. If you would like to try, I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1 schema files, yes they are different. I think mostly "assembly-xsd" module is the one dealing with schemas. Also, I found "databinding-sdo" module in 1.x has references to XSDs. If we can make this (databinding-sdo") module to work with SCA 1.1 schema file, that would be enough?
Could you define scope of the work more detail? Are you just looking for XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations) between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or package name changes. If somebody can contribute an XSLT script to "transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version 1.1 specifications. We'll port most of the existing features from 1.x into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
I would like to simplify the following issue and glad to receive suggestion from this team. Issue is ..
If a Remotable interface has an API and that API takes DataObject as a parameter (commonj.sdo.DataObject) and composite binds a service based this interface to JMS binding. Is this supported usecase? To avoid below exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving following exception
If I try to change the DataObject to org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its implementation type it start working.
Can anyone explain why the server side service operation parameter types have to concrete classes instead of Interface types. Is this a constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of Interface needs to be used as part of composite xml file?
Exception in thread "main" org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:60)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:181)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:432)
at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:70)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConnectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:135)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(UnifiedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:138)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(JAXBContextCache.java:127)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:276)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:203)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:235)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:98)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:58)
... 25 more
RE: Using Interfaces as parameter types of SCA service composite operation
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
Hi Raymond,
Yes I want to give a try. We don't have
any components developed with 1.x, this is the first time we started
using SCA, hence we choose latest release 2.0.
My requirement is to use SDO for databinding, that is the reason I am
looking for SDO feature in 2.0. If you provide me guidance, I can
contribute to getting 1.x sdo-binding to 2.0.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Saturday, 6 February 2010 3:55 AM
To: Malisetti, Ramanjaneyulu
Cc: tuscany-user
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need
to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType
files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used
in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It
might require a bit work to support OSGi well. If you would like to try,
I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng <ma...@gmail.com>
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1
schema files, yes they are different. I think mostly "assembly-xsd"
module is the one dealing with schemas. Also, I found "databinding-sdo"
module in 1.x has references to XSDs. If we can make this
(databinding-sdo") module to work with SCA 1.1 schema file, that would
be enough?
Could you define scope of the work more detail? Are you just looking for
XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations)
between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or
package name changes. If somebody can contribute an XSLT script to
"transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you
think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version
1.1 specifications. We'll port most of the existing features from 1.x
into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the
difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
Re: Using Interfaces as parameter types of SCA service composite operation
Posted by Raymond Feng <en...@gmail.com>.
Hi,
To port an SCA composite application from 1.x to 2.x, you probably need to do the following:
1) Fix the SCA related XML documents, such as Composite/ComponentType files and sca-contribution.xml (We can use an XSLT to help that)
2) Change the java package names for the SCA annotations and APIs used in your java components
For the databinding-sdo, it needs to be ported into Tuscany 2.x. It might require a bit work to support OSGi well. If you would like to try, I can help.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Friday, February 05, 2010 9:51 AM
To: Raymond Feng
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Hi Raymond
I had a quick look at SCA 1.0 and SCA 1.1 schema files, yes they are different. I think mostly "assembly-xsd" module is the one dealing with schemas. Also, I found "databinding-sdo" module in 1.x has references to XSDs. If we can make this (databinding-sdo") module to work with SCA 1.1 schema file, that would be enough?
Could you define scope of the work more detail? Are you just looking for XSLT script that gives 1.1 schema for requested 1.0 schema?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, 5 February 2010 3:35 AM
To: Malisetti, Ramanjaneyulu
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
There are changes in the SCDL XML and Java APIs (including annotations) between SCA 1.0 and SCA 1.1. But a big part of them is just namespace or package name changes. If somebody can contribute an XSLT script to "transform" from 1.0 to 1.1, it will be great.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:59 PM
To: user@tuscany.apache.org ; enjoyjava@gmail.com
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
What is involved in porting 1.x to 2.x? what is the approx effort you think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version 1.1 specifications. We'll port most of the existing features from 1.x into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
I would like to simplify the following issue and glad to receive suggestion from this team. Issue is ..
If a Remotable interface has an API and that API takes DataObject as a parameter (commonj.sdo.DataObject) and composite binds a service based this interface to JMS binding. Is this supported usecase? To avoid below exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving following exception
If I try to change the DataObject to org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its implementation type it start working.
Can anyone explain why the server side service operation parameter types have to concrete classes instead of Interface types. Is this a constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of Interface needs to be used as part of composite xml file?
Exception in thread "main" org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:60)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:181)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:432)
at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:70)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConnectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:135)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(UnifiedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:138)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(JAXBContextCache.java:127)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:276)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:203)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:235)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:98)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:58)
... 25 more
RE: Using Interfaces as parameter types of SCA service composite operation
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
What is involved in porting 1.x to 2.x? what is the approx effort you
think it involves? Accordingly I can plan.
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Thursday, 4 February 2010 10:25 AM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version
1.1 specifications. We'll port most of the existing features from 1.x
into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the
difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
Re: Using Interfaces as parameter types of SCA service composite operation
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Tuscany 2.x is an implementation of the OASIS OpenCSA based SCA version 1.1 specifications. We'll port most of the existing features from 1.x into 2.x over time. Any helps are welcome.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:44 PM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
Thanks Raymond. It seems 2.x is not suitable for us. What is the difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
I would like to simplify the following issue and glad to receive suggestion from this team. Issue is ..
If a Remotable interface has an API and that API takes DataObject as a parameter (commonj.sdo.DataObject) and composite binds a service based this interface to JMS binding. Is this supported usecase? To avoid below exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving following exception
If I try to change the DataObject to org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its implementation type it start working.
Can anyone explain why the server side service operation parameter types have to concrete classes instead of Interface types. Is this a constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of Interface needs to be used as part of composite xml file?
Exception in thread "main" org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:60)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:181)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:432)
at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:70)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConnectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:135)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(UnifiedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:138)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(JAXBContextCache.java:127)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:276)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:203)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:235)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:98)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:58)
... 25 more
RE: Using Interfaces as parameter types of SCA service composite operation
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
Thanks Raymond. It seems 2.x is not suitable for us. What is the
difference in 1.x to 2.0 other than OSGi support?
Regards
Raman
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, 3 February 2010 11:29 PM
To: user@tuscany.apache.org
Subject: Re: Using Interfaces as parameter types of SCA service
composite operation
Are you using Tuscany 1.x? If so, there is databinding-sdo module can
deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu <ma...@ca.com>
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service
composite operation
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more
Re: Using Interfaces as parameter types of SCA service composite operation
Posted by Raymond Feng <en...@gmail.com>.
Are you using Tuscany 1.x? If so, there is databinding-sdo module can deal with the SDO DataObject. We haven't yet ported it to 2.x though.
Thanks,
Raymond
From: Malisetti, Ramanjaneyulu
Sent: Wednesday, February 03, 2010 8:01 AM
To: user@tuscany.apache.org
Subject: RE: Using Interfaces as parameter types of SCA service composite operation
I would like to simplify the following issue and glad to receive suggestion from this team. Issue is ..
If a Remotable interface has an API and that API takes DataObject as a parameter (commonj.sdo.DataObject) and composite binds a service based this interface to JMS binding. Is this supported usecase? To avoid below exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving following exception
If I try to change the DataObject to org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its implementation type it start working.
Can anyone explain why the server side service operation parameter types have to concrete classes instead of Interface types. Is this a constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of Interface needs to be used as part of composite xml file?
Exception in thread "main" org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:60)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:181)
at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:114)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:432)
at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:70)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConnectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:135)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:61)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(UnifiedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:438)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:286)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:138)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBContextCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(JAXBContextCache.java:127)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:276)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:203)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:235)
at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:98)
at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:58)
... 25 more
RE: Using Interfaces as parameter types of SCA service composite operation
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
I would like to simplify the following issue and glad to receive
suggestion from this team. Issue is ....
If a Remotable interface has an API and that API takes DataObject as a
parameter (commonj.sdo.DataObject) and composite binds a service based
this interface to JMS binding. Is this supported usecase? To avoid below
exception, what is the right way of doing.
I appreciate your response.
Regards
Raman
From: Koganti, Naga [mailto:Naga.Koganti@ca.com]
Sent: Monday, 1 February 2010 1:31 PM
To: user@tuscany.apache.org
Subject: Using Interfaces as parameter types of SCA service composite
operation
Hi,
I have one service on server composite having the following method
public String start(String operID, DataObject selector, DataObject
operParams, OperationListener listener, String refID) throws Exception;
In above method the DataObject I am using are SDO DataObjects of type
commonj.sdo.DataObject and the OperationListener is our own interface
When I try to call the start method from the service client it is giving
following exception
If I try to change the DataObject to
org.apache.tuscany.sdo.impl.DataObjectImpl and OperationListener to its
implementation type it start working.
Can anyone explain why the server side service operation parameter types
have to concrete classes instead of Interface types. Is this a
constraint in Apache Tuscany SCA?
Is there any way we can specify what Implementation class types of
Interface needs to be used as part of composite xml file?
Exception in thread "main"
org.apache.tuscany.sca.databinding.TransformationException:
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4 counts of
IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:60)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:181)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransfor
mer.transform(Input2InputTransformer.java:1)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$Lazy
PullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImp
l.java:114)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(Mediat
orImpl.java:432)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationIntercept
or.invoke(DataTransformationInterceptor.java:70)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClient.start(UnifiedConn
ectorServiceClient.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementation
Invoker.invoke(JavaImplementationInvoker.java:135)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCA
BindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invo
ke(PassByValueInterceptor.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:289)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(
JDKInvocationHandler.java:154)
at $Proxy24.start(Unknown Source)
at
com.ca.ucf.connector.sca.UnifiedConnectorServiceClientTestCase.main(Unif
iedConnectorServiceClientTestCase.java:120)
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 4
counts of IllegalAnnotationExceptions
commonj.sdo.DataObject is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
commonj.sdo.DataObject does not have a no-arg default constructor.
this problem is related to the following location:
at commonj.sdo.DataObject
at protected commonj.sdo.DataObject
com.ca.ucf.connector.sca.jaxws.Start.arg1
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener is an interface, and JAXB
can't handle interfaces.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
com.ca.connector.runtime.OperationListener does not have a no-arg
default constructor.
this problem is related to the following location:
at com.ca.connector.runtime.OperationListener
at protected com.ca.connector.runtime.OperationListener
com.ca.ucf.connector.sca.jaxws.Start.arg3
at com.ca.ucf.connector.sca.jaxws.Start
at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(Il
legalAnnotationsException.java:102)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextIm
pl.java:438)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139
)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:138)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache$1.run(JAXBConte
xtCache.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.newJAXBContext(
JAXBContextCache.java:127)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(
JAXBContextCache.java:276)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:203)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:235)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBCont
ext(JAXBContextHelper.java:98)
at
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(J
AXB2OMElement.java:58)
... 25 more