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
Environment: Windows - Tomcat - April 17th download of Tuscany SVN
Reporter: Scott Kurz
Priority: Minor
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
