I'm totally convinced. I really like this approach. Michael
Matt Munz wrote: >>We might have to somehow "lock" the directory during >>changes and "unlock" it afterwards. > > > It's interesting the way Cruise Control deals with the same issue. A time > interval could be specified where the deployment scanner would wait to see > if there were any more updates before proceeding with the deployment -- kind > of like microwave popcorn -- "Wait until 2 seconds between pops before > removing from the microwave". > > This could allow "batch" updates in a fully automatic manner. > > - Matt > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Michael Bartmann > Sent: Wednesday, October 02, 2002 3:20 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Directory hot-deploy granularity > > > Hi, > > I think we have to consider race conditions here. > What keeps a deployment scanner from starting in the > middle of an update when only some (i.e. inconsistent) > changes have occured yet. > We might have to somehow "lock" the directory during > changes and "unlock" it afterwards. But this lowers > the degree of "automaticity"; you would at least > have to trigger the redeployment process manually at > some appropriate time. > > Regards, > Michael > > Gredler, Dani wrote: > >>Hi, >> >>I'm thinking about adding some code to JBoss to provide better granularity >>to the [hot] deployment of directories. Here's the situation: I'm getting >>tired of repackaging my EJB's into a JAR, creating a WAR, combining them >>into an EAR, dropping the EAR file into the deployment directory, and >>waiting for the whole EAR to redeploy before testing my one-line change. >> >>Now, I know JBoss lets you drop a directory in the hot-deploy directory, > > and > >>as long as it matches the EAR file structure, it will deploy it, and I > > have > >>considered using this. What I would like, however, is to be able to make > > my > >>one-line change to one of the EJB's in the directory, recompile the .class >>file, and have JBoss automatically recognize that the one EJB in the >>application needs to be redeployed, instead of having to redeploy the > > whole > >>application. This would speed my development on JBoss incredibly, and > > would > >>mitigate what I consider to be the Achilles heel of J2EE development. >> >>I've looked through the JBoss code available for download on the site, and >>from my quick perusing am inclined to think that, among others, my changes >>need to happen in: >> >>org.jboss.net.protocol.file.FileURLConnection - change the implementation > > of > >>getLastModified() so that it recurses all subdirectories and checks all >>files for modifications, not just the base directory. >> >>org.jboss.deployment.URLDeploymentScanner - change the implementation of >>scan() so that modified directories do not get bluntly undeployed and >>redeployed. Instead, intelligently determine which parts of the > > application > >>need redeploying, and do them instead. >> >>Basically I'm looking for feedback here. Is there an easier way to achieve >>my goal than this? If not, am I on the right track as far as how to make > > the > >>changes? Does anyone who is more familiar with the code than I have any >>suggestions or pointers? >> >>Thanks for reading my long rambling post :) >> >>Dani >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
