]
Work on ARQ-1848 started by Ian Brandt.
---------------------------------------
Tomcat managed containers should start and stop Tomcat using the
standard run scripts
-------------------------------------------------------------------------------------
Key: ARQ-1848
URL:
https://issues.jboss.org/browse/ARQ-1848
Project: Arquillian
Issue Type: Feature Request
Components: Tomcat Containers
Affects Versions: tomcat_1.0.0.CR7
Reporter: Ian Brandt
Assignee: Ian Brandt
Fix For: tomcat_1.0.0.Final
The [standard Tomcat run
scripts|http://tomcat.apache.org/tomcat-8.0-doc/RUNNING.txt]
contain a fair little bit of logic and features:
* Multiple instance support (requiring the proper merging of resources from
{{CATALINA_BASE}} and {{CATALINA_HOME}}).
* Logging configuration.
* Running with or without a security manager.
* Support for configuration in the 'setenv' script.
* Endorsed and temp directory configuration.
* Launching with JPDA related configuration.
* OS variant and TTY related configuration on UNIX.
By building the Java command to launch Tomcat directly the current
{{CommonTomcatManagedContainer}} forgoes the standard implementation of all this. There
is a growing history of bug reports and feature requests that suggest this may not be the
best approach:
* ARQ-628 - Tomcat managed throws NullPointerException when application under test brings
weld-servlet dependency
* ARQ-866 - Allow catalina.base to be configured separately from catalina.home in the
Tomcat managed adapters
* ARQ-1650 - Managed container bypasses tomcat jul setup
* ARQ-1843 - Tomcat managed container ignores javaHome configuration
* ARQ-1846 - Support configuration of the Tomcat system classpath from managed
containers
* ARQ-1847 - Support specifying JMX RMI server port
Rather than reinventing the wheel here, we should just launch and stop Tomcat with the
standard run script for the current OS, exposing it's environment variable-driven
configuration via arquillian.xml and the {{CommonTomcatManagedConfiguration}}. This
will:
* Add all the missing features and logic.
* Be simpler and presumably cheaper to maintain over trying to mirror the standard
scripts.
* Encourage better fidelity between managed containers and their production counterparts
(e.g. identical {{CATALINA_BASE}} and {{CATALINA_HOME}} merging, as well as setenv script
support).