-
1. Re: JBoss EAP 6.3 and Wildfly 8.2 publishing error
rob.stryker Feb 9, 2016 10:15 AM (in response to ddv)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
-
2. Re: JBoss EAP 6.3 and Wildfly 8.2 publishing error
ctomc Feb 9, 2016 10:54 AM (in response to rob.stryker)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.
-
3. Re: JBoss EAP 6.3 and Wildfly 8.2 publishing error
rob.stryker Feb 12, 2016 6:17 AM (in response to ctomc)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.
-
4. Re: JBoss EAP 6.3 and Wildfly 8.2 publishing error
tmader Apr 6, 2016 4:52 AM (in response to rob.stryker)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
-
5. Re: JBoss EAP 6.3 and Wildfly 8.2 publishing error
jsmith12333 Oct 24, 2017 3:16 PM (in response to tmader)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.
-
6. Re: JBoss EAP 6.3 and Wildfly 8.2 publishing error
ctomc Oct 30, 2017 8:01 AM (in response to jsmith12333)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.