]
James Perkins closed WFLY-8595.
-------------------------------
Resolution: Explained
I'm closing this as explained. The log manager must be on the boot class path, along
with it's dependencies, and the {{java.util.logging.manager}} system property needs to
be set in the JVM options.
The {{JBOSS_MODULES_SYSTEM_PKGS}} environment variable also needs to be set. Here are some
snippets on how this could be done with WildFly 18+
{code:title=standalone.conf}
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager,org.wildfly.common,$JBOSS_MODULES_SYSTEM_PKGS"
...
LOGMANAGER_JAR=$(find $JBOSS_HOME/modules -name "jboss-logmanager*.jar" -type f
| xargs readlink -m)
WILDFLY_COMMON_JAR=$(find $JBOSS_HOME/modules -name "wildfly-common*.jar" -type
f | xargs readlink -m)
JSON_API_JAR=$(find $JBOSS_HOME/modules -name "jakarta.json-api*.jar" -type f |
xargs readlink -m)
JSON_IMPL_JAR=$(find $JBOSS_HOME/modules -name "jakarta.json-1*.jar" -type f |
xargs readlink -m)
BOOT_CP="$LOGMANAGER_JAR:$WILDFLY_COMMON_JAR:$JSON_API_JAR:$JSON_IMPL_JAR"
JAVA_OPTS="-Djava.util.logging.manager=org.jboss.logmanager.LogManager
-Xbootclasspath/a:$BOOT_CP -Xhealthcenter $JAVA_OPTS"
{code}
Wildfly fails if wrapper class calls MemoryMXBean due to
"logging manager" conflict (IBM JDK and YAJSW)
-------------------------------------------------------------------------------------------------------
Key: WFLY-8595
URL:
https://issues.jboss.org/browse/WFLY-8595
Project: WildFly
Issue Type: Feature Request
Components: Logging
Affects Versions: 10.1.0.Final
Environment: * Wildfly 10.1
* IBM JDK 8
* YAJSW 11
Reporter: will milspec
Assignee: James Perkins
Priority: Major
*Upshot*
Wildfly 10.1 fails to run when called from YAJSW (Yet Another Service Wrapper) on the IBM
JDK.
It fails because YAJSW instantiates/calls MemoryMXBean prior to running the wildfly
classes.
IBM's implementation of MemoryMXBean instantiates the Logging manager, i.e. class
identified by -Djava.util.logging.manager.
A "class/classloader" conflict exists for the logging manager. Because IBM
JDK's MemoryMXBean "got to the log manager" first, wildfly presuppositions
are undermined, i.e. the "system classloader" loaded the log manager, not the
"jboss module classloader". A 'class identify check' (see below) fails.
*More Details*
This test returns false for Oracle JDK, true for IBM when run under yajsw. i.e. Under
OracleJDK, LogManager.getLogManager() has a different classloader (the jboss module
classoader ) than does the LogManager.class (system classloader)
jboss-modules.git/src/main/java/org/jboss/modules/Main.java
{{ final String logManagerName = getServiceName(bootClassLoader,
"java.util.logging.LogMa
nager");
if (logManagerName != null) {
System.setProperty("java.util.logging.manager", logManagerName);
* if (LogManager.getLogManager().getClass() == LogManager.class) {
* System.err.println("WARNING: Failed to load the specified log
manager class " + logManagerName);
} else {
Module.setModuleLogger(new JDKModuleLogger());
}
}
}}
*Workaround Gets Farther but Undermines Presuppositions of App Server*
If I add this jar to the Xbootclasspath/p, the "ibm system classes" loads
org.jboss.logmanager.LogManager, but a downstream check in the jboss code throws an
exception because the wrong classloader loaded org.jboss.logmanager.LogManager.
*Steps to Reproduce*
-Download IBM JDK
-Download yajsw. Run its "genconfig" tool to generate a configration file
-Start wildfly
*Resource Xref*
When I first came across this issue, I had trouble discerning "where the problem
lay", i.e. in what source code. I posted on the ibm developer works, yajsw and
wildfly forums.
https://sourceforge.net/p/yajsw/discussion/810311/thread/e730451b/
ibm developer works forum:
https://www.ibm.com/developerworks/community/forums/html/topic?id=8e9e4ae...
jboss developer forum:
https://developer.jboss.org/thread/272840