"max.andersen(a)jboss.com" wrote : I haven't had time to reproduce your scenario, but if WTP default adapters does not work with it then something else is missing. | | Check out the prjoects beta4 of jbosstools (announcing later today, but already available for download) generates for Seam EAR ...it is just using normal WTP funcitonallity. | WTP is working (after I cleaned by deploy/ dir manually of the exploded EAR) and WTPs default mechanism is to deploy to a EAR file (not exploded). FYI: I am already using beta4 (as per the thread subject :-) ). anonymous wrote : Yes - apparently default WTP adapter does not check if the project is already deployed (and possibly exploded) | | Yes - that is the most efficient way of deploying/developing so that is what we do by default. All Agreed. anonymous wrote : * Does it matter that my workspace and my JBoss runtime location are on different file system (different drives), since its not possible to rename files between my workspace and the JBoss runtime location. The IDE must perform a file copy. | | anonymous wrote : I don't understand the question. | | | | Renames/Deletes/Creations in your workspace will automatically be reflected on to the deployment location incrementally. | | | | why should that be affected by them being on different drives ? The Java operation that is "java.io.File#renameTo()" does not work across filesystems (or Drive letters I expect with windows). The only way to move a file from one filesystem to another is with a file copy. With Eclipse you can never assume the workspace filesystem, the project filesystem are the same. In the case with server tooling you can also never assume the filesystem your JBoss runtime is located on is the same as either of the above. For example: Workspace => C:\workspace Project => D:\project JBoss Runtime => E:\JBoss-4.2.1.GA\ So this is why its necessary to copy a file from your project build area into a temporary location in the JBoss Runtime first and then move it (via a rename) to the deploy subdir. * Copy file D:\project\bin\domain\MyClass.class to E:\JBoss-4.2.1.GA\server\default\tmp\MyClass.tmp * Fix modification stamp on E:\JBoss-4.2.1.GA\server\default\tmp\MyClass.tmp * Rename E:\JBoss-4.2.1.GA\server\default\tmp\MyClass.tmp to E:\JBoss-4.2.1.GA\server\default\deploy\MyEAR.war\MyEJB.jar\domain\MyClass.class So as you can see if the implementation of server tooling does not follow the strict methods outline above bad things can happen. For example: * If you try to rename directly from workspace/project into jboss runtime tree, then that wont work and _SHOULD_ indicate error from the #renameTo() call, you are checking all the error returns aren't you ? (another issue some people think it Throws an exception, which it can but most run of mill errors are indicated in the boolean return value). * If you try to fix modification stamp after you make the file visible to the runtime (by putting it into deploy/ subtree) then its possible the runtime will see the old timestamp first. * If you try to copy files directly from workspace/project tree directly into the final destination path then its possible to the runtime will see the partially built file and act upon it. This is one reason why modifications to descriptor should always be done last, like WEB-INF/web.xml is always the last update (reorder it if necessary). * If you try to copy files directly into workspace (by way of file truncation followed by file writes) you will get random crashes when you do this with jars on unix, since the active JVM the container is using cached information from the ZIP header or something but you just modified the contents, so its seeks to the wrong place, decodes something and crashes due to seemly corrupt data, yeah sure the JVMs ZIP implementation needs to be more robust but you cause the problem when you changed the file contents. * Any errors on file manipulation must always be shown to the IDE user, ensure you check the return values correctly. * Ideally when an IDE is making modifications to the a container runtime that is live it needs to do this in co-operation with that container. Basically you need to inhibit the deployer from acting now, even if it sees a timestamp change, while the IDE is will modifying, easiest way to do this is to have the IDE create a file like WEB-INF/deploy-ide-update.properties, which its mere existance makes the container busy loop after the moment it detects a change but before it performs a deployment action because of the detected change; until the file is removed by the IDE. Discussion on one this is best left for another time. The original Tomcat server tooling between WTP 0.7 and WTP 1.5.x was making many of these errors. Some of the reasons were due to a windows way of thinking about the world as opposed to a unix one (a transactional one). anonymous wrote : * When the files are copied are they copied atomically, i.e. each file is copied into tmp/filename.tmp first, then its last modified time is fixed to whatever it needs to be, then its renamed (i.e. moved) to the deploy/whatever/filename.foo. | | anonymous wrote : | | As said earlier, we don't use any tmp location; it is copied from the original location to the deployment. The timestamp will be updated in that process too (if not it's a bug) You can see from my brief outline of some of the problems why using a temporary can be important to get good service from the server tooling. anonymous wrote : please report a bug on this if this is how beta4 behaves (this is a bug that were present in beta3). | I have tested the jbosstools as ear deployment extensively with our EAR structure (which is just WTP) and it works...so if you could attach a project to a jira that shows this error it would be great. | Sure I can put an issue on if this thread doesn't turn up any identifiable cause. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092718#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...