You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Karan Malhi <ka...@gmail.com> on 2007/06/04 19:21:29 UTC
Re: Hotdeploy/Undeploy
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 <ka...@gmail.com> wrote:
> :)
>
>
> On 3/6/07, David Blevins <da...@visi.com> 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.com> 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 <ka...@gmail.com> 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@gmail.com> 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@gmail.com> 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 <da...@visi.com> 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
Re: Hotdeploy/Undeploy
Posted by David Blevins <da...@visi.com>.
On Jul 4, 2007, at 5:39 AM, Karan Malhi wrote:
> David,
>
> I just realized that you were working on this. Please do provide the
> hotdeploy functionality, I was just trying it on my own and it will
> probably take me a lot of time to implement it. You would be able to
> crank out the solution in no time. I think the sun xsd issue is more
> or less resolved. After my initial test , it works fine. So, I am not
> sure if we need to wait for Craig to clear up the license issues.
No, no. By all means, if you have something at least sort of working
you're farther then me. You can submit what you have and we can hack
together.
-David
>
> On 7/3/07, Dain Sundstrom <da...@iq80.com> wrote:
>> Sounds reasonable to me.
>>
>> -dain
>>
>> On Jul 3, 2007, at 12:12 PM, Karan Malhi wrote:
>>
>> > BTW, I got deploy to work using the Deployer bean. However, for
>> > hotdeploy to work, i would have to undeploy the module and then
>> deploy
>> > it. The Deployer bean gives me a nice deploy method where i can
>> > specify the location of the jar,
>> >
>> > However, the undeploy needs a moduleId. I saw the code and found
>> out
>> > that i will have to pretty much extract the moduleId myself from
>> the
>> > AppInfo and then give that moduleId to undeploy. I think instead of
>> > doing this stuff in the o.a.o.config.Deploy, we could add a
>> > convenience method to the DeployerEjb called undeploy(String
>> > location). Would it make sense to have something like this or am I
>> > totally on the wrong track?
>> >
>> > On 7/2/07, David Blevins <da...@visi.com> wrote:
>> >>
>> >> On Jun 5, 2007, at 6:24 PM, David Blevins wrote:
>> >>
>> >> >
>> >> > 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.
>> >>
>> >> So I'm looking into the command line deploy functionality and
>> hoping
>> >> to get something plumbed in in a short amount of time. I was
>> >> thinking we'd use a variation on this idea. Basically, we would
>> >> check to see if we can connect to the server and if so we'd deploy
>> >> via the Deployer ejb which is what the VmDeploymentManager uses.
>> >>
>> >> If we can't connect to the server then we could just add a
>> >> Deployments entry to their openejb.xml or maybe just copy the
>> archive
>> >> into the apps/ dir if they have one and print a message saying
>> >> they've deployed offline and the app should be picked up when
>> openejb
>> >> is started.
>> >>
>> >> -David
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Karan Singh Malhi
>>
>>
>
>
> --
> Karan Singh Malhi
>
Re: Hotdeploy/Undeploy
Posted by Karan Malhi <ka...@gmail.com>.
David,
I just realized that you were working on this. Please do provide the
hotdeploy functionality, I was just trying it on my own and it will
probably take me a lot of time to implement it. You would be able to
crank out the solution in no time. I think the sun xsd issue is more
or less resolved. After my initial test , it works fine. So, I am not
sure if we need to wait for Craig to clear up the license issues.
On 7/3/07, Dain Sundstrom <da...@iq80.com> wrote:
> Sounds reasonable to me.
>
> -dain
>
> On Jul 3, 2007, at 12:12 PM, Karan Malhi wrote:
>
> > BTW, I got deploy to work using the Deployer bean. However, for
> > hotdeploy to work, i would have to undeploy the module and then deploy
> > it. The Deployer bean gives me a nice deploy method where i can
> > specify the location of the jar,
> >
> > However, the undeploy needs a moduleId. I saw the code and found out
> > that i will have to pretty much extract the moduleId myself from the
> > AppInfo and then give that moduleId to undeploy. I think instead of
> > doing this stuff in the o.a.o.config.Deploy, we could add a
> > convenience method to the DeployerEjb called undeploy(String
> > location). Would it make sense to have something like this or am I
> > totally on the wrong track?
> >
> > On 7/2/07, David Blevins <da...@visi.com> wrote:
> >>
> >> On Jun 5, 2007, at 6:24 PM, David Blevins wrote:
> >>
> >> >
> >> > 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.
> >>
> >> So I'm looking into the command line deploy functionality and hoping
> >> to get something plumbed in in a short amount of time. I was
> >> thinking we'd use a variation on this idea. Basically, we would
> >> check to see if we can connect to the server and if so we'd deploy
> >> via the Deployer ejb which is what the VmDeploymentManager uses.
> >>
> >> If we can't connect to the server then we could just add a
> >> Deployments entry to their openejb.xml or maybe just copy the archive
> >> into the apps/ dir if they have one and print a message saying
> >> they've deployed offline and the app should be picked up when openejb
> >> is started.
> >>
> >> -David
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Karan Singh Malhi
>
>
--
Karan Singh Malhi
Re: Hotdeploy/Undeploy
Posted by Dain Sundstrom <da...@iq80.com>.
Sounds reasonable to me.
-dain
On Jul 3, 2007, at 12:12 PM, Karan Malhi wrote:
> BTW, I got deploy to work using the Deployer bean. However, for
> hotdeploy to work, i would have to undeploy the module and then deploy
> it. The Deployer bean gives me a nice deploy method where i can
> specify the location of the jar,
>
> However, the undeploy needs a moduleId. I saw the code and found out
> that i will have to pretty much extract the moduleId myself from the
> AppInfo and then give that moduleId to undeploy. I think instead of
> doing this stuff in the o.a.o.config.Deploy, we could add a
> convenience method to the DeployerEjb called undeploy(String
> location). Would it make sense to have something like this or am I
> totally on the wrong track?
>
> On 7/2/07, David Blevins <da...@visi.com> wrote:
>>
>> On Jun 5, 2007, at 6:24 PM, David Blevins wrote:
>>
>> >
>> > 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.
>>
>> So I'm looking into the command line deploy functionality and hoping
>> to get something plumbed in in a short amount of time. I was
>> thinking we'd use a variation on this idea. Basically, we would
>> check to see if we can connect to the server and if so we'd deploy
>> via the Deployer ejb which is what the VmDeploymentManager uses.
>>
>> If we can't connect to the server then we could just add a
>> Deployments entry to their openejb.xml or maybe just copy the archive
>> into the apps/ dir if they have one and print a message saying
>> they've deployed offline and the app should be picked up when openejb
>> is started.
>>
>> -David
>>
>>
>>
>>
>
>
> --
> Karan Singh Malhi
Re: Hotdeploy/Undeploy
Posted by Karan Malhi <ka...@gmail.com>.
BTW, I got deploy to work using the Deployer bean. However, for
hotdeploy to work, i would have to undeploy the module and then deploy
it. The Deployer bean gives me a nice deploy method where i can
specify the location of the jar,
However, the undeploy needs a moduleId. I saw the code and found out
that i will have to pretty much extract the moduleId myself from the
AppInfo and then give that moduleId to undeploy. I think instead of
doing this stuff in the o.a.o.config.Deploy, we could add a
convenience method to the DeployerEjb called undeploy(String
location). Would it make sense to have something like this or am I
totally on the wrong track?
On 7/2/07, David Blevins <da...@visi.com> wrote:
>
> On Jun 5, 2007, at 6:24 PM, David Blevins wrote:
>
> >
> > 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.
>
> So I'm looking into the command line deploy functionality and hoping
> to get something plumbed in in a short amount of time. I was
> thinking we'd use a variation on this idea. Basically, we would
> check to see if we can connect to the server and if so we'd deploy
> via the Deployer ejb which is what the VmDeploymentManager uses.
>
> If we can't connect to the server then we could just add a
> Deployments entry to their openejb.xml or maybe just copy the archive
> into the apps/ dir if they have one and print a message saying
> they've deployed offline and the app should be picked up when openejb
> is started.
>
> -David
>
>
>
>
--
Karan Singh Malhi
Re: Hotdeploy/Undeploy
Posted by Karan Malhi <ka...@gmail.com>.
Cool
On 7/2/07, David Blevins <da...@visi.com> wrote:
>
> On Jun 5, 2007, at 6:24 PM, David Blevins wrote:
>
> >
> > 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.
>
> So I'm looking into the command line deploy functionality and hoping
> to get something plumbed in in a short amount of time. I was
> thinking we'd use a variation on this idea. Basically, we would
> check to see if we can connect to the server and if so we'd deploy
> via the Deployer ejb which is what the VmDeploymentManager uses.
>
> If we can't connect to the server then we could just add a
> Deployments entry to their openejb.xml or maybe just copy the archive
> into the apps/ dir if they have one and print a message saying
> they've deployed offline and the app should be picked up when openejb
> is started.
>
> -David
>
>
>
>
--
Karan Singh Malhi
Re: Hotdeploy/Undeploy
Posted by David Blevins <da...@visi.com>.
On Jul 2, 2007, at 3:12 PM, David Blevins wrote:
>
> On Jun 5, 2007, at 6:24 PM, David Blevins wrote:
>
>>
>> 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.
>
> So I'm looking into the command line deploy functionality and
> hoping to get something plumbed in in a short amount of time. I
> was thinking we'd use a variation on this idea. Basically, we
> would check to see if we can connect to the server and if so we'd
> deploy via the Deployer ejb which is what the VmDeploymentManager
> uses.
>
> If we can't connect to the server then we could just add a
> Deployments entry to their openejb.xml or maybe just copy the
> archive into the apps/ dir if they have one and print a message
> saying they've deployed offline and the app should be picked up
> when openejb is started.
Ok, I just checked in a first run that should be pretty solid. I
tested what things looked like when deployment failed, when
validation failed, when you tried to deploy an app that was already
deployed, when you tried to deploy an app that contained a
deploymentid already in use, etc. After successful deployment it
also lists all the app clients, persistence units, ejb-jars, ejbs,
and even the jndi names for the ejbs.
I'll try and get some documentation together for it tomorrow with
some sample output.
We should be in good shape for release.
-David
Re: Hotdeploy/Undeploy
Posted by David Blevins <da...@visi.com>.
On Jun 5, 2007, at 6:24 PM, David Blevins wrote:
>
> 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.
So I'm looking into the command line deploy functionality and hoping
to get something plumbed in in a short amount of time. I was
thinking we'd use a variation on this idea. Basically, we would
check to see if we can connect to the server and if so we'd deploy
via the Deployer ejb which is what the VmDeploymentManager uses.
If we can't connect to the server then we could just add a
Deployments entry to their openejb.xml or maybe just copy the archive
into the apps/ dir if they have one and print a message saying
they've deployed offline and the app should be picked up when openejb
is started.
-David
Re: Hotdeploy/Undeploy
Posted by David Blevins <da...@visi.com>.
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 <ka...@gmail.com> wrote:
>> :)
>>
>>
>> On 3/6/07, David Blevins <da...@visi.com> 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.com> 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 <ka...@gmail.com> 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@gmail.com> 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@gmail.com> 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 <da...@visi.com> 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
>