[JBoss JIRA] (LOGMGR-218) JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/LOGMGR-218?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on LOGMGR-218:
-----------------------------------------
[~jmesnil] [~luck3y] FYI.
> JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11
> -----------------------------------------------------------------
>
> Key: LOGMGR-218
> URL: https://issues.jboss.org/browse/LOGMGR-218
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: Brian Stansberry
> Priority: Critical
>
> The current logmanager implementation is incompatible with use with the -Xbootclasspath/a option on JDK 11. The is because it is a multi-release jar which is incompatible with -Xbootclasspath/a. This is problematic because to allow Java Agents to work with JBoss Modules based applications (i.e. WildFly and derivatives) often it is necessary to include logmanager in -Xbootclasspath/a .
> Here's me starting WildFly with a -Xbootclasspath/a setting and JDK 11:
> {code}
> $ build/target/wildfly-core-7.0.0.CR2-SNAPSHOT/bin/standalone.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly-core/build/target/wildfly-core-7.0.0.CR2-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Djava.awt.headless=true -Xbootclasspath/a:/Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-7.0.0.CR2-SNAPSHOT/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.5.Final.jar -Djava.util.logging.manager=org.jboss.logmanager.LogManager --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-modules=java.se
> =========================================================================
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogLevelInitTask to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogLevelInitTask
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
> at org.jboss.as.server@7.0.0.CR2-SNAPSHOT//org.jboss.as.server.Main.main(Main.java:89)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> {code}
> Right now jboss-logmanager is a multi-release jar. But, per the MR jar spec (https://openjdk.java.net/jeps/238) that is incompatible with -Xbootclasspath:
> {quote}
> Multi-release jars and the boot loader
> Multi-release JARs are not supported by the boot loader (for example, when a multi-release JAR file is declared with the -Xbootclasspath/a option). Such support would complicate the boot loader implementation for what is considered a rare use-case.
> {quote}
> At this point I've identified two java agents that are commonly used with WildFly derived apps that cannot be installed in a JDK 11 environment: Hawkular and the Prometheus jmx-exporter. The former I could perhaps work around (i.e. don't install it with JDK 11) as it's use is deprecated. But being able to use of jmx-exporter is quite important.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (LOGMGR-218) JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11
by Brian Stansberry (Jira)
Brian Stansberry created LOGMGR-218:
---------------------------------------
Summary: JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11
Key: LOGMGR-218
URL: https://issues.jboss.org/browse/LOGMGR-218
Project: JBoss Log Manager
Issue Type: Bug
Reporter: Brian Stansberry
The current logmanager implementation is incompatible with use with the -Xbootclasspath/a option on JDK 11. The is because it is a multi-release jar which is incompatible with -Xbootclasspath/a. This is problematic because to allow Java Agents to work with JBoss Modules based applications (i.e. WildFly and derivatives) often it is necessary to include logmanager in -Xbootclasspath/a .
Here's me starting WildFly with a -Xbootclasspath/a setting and JDK 11:
{code}
$ build/target/wildfly-core-7.0.0.CR2-SNAPSHOT/bin/standalone.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly-core/build/target/wildfly-core-7.0.0.CR2-SNAPSHOT
JAVA: /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Djava.awt.headless=true -Xbootclasspath/a:/Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-7.0.0.CR2-SNAPSHOT/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.5.Final.jar -Djava.util.logging.manager=org.jboss.logmanager.LogManager --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-modules=java.se
=========================================================================
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jboss.logmanager.LogLevelInitTask to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogLevelInitTask
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
at org.jboss.as.server@7.0.0.CR2-SNAPSHOT//org.jboss.as.server.Main.main(Main.java:89)
at org.jboss.modules.Module.run(Module.java:352)
at org.jboss.modules.Module.run(Module.java:320)
at org.jboss.modules.Main.main(Main.java:593)
{code}
Right now jboss-logmanager is a multi-release jar. But, per the MR jar spec (https://openjdk.java.net/jeps/238) that is incompatible with -Xbootclasspath:
{quote}
Multi-release jars and the boot loader
Multi-release JARs are not supported by the boot loader (for example, when a multi-release JAR file is declared with the -Xbootclasspath/a option). Such support would complicate the boot loader implementation for what is considered a rare use-case.
{quote}
At this point I've identified two java agents that are commonly used with WildFly derived apps that cannot be installed in a JDK 11 environment: Hawkular and the Prometheus jmx-exporter. The former I could perhaps work around (i.e. don't install it with JDK 11) as it's use is deprecated. But being able to use of jmx-exporter is quite important.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11450) Cannot get delegate of JMSContext during an beforeCompletion synch
by Jan-Willem Gmelig Meyling (Jira)
[ https://issues.jboss.org/browse/WFLY-11450?page=com.atlassian.jira.plugin... ]
Jan-Willem Gmelig Meyling updated WFLY-11450:
---------------------------------------------
Affects Version/s: 8.0.0.CR1
14.0.1.Final
> Cannot get delegate of JMSContext during an beforeCompletion synch
> ------------------------------------------------------------------
>
> Key: WFLY-11450
> URL: https://issues.jboss.org/browse/WFLY-11450
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 14.0.1.Final, 8.0.0.CR1
> Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
> WildFly 8.0.0.CR1
> Reporter: Jan-Willem Gmelig Meyling
> Assignee: Matej Novotny
> Priority: Minor
> Attachments: ARJUNA016082.log
>
>
> The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction. (Because the synchronization cannot be placed)
> *Use case*
> I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
> *Workaround*
> Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
> The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
> (Which refers to WildFly 8.0.0.CR1)
> Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
> See the attached log for a full stack trace.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month