My understanding - and this might be wrong - is that the existing DeployerEjb behaves differently to just dropping the .war file in the webapps directory. When we deploy using DeployerEjb, OpenEJB processes the .war file first, and then hands it off to Tomcat. Dropping the war in the webapps folder on the other hand, means Tomcat processes the .war file first and then OpenEJB gets its turn.
I think the goal here is for the TCK to be as close to dropping the archives in the webapps folders as a user would do as possible. All that this deployer is doing is exactly the same thing using Tomcat's own deployer does - upload the .war file, and invoke a check method on the Deployer mbean which returns once the app has deployed. Making this a bit more "hot-deploy" friendly shouldn't be difficult, a quick check to see if the app has already been deployed - if so, undeploy it first. Jon On Mon, Nov 7, 2011 at 12:10 AM, Romain Manni-Bucau <[email protected]>wrote: > Hi, > > Hmm, for jar and ear DeployerEjb should work (for war too but with some > tricky things abt classloadibg)...but shouldnt we manage hot deploy more > than this? > > PS: i do not get why this deployer is useful, what is the goal? If i > understand it hopes tomcat already deployed the webapp, no? > > - Romain > > Le 7 nov. 2011 00:47, "Jonathan Gallimore" <[email protected]> > a > écrit : > > > Hi > > > > I've just committed a Tomcat webapp folder style implementation of > > Deployer. I've only tried it with .war files so far, going to try with > .ear > > and .jars tomorrow. For the .ear/.jar case is it sensible to invoke the > > usual DeployerEjb class in that case, or would it be better to take the > > same approach with .war files? > > > > Cheers > > > > Jon > > >
