Bringing up this thread again. Karan, you want to take a crack at
implementing this? Seems we have everything we need pre-requisite wise.
I think the easiest thing would be for us to follow this pattern,...
<openejb>
<Deployments dir="dir1" hotdeploy='false'/> // disable
hotdeploy for
dir1
<Deployments dir="dir2" /> // dir2 will be polled every x
seconds (
the default deployInterval)
</openejb>
..along with as second attribute 'deployInterval' just in case they
wanted to change that.
And in the new system.properties file we could add something like
this for controlling the defaults:
deployments.hotdeploy=true
deployments.deployInterval=10
Thoughts?
-David
On Jan 30, 2007, at 4:45 PM, Karan Malhi 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
