On Jun 4, 2007, at 10:21 AM, Karan Malhi wrote:

> 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.

I think that'd be a great thing to have.

>
> 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.

The hotdeploy function we need for the most part is a scanned  
directory (i.e. ability to configure that on a <Deployments> element)  
that would deploy on add, redeploy on change (maybe), and undeploy on  
delete.

As far as what you can undeploy/redeploy the answer is ears only.  If  
you deployed a ejb-jar all by itself, then internally we're going to  
wrap that with a "ear" of sorts and it can be undeployed/redeployed.  
If you put the ejb-jar in an ear and deploy the ear and later want to  
undeploy/redeploy just the ejb-jar, that's just not something we  
support -- you'd have to undeploy/redeploy the whole ear.  Not sure  
how much demand for that there is anyway.

-David


> On 3/6/07, Karan Malhi <karan.malhi@gmai...> wrote:
>> :)
>>
>>
>> On 3/6/07, David Blevins <david.blevins@visi...> 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 < david.blevins@visi...> 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 <karan.malhi@gmai...> 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 < karan.malhi@gmai...> 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 < 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
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> --
>> > >> >> Karan Malhi
>> > >> >>
>> > >> >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Karan Malhi
>> > >>
>> > >>
>> > >
>> > >
>> > > --
>> > > Karan Malhi
>> >
>> >
>>
>>
>>
>> --
>> Karan Malhi
>>
>
>
> --
> Karan Malhi
>