Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Short version: does Terracotta support custom XmlWebApplicationContexts, and how exactly is the "path" element used in the Terracotta Spring config?

Long version:
I notice that the Terracotta Spring config uses the path of the application context xml. For example:
Code:

<!-- tc:config/application/spring/jee-application --> 
 <application-contexts> 
   <application-context> 
      <paths> 
         <path>config/inventory-bean-config.xml</path> 
      </paths> 
   <application-context> 
 <application-contexts>

However, I'm using a custom class that extends XmlWebApplicationContext. The main thing this class does is test its environment and conditionally add path locations.

So, I have this in my web.xml:
Code:

  <context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>/WEB-INF/applicationContext.xml</param-value>
   </context-param>
 
   <context-param>
     <param-name>contextClass</param-name>
     <param-value>com...util.spring.ConditionalConfigurationXmlWebApplicationContext</param-value>
   </context-param>

Now, my "ConditionalConfigurationXmlWebApplicationContext" overrides the "refresh()" method, where it will test its environment and possibly modify the "configLocations" before invoking super.refresh(). For example, if the system is running in "test" mode, then it would do something like:
Code:

  ...
   String[] locations = getConfigLocations();
   locations = append(locations, "classpath*:/META-INF/config/service-module-test-only.xml");
   setConfigLocations(locations);
   ...
   super.refresh();

What would I put for the "path" element in Terracotta's config? Does Terracotta even support this sort of thing?

Thanks!

We don't really hook into specific class. So, any subclass of AbstractRefreshableApplicationContext should work if they don't change context initialization too much.

You can see exact advices applied to Spring code in the com.tc.object.config.SpringAspectModule class. For the part relevant to your question, we intercept BeanDefinitionReader+.loadBeanDefinitions() call and save resource names. See com.tcspring.BeanDefinitionProtocol.captureIdentity() method for more details how resource names are retrieved.

So, you should be able to specify something like */WEB-INF/applicationContext.xml or */applicationContext.xml to help with matching. You should be also see exact names for those resources if you enable debug logging for org.springframework and com.tcspring classes (i.e. using commons-logging configuration).