[
https://issues.jboss.org/browse/WFCORE-2223?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-2223:
------------------------------------------
See "Modular vs Non-Modular Classloading and JBOSS_HOME" in
http://wildfly.org/news/2015/03/13/Offline-CLI/ re module loading. Basically if you run
the CLI as a modular application, the module path is what was used to set up the CLI
process, and if you use jboss-cli.sh it supports JBOSS_MODULE_PATH. If you do not run the
CLI as a modular app, then the module path is <value_of_jboss_home>/modules and
JBOSS_MODULE_PATH has no meaning.
The simple thing to do here is to remove the validation of the property value. The
property is deprecated and has had no meaning for many years; all it does is drive the
value of a deprecated runtime management attribute that we preserve for management API
compatibility. There's no reason to validate this value.
Setting JBOSS_MODULEPATH is lost for second start of embed-server
-----------------------------------------------------------------
Key: WFCORE-2223
URL:
https://issues.jboss.org/browse/WFCORE-2223
Project: WildFly Core
Issue Type: Bug
Components: CLI, Server
Reporter: Josef Cacek
Assignee: Brian Stansberry
Priority: Critical
When {{embed-server}} command is used more times in the CLI and a custom
{{JBOSS_MODULEPATH}} is configured, then only the first server start uses the correct
module path.
The subsequent `embed-server` call results in error:
{code}
Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on embedded
process: WFLYSRV0118: Determined modules directory does not exist:
/tmp/jboss-eap-7.0-no-modules/modules
{code}
Using the {{JBOSS_MODULEPATH}} environment variable is documented in
https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)