[ https://issues.jboss.org/browse/JBIDE-13263?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-13263: ------------------------------------- API additions and conversions during the early phase of 4.0.0 (alpha / beta) led to this regression which went uncaught. In attempts to unify in a solid straight API methods to get a deploy folder regardless of whether the server is in local or remote / rse mode led to the creation of the publish m ethod and it's getDefaultDeployFolder. The listeners in charge of adding deployment scanners were previously using an api which returned the server's core deploy folder (standalone/deployments or server/default/deploy) and were counting this as the "insideServer" location. When the apis were enhanced, the new api was returning the current deploy folder (metadata or server or custom) rather than what was previously ONLY the server location. When the metadata location is checked, it matches the insideServer, and so is ignored as a duplicate. The insideServer location is assumed to never need to be added to a deployment scanner, since the server will add it by itself. The regression from JBIDE-12899 in fact delt with this issue, as JBIDE-12899 was causing the default deploy location to be added twice, which was wrong. While the issue was fixed for as7 to prevent the duplicate additions, the subclass was not verified. The subclass, which was not suffering from duplicate additions, now lost it's metadata deployment scanner in the process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira