[ http://issues.apache.org/jira/browse/TUSCANY-217?page=all ]
Jean-Sebastien Delfino updated TUSCANY-217:
-------------------------------------------
Assign To: Jim Marino (was: Rick Rineholt)
Priority: Critical (was: Minor)
This is actually a critical issue... WSDLs from different applications collide
in the WSDLDefinitionRegistry singleton and this is very confusing.
Jim and I discussed this issue yesterday. The problem is that there is a single
instance of the WSDLDefinitionRegistry and therefore one WSDL definition cache
for the whole Tuscany runtime. Instead what we need is an instance per
application...
Jim, I'm assigning this one to you because you may find an easy way to fix or
workaround this issue. If you find a way in the runtime to scope the
WSDLDefinitionRegistry per application then great! otherwise we'll have to
maintain a per-app cache in WSDLDefinitionRegistry and pass the app "key" to
the methods that populate or query the cache...
> 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: M1
> Environment: Windows - Tomcat - April 17th download of Tuscany SVN
> Reporter: Scott Kurz
> Assignee: Jim Marino
> Priority: Critical
> Fix For: 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
