I was thinking about the following: the CLI deploy option uses the org.apache.openejb.config.Deploy. I was thinking if somehow this object could use the org.apache.openejb.VmDeploymentManager. This way our CLI will be able to use the JSR-88 compliant interfaces for its deployment. The same logic used here could be re-used in a swing, web or IDE based administrative console application. I have tried to look through the code, but didnt have enough time to be able to view it thoroughly. I will give this a try if you feel this is a valid option.
Secondly, what is the difference between JSR-88 redploy and the hotdeploy option we are talking about. As far as i can gather, JSR-88 says that the whole module should be replaced in a redploy, are we looking at the same for hotdeploy also. For example, module ejb1 has 2 ejbs, JSR-88 way, we will have to redeploy module ejb1 even if i just changed one ejb. Would hotdeploy work the same way, or is it that we are looking to just hotdeploy the changed ejb and leave the unchanged ejbs alone. I am not sure if something like this is possible, so wanted to make sure, before i start looking deeper into this option. On 3/6/07, Karan Malhi <[EMAIL PROTECTED]> wrote:
:) On 3/6/07, David Blevins <[EMAIL PROTECTED]> wrote: > I was pruning the JIRA items assigned to me that I'm not working on > and saw that the Hot Deploy item was still assigned to me, which it > shouldn't be. > > You're now the proud assignee of OPENEJB-428! :) > > May future users shower you with their praise ;) > > -David > > On Mar 3, 2007, at 3:14 PM, Karan Malhi wrote: > > > 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 > > -- Karan Malhi
-- Karan Malhi
