[ https://jira.jboss.org/jira/browse/JBIDE-6243?page=com.atlassian.jira.plu... ] Gary Lamperillo updated JBIDE-6243: ----------------------------------- Attachment: bug3.png bug2.png -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBIDE-6243?page=com.atlassian.jira.plugin.s... ] Max Rydahl Andersen updated JBIDE-6243: --------------------------------------- Fix Version/s: 3.1.2 (was: 3.1.1) Priority: Critical (was: Major) moved of 3.0.1 because not been reproduced by us nor fixed before codefreeze. Marking to be fixed in branch when we can. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBIDE-6243?page=com.atlassian.jira.plugin.s... ] Rob Stryker resolved JBIDE-6243. -------------------------------- Fix Version/s: (was: 3.1.2) Resolution: Cannot Reproduce Bug First, I'm not able to replicate this. Second, it doesn't seem possible at all that deploying and undeploying an application would affect the configuration in this fashion. In a default installation, almost all servers deploy to workspace metadata. For EPP and EAP it seems to be using the default jboss 5.0 setting and deploying to the server's generic deploy folder (server/default/deploy), but, this still doesn't make much sense. Deploying and undeploying a module should publish *only* that blah.war folder and nothing else. In the (unlikely) event the path is wrong and it is deleting the parent folder, it would actually be deleting *everything* inside the server/default/deploy folder... *everything*. In this event, I'm sure you'd see a *much* bigger problem than merely ports not being found. Specifically, the XPath for JNDI is actually somewhere inside server/default/conf. This means the deployment mechanism would have to be accidentally deleting not only the war folder's parent (server/default/deploy) but also it's parent's parent (server/default). I can see nothing anywhere in the code to indicate a removal of some sort would delete server/default or delete server/default/conf, or arbitrarily change server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml So the improbability of it, along with the few hours endlessly debugging and trying to replicate, and finally via looking at the code to see if there was some way this might be happening, has all led me to close this as cannot reproduce. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira