[ http://issues.apache.org/jira/browse/TUSCANY-217?page=comments#action_12383257 ]
ant elder commented on TUSCANY-217: ----------------------------------- I've added an app that recreates this problem with bigbank to the sandbox: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/TUSCANY-217/ The war is in the target dir so you don't really need to check the whole thing out and build it. This app has the same bigbank account WSDL but with the endpoint in the WSDL set to http://aBadEndpointURL If this app starts before bigbank webclient then bigbank webclient will fail. The start order is alphabetical named "TUSCANY-217-SNAPSHOT.war" bigbank is fine, rename the war to "aTUSCANY-217-SNAPSHOT.war" and bigbank breaks. Drop the war in C:\SCA\SVN\HEAD\testing\tomcat\target\apache-tomcat-5.5.17\webapps and startup tomcat. Go to http://localhost:8080/bigbank-webclient-SNAPSHOT, logon with test/password, if this war starts first the bigbank should fail with: org.osoa.sca.ServiceUnavailableException: org.osoa.sca.ServiceRuntimeException: org.apache.axis2.AxisFault: aBadEndpointURL; > WSDLDefinition caching allows EntryPoint WS URLs to clobber ExternalService > URLs > --------------------------------------------------------------------------------- > > Key: TUSCANY-217 > URL: http://issues.apache.org/jira/browse/TUSCANY-217 > Project: Tuscany > Type: Improvement > Components: Java SCA Model > Versions: Java-M1 > Environment: Windows - Tomcat - April 17th download of Tuscany SVN > Reporter: Scott Kurz > Assignee: Jim Marino > Priority: Critical > Fix For: Java-M1 > > At a high-level, the problem is just that the URL in the EntryPoint-side WSDL > used in a WS binding.sometimes matters and sometimes does not. When invoking > over a WS binding, it might be nice to say that, although both client and > server have a copy of the WSDL, that only the client URL matters, but not the > server's. > The URL I'm talking about appears in the WSDL's <wsdlsoap:address> tag. > If an ExternalService using a WS binding with the same namespace as the Entry > Point is hosted in the same process as the Entry Point, then the URL used to > invoke the ExternalService will come from whichever WSDL Definition is loaded > first, the EntryPoint's or the ExternalService's. To be sure that the > correct URL is used, you must keep both URLs in synch with the URL > corresponding to the URL at which the app is actually hosted (i.e. the IP > address and port of your Tomcat service, plus your app's context root, plus > the SCA-specific portion of the URL at the end). > If the ExternalService lives in another JVM, however, then the EntryPoint > WSDL's URL is irrelevant for invoking the SCA WS over the External Service WS > binding. Then you only need to synchronize the External Service URL with the > URL at which the app is actually hosted. By adding an External Service into > the same JVM as the SCA WS with Entry Point , then, you all of a sudden make > the Entry Point WSDL's URL relevant. > To recreate this problem, take the HelloWorldWSClient sample, and put a JSP > front-end on it, and package it into a WAR. Then take the HelloWorld WS > sample WAR, and tweak the URL to something that doesn't match your Tomcat > server's URL. > If you install both WARs and you ensure that the newly-created > HelloWorldWSClient WAR starts before the HelloWorld WS WAR (with bad URL), > the sample will work fine... HelloWorldWSClient WAR will call out the WS in > HelloWorld WS. If, however, the apps are started in reverse order, the > garbage URL on the EntryPoint-side will take effect and it don't work. > At a low-level, the problem seems to be the definitionsByNamespace map used > by the method > org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadDefinitions, > which maps namespaces to WSDL Definitions. > > Assuming there is value caching WSDL Definitions per Namespace, maybe the > cache should be implemented such that EntryPoint-side URLs would not take > precedence over an ExternalService-side URL in this manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
