so maybe an optionnal module (or otherwise we need to find a utility to it ;)...and to manage all hot deploy directory and hosts :p)
but why not an openejb-tool or openejb-helper for such features. I saw a wiki generator, i didnt have a look why it was here but maybe it is another example. no? - Romain 2011/11/7 David Blevins <[email protected]> > > On Nov 7, 2011, at 11:15 AM, Romain Manni-Bucau wrote: > > > ok but the webappdeployer is not linked to the deployment at all, just to > > the way we deploy tcks so should we keep this ejb on trunk? > > We'll also want to run it with the CDI TCK. Though that part we probably > only want to do in buildbot. > > -David > > > 2011/11/7 David Blevins <[email protected]> > > > >> > >> On Nov 6, 2011, at 4:22 PM, Jonathan Gallimore wrote: > >> > >>> 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. > >> > >> Right. Close as in identical :) Unless we're going to tell people > "don't > >> drop apps in webapps/", we should test it. > >> > >> Next step is to get the VmDeploymentManager class updated so the impl > can > >> be configurable. Then update the "runtests" script so the > implementation > >> cab be set for a test run. Then of course to try a test or two to > verify > >> that all works. > >> > >> Then we can kick off an entire run with that approach and see where we > >> land. > >> > >> > >> -David > >> > >> > >> > >
