You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kent Tong <ke...@cpttm.org.mo> on 2007/02/25 05:56:11 UTC
reload on demand?
Hi,
In a development environment it's desirable to reload a webapp if any of
its class files has been changed. I know about the reloadable flag, but
it will keep reloading the webapp whenever a change is made and slows down
the computer. Instead, I'd like to reload it on demand, ie, when it is
accessed again. Is it a desirable feature? It shouldn't be that hard to
implement (invoke the reload logic before any access to the webapp instead
of from a background scheduler).
Yes, I know about the reload function in the Tomcat manager. But it requires
two manual steps: first, reload the webapp; second, access a page in the
webapp.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: reload on demand?
Posted by Kent Tong <ke...@cpttm.org.mo>.
Christopher Schultz <chris <at> christopherschultz.net> writes:
> I'm suggesting that you only deploy when you need to (even just copying
> files into your exploded WAR area). Are you updating your app many times
> more often than you want to reload it? Why?
Because the project output folder in Eclipse is set to context/WEB-INF/classes,
so every time a Java file is saved, the .class file is updated and the webapp
is reloaded. What's I'd like is to not reload it then, but only when I access
the webapp.
I could set up the output folder to somewhere else and copy it to the
exploded area only when I'd like to test run it. But this takes an
extra manual step (copy) in addition to accessing the webapp in a
browser.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: reload on demand?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kent,
Kent Tong wrote:
> Christopher Schultz <chris <at> christopherschultz.net> writes:
>
>> Why not only copy your new WAR file (or classes, etc.) to the deployment
>> directory when you actually want the webapp to reload?
>
> Creating a WAR file and copying it takes quite a lot of time. So, the
> webapp is setup as an exploded directory. What's missing is reload
> it on demand.
I'm suggesting that you only deploy when you need to (even just copying
files into your exploded WAR area). Are you updating your app many times
more often than you want to reload it? Why?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF4va/9CaO5/Lv0PARApVBAKCBVYXvB7VYXouInqM6/PpW+A407QCghgcB
E0KskEqZpq4BEfFxMtsR31A=
=7hpm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: reload on demand?
Posted by Kent Tong <ke...@cpttm.org.mo>.
Christopher Schultz <chris <at> christopherschultz.net> writes:
> Why not only copy your new WAR file (or classes, etc.) to the deployment
> directory when you actually want the webapp to reload?
Creating a WAR file and copying it takes quite a lot of time. So, the
webapp is setup as an exploded directory. What's missing is reload
it on demand.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: reload on demand?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kent,
Kent Tong wrote:
> John McPeek <spambomb <at> bellsouth.net> writes:
>
>> If you use eclipse and WTP it does all that for you. Then you can spend
>> almost 0 time thinking about start/stop/reload stuff.
>
> Thanks for the reply. However, it will reload the webapp whenever
> a change is made, just like setting reloadable to true and will
> slow down the computer.
Why not only copy your new WAR file (or classes, etc.) to the deployment
directory when you actually want the webapp to reload?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF4uVS9CaO5/Lv0PARAuoRAKCoy/a3TI6UrlFttMuH/iFsZ+N+xQCgwvc2
B3C77gSFdFfg1/x2bS9Xl68=
=Fa0l
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: reload on demand?
Posted by Kent Tong <ke...@cpttm.org.mo>.
John McPeek <spambomb <at> bellsouth.net> writes:
> If you use eclipse and WTP it does all that for you. Then you can spend
> almost 0 time thinking about start/stop/reload stuff.
Thanks for the reply. However, it will reload the webapp whenever
a change is made, just like setting reloadable to true and will
slow down the computer.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: reload on demand?
Posted by John McPeek <sp...@bellsouth.net>.
Hi Kent,
If you use eclipse and WTP it does all that for you. Then you can spend
almost 0 time thinking about start/stop/reload stuff.
John
>Hi,
>
>In a development environment it's desirable to reload a webapp if any of
>its class files has been changed. I know about the reloadable flag, but
>it will keep reloading the webapp whenever a change is made and slows down
>the computer. Instead, I'd like to reload it on demand, ie, when it is
>accessed again. Is it a desirable feature? It shouldn't be that hard to
>implement (invoke the reload logic before any access to the webapp instead
>of from a background scheduler).
>
>Yes, I know about the reload function in the Tomcat manager. But it requires
>two manual steps: first, reload the webapp; second, access a page in the
>webapp.
>
>
>
>
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: reload on demand?
Posted by Kent Tong <ke...@cpttm.org.mo>.
Paul Singleton <paul <at> jbgb.com> writes:
> Are you serious?! Our developers rely on Hot Code Replacement to
> enable them to continue debugging after changes to program logic,
> and only restart if they want/need to or if HCR fails (e.g. because
> they added/altered a public member signature etc.). They would
> not be happy with your policy!
I don't think we're talking about the same thing. I don't rely
on the debugger as heavily as your developers. I like implement
each feature bit by bit and test run each bit. This has nothing
to do with the debugger.
> Don't you run tests after changing your apps?
If it doesn't reload, how can I run the tests?
> I (think I) understand your Wish, but I reckon they way you work
> is so unusual that you won't be able to rally much support for it.
You mean that the reloadable flag is useless? Marty Hall strongly
suggests setting it to true for development (ref:
http://www.coreservlets.com/Apache-Tomcat-Tutorial).
> In our apps, it's initialisation of the application bean that takes
> time, and this happens at first request, not at reload.
If for some reason you have to perform lengthy initialization, it
may make sense to make the edit-reload-test cycle longer. However,
this is just your case. There are many webapps under development
that doesn't require length initialization.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: reload on demand?
Posted by Paul Singleton <pa...@jbgb.com>.
Kent Tong wrote:
> In a development environment it's desirable to reload a webapp if any of
> its class files has been changed.
Are you serious?! Our developers rely on Hot Code Replacement to
enable them to continue debugging after changes to program logic,
and only restart if they want/need to or if HCR fails (e.g. because
they added/altered a public member signature etc.). They would
not be happy with your policy!
> I know about the reloadable flag, but
> it will keep reloading the webapp whenever a change is made and slows down
> the computer. Instead, I'd like to reload it on demand, ie, when it is
> accessed again.
Don't you run tests after changing your apps? ;-)
> Is it a desirable feature? It shouldn't be that hard to
> implement (invoke the reload logic before any access to the webapp instead
> of from a background scheduler).
I (think I) understand your Wish, but I reckon they way you work
is so unusual that you won't be able to rally much support for it.
In our apps, it's initialisation of the application bean that takes
time, and this happens at first request, not at reload.
> Yes, I know about the reload function in the Tomcat manager. But it requires
> two manual steps: first, reload the webapp; second, access a page in the
> webapp.
Paul Singleton
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org