Thanks, the patch is now attached to https://issues.apache.org/jira/browse/TUSCANY-3069.
From: Ramkumar R Sent: Wednesday, June 17, 2009 4:07 AM To: [email protected] Subject: Re: How to resolve @location for implementation.spring? Hi Raymond, Yeah, I would like to have the patch you have created to deal with the class loader issue. I will work on the itests to make sure that all the xml files are available from within the contribution. On Mon, Jun 15, 2009 at 9:50 PM, Raymond Feng <[email protected]> wrote: Hi, I have a local fix for the first item. It will use the Contribution to resolve the location instead of TCCL. The change triggers some problems with itest-implementation-spring though, which has the context xml files on the classpath but outside the SCA contributions. Ram, do you want to attach the patch so that you can help fix the itests? Thanks, Raymond From: Ramkumar R Sent: Monday, June 08, 2009 9:35 AM To: [email protected] Subject: Re: How to resolve @location for implementation.spring? Hi Raymond, Good catch !!, I just realized that the specs does not recommend the use of @location for a URI to the spring context xml file. But the interesting point is that, support for @location with an external archive/directory is the latest feature addition that we did recently, I believe the use of @location for a URI to the spring context xml file was available since the birth of implementation.spring module. Not sure... Is it good or bad? to support this. Needs a discussion with specs group as well. On Tue, Jun 2, 2009 at 10:14 AM, Raymond Feng <[email protected]> wrote: Hi, I think we have some issues in Tuscany to interpret the @location attribute for <implementation.spring>. The current behavior is that we try to use TTCL.getResource() to find a URL for the location. If it is an XML file, then we take it as the Spring application context. I see two problems: 1) TTCL.getResource() is not reliable. It won't work if the contribution is loaded using a different classloader other than the TCCL. See https://issues.apache.org/jira/browse/TUSCANY-3069. 2) The SCA spec says the location points to an archive or directory where META-INF/MANIFEST.MF and META-INF/spring/*.xml are checked. Isn't a deviation that we use @location as a URI to the spring context xml file? To resolve the location, depending on the scheme of the URI, it can be relative to the current contribution, an external archive/directory or a URI within another contribution. But it shouldn't be checked against the classpath. The itests/spring uses the context files as relative URIs but they are outside the contribution. The following is quoted from the spec: The only part of this that is specific to Spring is the <implementation.spring> element. The location attribute of that element specifies the target uri of an archive file or directory that contains the Spring application context files. The resource paths to the Spring application context configuration files that are used to create the application context are then identified as follows: If the resource identified by the location attribute is an archive file, then the file META-INF/MANIFEST.MF is read from the archive. If the location URI identifies a directory, then META-INF/MANIFEST.MF must exist underneath that directory. If the manifest file contains a header "Spring-Context" of the format: Spring-Context ::= path ( ';' path )* Where path is a relative path with respect to the location URI, then the set of paths specified in the header identify the context configuration files. If there is no MANIFEST.MF file or no Spring-Context header within that file, then the default behaviour is to build an application context using all the *.xml files in the METAINF/ spring directory. Thanks, Raymond -- Thanks & Regards, Ramkumar Ramalingam -- Thanks & Regards, Ramkumar Ramalingam
