[ https://jira.jboss.org/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Francisco Jose Peredo Noguez updated JBIDE-2627: ------------------------------------------------ Description: When doing development of several independent applications over the JBoss AS, that JBoss AS installation get contaminated by those applications If I create workspaces1, and inside it I create dynamic webproject 1, and run it on JBoss, then I switch to workspace2, and create dynamic webproject 2, and run it on JBoss, since it is the same JBoss instance, both dynamic webproject 1 and dynamic webproject 2 will start (and there is no way, from inside eclipse to undeploy dynamic webproject 1 unless I go back to workspaces1 and undeploy it. But, if one is working with Tomcat, there is no problem, applications do not "contaminate" the shared Tomcat, why is that? well the Tomcat WTP Adapter has a configuration option enabled by default under "Server Location", that reads: "Use workspace metadata (does not modify Tomcat installation)". I would like to have an option like that for JBoss AS. was: When doing development of serveral independent applications over the JBoss AS, that JBoss AS installation get contaminated by those applications If I create workspaces1, and inside it I create dynamic webproject 1, and run it on JBoss, then I switch to workspace2, and create dynamic webproject 2, and run it on JBoss, since it is the same JBoss instance, both dynamic webproject 1 and dynamic webproject 2 will start (and there is no way, from inside eclipse to undeploy dynamic webproject 1 unless I go back to workspaces1 and undeploy it. But, if one is working with Tomcat, there is no problem, applications do not "contaminate" the shared Tomcat, why is that? well the Tomcat WTP Adapter has a configuration option enabled by default under "Server Location", that reads: "Use workspace metadata (does not modify Tomcat installation)". I would like to have an option like that for JBoss AS. Fix typo -- 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/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-2627: --------------------------------------- Fix Version/s: 3.0.0.beta1 That would require a full copy of the appserver inside your workspace metadata....right? Alternatively you can set the default deploy folder to something else and then it won't deploy into the jboss installation - but I think you still have to manually register that location within jboss. We should at least have a way to configure jbossas to use that folder automatically. -- 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/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Gabriele Garuglieri commented on JBIDE-2627: -------------------------------------------- Actually you have a couple of ways to use different deployment dirs without copying around installation dirs. 1- use the mbean "jboss.deployment:type=DeploymentScanner,flavor=URL" method addURL() via jmx after server startup to dynamically add a deployment directory. This must be done each time the server is restarted and you are still using the working dirs set of the installation. 2- use the ${jboss.server.base.dir}, ${jboss.server.base.url} and ${jboss.server.name} configuration properties to setup different server instances for each server definition in eclipse. In this way you need to twiddle a bit the jboss-service.xml (into ${jboss.server.base.dir}/${jboss.server.name}/conf) to include ${jboss.home.dir}/server/default/deploy into the directories scanned for deployment. This is what i use, in combination with service-bindings.xml, so that i can have multiple instances active at the same time(ref http://www.jboss.com/index.html?module=bb&op=viewtopic&t=143827). Respect to the former, this way gives the option to use, with a single installation, completely different set of working dirs (deploy, data, log, tmp, etc.) for each instance, avoiding possibility of any contamination and even build clustered configurations (if the pc processor and memory can cope with it). It would be great if the server component of JBoss Tools could add support these configuration options. -- 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/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-2627: ------------------------------------ good ideas all around -- 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/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Gabriele Garuglieri commented on JBIDE-2627: -------------------------------------------- Rob, please don't do it automatically, leave it as a checkable option. I use a home made "server generator" that by means of some ant tasks generates in seconds complete server configurations based on ${jboss.server.base.dir}, ${jboss.server.base.url} , ${jboss.server.name} and a user variable configuration properties and server bindings ports. The generated jboss-service.xml is already configured to include the ${jboss.server.base.dir}/${jboss.server.name}/deploy directory in the deployment scanner so automatically adding it again would duplicate it. This way of server configuration is really powerful and server component of JBoss tools is flexible enough to allow to use this kind of configuration with a bit of hacking of the server launch config, substituting the startup options with the --properties option. If i exclude the fact that sometimes the server launch is reset to default values (one of those is detailed in bug JBIDE-2899, but there are other circumstances, whose causes i've not yet been able to pinpoint, where it happens) the thing is usable enough. But i think that fully integrating support for advanced JBoss configuration would require much more than a simple ui reworking, i mean that there should be a clear distinction between the installation runtime, ${jboss.home.dir} where to look for lib dir and reference server (default, all) lib and deploy dirs, and server instances working dirs (conf, deploy, lib, log, tmp, data, work) based on ${jboss.server.base.dir}/${jboss.server.name}. Plus it would be required to integrate support for server bindings (ex bug JBIDE-2050) that is the base to use multiple server instances in the same machine, unless you can define virtual ip adapters. So to conclude, support to integrate a user deploy path into deployment scanner is a step ahead, but what i feel missing in all the JBoss adapters i've seen, is the thing that with tomcat is the normal way of working. The support for separation between the runtime (installation) and server instances working dirs. -- 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/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Rob Stryker updated JBIDE-2627: ------------------------------- Summary: Allow adding deploy location to server deployment locations via JMX (was: Add "Server Locations" option to JBoss WTP Adapter to prevent JBoss contamination) Changing name so I can tell what it is more easily ;) -- 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/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Rob Stryker updated JBIDE-2627: ------------------------------- Attachment: new_wizard.jpg new server wizard -- 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/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Max Rydahl Andersen reopened JBIDE-2627: ---------------------------------------- Feature looks great - just reopening to clarify a few points for release notes/docs and dependent features. 1) What will happen with existing configured AS adapters ? I assume they will be set to "custom" deploy and it will only be for new adapters we use the workspace by default ? 2) How do you now use the FileSet's to look into the deploy dir when it is in the workspace ? I don't see anywhere how users know where the deploy actually happens ? 3) More just a comment to 2: It is now more than ever relevant to have a way to be able to setup a fileset rooted on the deploy dir so users don't have to adjust the fileset 4) The text description for temporary deploy directory is now on top of 4 non-related ui elements. I think that should be moved below or above the actual field. -- 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/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Max Rydahl Andersen commented on JBIDE-2627: -------------------------------------------- And another question/note: Need to handle the common case of the server being secured and no user/password setup to allow JMX (which would prevent scanning) Maybe have a dialog popup asking if they want to move to deploying directly in default deploy ? -- 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/jira/browse/JBIDE-2627?page=com.atlassian.jira.plu... ] Rob Stryker resolved JBIDE-2627. -------------------------------- Resolution: Done Resolving as fixed. -- 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