1 2 Previous Next 29 Replies Latest reply on Oct 15, 2007 8:38 AM by Darryl Miles

    WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing correctly

    Darryl Miles Novice

      When I publish an EAR project from my workspace into JBoss 4.2.1 it does not publish correctly. I have tried both the WTP supplied 4.2 driver and the JBossAS-Tools supplied 4.2 driver.


      My JBoss runtime is at /opt/jboss-4.2.1.GA this directory tree is writable by my userid, also exists is $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2 which is also being published too as well as.


      After a successful publish operation (successful from looking at the GUI, but unsuccessful from looking at the JBoss log) the following things happen:

      The JBoss runtime home (/opt/jboss-4.2.1.GA/data/opt/jboss-4.2.1.GA/server/default/deploy/) ends up with an exploded EAR directory (this is the name of my project with the .ear extension but its a directory not a file), inside this directory is all the other subdirectories that make up the tree, but the only file in there is that of a Utility JAR. There was no META-INF/application.xml and there is no EJB implementation JAR.

      In the workspace server plugin temporary area for this server instance ($HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2) I find an EAR file (which internally has my META-INF/application.xml, my Utility JAR and my EJB JAR). It also has a directory (same name as EAR but without the .ear extension) this has all 3 files I'd expect to see in an exploded EAR tree.


      When looking at the launch configuration for JBoss I can't see where the workspace deployment location is specified in the configuration, so I can only presume that what JBoss sees is only the file copied into the runtime home. Unlike Tomcat which can have a read-only runtime home but a read-write instance tree allowing for the sharing of the container by multiple instances in server tooling.


      What copies the files during deployment into the JBoss runtime tree ?

      Is there anyone who is actually using the server tools successfully in this way ? If so what versions of things to you have installed ?

      I'm using: Eclipse 3.3.1, WTP 2.0.1, JBoss 4.2.1, JBossAS-Tools-1.0.0.beta4


      Thanks, Darryl

        • 1. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
          Max Rydahl Andersen Master

          We don't use any temporary publishing location; so that must be something the WTP supplied 4.2 driver uses.

          What kind of project are you publishing ?

          For me the projects that is created with Seam project wizard works just like it should here.

          Maybe you haven't specified the right dependencies between projects and j2ee module artifacts in WTP ?

          With respect to where we deploy then currently it just goes to the default location inside jboss (which depends on your JBoss configuration choice)



          • 2. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
            Darryl Miles Novice

            Hi Max thanks for the reply.

            Okay this is what I can tell you about things:

            I have an "EAR Project" called "EAREclipseManager", this has 2 artifacts added to it. These are 1 x "J2EE Utility project" called "TheLibrary" and 1 x "EJB Project" called "TheEJB".

            If I do a project properties on the "EAR Project" under "J2EE Dependancies" I has a tick for both of the other two projects set. The EAR Project has the Project Facet "EAR" set to "5.0", Project References also has a tick for both of the other two projects set, Seam Support is disabled (no tick in box), Targetted Runtime is : JBoss AS 4.2.

            Is is the encapsulating EAR project I am trying to publish. I don't think I need to do anything special with the project settings of the 2 contributing projects do I ?

            The deployment appears to be attempted in:

            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheLibrary.jar
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/META-INF/
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/META-INF/
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ejb/
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ejb/manager/
            /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ejb/manager/test/
            



            Hmm... when I run a "clean" function from the server tooling with the WTP provider driver I get an error:

            [jar] Building jar: $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/EAREclipseManager.ear
             [move] Moving 1 file to /opt/jboss-4.2.1.GA/server/default/deploy
            
            BUILD FAILED
            /opt/eclipse/plugins/org.eclipse.jst.server.generic.jboss_1.5.105.v200709061325/buildfiles/jboss323.xml:33: Failed to copy $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/EAREclipseManager.ear to /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear due to /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear (Is a directory)



            Is it possible to confirm 2 things:

            * Which method of deployment does JBossTool-AS use, does it create an exploded EAR ? When it created that exploded EAR does it create a directory with a ".ear" extension in the deploy directory ? Does an exploded EAR need to have a .ear extension so its treated correctly by the correct deployer ?

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

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

            There are other such things which should take place when updating a working runtime but maybe more on that once I have the basic thing ticking along.


            Okay I have manually cleaned the JBoss deploy directory of my project and let the WTP JBoss driver do its stuff and it create an .ear file in the correct directory and when JBoss starts it finds both application.xml and my TheEJB.jar implementation.

            I cleaned things again and tried with the JBossTool-AS driver and it created a directory with .ear extension, the tree is just like I put in the CODE block above, with AREclipseManager.ear/TheLibrary.jar being the only file and the application.xml and the .class files are all missing. So the problem for me appears to be with the JBossTool-AS driver (which is my preferred choice).


            Would there be any call to allow JBoss to take a command line property to configure a 2nd and alternative deployment directory ? The purpose of this would be to allow for a Tomcat like situation where the workspace area could be used for the deployment, when you just alter the driver to contribute the property to the launch configuration when it sets things up. Okay it would not be 100% compatible with tomcat since the work, tmp, log, etc.. directories would also need to be picked up based on the alternative path too. Just a thought, since it would seem difficult for "clean" to mean clean if the deploy directory was not empty to start with.

            • 3. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
              Max Rydahl Andersen Master

               

              "dlmiles" wrote:
              Hi Max thanks for the reply.

              Okay this is what I can tell you about things:

              I have an "EAR Project" called "EAREclipseManager", this has 2 artifacts added to it. These are 1 x "J2EE Utility project" called "TheLibrary" and 1 x "EJB Project" called "TheEJB".

              If I do a project properties on the "EAR Project" under "J2EE Dependancies" I has a tick for both of the other two projects set. The EAR Project has the Project Facet "EAR" set to "5.0", Project References also has a tick for both of the other two projects set, Seam Support is disabled (no tick in box), Targetted Runtime is : JBoss AS 4.2.

              Is is the encapsulating EAR project I am trying to publish. I don't think I need to do anything special with the project settings of the 2 contributing projects do I ?


              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.


              /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/
              


              Yes - that is where our WTP adapter would put things by default if your chosen configuration is the one named "default" and your project is called EAREclipseManager.


              Hmm... when I run a "clean" function from the server tooling with the WTP provider driver I get an error:

              [jar] Building jar: $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/EAREclipseManager.ear
               [move] Moving 1 file to /opt/jboss-4.2.1.GA/server/default/deploy
              
              BUILD FAILED
              /opt/eclipse/plugins/org.eclipse.jst.server.generic.jboss_1.5.105.v200709061325/buildfiles/jboss323.xml:33: Failed to copy $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/EAREclipseManager.ear to /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear due to /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear (Is a directory)



              Yes - apparently default WTP adapter does not check if the project is already deployed (and possibly exploded)


              * Which method of deployment does JBossTool-AS use, does it create an exploded EAR ?


              Yes - that is the most efficient way of deploying/developing so that is what we do by default.


              When it created that exploded EAR does it create a directory with a ".ear" extension in the deploy directory ?


              Yes.


              Does an exploded EAR need to have a .ear extension so its treated correctly by the correct deployer ?


              that was at least the case when we starting doing the exploded development; that might have changed in JBoss 4.2, but I do not think so.


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


              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 ?


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


              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)


              I cleaned things again and tried with the JBossTool-AS driver and it created a directory with .ear extension, the tree is just like I put in the CODE block above, with AREclipseManager.ear/TheLibrary.jar being the only file and the application.xml and the .class files are all missing. So the problem for me appears to be with the JBossTool-AS driver (which is my preferred choice).


              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.


              Would there be any call to allow JBoss to take a command line property to configure a 2nd and alternative deployment directory ?


              The JBoss 4.2 runtime currently is fixed to the deploy dir in the configuration; there is an jira issue for allowing an alternate location.


              The purpose of this would be to allow for a Tomcat like situation where the workspace area could be used for the deployment, when you just alter the driver to contribute the property to the launch configuration when it sets things up. Okay it would not be 100% compatible with tomcat since the work, tmp, log, etc.. directories would also need to be picked up based on the alternative path too. Just a thought, since it would seem difficult for "clean" to mean clean if the deploy directory was not empty to start with.


              there is also the option of using the "deploy only" runtime; where don't do anything but just maintaing a deployed directory.

              • 4. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
                Darryl Miles Novice

                 

                "max.andersen@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 :-) ).

                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.


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

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


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


                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.


                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.

                • 5. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
                  Max Rydahl Andersen Master

                  Ok - long thread, let me shorten it down.

                  No - we don't use renameTo(), we use copy. What we do in case of updates I'll need to check in code - or maybe even get rob to chime in.

                  And I've never bumped into these issues and I run both on Linux and Windows...maybe my machine is just too fast ...

                  The descriptor is not updated before the user actually updates it, but I can see how it might be relevant when doing a full update.

                  With respect to the deployer ignoring updates if a certain file is present that is something I always thought about doing but is it really an issue in day-to-day dev ?

                  I think you raise some valid issues, I'll point Rob to this thread; but I would also really like to have concrete examples of things actually failing because of these things (your missing files is not one of them as far as i can see - they might be a cause of something else which we definitly needs fixing)

                  • 6. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
                    Max Rydahl Andersen Master

                    btw. timestamps are updated and since the existing file won't change timestamp before the touch it should be fine (in most cases)

                    Anyway ;)

                    • 7. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
                      Max Rydahl Andersen Master

                      Another thought is that a ant build file doing incremental updates would have the exact same issues....

                      • 8. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
                        Rob Stryker Master

                        We don't use renaming or temporary locations at all. Everything is done with a file copy.

                        I'm relatively certain eclipse doesn't fire any resource changed events until after it's sure the local filesystem has finished writing those changes... so that only leaves the step between the workspace / fs and then runtime / fs.

                        The only thing I can think of right now that'd be best for incremental deployment (or even a new full publish) is to see if I can turn off the deployment scanner during a publish and turn it back on directly thereafter. This would probably be done with jmx.

                        I can look into this.

                        • 9. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
                          Rob Stryker Master

                          i'm still unable to reproduce the problems you mentioned at the beginning of the thread.

                          • 10. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
                            Max Rydahl Andersen Master

                            rob, invoking jmx between every update sounds like overkill to me....can't be fast, can it ?

                            • 11. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
                              Darryl Miles Novice

                               

                              "max.andersen@jboss.com" wrote:
                              No - we don't use renameTo(), we use copy. What we do in case of updates I'll need to check in code - or maybe even get rob to chime in.


                              Do you copy in situation ? This is what tomcat driver used to do in WTP0.7 thru WTP1.0 or so. Copy in situation means to me you take the existing file, truncate it, then write blocks of data repeatably to it, then close the file.

                              The file instance is the same after the copy as it was before the copy. This can cause the JVM to crash when applied to JARs which change. I would get between 5 JVM crashes a day on Linux when developing for Tomcat, this is always because I had a contributing J2EE Utility project which I was also developing in parallel to the web-app.

                              The problem is that the JVM holds an open descriptor to the file and possibly has a mmap() in place for the contents and continues to access it, expecting the old contents to be there. You can't change contents from under the JVM, you need to make a new file instance and replace (on unix, on windows file locking becomes an issue and was the reason for the broken methodology in the TC driver in the first place)


                              And I've never bumped into these issues and I run both on Linux and Windows...maybe my machine is just too fast ...


                              True the window of time problem can be made visible with a slower machine. Getting a faster machine can cover up the problem but none the less there is a design issue.


                              The descriptor is not updated before the user actually updates it, but I can see how it might be relevant when doing a full update.


                              Okay another beef I have here is that tools like XDoclet which modify descriptor don't do a replace-if-modified check after they build the new descriptor file. This means the timestamps on descriptors can keep incrementing when the contents were computed to be the same as the previous version. So there are cases where the user may not have actually modified a descriptor but the system did it for them (or rather the system modified a dependency which causes a rebuild of the descriptor but it turns out no change to the descriptor resulted).. This is very annoying and non productive to a developer.

                              The tooling uses incremental updates anyway for the large parts everything I'm saying relates to that.


                              With respect to the deployer ignoring updates if a certain file is present that is something I always thought about doing but is it really an issue in day-to-day dev ?

                              I think you raise some valid issues, I'll point Rob to this thread; but I would also really like to have concrete examples of things actually failing because of these things (your missing files is not one of them as far as i can see - they might be a cause of something else which we definitly needs fixing)


                              Its too soon for me to say if IMHO its a issue in day-to-day, certainly in tomcat the develop-run-test cycle is faster especially in relation to JSPs. So it did make a difference there.

                              This is early days for me using JBossTools-AS the large part of this comment is really clarifying the issues I found with TC which has now been fixed in WTP so I'm happy to provide the heads up and make you think in this realm about these matters.

                              But sure I don't have any concrete examples of bad things with JBossTools-AS at this moment because I've not gotten past the basic functionality of deploying an app. :)



                              "max.andersen@jboss.com from another post" wrote:
                              Another thought is that a ant build file doing incremental updates would have the exact same issues....


                              My thoughts here are I don't care as I always considered such ant tasks broken by design and have done deployment by copying a file to "default/deploy/MyEAR.tmp" and then renaming the file to "default/deploy/MyEAR.ear" to make it visible to the deployer with a trivial script.


                              One problem here is that Windows really doesn't have a transactional file system, it does not allow files that are open by another process to be deleted or renamed (not in Win2000 and Win98SE etc..) the concept was an after thought to the windows API added to WinXP. It does not allow a transactional rename, i.e. because the target of the rename has to be deleted first, and it can only be deleted if no other process has it open, so there is a window of time when another process will see no file exists.

                              Unix on the other hand does have a transactional file system the semantics of which are mandated by POSIX. It does allow a file than is open by another process to be deleted and/or renamed. It does have a rename() call which will replace the existing target atomically.

                              Unix has had very specific semantics for dealing with updating files atomically for many years, take the example of updating /etc/passwd to add a new account, what horrors would result if the /etc/passwd file for just a moment didn't exist, because another process deleted it before doing a rename of the /etc/passwd.tmp to /etc/passwd. The correct way of dealing with these issues was solved many years ago, its a shame none of it rubbed off on the windows platform.

                              IMHO J2EE stuff should have slightly different implementations to deal with each systems capabilities and quirks. The unix implemention would be pretty simple, the windows implementation can deal with file locking and other such hoops you're made to jump through.


                              "max.andersen@jboss.com from another post" wrote:
                              btw. timestamps are updated and since the existing file won't change timestamp before the touch it should be fine (in most cases)


                              The timestamp issue is mainly about not missing a lost update. i.e. imagine there are 2 updates in the workspace for a file queued in the event system, due to the speed of the system the first update is being pushed out to server runtime now.

                              Due to the copy in situation method of updating the modification date of the file is related to the write's currently being performed on the file. This timestamp is after the timestamp of the 2nd update already queued into the system and the runtime notices the timestamp on the file and takes action.

                              Now the IDE runtime driver completes the update, and keeps processing and eventually gets to work on another update on the same file. This time it writes the file out in situation again and then fixes the last modification timestamp after the last write. This time the server runtime due to it being busy only sees the file after the last modification was fixed, but this modification stamp is older than the last one so it ignores the update.

                              Copying to a temporary first, fixing the timestamp, then moving the file to its rightful position closes the door on this issue too.

                              IMHO the deployers should not care if a timestamp is older or newer, it should only care if the timestamp is different (as in !=) to the one its holding for the last deployment action.


                              All of these issues have further reaching consequences to provide robustness of implementation in the J2EE environment than just server tooling, it doesn't hurt to think and appreciate these matters.

                              "rob.stryker@jboss.com from another post" wrote:
                              I'm relatively certain eclipse doesn't fire any resource changed events until after it's sure the local filesystem has finished writing those changes... so that only leaves the step between the workspace / fs and then runtime / fs.

                              The only thing I can think of right now that'd be best for incremental deployment (or even a new full publish) is to see if I can turn off the deployment scanner during a publish and turn it back on directly thereafter. This would probably be done with jmx.


                              I'm only talking of the copy from workspace (or rather "project space" build area) to runtime in all of my comments here.

                              Sure on JMX if thats a way to go, the existence of a file idea was simply the most lightweight method I could think (that would also work with tomcat), but ideally both are good as JMX can work across a network (for when you have a remote deployment feature). Also the choice on using a .properties file would also allow communication between the IDE and the deployer for quick easy parsing, there are a number of useful issues that an IDE might want to convey to a deployer, for example in the case of Tomcat when taglibs are updated asking the container to flush its tag cache. So you end up with 2 well known file name paths, one used when the IDE is active and that file is then renamed to another filename when the IDE is inactive but has instructions it want the deployer to know about by parsing the .properties file.

                              This would then lead on to the deployer also writing out a .properties file to communicate with the IDE in the opposite direction. So the IDE didn't modify when the deployer was active.

                              The feature if it carries any performance bottleneck might be best served with a tickbox to disable it within the server runtime instance configuration in the server tooling.


                              Hopefully food for thought.

                              • 12. Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
                                Darryl Miles Novice

                                 

                                "rob.stryker@jboss.com" wrote:
                                i'm still unable to reproduce the problems you mentioned at the beginning of the thread.


                                Thanks for the feedback that it works with your setups (Max/Rob), so I have investigated some more. I have confirmed I am running beta4 (just to be sure).

                                My conclusion is that there is indeed a problem when the JBoss runtime is not on the same file system as the "project build area". As I setup another runtime in my home directory and that published with the JBossTools-AS fine.

                                I then moved this same runtime instance to another file system, and manually cleaned the servers/default/deploy/MyEAR.ear/ directory from it and proceeded to setup a new runtime in this location too (I could not edit the runtime home on the existing instance it would not let me). When I published I got the directory tree created and the MyJAR.jar (a Utility JAR for the EAR classpath) but none of the other files were created.

                                So I would guess that you too are not doing a file copy but a rename, just to be clear its only the final step of making the file visible to the runtime that interests me and indeed is what this thread concerns, you can use whatever method/algorithm you like in preparation for that final setup.


                                I shall find or open a new JIRA now, I don't think its difficult to recreate, type 'df' from linux to understand your filesystem layout and then use 'df /home/myuser/workspace' and 'df /somewhere/jboss-4.2.1.GA' to verify the two locations are on different file system.

                                If you don't have a big enough alternative filesystem with your linux install, then create a loopback one:

                                dd if=/dev/zero of=/tmp/bigfile.ext2 bs=1k count=163840
                                /sbin/mke2fs /tmp/bigfile.ext2
                                # Say Yes to proceed
                                mkdir /mnt/loop
                                su
                                # Enter root password
                                /bin/mount -o loop -t ext2 /tmp/bigfile.ext2 /mnt/loop
                                df /mnt/loop
                                cd /mnt/loop
                                unzip jboss-4.2.1.GA.zip
                                
                                # To tear it down as root
                                /bin/umount /mnt/loop
                                rm /tmp/bigfile.ext2
                                



                                I can't speak for Windows, but I would have expected using different drive letters would have the same effect.


                                1 2 Previous Next