1 Reply Latest reply on Oct 15, 2012 3:11 AM by rob.stryker

    Use single folder for WebResources, avoid copying static resources to standalone/deployments/

    mmg1

      After many years coding with Java EE and JBoss, there is still a advantage when using PHP+Apache/Nginx/XAMPP: immediate visiblity of changes on static web resources (HTML, JS, CSS). The reason is clear: everything is in a *single* folder, PHP files doesn't need to be compiled/recompiled. But static resources doesn't need to be recompiled, so why not let JBoss directly serve static resource instaed of let Eclipse copying them to a secondary folder?

       

      PROBLEM

      Eclipse *tries* to detect changes in Java classes and static web resources in WebContent (HTML, JS, CSS), but in many cases it takes many seconds until modifications on static resources in WebContent\ are visible on JBoss.

       

      I noticied that Eclipse *copies* folder WebContent\ to JBOSS\standalone\deployments\ when it detects changes. In my case the folders are c:\Users\dell\workspace\DynamicWeb\WebContent\ and d:\software\jboss7.1.1Final\standalone\deployments\DynamicWeb.war\.

       

      The problem is *not* that Eclipse is not smart enough to detect changes immediately (is there no inotify in Windows 7?), but that there are two *seperate* folders that it needs to copy/synchronize.

       

      SOLUTION

      Why not let JBoss AS directly serve static resources from c:\Users\dell\workspace\DynamicWeb\WebContent\ to avoid introducing the lag introduced by copying folders? This avoids the need for a second folder in JBOSS\standalone\deployments\DynamicWeb.war\

       

      When there is only a single folder, there is no need to copy or redeploy a project when only simple static resources (HTML, JS, CSS) changed. Only when Java classes are changes, but that's OK and not avoidable.

       

      Also, I don't understand why the server adapter "JBossAS Tools" uses manual deploy with "touch DynamicWeb.war.dodeploy" instead of directly using the JBoss API to deploy and make changes visible?

       

      PREQUISITES

      I downloaded and extracted fresh copies of "Eclipse IDE for Java EE Developers" and "JBoss AS Brontes 7.1.1Final". I extracted JBoss AS in d:\software\jboss7.1.1Final\.

       

      In Eclipse I switched to the "Java EE" perspective and addedd JBoss as a new Server. For this I needed to download a new adapter called "JBossAS Tools". I didn't install complete JBoss Tools for Eclipse.

       

      I created a new "Dynamic Web Project" in Eclipse. The project files are located in c:\Users\dell\workspace\DynamicWeb\. I added the project ("Add and Remove") to the JBoss AS.

        • 1. Re: Use single folder for WebResources, avoid copying static resources to standalone/deployments/
          rob.stryker

          > Also, I don't understand why the server adapter "JBossAS Tools" uses manual deploy with "touch DynamicWeb.war.dodeploy" instead of directly using the JBoss API to deploy and make changes visible?

           

          Many users do not expose their management ports, and so we use the .dodeploy mechanism to ensure all deployments get published.

           

          > Why not let JBoss AS directly serve static resources from c:\Users\dell\workspace\DynamicWeb\WebContent\ to avoid introducing the lag introduced by copying folders? This avoids the need for a second folder in JBOSS\standalone\deployments\DynamicWeb.war\

           

          IF you can suggest how a deployment named DynamicWeb.war can point it's static resources to another folder, please go into more details and we'll consider it. However, somehow, this seems very strange to me. You'd have one project in eclipse named DynamicWeb, and then you only want the actual .class files published to the standalone/deployments folder, and you want all static resources to remain and be served out of eclipse?  I really can't imagine this project structure at all.

           

          > I noticied that Eclipse *copies* folder WebContent\ to JBOSS\standalone\deployments\ when it detects changes. In my case the folders are c:\Users\dell\workspace\DynamicWeb\WebContent\ and d:\software\jboss7.1.1Final\standalone\deployments\DynamicWeb.war\.

           

          The copy is almost instantaneous and has been tested on files large and small. It is the same speed as a filesystem copy, pretty much.

           

          > Eclipse *tries* to detect changes in Java classes and static web resources in WebContent (HTML, JS, CSS), but in many cases it takes many seconds until modifications on static resources in WebContent\ are visible on JBoss.

           

          Your validators may be running slowly, which may delay the publish event. I don't believe the two are related, but it is a possibility.

           

          I'd like to note that any incremental publishes do NOT use the .dodeploy mechanism. Incremental publishes only simply copy files, and that's it. There's no waiting for redeployment. Unless you're using a zipped deployment. If you're using the zipped deployment options, then yeah, everything needs to be zipped up and copied on every publish (incremental or full), and the dodeploy is called. (However, even in this case we use a library called truezip which really really speeds up the re-zipping of the archive with only the changed data... )

           

          If however you're not using zipped deployment, and you change 3 html files in a 10,000 file project, ONLY those 3 files will be copied, and .dodeploy will not be called, and the server will not have to redeploy the changes.  THe changes will be served directly out of the standalone/deployments/YourWeb.war/blah folder.

           

           

          And finally, many users have successfully used JRebel in combination with JBoss Tools to help speed up some parts. You might consider looking into that.

           

          But as for your idea of somehow deploying all the real resources of a web project to standalone/deployments but serving html, css, etc files directly out of eclipse, I simply can't imagine a project structure that would support that.