Tomcat as an Infrastructure Provider (in Test)
i had an interesting requirement come across my desk the other day for a testing scenario in Tomcat that involved a 'foolish' integration test. that is, 2x applications deployed in Tomcat sharing a single database and a JMS queue server. so, i tried the usual H2 and AMQ including their infrastructure pieces but didn't have any joy. generally speaking, startup order got me as both applications expected the infrastructure to be there, and when trying to have them 'create the missing components', it failed.
so, to counter that, a colleague suggested using the Tomcat container itself to initialize the infrastructure before the applications. this kind of brings it inline with the production environment so we had a dig into it. one of the things that struck me is that we were trying to piece together technology pieces that are quite easy and accessible in Spring (multiple implementations of a common interface, database script coordination and installation). so, i've taken the concept a little further and created a simple listener project up on github called catalina-spring-listener.
the basis behind the project is that the tomcat container initializes an application context upon the configure event in it's lifecycle. this allows the application context to startup various services and access all Springs goodness as a separate app before anything else starts up.
so, why Spring in a lifecycle? why not a separate WAR? mainly startup order. by having just tow different machines available (one vastly slower than the other) we could effectively demonstrate that startup order was unreliable and can unwittingly generate race conditions. by why Spring? why re-invent the wheel? Spring's got most of these things in place and most of the infrastructure vendors have spring hooks. so, launch an app context, and then let Spring do the rest.
if you want the project to look at, it's here… https://github.com/incomplete-code/catalina-spring-listener
so, to counter that, a colleague suggested using the Tomcat container itself to initialize the infrastructure before the applications. this kind of brings it inline with the production environment so we had a dig into it. one of the things that struck me is that we were trying to piece together technology pieces that are quite easy and accessible in Spring (multiple implementations of a common interface, database script coordination and installation). so, i've taken the concept a little further and created a simple listener project up on github called catalina-spring-listener.
the basis behind the project is that the tomcat container initializes an application context upon the configure event in it's lifecycle. this allows the application context to startup various services and access all Springs goodness as a separate app before anything else starts up.
so, why Spring in a lifecycle? why not a separate WAR? mainly startup order. by having just tow different machines available (one vastly slower than the other) we could effectively demonstrate that startup order was unreliable and can unwittingly generate race conditions. by why Spring? why re-invent the wheel? Spring's got most of these things in place and most of the infrastructure vendors have spring hooks. so, launch an app context, and then let Spring do the rest.
if you want the project to look at, it's here… https://github.com/incomplete-code/catalina-spring-listener
No comments:
Post a Comment