Re: Trying to package a standalone application.
Hi, I have an import.sdo location into my client SCDL. It looks like this : dbsdo:import.sdo xmlns:dbsdo=http://incubator.apache.org/tuscany/xmlns/databinding/sdo/1.0-incubator-M2; location=bank/common/AccountService.wsdl/ With this import I have a class cast exception. (see previous message) When I change the import location by an import factory it works ! (thanks to Lee !) It is mandatory to specify a factory when generating SDO classes with the generator ? Is there a way to map things to existing business object ? -- Guillaume. When I had this problem, it was indeed because the static types were not being registerred properly. I was able to bypass the problem by using the factory attribute instead of the location attribute and pointed it directly to the static factory I had generated. That is, import.sdo facotry=com.example.MyFactory instead of import.sdolocation=wsdl/myWsdl.wsdl This is consistent with sample-bigbank-account. -Lee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
Hi, Static types need to be registered, and the factory does this registration for you will (AFAIK) always generate one for you from an XSD source. You can also use the factory for creating new instances of your SDOs. The current implementation doesn't define types if you simply new them, various reasons... so, for now the factory approach is the one to take. Hope this helps, Dan On 05/03/07, Guillaume Dufrêne [EMAIL PROTECTED] wrote: Hi, I have an import.sdo location into my client SCDL. It looks like this : dbsdo:import.sdo xmlns:dbsdo= http://incubator.apache.org/tuscany/xmlns/databinding/sdo/1.0-incubator-M2 location=bank/common/AccountService.wsdl/ With this import I have a class cast exception. (see previous message) When I change the import location by an import factory it works ! (thanks to Lee !) It is mandatory to specify a factory when generating SDO classes with the generator ? Is there a way to map things to existing business object ? -- Guillaume. When I had this problem, it was indeed because the static types were not being registerred properly. I was able to bypass the problem by using the factory attribute instead of the location attribute and pointed it directly to the static factory I had generated. That is, import.sdo facotry=com.example.MyFactory instead of import.sdolocation=wsdl/myWsdl.wsdl This is consistent with sample-bigbank-account. -Lee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
Hi Jeremy, I'm using the launcher for running my sample. So, my command looks like : java -jar (sca-home)/bin/launcher.jar my_application.jar In my case sca-home is located at C:\workspace\fcSOAP\tuscany-1.0-incubator-M2 but anyway ... Where does the launcher intend to find the sdo-impl jar ? It seems to be in the (sca-home)/lib but when I copy (sca-home)/boot/stax-api-1.0.1.jar and (sca-home)/boot/wstx-asl-3.2.0.jar to the lib directory I obtain the same exception. -- Guillaume. _ _ You will need to have the StAX API and an implementation visible in the same classloader as used for SDO. If you have the SDO impl jars in WEB-INF/lib you should make sure: * stax-api-1.0.1.jar * wstx-asl-3.2.0.jar are in the same place (using the StAX impl from http:// woodstox.codehaus.org). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
On Mar 2, 2007, at 5:02 AM, Guillaume Dufrêne wrote:
Hi Jeremy,
I'm using the launcher for running my sample.
So, my command looks like :
java -jar (sca-home)/bin/launcher.jar my_application.jar
In my case sca-home is located at C:\workspace\fcSOAP\tuscany-1.0-
incubator-M2 but anyway ...
Where does the launcher intend to find the sdo-impl jar ?
It seems to be in the (sca-home)/lib but when I copy (sca-home)/
boot/stax-api-1.0.1.jar and
(sca-home)/boot/wstx-asl-3.2.0.jar to the lib directory I obtain
the same exception.
sdo-impl and all of its dependencies are on the Manifest Class-Path
for the launcher jar:
Class-Path: ../lib/sca-api-r0.95-1.0-incubator-M2.jar ...
You will need to add the two StAX jars to that. There are two
workarounds I can think of:
1. extract the MANIFEST.MF, add the two jars to the Class-Path entry
and repack the jar
2. run from the command line with
java --classpath ${sca.home}/bin/launcher.jar:${sca.home}/boot/stax-
api-1.0.1.jar:${sca.home}/wstx-asl-3.2.0.jar \
-Dtuscany.installDir=${sca.home} \
org.apache.tuscany.launcher.MainLauncherBooter ...
HTH
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
I do not try the 1st cause the 2nd seems smarter.
It seems easier to do with an ant script :-)
So, the 2nd solution works fine. Thanks !!
I have added -Doffline=true to bypass maven update check.
Ok, now I have a classCastException because the return object of the
proxy is a DynamicDataObjectImpl
instead of my SDO generated object.
Here the stackTrace :
Exception in thread main java.lang.ClassCastException:
org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
at $Proxy19.getOperations(Unknown Source)
at scabank.ClientComponent.getOperations(Unknown Source)
at scabank.ClientImpl.main(Unknown Source)
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:585)
at
org.apache.tuscany.launcher.MainLauncherBooter.runApplication(MainLauncherBooter.java:107)
at
org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:88)
I will take a look at this on Monday but if someone know where does it
may come from, please reply :-)
thanks again,
have a nice week-end.
--
Guillaume.
sdo-impl and all of its dependencies are on the Manifest Class-Path
for the launcher jar:
Class-Path: ../lib/sca-api-r0.95-1.0-incubator-M2.jar ...
You will need to add the two StAX jars to that. There are two
workarounds I can think of:
1. extract the MANIFEST.MF, add the two jars to the Class-Path entry
and repack the jar
2. run from the command line with
java --classpath
${sca.home}/bin/launcher.jar:${sca.home}/boot/stax-api-1.0.1.jar:${sca.home}/wstx-asl-3.2.0.jar
\
-Dtuscany.installDir=${sca.home} \
org.apache.tuscany.launcher.MainLauncherBooter ...
HTH
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
On Mar 2, 2007, at 9:05 AM, Guillaume Dufrêne wrote: I do not try the 1st cause the 2nd seems smarter. It seems easier to do with an ant script :-) So, the 2nd solution works fine. Thanks !! Phew :-) I have added -Doffline=true to bypass maven update check. Ok, now I have a classCastException because the return object of the proxy is a DynamicDataObjectImpl instead of my SDO generated object. Here the stackTrace : Exception in thread main java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy19.getOperations(Unknown Source) at scabank.ClientComponent.getOperations(Unknown Source) at scabank.ClientImpl.main(Unknown Source) 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:585) at org.apache.tuscany.launcher.MainLauncherBooter.runApplication (MainLauncherBooter.java:107) at org.apache.tuscany.launcher.MainLauncherBooter.main (MainLauncherBooter.java:88) I will take a look at this on Monday but if someone know where does it may come from, please reply :-) I think the static type mapping for SDO may not be set up right but I'll leave that for the SDO folks to comment on. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
On the server side this is a SCA component deployed on tomcat. It exposes a service as a web service. The client side (on which I have this exception) is a standalone program. (like helloworldclientws sample) I run it with the launcher provided with tuscany-sca-java binaries. There's nothing more on the stack trace. I do not register anything ... All the necessary stuff is generated by the tuscany-sdo-tool, no ? Maybe I have missed something on a particular annotation or something like this. It may be that the types need to be be registered (although I would be supprised), is there anything more in the stack trace ? Are you running this in a complex server container (as opposed to tomcat) in which case there may be some classpath issues (depends on which server, eg WAS V 6 etc you may be using)... I believe that I'm right in saying that you don't normally have DynamicDataObjectImpls as it implies that (as Jermey said) that the types are not registered (or not correctly). Regards On 02/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 2, 2007, at 9:05 AM, Guillaume Dufrêne wrote: I do not try the 1st cause the 2nd seems smarter. It seems easier to do with an ant script :-) So, the 2nd solution works fine. Thanks !! Phew :-) I have added -Doffline=true to bypass maven update check. Ok, now I have a classCastException because the return object of the proxy is a DynamicDataObjectImpl instead of my SDO generated object. Here the stackTrace : Exception in thread main java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy19.getOperations(Unknown Source) at scabank.ClientComponent.getOperations(Unknown Source) at scabank.ClientImpl.main(Unknown Source) 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:585) at org.apache.tuscany.launcher.MainLauncherBooter.runApplication (MainLauncherBooter.java:107) at org.apache.tuscany.launcher.MainLauncherBooter.main (MainLauncherBooter.java:88) I will take a look at this on Monday but if someone know where does it may come from, please reply :-) I think the static type mapping for SDO may not be set up right but I'll leave that for the SDO folks to comment on. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
Do you have an import.sdo in you scdl which i think is required to use static SDOs? See the bigbank sample for an example: https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-M2/samples/applications/bigbank/webclient/src/main/webapp/WEB-INF/default.scdl ...ant On 3/2/07, Guillaume Dufrêne [EMAIL PROTECTED] wrote: On the server side this is a SCA component deployed on tomcat. It exposes a service as a web service. The client side (on which I have this exception) is a standalone program. (like helloworldclientws sample) I run it with the launcher provided with tuscany-sca-java binaries. There's nothing more on the stack trace. I do not register anything ... All the necessary stuff is generated by the tuscany-sdo-tool, no ? Maybe I have missed something on a particular annotation or something like this. It may be that the types need to be be registered (although I would be supprised), is there anything more in the stack trace ? Are you running this in a complex server container (as opposed to tomcat) in which case there may be some classpath issues (depends on which server, eg WAS V 6 etc you may be using)... I believe that I'm right in saying that you don't normally have DynamicDataObjectImpls as it implies that (as Jermey said) that the types are not registered (or not correctly). Regards On 02/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 2, 2007, at 9:05 AM, Guillaume Dufrêne wrote: I do not try the 1st cause the 2nd seems smarter. It seems easier to do with an ant script :-) So, the 2nd solution works fine. Thanks !! Phew :-) I have added -Doffline=true to bypass maven update check. Ok, now I have a classCastException because the return object of the proxy is a DynamicDataObjectImpl instead of my SDO generated object. Here the stackTrace : Exception in thread main java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy19.getOperations(Unknown Source) at scabank.ClientComponent.getOperations(Unknown Source) at scabank.ClientImpl.main(Unknown Source) 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:585) at org.apache.tuscany.launcher.MainLauncherBooter.runApplication (MainLauncherBooter.java:107) at org.apache.tuscany.launcher.MainLauncherBooter.main (MainLauncherBooter.java:88) I will take a look at this on Monday but if someone know where does it may come from, please reply :-) I think the static type mapping for SDO may not be set up right but I'll leave that for the SDO folks to comment on. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
Hum, I have a doubt now ... I'm sure I have this into my scdl on the server side but I don't remenber if I have this import into the client scdl. I'm at home now but be sure I will look this monday morning (GMT+1). So, I'll send something soon ;-) Have a nice week-end, Thanks for your help. -- Guillaume. Do you have an import.sdo in you scdl which i think is required to use static SDOs? See the bigbank sample for an example: https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-M2/samples/applications/bigbank/webclient/src/main/webapp/WEB-INF/default.scdl ...ant On 3/2/07, Guillaume Dufrêne [EMAIL PROTECTED] wrote: On the server side this is a SCA component deployed on tomcat. It exposes a service as a web service. The client side (on which I have this exception) is a standalone program. (like helloworldclientws sample) I run it with the launcher provided with tuscany-sca-java binaries. There's nothing more on the stack trace. I do not register anything ... All the necessary stuff is generated by the tuscany-sdo-tool, no ? Maybe I have missed something on a particular annotation or something like this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
When I had this problem, it was indeed because the static types were not being registerred properly. I was able to bypass the problem by using the factory attribute instead of the location attribute and pointed it directly to the static factory I had generated. That is, import.sdo facotry=com.example.MyFactory instead of import.sdolocation=wsdl/myWsdl.wsdl This is consistent with sample-bigbank-account. -Lee On 3/2/07, ant elder [EMAIL PROTECTED] wrote: Do you have an import.sdo in you scdl which i think is required to use static SDOs? See the bigbank sample for an example: https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-M2/samples/applications/bigbank/webclient/src/main/webapp/WEB-INF/default.scdl ...ant On 3/2/07, Guillaume Dufrêne [EMAIL PROTECTED] wrote: On the server side this is a SCA component deployed on tomcat. It exposes a service as a web service. The client side (on which I have this exception) is a standalone program. (like helloworldclientws sample) I run it with the launcher provided with tuscany-sca-java binaries. There's nothing more on the stack trace. I do not register anything ... All the necessary stuff is generated by the tuscany-sdo-tool, no ? Maybe I have missed something on a particular annotation or something like this. It may be that the types need to be be registered (although I would be supprised), is there anything more in the stack trace ? Are you running this in a complex server container (as opposed to tomcat) in which case there may be some classpath issues (depends on which server, eg WAS V 6 etc you may be using)... I believe that I'm right in saying that you don't normally have DynamicDataObjectImpls as it implies that (as Jermey said) that the types are not registered (or not correctly). Regards On 02/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 2, 2007, at 9:05 AM, Guillaume Dufrêne wrote: I do not try the 1st cause the 2nd seems smarter. It seems easier to do with an ant script :-) So, the 2nd solution works fine. Thanks !! Phew :-) I have added -Doffline=true to bypass maven update check. Ok, now I have a classCastException because the return object of the proxy is a DynamicDataObjectImpl instead of my SDO generated object. Here the stackTrace : Exception in thread main java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl at $Proxy19.getOperations(Unknown Source) at scabank.ClientComponent.getOperations(Unknown Source) at scabank.ClientImpl.main(Unknown Source) 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:585) at org.apache.tuscany.launcher.MainLauncherBooter.runApplication (MainLauncherBooter.java:107) at org.apache.tuscany.launcher.MainLauncherBooter.main (MainLauncherBooter.java:88) I will take a look at this on Monday but if someone know where does it may come from, please reply :-) I think the static type mapping for SDO may not be set up right but I'll leave that for the SDO folks to comment on. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
Hum, nice, Thanks for that trick. I'll try this solution too. -- Guillaume. When I had this problem, it was indeed because the static types were not being registerred properly. I was able to bypass the problem by using the factory attribute instead of the location attribute and pointed it directly to the static factory I had generated. That is, import.sdo facotry=com.example.MyFactory instead of import.sdolocation=wsdl/myWsdl.wsdl This is consistent with sample-bigbank-account. -Lee On 3/2/07, ant elder [EMAIL PROTECTED] wrote: Do you have an import.sdo in you scdl which i think is required to use static SDOs? See the bigbank sample for an example: https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-M2/samples/applications/bigbank/webclient/src/main/webapp/WEB-INF/default.scdl ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to package a standalone application.
You will need to have the StAX API and an implementation visible in the same classloader as used for SDO. If you have the SDO impl jars in WEB-INF/lib you should make sure: * stax-api-1.0.1.jar * wstx-asl-3.2.0.jar are in the same place (using the StAX impl from http:// woodstox.codehaus.org). -- Jeremy On Mar 1, 2007, at 4:39 AM, Guillaume Dufrêne wrote: Hi, I try to package a standalone SCA ws-client. I follow the instructions on http://incubator.apache.org/tuscany/ java_sca_overview.html But when I launcher the application an exception occured : Exception in thread main java.lang.NoClassDefFoundError: javax/ xml/stream/XMLStreamException at org.apache.tuscany.sdo.util.SDOUtil.createXMLStreamHelper (SDOUtil.java:338) at org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transfor m(XMLStreamReader2DataObject.java:43) at org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transfor m(XMLStreamReader2DataObject.java:37) at org.apache.tuscany.core.databinding.impl.MediatorImpl.mediate (MediatorImpl.java:95) at org.apache.tuscany.core.databinding.impl.Output2OutputTransformer.tran sform(Output2OutputTransformer.java:176) at org.apache.tuscany.core.databinding.impl.MediatorImpl.mediate (MediatorImpl.java:95) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.transfo rm(DataBindingInteceptor.java:105) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke( DataBindingInteceptor.java:89) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke (AbstractOutboundInvocationHandler.java:60) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke (JDKOutboundInvocationHandler.java:121) at $Proxy19.getOperations(Unknown Source) at scabank.ClientComponent.getOperations(Unknown Source) at scabank.ClientImpl.main(Unknown Source) 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:585) at org.apache.tuscany.launcher.MainLauncherBooter.runApplication (MainLauncherBooter.java:107) at org.apache.tuscany.launcher.MainLauncherBooter.main (MainLauncherBooter.java:88) I have read something about the XMLStreamException dependency on SDO (jira *TUSCANY*-1105) and on http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg14302.html and on http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg12442.html But don't know if my problem is linked to this or how I can solve it. I'm using tuscany-sca M2 binaries for windows, JDK 1.5.06. I hope you can help me. -- Guillaume Dufrene. PhD student at LIFL (France), INRIA ADAM team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
