Thanks for pointing out where to start!! On 3/2/07, David Blevins <[EMAIL PROTECTED]> wrote:
On Mar 2, 2007, at 2:36 PM, Karan Malhi wrote: > Sure, > > Let me start looking into it over the weekend Definitely feel free (encouraged even) to post as you poke around looking for where to implement this. I'm not totally sure myself, so it's likely to be a discovery process for us all. We have the required parts (ability to deploy at runtime, undeploy at runtime, an ejb that can help with deploying other ejbs) we just need to find some way (and some place) to sew it all together. You seem really comfortable brainstorming in public, so that's great -- half the battle really. Couple areas off the top of my head to poke at are the castor objects that make the openejb xml. The class that represents the <Deployments> element is org.apache.openejb.config.sys.Deployments, notice there's a matching DeploymentsDescriptor which has all the castor xml specific marshalling code in it. We've typically updated those by hand when it comes to adding an attribute here or there. Usually is easy to copy another one and teak it. Second, it's the ConfigurationFactory's job to process the openejb xml and likely it'll be something in that package that set's up the directory scanners. Not sure how or where specifically. We've got a general-purpose directory scanning class here I checked in a bit ago to help with this: org.apache.openejb.util.DirectoryMonitor So as I say, lot's of bits, nothing that ties everything together. -David > > On 1/30/07, Karan Malhi <[EMAIL PROTECTED]> wrote: >> >> Hi David, >> >> I think i mixed the two in trying to explain what I was >> suggesting. Here >> is what I was thinking >> >> =>By default we could have hotdeploy to true i.e. even if i have >> something >> like below, still dir1 and dir2 (or any other deployment) should be >> hotdeployed every x seconds: >> >> <openejb> >> <Deployments dir="dir1" /> >> <Deployments dir="dir2" /> >> </openejb> >> >> => We should explicitly be able to disable hotdeploy >> <openejb> >> <hotDeploy enable='false' /> >> <Deployments dir="dir1" /> >> <Deployments dir="dir2" /> >> </openejb> >> >> => We should be able to set the deployInterval >> <openejb> >> <hotDeploy deployInterval='10'/> // we do not need explicitly set >> enable >> to true because hotdeploy would be true by default >> <Deployments dir="dir1" /> >> <Deployments dir="dir2" /> >> </openejb> >> >> => However <Deployments> should be allowed to override the hotdeploy >> property. For example, lets say i have two dirs, dir1 and dir2. I >> know for >> sure that code in dir1 will never change (or change so >> infrequently that I >> could make the changes and simply restart instead of polling >> frequently) and >> all the work has to be deployed in dir2. In that case, i do not >> want to poll >> dir1 and I could do the following: >> >> <openejb> >> <Deployments dir="dir1" hotdeploy='false'/> // disable >> hotdeploy >> for dir1 >> <Deployments dir="dir2" /> // dir2 will be polled every x >> seconds ( >> the default deployInterval) >> </openejb> >> >> The whole objective is to make it clear and easier for openejb >> newbies >> like me to create and deploy an EJB. Setting it to true by default >> will >> result in one less step for an individual to perform if she/he was >> just >> getting started with openejb. People experienced enough with >> openejb will >> know/learn on how to disable hotdeploy using the conf file. >> >> I agree with you that a System property could replace the <hotDeploy> >> element under <openejb> . >> >> >> On 1/26/07, Karan Malhi < [EMAIL PROTECTED]> wrote: >> > >> > Actually if hotdeploy is set to true by default then Option 1 >> could be >> > >> > <openejb> >> > <hotdeploy enable='false' pollInterval='5' /> // the enable >> > attribute could take true or false. >> > </openejb> >> > >> > On 1/26/07, Karan Malhi < [EMAIL PROTECTED]> wrote: >> > > >> > > OPTION I >> > > ----------------- >> > > It could be under the <openejb> element >> > > >> > > <openejb> >> > > <hotdeploy pollInterval='5' /> <!-- This pollInterval >> could be in >> > > seconds or milliseconds. I personally prefer to use seconds ---> >> > > </openejb> >> > > >> > > OPTION II >> > > --------------- >> > > <openejb> >> > > <Deployments jar="c:/my/app/a.jar" hotdeploy='true' >> > > pollInterval='5' /> >> > > </openejb> >> > > >> > > By default hotdeploy should be set to true if not mentioned in >> the >> > > openejb.conf with a poll interval of x seconds (I dont know what >> > > would be the best interval for polling) >> > > >> > > I like OPTION I better because adding attributes to the >> <Deployments> >> > > element might lead to something like >> > > <openejb> >> > > <Deployments jar="c:/my/app/a.jar" hotdeploy='true' >> > > pollInterval='5'/> // poll interval of 5 seconds >> > > <Deployments jar="c:/my/app/b.jar" hotdeploy='true' >> > > pollInterval='10'/> // poll interval of 10 seconds >> > > </openejb> >> > > So what would be a desired behaviour in this case, you would >> need to >> > > poll in different intervals for different jars. I cannot think >> of any case >> > > requiring this feature. >> > > >> > > However <Deployments> should be allowed to override the hotdeploy >> > > property. For example, lets say i have two dirs, dir1 and >> dir2. I know for >> > > sure that code in dir1 will never change (or change so >> infrequently that I >> > > could make the changes and simply restart instead of polling >> frequently) and >> > > all the work has to be deployed in dir2. In that case, i do >> not want to poll >> > > dir1 and I could do the following: >> > > >> > > <openejb> >> > > <hotdeploy pollInterval='5' /> >> > > <Deployments dir="dir1" hotdeploy='false'/> // disable >> > > hotdeploy for dir1 >> > > <Deployments dir="dir2" /> // dir2 will be polled every 5 >> > > seconds >> > > </openejb> >> > > >> > > I think the attribute 'pollInterval' could be replaced by >> something >> > > more intuitive. Something which doent expose the "nature >> (polling)" of >> > > hotdeploy >> > > >> > > >> > > On 1/26/07, David Blevins <[EMAIL PROTECTED]> wrote: >> > > > >> > > > Ok, so I plugged in the ability for us to remove >> applications from >> > > > the system at runtime. We also have the ability to add them at >> > > > runtime. >> > > > >> > > > See this test for how it basically works: >> > > > >> > > > http://svn.apache.org/repos/asf/incubator/openejb/trunk/ >> openejb3/ >> > > > container/openejb-core/src/test/java/org/apache/openejb/ >> assembler/ >> > > > classic/RedeployTest.java >> > > > >> > > > I've even added a class that we can use for scanning >> directories >> > > > (org.apache.openejb.util.DirectoryMonitor). At this point >> we are >> > > > just moments away from some sort of hot deploy / undeploy >> directory >> > > > where people can drop apps. >> > > > >> > > > http://svn.apache.org/repos/asf/incubator/openejb/trunk/ >> openejb3/ >> > > > container/openejb-core/src/main/java/org/apache/openejb/util/ >> > > > DirectoryMonitor.java >> > > > >> > > > What we're lacking is some intelligent way to configure all >> this in >> > > > your openejb.conf file. At minimum someone should be able to >> > > > specify >> > > > whether or not they want to scan past the initial startup >> and what >> > > > the poll interval might be. We could potentially just add >> these as >> > > > attributes on the <Deployments> element of our conf. >> > > > >> > > > Thoughts, ideas? Brainstorming welcome. >> > > > >> > > > -David >> > > > >> > > > >> > > >> > > >> > > -- >> > > Karan Malhi >> > > >> > >> > >> > >> > -- >> > Karan Malhi >> > >> >> >> >> -- >> Karan Malhi >> > > > > -- > Karan Malhi
-- Karan Malhi
