[jira] Closed: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip closed TUSCANY-1814. - Resolution: Fixed Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0.1 Fixed in 1.0.1 Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Assignee: Raymond Feng Fix For: Java-SCA-1.0.1 Attachments: ExampleService.war, Memory Footprint (Startup Profile).png, trninq.zip, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1893) Axis timeout settings are hardcoded at 2 minutes
[ https://issues.apache.org/jira/browse/TUSCANY-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1893: -- Attachment: Axis2BindingInvoker.java Made GLOBAL_AXIS_TIMEOUT a public static so Axis timeout setting can be modified. Axis timeout settings are hardcoded at 2 minutes Key: TUSCANY-1893 URL: https://issues.apache.org/jira/browse/TUSCANY-1893 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat, Windows/Websphere, Solaris/Websphere Reporter: Sunny Ip Priority: Minor Attachments: Axis2BindingInvoker.java The Axis timeout settings should be configurable. A team member put in a quick hack to expose the timeout field as public static. Will attach the class to this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1893) Axis timeout settings are hardcoded at 2 minutes
Axis timeout settings are hardcoded at 2 minutes Key: TUSCANY-1893 URL: https://issues.apache.org/jira/browse/TUSCANY-1893 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat, Windows/Websphere, Solaris/Websphere Reporter: Sunny Ip Priority: Minor The Axis timeout settings should be configurable. A team member put in a quick hack to expose the timeout field as public static. Will attach the class to this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1894) Details of any remote exceptions are lost during web service invocation
[ https://issues.apache.org/jira/browse/TUSCANY-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1894: -- Attachment: RemotableInterfaceTemplate.xsl Details of any remote exceptions are lost during web service invocation --- Key: TUSCANY-1894 URL: https://issues.apache.org/jira/browse/TUSCANY-1894 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat, Windows/Websphere, Solaris/Websphere Reporter: Sunny Ip Priority: Minor Attachments: RemotableInterfaceTemplate.xsl The service interfaces generated from the WSDL2Java generator do not throws RemoteExceptions, so any exceptions will cause an unknown exception with no details. The XSL used by WSDL2Java has been modified to include throws RemoteException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1894) Details of any remote exceptions are lost during web service invocation
Details of any remote exceptions are lost during web service invocation --- Key: TUSCANY-1894 URL: https://issues.apache.org/jira/browse/TUSCANY-1894 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat, Windows/Websphere, Solaris/Websphere Reporter: Sunny Ip Priority: Minor Attachments: RemotableInterfaceTemplate.xsl The service interfaces generated from the WSDL2Java generator do not throws RemoteExceptions, so any exceptions will cause an unknown exception with no details. The XSL used by WSDL2Java has been modified to include throws RemoteException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1884) Allow the setting of the contribution root in the web.xml
[ https://issues.apache.org/jira/browse/TUSCANY-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539095 ] Sunny Ip commented on TUSCANY-1884: --- The location parameter should be pointing at the contribution root (the one that contains the META-INF\sca-contribution.xml) and the scdl file can be anywhere inside the root. We have not tried using a contribution jar, and we can try that as well as trying with the latest trunk code. Allow the setting of the contribution root in the web.xml - Key: TUSCANY-1884 URL: https://issues.apache.org/jira/browse/TUSCANY-1884 Project: Tuscany Issue Type: Improvement Components: Java SCA Web App Integration Affects Versions: Java-SCA-1.0 Environment: Solaris, WebSphere Reporter: Sunny Ip Priority: Minor Attachments: WebAppServletHost.java Currently, the composite file must be located in the classpath, but it is sometime useful to be able to specify the location of the composite file. In our case, we'd like to place it outside of the EAR/WAR so the composite file can be modified for different environments without modifying the EAR/WAR. The attached code allows the servlet/filter to be configured in the web.xml with the path to the contribution root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1884) Allow the setting of the contribution root in the web.xml
Allow the setting of the contribution root in the web.xml - Key: TUSCANY-1884 URL: https://issues.apache.org/jira/browse/TUSCANY-1884 Project: Tuscany Issue Type: Improvement Components: Java SCA Web App Integration Affects Versions: Java-SCA-1.0 Environment: Solaris, WebSphere Reporter: Sunny Ip Priority: Minor Currently, the composite file must be located in the classpath, but it is sometime useful to be able to specify the location of the composite file. In our case, we'd like to place it outside of the EAR/WAR so the composite file can be modified for different environments without modifying the EAR/WAR. The attached code allows the servlet/filter to be configured in the web.xml with the path to the contribution root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1884) Allow the setting of the contribution root in the web.xml
[ https://issues.apache.org/jira/browse/TUSCANY-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1884: -- Attachment: WebAppServletHost.java Allow the setting of the contribution root in the web.xml - Key: TUSCANY-1884 URL: https://issues.apache.org/jira/browse/TUSCANY-1884 Project: Tuscany Issue Type: Improvement Components: Java SCA Web App Integration Affects Versions: Java-SCA-1.0 Environment: Solaris, WebSphere Reporter: Sunny Ip Priority: Minor Attachments: WebAppServletHost.java Currently, the composite file must be located in the classpath, but it is sometime useful to be able to specify the location of the composite file. In our case, we'd like to place it outside of the EAR/WAR so the composite file can be modified for different environments without modifying the EAR/WAR. The attached code allows the servlet/filter to be configured in the web.xml with the path to the contribution root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532470 ] Sunny Ip commented on TUSCANY-1814: --- There was no stacktrace in the console, but stepping into the code, I see this as the cause: org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:163) at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:51) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:223) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:304) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:77) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3600) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4193) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:904) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:867) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) 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.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getElement(WSDLOperationIntrospectorImpl.java:219) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.access$000(WSDLOperationIntrospectorImpl.java:62) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl$WSDLPart.init(WSDLOperationIntrospectorImpl.java:260) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getMessageType(WSDLOperationIntrospectorImpl.java:186) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getInputType(WSDLOperationIntrospectorImpl.java:128) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getOperation(WSDLOperationIntrospectorImpl.java:206) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceIntrospectorImpl.introspectOperations(WSDLInterfaceIntrospectorImpl.java:50) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceIntrospectorImpl.introspectPortType(WSDLInterfaceIntrospectorImpl.java:57) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLFactoryImpl.createWSDLInterface(WSDLFactoryImpl.java:51) at org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolveWSDLInterface(WSDLInterfaceProcessor.java:152) at org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolve(WSDLInterfaceProcessor.java:168) at org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolve(WSDLInterfaceProcessor.java:43) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211) at
[jira] Updated: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1814: -- Attachment: trninq.zip Attached a zip containing a single wsdl and the dependent schemas. The elements and import statement in the included schema are not read properly when the TuscanyServletFilter starts. Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: Memory Footprint (Startup Profile).png, trninq.zip, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1814: -- Attachment: wsdl.zip Noticed another problem caused by this change. When I have a wsdl that includes an xsd that imports another xsd, the TuscanyServletFilter fails to start (console shows SEVERE: Error filterStart) with this change. Going back to Tuscany 1.0 works fine. I have modified and included a wsdl that has this structure. Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Fix For: Java-SCA-Next Attachments: Memory Footprint (Startup Profile).png, wsdl.zip, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1814: -- Attachment: wsdl.zip Reposting with license to ASF Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Fix For: Java-SCA-Next Attachments: Memory Footprint (Startup Profile).png, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1814: -- Attachment: (was: wsdl.zip) Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Fix For: Java-SCA-Next Attachments: Memory Footprint (Startup Profile).png, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1814: -- Attachment: (was: wsdl.zip) Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Fix For: Java-SCA-Next Attachments: Memory Footprint (Startup Profile).png, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532264 ] Sunny Ip commented on TUSCANY-1814: --- Yes I have. That fixed being able to query with ?wsdl using the original wsdl and xsd, but had no impact on getting a wsdl that includes an xsd that imports another xsd breaking Tuscany startup. Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Fix For: Java-SCA-Next Attachments: Memory Footprint (Startup Profile).png, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531941 ] Sunny Ip commented on TUSCANY-1814: --- I applied the fix (along with the fix for TUSCANY-1821) and preliminary testing looks very encouraging. There was an immediate drop in memory consumption and adding additional services did not increase the memory footprint significantly at all. We will test more thoroughly and followup with more information. Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Fix For: Java-SCA-Next Attachments: Memory Footprint (Startup Profile).png, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531943 ] Sunny Ip commented on TUSCANY-1814: --- And regarding the IFX license, here is a link to IFX's license agreement: http://www.ifxforum.org/standards/standard/license I am unfamiliar with the Apache license, does this look acceptable for what we need? Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Fix For: Java-SCA-Next Attachments: Memory Footprint (Startup Profile).png, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1814: -- Attachment: wsdl.zip Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Attachments: wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Attachments: wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1814: -- Attachment: Memory Footprint (Startup Profile).png A graph created from a memory profiler. This was taken from a Websphere installation with Spring loading SDO objects defined as beans, followed by Tuscany servlet startup. The blue is actual memory used while the yellow is memory allocated. Large memory footprint with large wsdl/schemas -- Key: TUSCANY-1814 URL: https://issues.apache.org/jira/browse/TUSCANY-1814 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Environment: Windows/Tomcat Reporter: Sunny Ip Attachments: Memory Footprint (Startup Profile).png, wsdl.zip Creating services and components based on large wsdl/schemas (SDO generation/databinding, ws binding, etc.) results in very high memory footprint. Attaching sample wsdls that make use of the very large schema that we are using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
[ https://issues.apache.org/jira/browse/TUSCANY-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1541: -- Attachment: ifx-ws-sdo.zip Here is a sample unit test that illustrates the problem. XMLStreamException in when calling XMLHelper.load() with a large XML Key: TUSCANY-1541 URL: https://issues.apache.org/jira/browse/TUSCANY-1541 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: Tomcat Reporter: Sunny Ip Assignee: Raymond Feng Priority: Critical Fix For: Java-SCA-Next Attachments: ifx-ws-sdo.zip When XMLHelper.load() is called with a very long XML string, OMStAXWrapper throws an XMLStreamException. I get this problem when I'm receiving a WS response with an SDO object containing a collection of records, leading to a TransformationException when databinding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
[ https://issues.apache.org/jira/browse/TUSCANY-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521168 ] Sunny Ip commented on TUSCANY-1541: --- Looking at the javadocs for Axis2: http://ws.apache.org/axis2/1_2/api/org/apache/axis2/client/OperationClient.html#complete(org.apache.axis2.context.MessageContext it says DO NOT call this method if you are not using two transports to send and receive. I wasn't sure if Tuscany is using two transports, but I tried to remove operation.complete(), and my client stops working after two invocations. If we need to call complete, then the entire XML will have to be parsed before we can call complete, which seems to negate the advantages of using StAX. Can somebody shed some light on this? XMLStreamException in when calling XMLHelper.load() with a large XML Key: TUSCANY-1541 URL: https://issues.apache.org/jira/browse/TUSCANY-1541 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Affects Versions: Java-SDO-Next Environment: Tomcat Reporter: Sunny Ip Priority: Critical Fix For: Java-SDO-Next When XMLHelper.load() is called with a very long XML string, OMStAXWrapper throws an XMLStreamException. I get this problem when I'm receiving a WS response with an SDO object containing a collection of records, leading to a TransformationException when databinding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
[
https://issues.apache.org/jira/browse/TUSCANY-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521011
]
Sunny Ip commented on TUSCANY-1541:
---
We have found the line that causes this exception, in the invokeTarget() method
of Axis2BindingInvoker:
protected Object invokeTarget(final Object payload, final
ConversationSequence sequence, String conversationId)
throws InvocationTargetException {
try {
Object[] args = (Object[])payload;
OperationClient operationClient = createOperationClient(args,
conversationId);
// ensure connections are tracked so that they can be closed by the
reference binding
MessageContext requestMC =
operationClient.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.TRUE);
requestMC.getOptions().setTimeOutInMilliSeconds(12L);
operationClient.execute(true);
MessageContext responseMC =
operationClient.getMessageContext(WSDLConstants.MESSAGE_LABEL_IN_VALUE);
operationClient.complete(requestMC);
return responseMC.getEnvelope().getBody().getFirstElement();
} catch (AxisFault e) {
throw new InvocationTargetException(e);
}
}
The culprit is the operation.complete() method being called too early before
the message is fully loaded. If I do a responseMC.getEnvelope().toString()
before the complete, everything works fine. Without that change, long complex
XML messages trigger the exception.
XMLStreamException in when calling XMLHelper.load() with a large XML
Key: TUSCANY-1541
URL: https://issues.apache.org/jira/browse/TUSCANY-1541
Project: Tuscany
Issue Type: Bug
Components: Java SCA Problem Determination
Affects Versions: Java-SDO-Next
Environment: Tomcat
Reporter: Sunny Ip
Priority: Critical
Fix For: Java-SDO-Next
When XMLHelper.load() is called with a very long XML string, OMStAXWrapper
throws an XMLStreamException. I get this problem when I'm receiving a WS
response with an SDO object containing a collection of records, leading to a
TransformationException when databinding.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
[ https://issues.apache.org/jira/browse/TUSCANY-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520416 ] Sunny Ip commented on TUSCANY-1541: --- I wasn't sure what the best way of getting all the various classes initialized outside of the SCA environment was, so this is what I did to try to simulate the serialize/deserialize process: /* populate response */ String responseStr = XMLHelper.INSTANCE.save((DataObject)response,http://namespace,ResponseType;); XMLStreamHelperImpl strHelper = new XMLStreamHelperImpl(HelperProvider.getDefaultContext()); XMLDocument doc = XMLHelper.INSTANCE.load(responseStr); XMLStreamReader reader = strHelper.createXMLStreamReader(doc); reader.next(); DataObject obj = strHelper.loadObject(reader); return response; after populating response (which is an SDO generated object) with a collection of child SDO objects in my service impl, which is a component in the SCADomain. This succeeded without any problems, and the resulting DataObject looked fine. However, I return the original response back to the invoking client (through a web service binding) and get the XMLStreamException. If the collection in my response contains less objects, then everything works fine. When I have more than 30 (in this case) objects in the collection, manually calling XMLStreamHelper works but the invoking client fails. XMLStreamException in when calling XMLHelper.load() with a large XML Key: TUSCANY-1541 URL: https://issues.apache.org/jira/browse/TUSCANY-1541 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Environment: Tomcat Reporter: Sunny Ip Priority: Critical Fix For: Java-SDO-Next When XMLHelper.load() is called with a very long XML string, OMStAXWrapper throws an XMLStreamException. I get this problem when I'm receiving a WS response with an SDO object containing a collection of records, leading to a TransformationException when databinding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
XMLStreamException in when calling XMLHelper.load() with a large XML Key: TUSCANY-1541 URL: https://issues.apache.org/jira/browse/TUSCANY-1541 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Environment: Tomcat Reporter: Sunny Ip Priority: Critical When XMLHelper.load() is called with a very long XML string, OMStAXWrapper throws an XMLStreamException. I get this problem when I'm receiving a WS response with an SDO object containing a collection of records, leading to a TransformationException when databinding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
[ https://issues.apache.org/jira/browse/TUSCANY-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520146 ] Sunny Ip commented on TUSCANY-1541: --- Here is the stacktrace. I misread it and the problem actually isn't coming from XMLHelper.load(), but XMLDocumentImpl.load(). Exception org.apache.tuscany.sca.databinding.TransformationException Exception message: org.apache.tuscany.sca.databinding.TransformationException: javax.xml.stream.XMLStreamException org.apache.tuscany.sca.databinding.TransformationException: org.apache.tuscany.sca.databinding.TransformationException: javax.xml.stream.XMLStreamException at org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:181) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:77) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.transform(DataTransformationInteceptor.java:168) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:152) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy11.DepAcctTrnInq(Unknown Source) at com.bns.soa.mci.svc.actvb.trninq.TrnInqClient.DepAcctTrnInq(TrnInqClient.java:22) 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.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy11.DepAcctTrnInq(Unknown Source) at org.apache.jsp.DepAcctTrnInqTest_jsp._jspService(DepAcctTrnInqTest_jsp.java:222) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.tuscany.sca.databinding.TransformationException: javax.xml.stream.XMLStreamException at org.apache.tuscany.sca.databinding.sdo.XMLStreamReader2DataObject.transform(XMLStreamReader2DataObject.java:50) at
[jira] Created: (TUSCANY-1490) Compile error when generating a schema with a dependency on another schema with the same leaf element name
Compile error when generating a schema with a dependency on another schema with the same leaf element name -- Key: TUSCANY-1490 URL: https://issues.apache.org/jira/browse/TUSCANY-1490 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SDO-Next Reporter: Sunny Ip When generating SDO classes using XSD2JavaGenerator, the FactoryImpl generated from a schema with a dependency on another schema with the same leaf element name (e.g. http://sample/helloworld and http://sample/type/helloworld) results in a compile error in the init() method, where the full package name (including .) is used as part of the variable name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1490) Compile error when generating a schema with a dependency on another schema with the same leaf element name
[ https://issues.apache.org/jira/browse/TUSCANY-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1490: -- Attachment: helloworld.xsd helloworld.wsdl Including a wsdl/xsd that illustrates the problem Compile error when generating a schema with a dependency on another schema with the same leaf element name -- Key: TUSCANY-1490 URL: https://issues.apache.org/jira/browse/TUSCANY-1490 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SDO-Next Reporter: Sunny Ip Attachments: helloworld.wsdl, helloworld.xsd When generating SDO classes using XSD2JavaGenerator, the FactoryImpl generated from a schema with a dependency on another schema with the same leaf element name (e.g. http://sample/helloworld and http://sample/type/helloworld) results in a compile error in the init() method, where the full package name (including .) is used as part of the variable name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1490) Compile error when generating a schema with a dependency on another schema with the same leaf element name
[ https://issues.apache.org/jira/browse/TUSCANY-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1490: -- Attachment: SDOFactoryClass.java Compile error when generating a schema with a dependency on another schema with the same leaf element name -- Key: TUSCANY-1490 URL: https://issues.apache.org/jira/browse/TUSCANY-1490 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SDO-Next Reporter: Sunny Ip Attachments: helloworld.wsdl, helloworld.xsd, SDOFactoryClass.java When generating SDO classes using XSD2JavaGenerator, the FactoryImpl generated from a schema with a dependency on another schema with the same leaf element name (e.g. http://sample/helloworld and http://sample/type/helloworld) results in a compile error in the init() method, where the full package name (including .) is used as part of the variable name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1490) Compile error when generating a schema with a dependency on another schema with the same leaf element name
[ https://issues.apache.org/jira/browse/TUSCANY-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516543 ] Sunny Ip commented on TUSCANY-1490: --- Included a fix to SDOFactoryClass that replaces the . with _. Compile error when generating a schema with a dependency on another schema with the same leaf element name -- Key: TUSCANY-1490 URL: https://issues.apache.org/jira/browse/TUSCANY-1490 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SDO-Next Reporter: Sunny Ip Attachments: helloworld.wsdl, helloworld.xsd, SDOFactoryClass.java When generating SDO classes using XSD2JavaGenerator, the FactoryImpl generated from a schema with a dependency on another schema with the same leaf element name (e.g. http://sample/helloworld and http://sample/type/helloworld) results in a compile error in the init() method, where the full package name (including .) is used as part of the variable name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1490) Compile error when generating a schema with a dependency on another schema with the same leaf element name
[ https://issues.apache.org/jira/browse/TUSCANY-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1490: -- Priority: Minor (was: Major) Compile error when generating a schema with a dependency on another schema with the same leaf element name -- Key: TUSCANY-1490 URL: https://issues.apache.org/jira/browse/TUSCANY-1490 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SDO-Next Reporter: Sunny Ip Priority: Minor Attachments: helloworld.wsdl, helloworld.xsd, SDOFactoryClass.java When generating SDO classes using XSD2JavaGenerator, the FactoryImpl generated from a schema with a dependency on another schema with the same leaf element name (e.g. http://sample/helloworld and http://sample/type/helloworld) results in a compile error in the init() method, where the full package name (including .) is used as part of the variable name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1491) Sample showing SDO and web service, running in a web app
Sample showing SDO and web service, running in a web app Key: TUSCANY-1491 URL: https://issues.apache.org/jira/browse/TUSCANY-1491 Project: Tuscany Issue Type: New Feature Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: Tested on Windows/Tomcat environment Reporter: Sunny Ip Priority: Minor Fix For: Java-SCA-Next Attachments: helloworld-ws-sdo-webapp.zip Created a sample that used SDO and web services that was deployable to a web container. The sample also includes some schema inheritance, as that was the scenario we wanted to test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1491) Sample showing SDO and web service, running in a web app
[ https://issues.apache.org/jira/browse/TUSCANY-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1491: -- Attachment: helloworld-ws-sdo-webapp.zip Sample showing SDO and web service, running in a web app Key: TUSCANY-1491 URL: https://issues.apache.org/jira/browse/TUSCANY-1491 Project: Tuscany Issue Type: New Feature Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: Tested on Windows/Tomcat environment Reporter: Sunny Ip Priority: Minor Fix For: Java-SCA-Next Attachments: helloworld-ws-sdo-webapp.zip Created a sample that used SDO and web services that was deployable to a web container. The sample also includes some schema inheritance, as that was the scenario we wanted to test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1199) ClassCastException when getting back a type extended from anything besides a string
[ https://issues.apache.org/jira/browse/TUSCANY-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip closed TUSCANY-1199. - Resolution: Invalid Didn't realize this was still open. We found that the generated factory was not referenced in the composite file using dbsdo:import.sdo. I believe this should no longer be an issue. ClassCastException when getting back a type extended from anything besides a string --- Key: TUSCANY-1199 URL: https://issues.apache.org/jira/browse/TUSCANY-1199 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Integration Affects Versions: Java-SCA-M2 Environment: Apache Tomcat 5.5.17 Reporter: Sunny Ip Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: AccountHistoryService.wsdl, default.scdl Originally posted under SDO Implementation, but it was suggested it may be an SCA proxy problem: In my client code (originating from a JSP), whenever I am expecting a return type that extends anything but a string (tried so far with boolean, int, double, decimal, long), I get the following when I call my service: java.lang.ClassCastException: java.lang.String $Proxy34.getAccountBalance(Unknown Source) com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) Here is a snippet from a WSDL file that is being used: xs:schema xmlns:sample=http://sample; targetNamespace=http://sample; xsd:element name=getAccountBalance xsd:complexType xsd:sequence xsd:element name=accountNumber type=sample:AccountNumber / /xs:sequence /xsd:complexType /xsd:element xsd:element name=getAccountBalanceResponse xsd:complexType xsd:sequence xsd:element name=return type=sample:Dollars / /xsd:sequence /xsd:complexType /xsd:element xsd:simpleType name=Dollars xsd:restriction base=xsd:double xsd:minInclusive value=0 / /xsd:restriction /xsd:simpleType /xsd:schema with everything else exactly the same, changing the return type for getAccountBalanceResponse from sample:Dollars to xsd:double makes everything work fine. I have attached the wsdl and scdl (client side) files for reference. To reproduce: 1) create/generate classes to implement and consume the service described by the wsdl 2) expose the service in your scdl 3) call the getAccountBalance operation The crash will occur after the method on the service side is complete, but before the client gets a response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1198) ClassCastException when getting back a type extended from anything besides a string
ClassCastException when getting back a type extended from anything besides a string --- Key: TUSCANY-1198 URL: https://issues.apache.org/jira/browse/TUSCANY-1198 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: Apache Tomcat 5.5.17 Reporter: Sunny Ip In my client code (calling from a JSP), whenever I am expecting a return type that extends anything but a string (tried so far with boolean, int, double, decimal, long), I get the following: java.lang.ClassCastException: java.lang.String $Proxy34.getAccountBalance(Unknown Source) com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) Here is a snippet from a WSDL file that is being used: xs:schema xmlns:sample=http://sample; targetNamespace=http://sample; xsd:element name=getAccountBalance xsd:complexType xsd:sequence xsd:element name=accountNumber type=sample:AccountNumber / /xs:sequence /xsd:complexType /xsd:element xsd:element name=getAccountBalanceResponse xsd:complexType xsd:sequence xsd:element name=return type=sample:Dollars / /xsd:sequence /xsd:complexType /xsd:element xsd:simpleType name=Dollars xsd:restriction base=xsd:double xsd:minInclusive value=0 / /xsd:restriction /xsd:simpleType /xsd:schema with everything else exactly the same, changing the return type for getAccountBalanceResponse from sample:Dollars to xsd:double makes everything work fine. However, I need to be able to handle these kinds of extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1198) ClassCastException when getting back a type extended from anything besides a string
[ https://issues.apache.org/jira/browse/TUSCANY-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1198: -- Attachment: AccountHistoryService.wsdl ClassCastException when getting back a type extended from anything besides a string --- Key: TUSCANY-1198 URL: https://issues.apache.org/jira/browse/TUSCANY-1198 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: Apache Tomcat 5.5.17 Reporter: Sunny Ip Attachments: AccountHistoryService.wsdl In my client code (calling from a JSP), whenever I am expecting a return type that extends anything but a string (tried so far with boolean, int, double, decimal, long), I get the following: java.lang.ClassCastException: java.lang.String $Proxy34.getAccountBalance(Unknown Source) com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) Here is a snippet from a WSDL file that is being used: xs:schema xmlns:sample=http://sample; targetNamespace=http://sample; xsd:element name=getAccountBalance xsd:complexType xsd:sequence xsd:element name=accountNumber type=sample:AccountNumber / /xs:sequence /xsd:complexType /xsd:element xsd:element name=getAccountBalanceResponse xsd:complexType xsd:sequence xsd:element name=return type=sample:Dollars / /xsd:sequence /xsd:complexType /xsd:element xsd:simpleType name=Dollars xsd:restriction base=xsd:double xsd:minInclusive value=0 / /xsd:restriction /xsd:simpleType /xsd:schema with everything else exactly the same, changing the return type for getAccountBalanceResponse from sample:Dollars to xsd:double makes everything work fine. However, I need to be able to handle these kinds of extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1199) ClassCastException when getting back a type extended from anything besides a string
ClassCastException when getting back a type extended from anything besides a string --- Key: TUSCANY-1199 URL: https://issues.apache.org/jira/browse/TUSCANY-1199 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Runtime Affects Versions: Java-M2 Environment: Apache Tomcat 5.5.17 Reporter: Sunny Ip Originally posted under SDO Implementation, but it was suggested it may be an SCA proxy problem: In my client code (originating from a JSP), whenever I am expecting a return type that extends anything but a string (tried so far with boolean, int, double, decimal, long), I get the following when I call my service: java.lang.ClassCastException: java.lang.String $Proxy34.getAccountBalance(Unknown Source) com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) Here is a snippet from a WSDL file that is being used: xs:schema xmlns:sample=http://sample; targetNamespace=http://sample; xsd:element name=getAccountBalance xsd:complexType xsd:sequence xsd:element name=accountNumber type=sample:AccountNumber / /xs:sequence /xsd:complexType /xsd:element xsd:element name=getAccountBalanceResponse xsd:complexType xsd:sequence xsd:element name=return type=sample:Dollars / /xsd:sequence /xsd:complexType /xsd:element xsd:simpleType name=Dollars xsd:restriction base=xsd:double xsd:minInclusive value=0 / /xsd:restriction /xsd:simpleType /xsd:schema with everything else exactly the same, changing the return type for getAccountBalanceResponse from sample:Dollars to xsd:double makes everything work fine. I have attached the wsdl and scdl (client side) files for reference. To reproduce: 1) create/generate classes to implement and consume the service described by the wsdl 2) expose the service in your scdl 3) call the getAccountBalance operation The crash will occur after the method on the service side is complete, but before the client gets a response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1199) ClassCastException when getting back a type extended from anything besides a string
[ https://issues.apache.org/jira/browse/TUSCANY-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1199: -- Attachment: AccountHistoryService.wsdl default.scdl ClassCastException when getting back a type extended from anything besides a string --- Key: TUSCANY-1199 URL: https://issues.apache.org/jira/browse/TUSCANY-1199 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Runtime Affects Versions: Java-M2 Environment: Apache Tomcat 5.5.17 Reporter: Sunny Ip Attachments: AccountHistoryService.wsdl, default.scdl Originally posted under SDO Implementation, but it was suggested it may be an SCA proxy problem: In my client code (originating from a JSP), whenever I am expecting a return type that extends anything but a string (tried so far with boolean, int, double, decimal, long), I get the following when I call my service: java.lang.ClassCastException: java.lang.String $Proxy34.getAccountBalance(Unknown Source) com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) Here is a snippet from a WSDL file that is being used: xs:schema xmlns:sample=http://sample; targetNamespace=http://sample; xsd:element name=getAccountBalance xsd:complexType xsd:sequence xsd:element name=accountNumber type=sample:AccountNumber / /xs:sequence /xsd:complexType /xsd:element xsd:element name=getAccountBalanceResponse xsd:complexType xsd:sequence xsd:element name=return type=sample:Dollars / /xsd:sequence /xsd:complexType /xsd:element xsd:simpleType name=Dollars xsd:restriction base=xsd:double xsd:minInclusive value=0 / /xsd:restriction /xsd:simpleType /xsd:schema with everything else exactly the same, changing the return type for getAccountBalanceResponse from sample:Dollars to xsd:double makes everything work fine. I have attached the wsdl and scdl (client side) files for reference. To reproduce: 1) create/generate classes to implement and consume the service described by the wsdl 2) expose the service in your scdl 3) call the getAccountBalance operation The crash will occur after the method on the service side is complete, but before the client gets a response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
