[ https://issues.jboss.org/browse/JBIDE-11297?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-11297: ------------------------------------- In AS7, scanners added are persistent even across server restarts. This is important to note for several reasons. Adding the same scanner name twice will result in an error. Two scanners by different names scanning the same path will attempt to deploy the artifact twice. This results in a strange situation where it is added, then undeployed, then added by the second scanner, but undeployed by the second scanner due to the .undeployed marker. So care must be taken that a predictable naming strategy is used for our scanners and that such changes are carefully tracked and maintained by the tools. Note: Previous versions did not persist through app server restarts, and so it was safe to add new scanners or new paths at startup almost without any care. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11297?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-11297: ------------------------------------- The properties file that was being used to store this information has been deprecated (actually just removed since it was never in wide usage). A scanner's name is determined by taking the list of current scanners and finding the first scanner name beginning with the prefix JBossToolsScanner and ending with a number which is unused. Therefore given scanners "Hello", "Hello6", "JBossToolsScanner6", "JBossToolsScanner1", the name of the newly added scanner will be JBossToolsScanner2. The list of currently used scanners, no longer stored in a properties file, is now retrieved directly from the server. So the server tells us what scanners are added. If this workspace, or even this server-view server instance, requires a certain setup, it will be put that way. For example if you have two servers using the same runtime, and server1 has a deploy folder of ~/tmp/one while scanner2 has a folder of ~/tmp/two, the following will occur: 1) Start server1, 1a) ~/tmp/one is added to the scanner list 2) Stop server1. 3) Start server2 3a) ~/tmp/one is removed from the scanner list 3b) ~/tmp/two is added to the scanner list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11297?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-11297. --------------------------------- Resolution: Done This is working as intended. The reason in your case the scanner is replaced is because the server should not be loading deployments from a previous workspace. The code works as follows: 1) determine what folders SHOULD be added. Determine this from the settings stored in the server editor. 2) Get the list of current deployment scanners from the app server 3) Remove any scanners that are in the list of step 2) but NOT in the list from step 1) who's names start with jbosstoolsscanner 4) Add any scanners which are in the list from step 1) which are NOT in the list from step 2) So... to get arbitrary folders added, you may perform the following: 1) create a new server 2) mark it as metadata 3) create a dynamic web project 4) in the server editor page 2, mark the new dynamic web project to deploy to /home/yourname/tmp/folder 5) deploy the project 6) start the server You will note here that the server will remove any scanners added from a previous workspace, then add the metadata folder, and then add the folder from step 4) In this way you can have each module deploy to a different folder, and a scanner for each folder will be added. The idea here is that a server should not be "infected" by another workspace using the same server. If workspace1 needs /home/rob/folder1 added to the deployment scanner list, there is no guarantee workspace2 needs that at all. Workspace2 most likely does not want /home/rob/folder1 added to the scanner list. In fact, the user would be very confused. (Why is my workspace1web.war deployed?! I'm in a different workspace!!) So we remove that scanner, and add only those which are relevant for the current server adapter object. This is working as intended -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira