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
