[ http://issues.apache.org/jira/browse/TUSCANY-217?page=all ]
Jean-Sebastien Delfino resolved TUSCANY-217:
--------------------------------------------
Resolution: Fixed
Jim, your patch didn't really work because there is no guarantee that the
current thread classloader application class loader, in general in the SCA
runtime, the tomcat server classloader is on the thread.
I has to fix the problem differently, by passing the application classloader to
the various methods on WSDLDefinitionRegistry.
This is really just a workaround for now, longer term we'll have to support
application scoped system services.
> 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
