title: Multiple Spring application contexts using different class loaders?
body: <p>Often people want to have multiple web applications share access to a single application context. How to do that is described e.g. <a href="http://springtips.blogspot.com/2007/06/using-shared-parent-application-context.html" rel="nofollow">here</a>.</p>
  
  <p>This question is about the opposite: having multiple application contexts inside a single web application. Usually this is easy, you just create them and use them.</p>
  
  <p>However there are some situations caused by static variables in Spring aspects where it becomes impossible, such as:</p>
  
  <ul>
  <li>You have two application contexts X and Y, both of which create a <code>MyBean</code> which has a <code>@Transactional</code> annotation</li>
  <li>Both X and Y contain their own transaction managers</li>
  <li>Both X and Y have <code>&lt;tx:annotation-driven mode="aspectj"/&gt;</code> declarations</li>
  <li>You are doing build-time AspectJ weaving</li>
  </ul>
  
  <p>In this case the problem is that the <code>&lt;tx:annotation-driven mode="aspectj"/&gt;</code> is in effect converted into a bean like this:</p>
  
  <pre><code>&lt;bean class="org.springframework.transaction.aspectj.AnnotationTransactionAspect"
    factory-method="aspectOf"/&gt;
  </code></pre>
  
  <p>Note that this returns the aspect object for <code>AnnotationTransactionAspect</code>, which is a singleton stored in a static variable.  <code>AnnotationTransactionAspect</code> extends <code>TransactionAspectSupport</code>, which contains instance fields that e.g. cache the transaction manager.</p>
  
  <p>The effect is that even though the beans in X and Y are totally separated, they will be fighting over the same instance fields in the <code>AnnotationTransactionAspect</code> aspect singleton. This causes e.g. "no transaction is in progress" exceptions because somebody gets the wrong transaction manager.</p>
  
  <p>The same thing happens with <code>@Configurable</code>: the bean factory used to configure beans is stored in a static variable (see <code>AnnotationBeanConfigurerAspect.beanConfigurerSupport</code>). This is more of a problem, because you can avoid AspectJ with <code>@Transactional</code>, but you can't avoid it with <code>@Configurable</code>.</p>
  
  <p>I can think of three solutions:</p>
  
  <ol>
  <li>Stop using aspects</li>
  <li>Write my own aspect</li>
  <li>Create/set new context class loaders in the threads that create X and Y</li>
  </ol>
  
  <p>Option #1 is bad because I really like <code>@Configurable</code>.</p>
  
  <p>Option #2 does not look like fun.</p>
  
  <p>Option #3 looks like the easy way out.</p>
  
  <p>So how would option #3 work? This is where I get fuzzy. I would need the Spring classes to be loaded into different class loaders in X and Y. That means the context class loader couldn't delegate normally to it's parent (the web application class loader), etc. How would you set this up?</p>
  
  <p>Thanks.</p>