[
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.
Add "Server Locations" option to JBoss WTP Adapter to
prevent JBoss contamination
---------------------------------------------------------------------------------
Key: JBIDE-2627
URL:
https://jira.jboss.org/jira/browse/JBIDE-2627
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: JBossAS
Affects Versions: 2.1.2
Reporter: Francisco Jose Peredo Noguez
Assignee: Rob Stryker
Fix For: 3.0.0.cr1
Attachments: screenshot-1.jpg
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.
--
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