[jira] Resolved: (TUSCANY-217) WSDLDefinition caching allows EntryPoint WS URLs to clobber ExternalService URLs

["Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>]

     [ 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