[ https://issues.jboss.org/browse/JBIDE-9101?page=com.atlassian.jira.plugin... ] Andre Dietisheim updated JBIDE-9101: ------------------------------------ Steps to Reproduce: # make sure you have a project that is deployed to an as7 that you run (ex. create a Dynamic Web Project from scratch, add a index.html file to the WebContent folder) # change a single file in your project (ex. index.html) Result: You see in the server log that the deployment is being restarted (ex. my project is called bogus and I catch the following in the server log when changing index.html: {code} 23:02:25,075 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "bogus.war" 23:02:25,298 INFO [org.jboss.web] (MSC service thread 1-7) registering web context: /bogus {code} Expected: The deployment should not get restarted. The file should get replaced by the new one and picked by AS7 instantly (without a restart of the deployment). was: # make sure you have a project that is deployed to an as7 that you run (ex. create a Dynamic Web Project from scratch, add a index.html file to the WebContent folder) # change a single file in your project (ex. index.html) Result: You see in the server log that the deployment is being restarted (ex. my project is called bogus and I catch the following in the server log when changing index.html: {code} 23:02:25,075 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "bogus.war" 23:02:25,298 INFO [org.jboss.web] (MSC service thread 1-7) registering web context: /bogus {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9101?page=com.atlassian.jira.plugin... ] Andre Dietisheim edited comment on JBIDE-9101 at 6/8/11 5:39 PM: ----------------------------------------------------------------- I noticed a 'new' behavior in as7: If I cripple the web.xml (ex. remove a closing xml so that it gets invalid), and do not create a new .dodeploy marker, the server stops the deployment and creates a .undeployed. Our prior implementation, which created a .dodeploy even for incremental changes, had as7 creating a .failed marker instead. IMHO this means for us, that we would have to remove a .undeployed marker in incremental deploys. @Rob: right? was (Author: adietish): I noticed a strange behavior in as7: If I cripple the web.xml (ex. remove a closing xml so that it gets invalid), and do not create a new .dodeploy marker, the server stops the deployment and creates a .undeployed. Our prior implementation, which created a .dodeploy even for incremental changes, had as7 creating a .failed marker instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9101?page=com.atlassian.jira.plugin... ] Andre Dietisheim edited comment on JBIDE-9101 at 6/9/11 6:27 PM: ----------------------------------------------------------------- weird enough I cannot replicate the behavior from the prior comment with manual steps: # make sure you have a exploded war deployed to as7 beta3 # change it's web.xml to something invalid # watch the server log to see if there's any change in the deployment state (according to the above comment as7 should pick the change and undeploy the artifact) Result: AS7 does not change the state of the deployment, it does not pick the change. # now change a resource in your deployment (ex. index.html) Result: AS7 now delivers the changed resource. # now clean Result: The app is not available any more, you get a 404. Afaik this behaves exactly the way it should. was (Author: adietish): weird enough I cannot replicate the behavior from the prior comment with manual steps: # make sure you have a exploded war deployed to as7 beta3 # change it's web.xml to something invalid # watch the server log to see if there's any change in the deployment state (according to the above comment as7 should pick the change and undeploy the artifact) Result: AS7 does nothing, it does not pick the change. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9101?page=com.atlassian.jira.plugin... ] Andre Dietisheim commented on JBIDE-9101: ----------------------------------------- reproducing the issue & talking to rob and emuckenhuber I found out that this definitely is a bug in AS7: AS7-987 The tooling behaves absolutely correct in terms of this issue. I therefore close it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9101?page=com.atlassian.jira.plugin... ] Andre Dietisheim edited comment on JBIDE-9101 at 6/10/11 6:28 AM: ------------------------------------------------------------------ weird enough I cannot replicate the behavior from the prior comment with manual steps, but I experience other strange things: # make sure you have a exploded war deployed to as7 beta3 # change it's web.xml to something invalid # watch the server log to see if there's any change in the deployment state (according to the above comment as7 should pick the change and undeploy the artifact) Result: AS7 does not change the state of the deployment, it does not pick the change. # now change a resource in your deployment (ex. index.html) Result: AS7 now delivers the changed resource. # now clean Result: The app is not available any more, you get a 404. The deployment folder has a .deployed marker though. # now change the web.xml to something valid again and clean. Result: The app is accessible but the deployment folder has a .failed now. was (Author: adietish): weird enough I cannot replicate the behavior from the prior comment with manual steps: # make sure you have a exploded war deployed to as7 beta3 # change it's web.xml to something invalid # watch the server log to see if there's any change in the deployment state (according to the above comment as7 should pick the change and undeploy the artifact) Result: AS7 does not change the state of the deployment, it does not pick the change. # now change a resource in your deployment (ex. index.html) Result: AS7 now delivers the changed resource. # now clean Result: The app is not available any more, you get a 404. The deployment folder has a .deployed marker though. # now change the web.xml to something valid again and clean. Result: The app is accessible but the deployment folder has a .failed now. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9101?page=com.atlassian.jira.plugin... ] Andre Dietisheim resolved JBIDE-9101. ------------------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira