[Bug 66026] Jars blocked
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #5 from Mark Thomas --- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66026] Jars blocked
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026 --- Comment #4 from Marvin Fröhlich --- (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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66026] Jars blocked
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026 --- Comment #3 from Christopher Schultz --- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66026] Jars blocked
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026 Marvin Fröhlich changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #2 from Marvin Fröhlich --- 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
[Bug 66026] Jars blocked
https://bz.apache.org/bugzilla/show_bug.cgi?id=66026 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID OS||All --- Comment #1 from Mark Thomas --- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org