[jboss-jira] [JBoss JIRA] (WFLY-8595) Wildfly fails if wrapper class calls MemoryMXBean due to "logging manager" conflict (IBM JDK and YAJSW)

[James Perkins (Jira)]

     [ https://issues.jboss.org/browse/WFLY-8595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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=8e9e4ae2-53a7-42e8-8086-6208b80e2910
> jboss developer forum:
> https://developer.jboss.org/thread/272840



--
This message was sent by Atlassian Jira
(v7.13.8#713008)