https://bz.apache.org/bugzilla/show_bug.cgi?id=66026
Marvin Fröhlich <apa...@froehlich-mail.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |REOPENED
--- Comment #2 from Marvin Fröhlich <apa...@froehlich-mail.net> ---
This seems to be a misunderstanding.
First, we don't want to replace jars at runtime in means, that tomcat is
expected to run updated code seamlessly without a restart.
The problem here, and probably a commonly known problem, is, that in
development environments the webapp is version controlled together with jars.
Not only the application's own jars, but all third party jars reside in our
local SVN. Now when I commit new jars to the repository and someone else checks
our and forgets to shutdown tomcat before, SVN update will fail with a file
locked exception and will mark the working copy dirty. I have to shutdown
tomcat, cleanup the working copy, update again and then start tomcat. Some
people even don't see the file locked exception and start working with the
corrupted working copy, which results in strange behavior.
Well, it is true, that in production environments no jar needs to be replaced
without tomcat to be shutdown. But in dev environments it is just nasty, that
you cannot. Of course tomcat needs a restart after that. It's just a nasty
source of failure, that you have to shutdown tomcat first.
Now, that we're using a custom webapp classloader, I would have expected the
same file locking behavior for it like jars from WEB-INF/lib. But it behaves
rather like common class loader. And this seems strange.
It would help to have a switch, that keeps tomcat from locking jars overall,
which we would activate in dev environments.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
