You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jacek Laskowski <jl...@apache.org> on 2005/10/23 22:08:21 UTC
The autodeploy feature in Geronimo
Hi,
The recent question about JetSpeed and its portlet autodeployment made
me wonder if it's being worked out. Is anyone working on it? How is it
going? And more importantly, where is it being tracked?
If it is not yet, I'd like to write it. Which module should it be placed
in? Am I right that the simplest solution is to develop a GBean that
would monitor a directory and hand over a deployable to a deployer?
Jacek
Re: The autodeploy feature in Geronimo
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Oct 24, 2005, at 3:32 PM, David Jencks wrote:
>
> On Oct 24, 2005, at 12:24 PM, Geir Magnusson Jr. wrote:
>
>
>>
>> On Oct 24, 2005, at 3:16 PM, Sachin Patel wrote:
>>
>>
>>>
>>>
>>> Geir Magnusson Jr. wrote:
>>>
>>>
>>>> On Oct 24, 2005, at 1:05 PM, Joe Bohn wrote:
>>>>
>>>>
>>>>>
>>>>> How about if we provide a "hot deploy" location that acts as an
>>>>> "addition/over-ride" location much the same as adding a library
>>>>> earlier in a path. I tend to think of this "hot deploy"
>>>>> activity as a developer activity and so I think most folks
>>>>> running a production server would follow the traditional
>>>>> deploy, undeploy, redeploy mechanics. Hot-deploy would most
>>>>> likely be used exclusively in development or to "patch" a
>>>>> critical problem with a temporary fix.
>>>>>
>>>>>
>>>> I only think of hot-deploy as a developer activity, and
>>>> personally would turn it off in production.
>>>>
>>>>
>>>
>>> Yes, this would definately not be a production tool. For now I
>>> really think we just need something VERY simple. Like David J.
>>> said, lets simply restrict the deployables to archives containing
>>> plans. This would eliminate unncessary complexity until further
>>> thought can be put into a solution that allows additional
>>> capability and be able to properly handle these scenarios. We
>>> can make this as simple as we want or as complex as we want.
>>> Lets start with something simple for now :)
>>>
>>
>> Fine. But I don't think we need to think of this as being a part
>> of the core geronimo server. Lets start it as a simple tool in
>> devutils that someone can choose to use...
>>
>> I think that's part of the problem here - we're thinking too
>> deeply. Lets just throw together a little webapp that hosts this
>> functionality. Lets see how it works.
>>
>> I think I'll go start this now in devutils sandbox or something :)
>>
>
> Why do you want to make it a web app? This implies it has a web
> GUI and makes it difficult to access gbeans. I think you would
> make life simpler for everyone if you just wrote a gbean for this.
> Sachin's design looks ok to me, but it needs replacement of the
> LGPL code in the patch.
It doesn't have to be a webapp, but certainly I can see having a UI
might be nice.
I'll go look for his patch...
My main point is that for now, we can keep this out of the core
server until we get some real chance to play with it...
--
Geir Magnusson Jr +1-203-665-6437
geir@optonline.net
Re: The autodeploy feature in Geronimo
Posted by David Jencks <da...@yahoo.com>.
On Oct 24, 2005, at 12:24 PM, Geir Magnusson Jr. wrote:
>
> On Oct 24, 2005, at 3:16 PM, Sachin Patel wrote:
>
>>
>>
>> Geir Magnusson Jr. wrote:
>>
>>> On Oct 24, 2005, at 1:05 PM, Joe Bohn wrote:
>>>
>>>>
>>>> How about if we provide a "hot deploy" location that acts as an
>>>> "addition/over-ride" location much the same as adding a library
>>>> earlier in a path. I tend to think of this "hot deploy" activity
>>>> as a developer activity and so I think most folks running a
>>>> production server would follow the traditional deploy, undeploy,
>>>> redeploy mechanics. Hot-deploy would most likely be used
>>>> exclusively in development or to "patch" a critical problem with a
>>>> temporary fix.
>>>>
>>> I only think of hot-deploy as a developer activity, and personally
>>> would turn it off in production.
>>>
>>
>> Yes, this would definately not be a production tool. For now I
>> really think we just need something VERY simple. Like David J. said,
>> lets simply restrict the deployables to archives containing plans.
>> This would eliminate unncessary complexity until further thought can
>> be put into a solution that allows additional capability and be able
>> to properly handle these scenarios. We can make this as simple as we
>> want or as complex as we want. Lets start with something simple for
>> now :)
>
> Fine. But I don't think we need to think of this as being a part of
> the core geronimo server. Lets start it as a simple tool in devutils
> that someone can choose to use...
>
> I think that's part of the problem here - we're thinking too deeply.
> Lets just throw together a little webapp that hosts this
> functionality. Lets see how it works.
>
> I think I'll go start this now in devutils sandbox or something :)
Why do you want to make it a web app? This implies it has a web GUI
and makes it difficult to access gbeans. I think you would make life
simpler for everyone if you just wrote a gbean for this. Sachin's
design looks ok to me, but it needs replacement of the LGPL code in the
patch.
thanks
david jencks
>
> geir
>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
Re: The autodeploy feature in Geronimo
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 24, 2005, at 3:16 PM, Sachin Patel wrote:
>
>
> Geir Magnusson Jr. wrote:
>
>> On Oct 24, 2005, at 1:05 PM, Joe Bohn wrote:
>>
>>>
>>> How about if we provide a "hot deploy" location that acts as an
>>> "addition/over-ride" location much the same as adding a library
>>> earlier in a path. I tend to think of this "hot deploy" activity
>>> as a developer activity and so I think most folks running a
>>> production server would follow the traditional deploy, undeploy,
>>> redeploy mechanics. Hot-deploy would most likely be used
>>> exclusively in development or to "patch" a critical problem with
>>> a temporary fix.
>>>
>> I only think of hot-deploy as a developer activity, and personally
>> would turn it off in production.
>>
>
> Yes, this would definately not be a production tool. For now I
> really think we just need something VERY simple. Like David J.
> said, lets simply restrict the deployables to archives containing
> plans. This would eliminate unncessary complexity until further
> thought can be put into a solution that allows additional
> capability and be able to properly handle these scenarios. We can
> make this as simple as we want or as complex as we want. Lets
> start with something simple for now :)
Fine. But I don't think we need to think of this as being a part of
the core geronimo server. Lets start it as a simple tool in devutils
that someone can choose to use...
I think that's part of the problem here - we're thinking too deeply.
Lets just throw together a little webapp that hosts this
functionality. Lets see how it works.
I think I'll go start this now in devutils sandbox or something :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: The autodeploy feature in Geronimo
Posted by Sachin Patel <sp...@gmail.com>.
Geir Magnusson Jr. wrote:
>
> On Oct 24, 2005, at 1:05 PM, Joe Bohn wrote:
>>
>> How about if we provide a "hot deploy" location that acts as an
>> "addition/over-ride" location much the same as adding a library
>> earlier in a path. I tend to think of this "hot deploy" activity as a
>> developer activity and so I think most folks running a production
>> server would follow the traditional deploy, undeploy, redeploy
>> mechanics. Hot-deploy would most likely be used exclusively in
>> development or to "patch" a critical problem with a temporary fix.
>
> I only think of hot-deploy as a developer activity, and personally would
> turn it off in production.
Yes, this would definately not be a production tool. For now I really
think we just need something VERY simple. Like David J. said, lets
simply restrict the deployables to archives containing plans. This
would eliminate unncessary complexity until further thought can be put
into a solution that allows additional capability and be able to
properly handle these scenarios. We can make this as simple as we want
or as complex as we want. Lets start with something simple for now :)
>
> I also don't think that with a sane deployer infrastructure and tool,
> that this has to be part of the core server.
>
> Rather, I see it as an additional tool that you can use if you choose -
> for example a little webapp that you deploy to your development server
> that does this for you - scans the directory and then just uses the
> standard deployment API to get 'r done. It could have it's own
> web-based UI that you could use to define the deployment directory, to
> pause it, to do whateveer...
>
> geir
>
> --Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: The autodeploy feature in Geronimo
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 24, 2005, at 1:05 PM, Joe Bohn wrote:
>
> How about if we provide a "hot deploy" location that acts as an
> "addition/over-ride" location much the same as adding a library
> earlier in a path. I tend to think of this "hot deploy" activity
> as a developer activity and so I think most folks running a
> production server would follow the traditional deploy, undeploy,
> redeploy mechanics. Hot-deploy would most likely be used
> exclusively in development or to "patch" a critical problem with a
> temporary fix.
I only think of hot-deploy as a developer activity, and personally
would turn it off in production.
I also don't think that with a sane deployer infrastructure and tool,
that this has to be part of the core server.
Rather, I see it as an additional tool that you can use if you choose
- for example a little webapp that you deploy to your development
server that does this for you - scans the directory and then just
uses the standard deployment API to get 'r done. It could have it's
own web-based UI that you could use to define the deployment
directory, to pause it, to do whateveer...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: The autodeploy feature in Geronimo
Posted by Joe Bohn <jo...@earthlink.net>.
I've made one final attempt to clarify my proposal. If it's still
hair-brained then I'll let it fade into the dev archives ... :-)
David Jencks wrote:
>
> On Oct 24, 2005, at 10:05 AM, Joe Bohn wrote:
>
>>
>>
>> Jeff Genender wrote:
>>
>>> Sachin Patel wrote:
>>>
>>>> Wouldn't it be more confusing to the user if their file got removed
>>>> after it got deployed? I feel the point of a "live" directory is for
>>>> the runtime to be able to react to any changes to it, including
>>>> deletions. Both Jboss and Websphere's hot deploy capability allow
>>>> deletions.
>>>
>>> I would like to get more input on this. I really believe a hot
>>> deploy directory should be just for that..to deploy/redeploy. There
>>> was some great discussion in the past on this (check the lists). But
>>> I am open to this. The problems we will run into this whole idea is
>>> managing the plans and ensuring the dropped wars/jars/ears/rars/etc
>>> are the same in the config store. Then, also what about exploded libs?
>>> I wouldn't necessarily say the because WS and JBoss have it, means
>>> its the right way. How is BEA doing it? We should think about this
>>> all the way through before going down a path.
>>
>>
>> I agree with the notion that any "hot deploy" directory we deliver
>> should be only for deploy/redeploy. However, I don't think that
>> makes it necessary to remove the items once they were deployed. I
>> agree with Geir that we should keep things there so that you can
>> verify what is really active at any given time.
>
>
> Hot deploy has got to be a very secondary method for unsophisticated
> developers who don't care much about tracking what state there server is
> in. Since it is fundamentally inconsistent with the required jsr-88
> stuff we should not break our architecture to support a bad although
> popular idea.
I agree (as I mentioned a little lower in my original post). The
primary goal here should be to provide a quick means to update or change
items during development. It could also be used to provide quick
patches for problems in production but this is not essential. However,
it should not replace the general deployment mechanisms. This is
exactly why I think we should keep the items from hot-deploy distinct
from config-store and not allow those things to corrupt the
config-store. If we don't keep these distinct than an attempt to make a
change and back it out without permanently affecting the installed
application would impossible.
>
>>
>> I have a somewhat different view on this (perhaps entirely wrong) but
>> I'd like to toss it out there.
>>
>> How about if we provide a "hot deploy" location that acts as an
>> "addition/over-ride" location much the same as adding a library
>> earlier in a path. I tend to think of this "hot deploy" activity as a
>> developer activity and so I think most folks running a production
>> server would follow the traditional deploy, undeploy, redeploy
>> mechanics. Hot-deploy would most likely be used exclusively in
>> development or to "patch" a critical problem with a temporary fix.
>
>
> I have no idea how this could possibly work. Could you explain? Say
> you have an application deployed using jsr-88 or the maven plugin as
> part of your development process. How would you use the hot deploy
> directory to undeploy the already deployed app and deploy the "fix"?
I did preface my original post with the disclaimer that this view could
be "entirely wrong" :-). This may be too complicated and not feasible
... but before we dismiss it I'd like to ensure that the concept is
understood.
Perhaps part of the problem here is terminology so let's use these terms:
- jsr88-deploy/deployment - the current deploy capability that populates
config-store.
- config-store - the repository for jsr88-deployed applications
- hot-deploy/deployment - the alternative deployment capability that I'm
suggesting that could populate the hot-config-store.
- hot-config-store - the repository for hot-deployed applications
The actual processing during deployment could be consistent for both the
jsr88-deploy and the hot-deploy assuming that the deployment process
itself was updated to reference the hot-config-store prior to the
config-store.
To answer your question about undeploy using these terms .... you would
never undeploy a jsr88-deployed item using hot-deploy. If you removed
an EAR/WAR/JAR/RAR... from the hot-deploy location then the
corresponding items would be removed from the hot-config-store. To
remove an item from the config-store would require a jsr88-deployment
undeploy. Since config-store is the "official" deployment location then
any jsr88-undeploy should also remove any corresponding elements from
the hot-config-store but not vice-versa.
>
>>
>> If this idea has any merit then I would propose the following:
>> - The hot deploy location would be used as a the initial place to look
>> for any application or application element prior to looking in the
>> config-store. Therefore, it could be used to over-ride items from a
>> previously deployed application.
>
>
> I can't see the use of this, or how to make it work, and I think it
> would cause complete confusion.
I don't think this is arbitrarily complex.
Given the following:
- lib1 contains MyApplClass.class
- lib2 contains MyApplClass.class
- path = .... lib1;lib2....
Is it confusing that MyApplClass.class from lib1 will be used when
searching path? If you remove MyApplClass from lib1 would you not
expect that MyApplClass from lib2 would be used? This is all that I'm
proposing for hot deploy.
The only difference with this proposal is that it must deal with
complete applications which must be deployed as a unit in addition to
individual components. Hence the resultant "path" when locating
classes, applications, etc... would be:
hot-deploy-location;hot-config-store;config-store
where:
- hot-deploy-location is for individual file/component over-rides
- hot-config-store is for deployed application over-rides (EAR/WAR/JAR....)
- config-store - same as now ...
>
>> - New applications added to the hot-deploy location would not be fully
>> "deployed" in the sense of being added to the config-store. Rather,
>> they would be deployed to a temporary location (possibly somewhere
>> under the same hot-deploy location). That will keep the two
>> deployment types and locations distinct.
>
>
> We could have another config-store for these, but I really don't see
> what the point would be.
>
>> - Applications which only existed in the hot deploy location and were
>> removed would be "undeployed" from the temporary location (but not
>> from the config-store since a hot-deploy item is never included in the
>> config-store). This would then result in the application being
>> completely removed from the system if it was never fully deployed to
>> the config-store or the original, deployed application would then once
>> again become the "used" application.
>> - There would be no capability to really undeploy an application that
>> has been deployed to the config-store ...only the ability to over-ride
>> it or stop over-riding it.
>
>
> If we had 2 config stores, with the one used by hot deploy preceding the
> normal one in the configuration manager's list of config stores
> (although I don't think its ordered at the moment) then when you
> restarted the server you'd get the hot-deployed one. But stopping and
> removing the original app from the config store is a much smaller
> operation than restarting the server. Why would you force someone to
> restart the server rather than just administering configurations?
I certainly wasn't proposing that we replace one config-store with
another and hence require a server restart. If the architecture is such
that it's technically impossible to provide this file-level and
application-level override without a server restart then we should just
drop this idea for now.
>
> I really don't understand where you are trying to go with this idea.
I hope I clarified that above ... I'm more than willing to let this die
if I can't get others to see the value or if it's not practical.
>
> thanks
> david jencks
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
Re: The autodeploy feature in Geronimo
Posted by David Jencks <da...@yahoo.com>.
On Oct 24, 2005, at 10:05 AM, Joe Bohn wrote:
>
>
> Jeff Genender wrote:
>> Sachin Patel wrote:
>>> Wouldn't it be more confusing to the user if their file got removed
>>> after it got deployed? I feel the point of a "live" directory is for
>>> the runtime to be able to react to any changes to it, including
>>> deletions. Both Jboss and Websphere's hot deploy capability allow
>>> deletions.
>> I would like to get more input on this. I really believe a hot
>> deploy directory should be just for that..to deploy/redeploy. There
>> was some great discussion in the past on this (check the lists). But
>> I am open to this. The problems we will run into this whole idea is
>> managing the plans and ensuring the dropped wars/jars/ears/rars/etc
>> are the same in the config store. Then, also what about exploded
>> libs?
>> I wouldn't necessarily say the because WS and JBoss have it, means
>> its the right way. How is BEA doing it? We should think about this
>> all the way through before going down a path.
>
> I agree with the notion that any "hot deploy" directory we deliver
> should be only for deploy/redeploy. However, I don't think that
> makes it necessary to remove the items once they were deployed. I
> agree with Geir that we should keep things there so that you can
> verify what is really active at any given time.
Hot deploy has got to be a very secondary method for unsophisticated
developers who don't care much about tracking what state there server
is in. Since it is fundamentally inconsistent with the required jsr-88
stuff we should not break our architecture to support a bad although
popular idea.
>
> I have a somewhat different view on this (perhaps entirely wrong) but
> I'd like to toss it out there.
>
> How about if we provide a "hot deploy" location that acts as an
> "addition/over-ride" location much the same as adding a library
> earlier in a path. I tend to think of this "hot deploy" activity as a
> developer activity and so I think most folks running a production
> server would follow the traditional deploy, undeploy, redeploy
> mechanics. Hot-deploy would most likely be used exclusively in
> development or to "patch" a critical problem with a temporary fix.
I have no idea how this could possibly work. Could you explain? Say
you have an application deployed using jsr-88 or the maven plugin as
part of your development process. How would you use the hot deploy
directory to undeploy the already deployed app and deploy the "fix"?
>
> If this idea has any merit then I would propose the following:
> - The hot deploy location would be used as a the initial place to look
> for any application or application element prior to looking in the
> config-store. Therefore, it could be used to over-ride items from a
> previously deployed application.
I can't see the use of this, or how to make it work, and I think it
would cause complete confusion.
> - New applications added to the hot-deploy location would not be fully
> "deployed" in the sense of being added to the config-store. Rather,
> they would be deployed to a temporary location (possibly somewhere
> under the same hot-deploy location). That will keep the two
> deployment types and locations distinct.
We could have another config-store for these, but I really don't see
what the point would be.
> - Applications which only existed in the hot deploy location and were
> removed would be "undeployed" from the temporary location (but not
> from the config-store since a hot-deploy item is never included in the
> config-store). This would then result in the application being
> completely removed from the system if it was never fully deployed to
> the config-store or the original, deployed application would then once
> again become the "used" application.
> - There would be no capability to really undeploy an application that
> has been deployed to the config-store ...only the ability to over-ride
> it or stop over-riding it.
If we had 2 config stores, with the one used by hot deploy preceding
the normal one in the configuration manager's list of config stores
(although I don't think its ordered at the moment) then when you
restarted the server you'd get the hot-deployed one. But stopping and
removing the original app from the config store is a much smaller
operation than restarting the server. Why would you force someone to
restart the server rather than just administering configurations?
I really don't understand where you are trying to go with this idea.
thanks
david jencks
Re: The autodeploy feature in Geronimo
Posted by Jeff Genender <jg...@savoirtech.com>.
Joe Bohn wrote:
> I agree with the notion that any "hot deploy" directory we deliver
> should be only for deploy/redeploy. However, I don't think that makes
> it necessary to remove the items once they were deployed. I agree with
> Geir that we should keep things there so that you can verify what is
> really active at any given time.
>
> I have a somewhat different view on this (perhaps entirely wrong) but
> I'd like to toss it out there.
>
> How about if we provide a "hot deploy" location that acts as an
> "addition/over-ride" location much the same as adding a library earlier
> in a path. I tend to think of this "hot deploy" activity as a developer
> activity and so I think most folks running a production server would
> follow the traditional deploy, undeploy, redeploy mechanics. Hot-deploy
> would most likely be used exclusively in development or to "patch" a
> critical problem with a temporary fix.
>
> If this idea has any merit then I would propose the following:
> - The hot deploy location would be used as a the initial place to look
> for any application or application element prior to looking in the
> config-store. Therefore, it could be used to over-ride items from a
> previously deployed application.
Yes....agreed.
> - New applications added to the hot-deploy location would not be fully
> "deployed" in the sense of being added to the config-store. Rather,
> they would be deployed to a temporary location (possibly somewhere under
> the same hot-deploy location). That will keep the two deployment types
> and locations distinct.
IMHO this could get really ugly. I think we need a single location. If
we have a hot-deploy directory, then it should be there to make is easy
to auto deploy instead of running a script.
> - Applications which only existed in the hot deploy location and were
> removed would be "undeployed" from the temporary location (but not from
> the config-store since a hot-deploy item is never included in the
> config-store). This would then result in the application being
> completely removed from the system if it was never fully deployed to the
> config-store or the original, deployed application would then once again
> become the "used" application.
This is where we run into problems. We now have 2 deploy areas with
files that may or may not be representative of the same application.
This is why I believe that if we do this...the jar/war/ear/rar (or what
have you) will disappear - meaning Geronimo deployed it - or had its way
with it. I am going to agree with David Jencks that this should be a
very unstandard way of doing things due to the JSR issues. I think
having 2 deployment areas will cause us a tremendous amount of problems
in ensuring both areas represent the same area. This is why I am saying
it should be for deploy/redploy only and "poof" it is gone. This should
be a development-only tool, and I would like that if we do this, that
its something that needs to be enabled and is not available in the
default configuration.
> - There would be no capability to really undeploy an application that
> has been deployed to the config-store ...only the ability to over-ride
> it or stop over-riding it.
Yes...this was my thinking.
>
> Thoughts?
>
> Joe
>
>>>
>>> What does tomcat allow?
>>>
>>> Sachin
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Jacek
>>>>>>
>>>>
>>
>>
>
Re: The autodeploy feature in Geronimo
Posted by Joe Bohn <jo...@earthlink.net>.
Jeff Genender wrote:
>
>
> Sachin Patel wrote:
>
>> Wouldn't it be more confusing to the user if their file got removed
>> after it got deployed? I feel the point of a "live" directory is for
>> the runtime to be able to react to any changes to it, including
>> deletions. Both Jboss and Websphere's hot deploy capability allow
>> deletions.
>
>
> I would like to get more input on this. I really believe a hot deploy
> directory should be just for that..to deploy/redeploy. There was some
> great discussion in the past on this (check the lists). But I am open to
> this. The problems we will run into this whole idea is managing the
> plans and ensuring the dropped wars/jars/ears/rars/etc are the same in
> the config store. Then, also what about exploded libs?
>
> I wouldn't necessarily say the because WS and JBoss have it, means its
> the right way. How is BEA doing it? We should think about this all the
> way through before going down a path.
>
I agree with the notion that any "hot deploy" directory we deliver
should be only for deploy/redeploy. However, I don't think that makes
it necessary to remove the items once they were deployed. I agree with
Geir that we should keep things there so that you can verify what is
really active at any given time.
I have a somewhat different view on this (perhaps entirely wrong) but
I'd like to toss it out there.
How about if we provide a "hot deploy" location that acts as an
"addition/over-ride" location much the same as adding a library earlier
in a path. I tend to think of this "hot deploy" activity as a developer
activity and so I think most folks running a production server would
follow the traditional deploy, undeploy, redeploy mechanics. Hot-deploy
would most likely be used exclusively in development or to "patch" a
critical problem with a temporary fix.
If this idea has any merit then I would propose the following:
- The hot deploy location would be used as a the initial place to look
for any application or application element prior to looking in the
config-store. Therefore, it could be used to over-ride items from a
previously deployed application.
- New applications added to the hot-deploy location would not be fully
"deployed" in the sense of being added to the config-store. Rather,
they would be deployed to a temporary location (possibly somewhere under
the same hot-deploy location). That will keep the two deployment types
and locations distinct.
- Applications which only existed in the hot deploy location and were
removed would be "undeployed" from the temporary location (but not from
the config-store since a hot-deploy item is never included in the
config-store). This would then result in the application being
completely removed from the system if it was never fully deployed to the
config-store or the original, deployed application would then once again
become the "used" application.
- There would be no capability to really undeploy an application that
has been deployed to the config-store ...only the ability to over-ride
it or stop over-riding it.
Thoughts?
Joe
>>
>> What does tomcat allow?
>>
>> Sachin
>>
>>>
>>>>
>>>>>
>>>>> Jacek
>>>>>
>>>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
Re: The autodeploy feature in Geronimo
Posted by Jeff Genender <jg...@savoirtech.com>.
Sachin Patel wrote:
> Wouldn't it be more confusing to the user if their file got removed
> after it got deployed? I feel the point of a "live" directory is for the
> runtime to be able to react to any changes to it, including deletions.
> Both Jboss and Websphere's hot deploy capability allow deletions.
I would like to get more input on this. I really believe a hot deploy
directory should be just for that..to deploy/redeploy. There was some
great discussion in the past on this (check the lists). But I am open to
this. The problems we will run into this whole idea is managing the
plans and ensuring the dropped wars/jars/ears/rars/etc are the same in
the config store. Then, also what about exploded libs?
I wouldn't necessarily say the because WS and JBoss have it, means its
the right way. How is BEA doing it? We should think about this all the
way through before going down a path.
>
> What does tomcat allow?
>
> Sachin
>
>>
>>>
>>>>
>>>> Jacek
>>>>
>>
Re: The autodeploy feature in Geronimo
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
I said the same thing, but my message never made it. :/
I think you'd want to leave the file there, because then you can
examine it to see what exactly you deployed... You could also take
that exact artifact and give to someone else for deployment elsewhere
(in QA, for example) confident that what you tested is what you gave
out.
geir
On Oct 24, 2005, at 10:16 AM, Sachin Patel wrote:
>
>
> Jeff Genender wrote:
>
>> Sachin Patel wrote:
>>
>>>
>>>
>>> Jacek Laskowski wrote:
>>>
>>> Am I right that the simplest solution is to develop a GBean that
>>>
>>>
>>>> would monitor a directory and hand over a deployable to a deployer?
>>>>
>>>
>>>
>>> This was my thinking as well. The directory would listen for
>>> adds, modifications, and deletions.
>>>
>> I think this may be somewhat confusing. I think when dropping in
>> the directory, it should should deploy...then be immediately
>> removed from the directory. IMHO, this dir should be for hot
>> deploy only. Let the deployer decide if it should be updated or
>> added. I think the deletions should not be done through this
>> dir. We should use the normal undeploy capabilities of the deployer.
>>
>
> Wouldn't it be more confusing to the user if their file got removed
> after it got deployed? I feel the point of a "live" directory is
> for the runtime to be able to react to any changes to it, including
> deletions. Both Jboss and Websphere's hot deploy capability allow
> deletions.
>
> What does tomcat allow?
>
> Sachin
>
>
>>>
>>>
>>>>
>>>> Jacek
>>>>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: The autodeploy feature in Geronimo
Posted by Sachin Patel <sp...@gmail.com>.
Jeff Genender wrote:
>
>
> Sachin Patel wrote:
>>
>>
>> Jacek Laskowski wrote:
>>
>> Am I right that the simplest solution is to develop a GBean that
>>
>>> would monitor a directory and hand over a deployable to a deployer?
>>
>>
>> This was my thinking as well. The directory would listen for adds,
>> modifications, and deletions.
>
> I think this may be somewhat confusing. I think when dropping in the
> directory, it should should deploy...then be immediately removed from
> the directory. IMHO, this dir should be for hot deploy only. Let the
> deployer decide if it should be updated or added. I think the deletions
> should not be done through this dir. We should use the normal undeploy
> capabilities of the deployer.
Wouldn't it be more confusing to the user if their file got removed
after it got deployed? I feel the point of a "live" directory is for the
runtime to be able to react to any changes to it, including deletions.
Both Jboss and Websphere's hot deploy capability allow deletions.
What does tomcat allow?
Sachin
>
>>
>>>
>>> Jacek
>>>
>
Re: The autodeploy feature in Geronimo
Posted by Bobby Abraham <bo...@subtleguru.com>.
On Sun, 2005-10-23 at 16:00 -0600, Jeff Genender wrote:
>
> Sachin Patel wrote:
> >
> >
> > Jacek Laskowski wrote:
> >
> > Am I right that the simplest solution is to develop a GBean that
> >
> >> would monitor a directory and hand over a deployable to a deployer?
> >
> >
> > This was my thinking as well. The directory would listen for adds,
> > modifications, and deletions.
>
> I think this may be somewhat confusing. I think when dropping in the
> directory, it should should deploy...then be immediately removed from
> the directory. IMHO, this dir should be for hot deploy only. Let the
> deployer decide if it should be updated or added. I think the deletions
> should not be done through this dir. We should use the normal undeploy
> capabilities of the deployer.
As a user it would be nice if a copy to the hot-deploy directory had the
effect of an undeploy of any existing application of the same name and
then reployment of the new one. This is the most common use case within
development.
It is also very common for the copy to the hot-deploy directory to be
over a slower network. When this happens it is important to check that
the file is not still being written and avoid deploying an application
before the copy is complete.
There is also the issue of deploying with a separate plan. In this case
I suggest copying the plan first and ignoring it until the application
is copied, then use the plan for the hot deployment and finally remove
both the plan and the application from the hot-deploy directory.
- bobby
--
Bobby Abraham <bo...@subtleguru.com>
Subtle Guru
Re: The autodeploy feature in Geronimo
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 24, 2005, at 12:44 PM, Jeff Genender wrote:
>
>
> Geir Magnusson Jr. wrote:
>
>> On Oct 23, 2005, at 6:00 PM, Jeff Genender wrote:
>>
>>>
>>>
>>> Sachin Patel wrote:
>>>
>>>
>>>> Jacek Laskowski wrote:
>>>> Am I right that the simplest solution is to develop a GBean that
>>>>
>>>>
>>>>> would monitor a directory and hand over a deployable to a
>>>>> deployer?
>>>>>
>>>>>
>>>> This was my thinking as well. The directory would listen for
>>>> adds, modifications, and deletions.
>>>>
>>>>
>>>
>>> I think this may be somewhat confusing. I think when dropping
>>> in the directory, it should should deploy...then be immediately
>>> removed from the directory.
>>>
>> Eeek. I think you'd want it to remain - helps you figure out
>> what exactly has been deployed. IOW you can always look in the
>> dir to see what is supposedly running...
>>
>
> Not necessarily...I think keeping the config store aligned with
> what is in this directory will cause more headaches than not. What
> if the deployment fails? Then what you have in config store will
> not match this directory. This is the problem in having 2
> deployment areas. I really think this needs to be thought through.
I agree. (on the last part)
>
>
>> geir
>>
>>> IMHO, this dir should be for hot deploy only. Let the deployer
>>> decide if it should be updated or added. I think the deletions
>>> should not be done through this dir. We should use the normal
>>> undeploy capabilities of the deployer.
>>>
>>>
>>>
>>>>>
>>>>> Jacek
>>>>>
>>>>>
>>>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: The autodeploy feature in Geronimo
Posted by Jeff Genender <jg...@savoirtech.com>.
David Jencks wrote:
> Well, directory scanning hot deployment is a really bad idea and suffers
> from innumerable problems of this sort and basically cannot be made to
> work. I think we should implement something compatible with other
> implementations of this bad idea and tell people not to use it. This
> means not altering stuff in the hot deploy directory ourselves but
> attempting to monitor it. The other major problem is that it is
> completely incompatible with j2ee 1.4/jsr-88 separation of plans and
> applications. I think we should restrict hot deploy to deploying
> archaic applications with plans inside the application.
I agree with all that you said here DJ...except the not altering of
stuff in the directory. I think we are going to run a huge risk of
getting the config store and hot-deploy out of sync.
>
> Just MNSHO :-)
>
> thanks
> david jencks
>
>>
>>> geir
>>>
>>>> IMHO, this dir should be for hot deploy only. Let the deployer
>>>> decide if it should be updated or added. I think the deletions
>>>> should not be done through this dir. We should use the normal
>>>> undeploy capabilities of the deployer.
>>>>
>>>>
>>>>>>
>>>>>> Jacek
>>>>>>
>>>>
>>
Re: The autodeploy feature in Geronimo
Posted by David Jencks <da...@yahoo.com>.
On Oct 24, 2005, at 9:44 AM, Jeff Genender wrote:
>
>
> Geir Magnusson Jr. wrote:
>> On Oct 23, 2005, at 6:00 PM, Jeff Genender wrote:
>>>
>>>
>>> Sachin Patel wrote:
>>>
>>>> Jacek Laskowski wrote:
>>>> Am I right that the simplest solution is to develop a GBean that
>>>>
>>>>> would monitor a directory and hand over a deployable to a deployer?
>>>>>
>>>> This was my thinking as well. The directory would listen for
>>>> adds, modifications, and deletions.
>>>>
>>>
>>> I think this may be somewhat confusing. I think when dropping in
>>> the directory, it should should deploy...then be immediately
>>> removed from the directory.
>> Eeek. I think you'd want it to remain - helps you figure out what
>> exactly has been deployed. IOW you can always look in the dir to see
>> what is supposedly running...
>
> Not necessarily...I think keeping the config store aligned with what
> is in this directory will cause more headaches than not. What if the
> deployment fails? Then what you have in config store will not match
> this directory. This is the problem in having 2 deployment areas. I
> really think this needs to be thought through.
Well, directory scanning hot deployment is a really bad idea and
suffers from innumerable problems of this sort and basically cannot be
made to work. I think we should implement something compatible with
other implementations of this bad idea and tell people not to use it.
This means not altering stuff in the hot deploy directory ourselves but
attempting to monitor it. The other major problem is that it is
completely incompatible with j2ee 1.4/jsr-88 separation of plans and
applications. I think we should restrict hot deploy to deploying
archaic applications with plans inside the application.
Just MNSHO :-)
thanks
david jencks
>
>> geir
>>> IMHO, this dir should be for hot deploy only. Let the deployer
>>> decide if it should be updated or added. I think the deletions
>>> should not be done through this dir. We should use the normal
>>> undeploy capabilities of the deployer.
>>>
>>>
>>>>>
>>>>> Jacek
>>>>>
>>>
>
Re: The autodeploy feature in Geronimo
Posted by Bruce Snyder <br...@gmail.com>.
On 10/24/05, Jeff Genender <jg...@savoirtech.com> wrote:
> >> Sachin Patel wrote:
> >>
> >>> Jacek Laskowski wrote:
> >>> Am I right that the simplest solution is to develop a GBean that
> >>>
> >>>> would monitor a directory and hand over a deployable to a deployer?
> >>>>
> >>> This was my thinking as well. The directory would listen for adds,
> >>> modifications, and deletions.
> >>>
> >>
> >> I think this may be somewhat confusing. I think when dropping in the
> >> directory, it should should deploy...then be immediately removed from
> >> the directory.
> >
> >
> > Eeek. I think you'd want it to remain - helps you figure out what
> > exactly has been deployed. IOW you can always look in the dir to see
> > what is supposedly running...
>
> Not necessarily...I think keeping the config store aligned with what is
> in this directory will cause more headaches than not. What if the
> deployment fails? Then what you have in config store will not match
> this directory. This is the problem in having 2 deployment areas. I
> really think this needs to be thought through.
How about a deploy dir and if any deployments fail they get moved into
a dir inside the deploy dir named failed (deploy/failed)?
I agree this is very unsophisticated but it's also not our call on
*why* someone should or shouldn't do something. I have to believe that
there must be some way to accomplish this and simply bypass the
sophistication of the jsr-88 contracts (i.e., if you want jsr-88 style
of state tracking then use the deploy tool).
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: The autodeploy feature in Geronimo
Posted by Jeff Genender <jg...@savoirtech.com>.
Geir Magnusson Jr. wrote:
>
> On Oct 23, 2005, at 6:00 PM, Jeff Genender wrote:
>
>>
>>
>> Sachin Patel wrote:
>>
>>> Jacek Laskowski wrote:
>>> Am I right that the simplest solution is to develop a GBean that
>>>
>>>> would monitor a directory and hand over a deployable to a deployer?
>>>>
>>> This was my thinking as well. The directory would listen for adds,
>>> modifications, and deletions.
>>>
>>
>> I think this may be somewhat confusing. I think when dropping in the
>> directory, it should should deploy...then be immediately removed from
>> the directory.
>
>
> Eeek. I think you'd want it to remain - helps you figure out what
> exactly has been deployed. IOW you can always look in the dir to see
> what is supposedly running...
Not necessarily...I think keeping the config store aligned with what is
in this directory will cause more headaches than not. What if the
deployment fails? Then what you have in config store will not match
this directory. This is the problem in having 2 deployment areas. I
really think this needs to be thought through.
>
> geir
>
>> IMHO, this dir should be for hot deploy only. Let the deployer
>> decide if it should be updated or added. I think the deletions
>> should not be done through this dir. We should use the normal
>> undeploy capabilities of the deployer.
>>
>>
>>>>
>>>> Jacek
>>>>
>>
>
Re: The autodeploy feature in Geronimo
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 23, 2005, at 6:00 PM, Jeff Genender wrote:
>
>
> Sachin Patel wrote:
>
>> Jacek Laskowski wrote:
>> Am I right that the simplest solution is to develop a GBean that
>>
>>> would monitor a directory and hand over a deployable to a deployer?
>>>
>> This was my thinking as well. The directory would listen for
>> adds, modifications, and deletions.
>>
>
> I think this may be somewhat confusing. I think when dropping in
> the directory, it should should deploy...then be immediately
> removed from the directory.
Eeek. I think you'd want it to remain - helps you figure out what
exactly has been deployed. IOW you can always look in the dir to see
what is supposedly running...
geir
> IMHO, this dir should be for hot deploy only. Let the deployer
> decide if it should be updated or added. I think the deletions
> should not be done through this dir. We should use the normal
> undeploy capabilities of the deployer.
>
>
>>>
>>> Jacek
>>>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: The autodeploy feature in Geronimo
Posted by Jeff Genender <jg...@savoirtech.com>.
Sachin Patel wrote:
>
>
> Jacek Laskowski wrote:
>
> Am I right that the simplest solution is to develop a GBean that
>
>> would monitor a directory and hand over a deployable to a deployer?
>
>
> This was my thinking as well. The directory would listen for adds,
> modifications, and deletions.
I think this may be somewhat confusing. I think when dropping in the
directory, it should should deploy...then be immediately removed from
the directory. IMHO, this dir should be for hot deploy only. Let the
deployer decide if it should be updated or added. I think the deletions
should not be done through this dir. We should use the normal undeploy
capabilities of the deployer.
>
>>
>> Jacek
>>
Re: The autodeploy feature in Geronimo
Posted by Sachin Patel <sp...@gmail.com>.
Jacek Laskowski wrote:
Am I right that the simplest solution is to develop a GBean that
> would monitor a directory and hand over a deployable to a deployer?
This was my thinking as well. The directory would listen for adds,
modifications, and deletions.
>
> Jacek
>