• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • SpringRuntime
  • drb
  • Reporter: javaguy4
  • December 17, 2007
  • 0
  • Watchers: 0
  • April 10, 2009
  • February 04, 2008

Attachments

Description

Tc spring does not pick up spring contexts as distributed when:

  1. tc-config.xml is set as normal like: resources/applicationContext-business-core.xml resources/applicationContext-resources-core.xml resources/applicationContext-cdsweb-client.xml resources/applicationContext-services-core.xml resources/applicationContext-python.xml resources/applicationContext-grid.xml

  2. web.xml spring contexts are set in valid format. notice that there is an * after classpath

    contextConfigLocation classpath*:/resources/applicationContext-business-core.xml classpath*:/resources/applicationContext-resources-core.xml classpath*:/resources/applicationContext-cdsweb-client.xml classpath*:/resources/applicationContext-services-core.xml classpath*:/resources/applicationContext-python.xml classpath*:/resources/applicationContext-grid.xml

  3. what happens is BeanDefinitionProtocol.captureIdentity(xxx) cannot handle a URLResource. As such the context never becoems distributable

Comments

Eugene Kuleshov 2007-12-19

Thanks for the analysys Stanley. I should probably have asked you to submit a patch for this since you obviously dug deep enough to understand what is happening in there. Anyways, I’ve been able to reproduce this and even have a workaround without changes in the code, but clearly the current behaviour is not intuitive.

First of all, BeanDefinitionProtocol.captureIdentity() method does support all subclasses of Resources, so in the worst case it fall into resource.getDescription() call, which will return “URL [actual_url_here]” if resource is an instance of the UrlResource. So you could ajust your matching pattern in tc-config.xml to match that. Something like this would work:

\*resources/applicationContext-business-core.xml\*

I will add an explicit support of the UrlResource to the BeanDefinitionProtocol.captureIdentity() method, then you won’t need to specify trailing “*” in the path element, but you’ll still need the leading “*” because it will have the full path to your resource at runtime.

Now, depends on how your web application is deployed on a cluster the actual resource url can include full path to the web application war file, and that path can be different between cluster nodes, so resource urls won’t be the same and in result synthetic identity generated for application context also won’t be the same.

To work around that you can specify element in tc-config.xml. For example:

…

urlResource *com/tctest/spring/beanfactory.xml* ... </div> {:.comment-heading} ### **Eugene Kuleshov** 2007-12-19

Fiona, Alex, can you please tell me if code change for this need to go into the 2.5 branch or it is enough to make it in the trunk only?

{:.comment-heading} ### **Eugene Kuleshov** 2008-02-04

Fixed while ago