You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2022/04/22 13:13:35 UTC
[Bug 66026] New: Jars blocked
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026
Bug ID: 66026
Summary: Jars blocked
Product: Tomcat 9
Version: 9.0.59
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: apache@froehlich-mail.net
Target Milestone: -----
Jars are being (b)locked when tomcat loads them. When a jar is loaded via
tomcat's central classloader it cannot be deleted or updated (e. g. via SVN).
If the same jar is loaded via WEB-INF/lib it is NOT blocked.
We're now using a custom WebappClassLoaderBase extension to load all of our
jars. And I expected not jar not to be blocked that way. Unfortunately all are.
Is there a bug on our side? Is is expected behavior? Can we do anything here?
Or is it a bug on Tomcat side?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 66026] Jars blocked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
OS| |All
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
JARs loaded via the common class loader are not expected to be replaced while
Tomcat is running. If you did manage to replace a JAR, it is likely you would
start to see ClassNotFoundExceptions or similar.
I'm not surprised these JARs are locked and it isn't a bug that they are.
JAR replacement requires web application reload. If you want to be able to do
that all JARs need to be packaged in WEB-INF/lib.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 66026] Jars blocked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026
Marvin Fröhlich <ap...@froehlich-mail.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |REOPENED
--- Comment #2 from Marvin Fröhlich <ap...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 66026] Jars blocked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> ---
I believe this is your operating system "locking" JAR files. I have never ever
had a problem deleting, updating, replacing, patching, etc. JAR files on Linux,
but evidently on Windows it's generally not possible.
I wonder why you are checking assets out of revision-control directly into the
deployment directory of Tomcat. Or are you you using embedded Tomcat?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 66026] Jars blocked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026
--- Comment #4 from Marvin Fröhlich <ap...@froehlich-mail.net> ---
(In reply to Christopher Schultz from comment #3)
> I believe this is your operating system "locking" JAR files. I have never
> ever had a problem deleting, updating, replacing, patching, etc. JAR files
> on Linux, but evidently on Windows it's generally not possible.
This is true. The classloader doesn't release the jars. And on Windows this
leads to these files being locked, on Linux it doesn't. I had to learn this
myself when I switched to Windows. Though it's still the classloader, that
induces this behavior. The WEB-INF/lib classloader doesn't do that. And I was
surprised to see, that a custom webapp classloader doesn't behave the same way
a WEB-INF/lib classloader does. This is the reason for this ticket.
(In reply to Christopher Schultz from comment #3)
> I wonder why you are checking assets out of revision-control directly into
> the deployment directory of Tomcat. Or are you you using embedded Tomcat?
Well, why not? It is the fastest way of synchronizing the webapp with
development state on a dev machine.
No, we're not using tomcat embedded.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 66026] Jars blocked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Mark Thomas <ma...@apache.org> ---
If your custom class loader is locking files then that is an issue for your
custom class loader.
JARs placed in $CATALINA_BASE/lib will be locked by Tomcat's common class
loader. This is not a bug.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org