JBoss EAP 6.3 and Wildfly 8.2 publishing error

[ddv]

Hello, I've been experiencing this error, while publishing to either JBoss EAP 6.3 or Wildfly 8.2 from Eclipse.

I am able to reproduce the error with a very simple Spring Boot application at home (Wildfly) and other web applications at work (JBoss EAP).

I don't believe the problem is somehow with Spring Boot as on different projects, different jars were unable to be renamed.

I'm using:
Eclipse Mars
jdk 1.8.0.66

JBoss Tools plugin 4.3

Maven

Windows 7/10

The server is configured to deploy projects as compressed archives.

Building with Maven from Eclipse and from the command line makes no difference.

My user is an administrator in both cases, full rights have been given to the server directory.

I tried so far

     - reinstalling Eclipse and using Luna instead of Mars with JBoss Tools 4.2.3

     - using a newly created workspace

     - recreating the server multiple times

     - using a different jdk version

Nothing helps and frankly I'm getting a bit desperate, because there are no clues for me to follow. If anyone has experienced this before and knows how to fix it, I'd be really thankful.

I'm sorry if this is a wrong forum for this kind of question.

[rob.stryker]

This is a common and long-standing bug on windows for wildfly and eap. Windows basically locks some files (usually .jar files) in the deployments folder for use. This makes it difficult (ie impossible) to do a publish that needs to overwrite that file on windows.

On the bright side, users rarely change their bundled libraries...  well, at least compared to how often they change their own code.

The best workaround for this issue is to stop the server, right-click on the module, and do a full publish. Since the server is stopped, no process on the machine should have a lock on that file anymore, and it will be overwritten safely.  Once the server is started again, odds are you'll only need incremental publishes for most changes in your workspace. These should be able to be published without error, since none of the files being changed are likely to be locked by the server.

I can't seem to locate the WFCore jira issue representing this long-standing bug, but I'll be sure to ask around and see if I can at least point you to proof that the bug is known to exist and it's not just your machine that hates you

[ctomc]

Well no, it is not long standing bug, but rather expected behavior.

jar/class files are locked by classloader on any platform, but only Windows's NTFS file system honors them by not allowing modifications to them.

But when it comes to exploded deployments in most cases replacing jar file with newer version (rename/move) usually works as long as you properly invoke that operation, I say usually as it depends in what kind of state deployment is.

[rob.stryker]

Yeah, as I understand it we simply do a temporaryNewFile.renameTo(existingFile),  but that call is returning as unsuccessful due to the file lock. I guess I'll have to try to replicate and use File Leak Detector - to debug it, but it's not something I replicate often because I so rarely use the windows environment.

[tmader]

I have a case where the publish job can't rename a MANIFEST.MF file to it's final destination. What I am observing is that that the directory that is being deployed (<install>\standalone\deployments\Test.war in my case) has no owner and thus can't be changed. This is on Windows 10/Wildfly 10

[jsmith12333]

Same exact thing here on windows 7, wildfly 10.1 latest. I can redeploy anywhere from 1-4 times, then we get a lock on the manifest file. Using JSF. Happy to help with debug if anyone on the wildfly team has time to look into it.

[ctomc]

Do you see who is holding a lock?

you can use tools like handle or procexp (for gui)

from https://live.sysinternals.com/

to detect what process is holding the lock as it could be either WildFly, Eclipse or even something else like AV software.

once you get the process that is to blame for the lock and if it is in JVM you can use tools like http://file-leak-detector.kohsuke.org/ to see what code in JVM is actually to blame.