"Web App Libraries" causes files to be locked in MyEclipse 2015, 2016 and 2017
When you have "Web App Libraries" added to the build path of a Dynamic Web Project, the jar files in "WEB-INF/lib" may be intermittedly locked. I have reproduced this issue in MyEclipse 2015 Stable 1.0, 2016 CI and 2017 CI.
We use a script that overwrites the contents of the "WEB-INF/lib" folder with our dependencies. (Specifically, this is a Maven plugin that triggers when we run "Maven clean" on our "pom.xml" file. The project itself is not a Maven project, as that seems to bypass the "WEB-INF/lib" folder entirely which is not desirable.)
Sometimes the files are locked, and our script can't clear the folder and overwrite the files.
We'd like to see the MyEclipse team investigate this issue and determine:
1) Why the files are locked in the first place?
2) Is there anything you can do to prevent/mitigate this problem?
This may very well be an Eclipse issue, in which case we'd like to see the problem reported upstream.
Our current workaround is to use a 3rd party tool to clear the lock. This allows our script to overwrite the files. There is a 40/60 chance that MyEclipse crashes (i.e., asks us to close the workbench due to a fatal error).
Sorry you're seeing a new issue and apologies for the delay in responding. It would be better to pursue this on our support forums. We've created a new topic and asked some questions there: https://www.genuitec.com/forums/topic/tomcat-deployment-problem-with-spring-related-jars/#post-536882
Encountered another problem today with deployment.
I receive the following error from MyEclipse. After that it asks me if I want to close to workbench. If I don't agree to this I can continue, but I'll occassionally see the same error message and the Servers view will be frozen. A restart fixes the problem until I need to replace my jar files again.
An internal error occurred during: "Updating status for ATSC Development Tomcat...".
jzentry == 0,
jzfile = 549914128,
total = 607,
name = F:\Workspaces\Git\JB\fitch\fitch\WebRoot\WEB-INF\lib\thirdparty-spring-web-4.3.8.RELEASE.jar,
i = 1,
message = ZIP_Read: error reading zip file
I've noticed that it's always spring-web that's causing the issue. spring-web is also the only jar file visible under my deployments in the Servers view. Is there something special about this library that it affects my Tomcat deployment?
Since our initial report we've modified our script to automatically run LockHunter to remove the locks prior to overwriting the files. Usually this gives no problem, but occassionally we receive an error.
Just received the following exception after forcibly overwriting files:
java.util.zip.ZipError: jzentry == 0,
jzfile = 338948352,
total = 541,
name = F:\Workspaces\MyEclipse\JB\MultiTrader\WebRoot\WEB-INF\lib\atsc-commons-3.6.6.jar,
i = 1,
message = null
Appreciate the prompt and detailed response. Your project is rather basic, and the JDT classloaders do look like the most likely culprits, can't point to anything else that would lock the resources.
There is a recently revived bug over at Eclipse on this same issue, which you can find here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=406170
We may pick up a fix in the next release of Eclipse if the JDT team fixes the issue or be able to patch the plugins responsible if not too dangerous. We'll keep our eyes on this bug to see how it progresses over the next few weeks. Since you can replicate the problem, your team could probably contribute invaluable debugging information as well.
1. Windows 10 Professional, 64-bit. The problem occurs in both the 32-bit and 64-bit versions of MyEclipse 2015, 2016 and 2017.
2. The project is being deployed to a Tomcat server. The files are not shared between the Tomcat instance and the MyEclipse workspace. The problem also occurs if Tomcat is not running at all.
3. The tool "LockHunter" reports that "javaw.exe" keeps the files locked. It specifically points at the JRE used by MyEclipse, not the one used by Tomcat.
4. I have no crash log to provide at this time, as we've always closed the workbench and restarted whenever the issue occurred. I will provide a crash log as soon as one is available. (I have a workspace on a different machine running MyEclipse 2017 where the problem seems to occur every time. I will try to post a crash log of that system as soon as I get to it.)
5. It's a Dynamic Web Project which has the following builders:
The following natures are used:
<classpathentry kind="src" path="src"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="con" path="com.genuitec.runtime.library/com.genuitec.generic_7.0">
<attribute name="org.eclipse.jst.component.nondependency" value=""/>
<classpathentry kind="con" path="org.eclipse.jst.j2ee.internal.web.container"/> <!-- the problem does not occur if this classpathentry is removed (but then we don't have the libraries from WEB-INF/lib on the classpath) -->
<classpathentry kind="output" path="WebRoot/WEB-INF/classes"/>
<installed facet="java" version="1.7"/>
<installed facet="jst.web" version="3.0"/>
<installed facet="wst.jsdt.web" version="1.0"/>
The files are possibly being locked by the Java tools (JDT) classloader, or other loaders that are accessing the libraries to provide code assistance, analytics, etc. Unfortunately hard to say without further analysis.
We have a few questions:
1) What OS is this, I'm assuming it's Windows? What version?
2) How are you deploying the project, and what server are you deploying to?
2.a) Are you using a custom deployment which results in the server using the same resources that are in the workspace? In that case, the server could be locking the files too. Do you find that the files are normally locked only after you deploy?
3) Does the 3rd party tool report what process is locking the files?
4) Could you give us the crash log when ME crashes as a result of releasing the log?
(Consider writing to email@example.com with a link to this post)
5) Can you tell us what sort of project this is? i.e. Dynamic web project + Spring / JSF, etc? You could also send us all the files in the ".settings" folder, we could figure it out from there too.
Hope we'll be be able to figure this out with your support Thank you for reporting the problem and the details.