> 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
