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 <karan.malhi@gmai...> 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 <david.blevins@visi...> 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