[jboss-user] [JBoss Tools] - Re: Use single folder for WebResources, avoid copying static resources to standalone/deployments/

Rob Stryker do-not-reply at jboss.com
Mon Oct 15 03:11:33 EDT 2012


Rob Stryker [https://community.jboss.org/people/rob.stryker] created the discussion

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

To view the discussion, visit: https://community.jboss.org/message/764741#764741

--------------------------------------------------------------
> 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.
--------------------------------------------------------------

Reply to this message by going to Community
[https://community.jboss.org/message/764741#764741]

Start a new discussion in JBoss Tools at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2128]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20121015/3c485d4a/attachment.html 


More information about the jboss-user mailing list