4 Replies Latest reply on Apr 6, 2016 4:52 AM by Thomas Mäder

    JBoss EAP 6.3 and Wildfly 8.2 publishing error

    Daniel Vladimirov Newbie

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

       

      problem.jpg

       

      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.

        • 1. Re: JBoss EAP 6.3 and Wildfly 8.2 publishing error
          Rob Stryker Master

          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
            Tomaz Cerar Master

            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 Master

              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
                Thomas Mäder Newbie

                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