[JBoss JIRA] (WFCORE-4143) Embed CLI failures on IBM jdk - checkLogging
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4143?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-4143:
----------------------------------
Labels: OpenJ9 (was: )
> Embed CLI failures on IBM jdk - checkLogging
> --------------------------------------------
>
> Key: WFCORE-4143
> URL: https://issues.jboss.org/browse/WFCORE-4143
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Environment: IBM JDK
> {noformat}
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 8.0.5.20 - pxa6480sr5fp20-20180802_01(SR5 FP20))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20180731_393394 (JIT enabled, AOT enabled)
> OpenJ9 - bd23af8
> OMR - ca1411c
> IBM - 98805ca)
> JCL - 20180719_01 based on Oracle jdk8u181-b12
> {noformat}
> Reporter: Petr Kremensky
> Assignee: James Perkins
> Priority: Major
> Labels: OpenJ9
>
> {{testLogging}} for Cli tests in Wildfly-core testsuite fails on IBM JDK.
> *reproduce*
> cd wildfly-core/testsuite
> mvn clean test -fae -Dts.manualmode -pl manualmode,standalone -Dtest=CLIEmbedHostControllerTestCase,CLIEmbedServerTestCase,SilentModeTestCase
> ...
> [ERROR] Failures:
> [ERROR] SilentModeTestCase.testLogging:99->checkIfEmpty:152
> [INFO]
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0
> ...
> [ERROR] Failures:
> [ERROR] CLIEmbedHostControllerTestCase.testHelp:321->checkLogging:744
> [ERROR] CLIEmbedHostControllerTestCase.testStdOutDefault:160->stdoutTest:188->checkClientSideLogging:231->checkLogging:744
> [ERROR] CLIEmbedHostControllerTestCase.testStdOutDiscard:166->stdoutTest:188->checkClientSideLogging:231->checkLogging:744
> [ERROR] CLIEmbedHostControllerTestCase.testStdOutEcho:172->stdoutTest:188->checkClientSideLogging:231->checkLogging:744
> [ERROR] CLIEmbedServerTestCase.testHelp:543->checkLogging:764
> [ERROR] CLIEmbedServerTestCase.testStdOutDefault:196->stdoutTest:224->checkClientSideLogging:267->checkLogging:764
> [ERROR] CLIEmbedServerTestCase.testStdOutDiscard:202->stdoutTest:224->checkClientSideLogging:267->checkLogging:764
> [ERROR] CLIEmbedServerTestCase.testStdOutEcho:208->stdoutTest:224->checkClientSideLogging:267->checkLogging:764
> [INFO]
> [ERROR] Tests run: 51, Failures: 8, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-8595) Wildfly fails if wrapper class calls MemoryMXBean due to "logging manager" conflict (IBM JDK and YAJSW)
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-8595?page=com.atlassian.jira.plugin.... ]
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
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-9169) Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE)
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-9169?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-9169.
-------------------------------
Resolution: Out of Date
I'm closing this as out of date. If this is still an issue with WildFly 18 please feel free to reopen.
> Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE)
> --------------------------------------------------------------------------
>
> Key: WFLY-9169
> URL: https://issues.jboss.org/browse/WFLY-9169
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final
> AIX Version 7.2
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pap6480sr3fp22-20161213_02(SR3 FP22))
> IBM J9 VM (build 2.8, JRE 1.8.0 AIX ppc64-64 Compressed References 20161209_329148 (JIT enabled, AOT enabled)
> J9VM - R28_20161209_1345_B329148
> JIT - tr.r14.java.green_20161207_128946
> GC - R28_20161209_1345_B329148_CMPRSS
> J9CL - 20161209_329148)
> JCL - 20161213_01 based on Oracle jdk8u111-b14
> Reporter: Blass MeGod
> Priority: Major
> Labels: deadlock, regression, remoting
>
> Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE):
> {code}
> 3XMTHREADINFO "p0" J9VMThread:0x00000000304BD100, j9thread_t:0x0000010029E423D0, java/lang/Thread:0x0000000408F664F8, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x8C96, isDaemon:false)
> 3XMTHREADINFO1 (native thread ID:0x20401E7, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000101)
> 3XMCPUTIME CPU usage total: 0.379679000 secs, user: 0.354485000 secs, system: 0.025194000 secs, current category="Application"
> 3XMTHREADBLOCK Waiting on: java/lang/Object@0x000000040ECC59A0 Owned by: <unowned>
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/lang/Object.wait(Native Method)
> 4XESTACKTRACE at java/lang/Object.wait(Object.java:172(Compiled Code))
> 4XESTACKTRACE at org/jboss/remoting3/spi/AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:190(Compiled Code))
> 5XESTACKTRACE (entered lock: java/lang/Object@0x000000040ECC59A0, entry count: 1)
> 4XESTACKTRACE at org/jboss/naming/remote/client/EndpointCache.release(EndpointCache.java:67(Compiled Code))
> 5XESTACKTRACE (entered lock: org/jboss/naming/remote/client/EndpointCache@0x00000004002F3830, entry count: 1)
> 4XESTACKTRACE at org/jboss/naming/remote/client/EndpointCache$EndpointWrapper.close(EndpointCache.java:183(Compiled Code))
> 4XESTACKTRACE at org/jboss/naming/remote/client/InitialContextFactory$1.close(InitialContextFactory.java:233(Compiled Code))
> 4XESTACKTRACE at org/jboss/naming/remote/client/RemoteContext.close(RemoteContext.java:290(Compiled Code))
> 4XESTACKTRACE at javax/naming/InitialContext.close(InitialContext.java:567(Compiled Code))
> ...
> {code}
> This might happen when using remoting client with XNIO version 3.3.4
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-11451) Classloading issues on IBM JDK 8 when JProfiler agent is enabled
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11451?page=com.atlassian.jira.plugin... ]
James Perkins closed WFLY-11451.
--------------------------------
Resolution: Rejected
This can be resolved by adding the log manager to the boot class path and defining the {{java.util.logging.manager}} in the {{JAVA_OPTS}}.
The following example works for WildFly 18+ for lower versions you'd use the "javax" prefix where "jakarta" is used below.
{code:title=standalone.conf}
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}
> Classloading issues on IBM JDK 8 when JProfiler agent is enabled
> ----------------------------------------------------------------
>
> Key: WFLY-11451
> URL: https://issues.jboss.org/browse/WFLY-11451
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 14.0.1.Final
> Environment: IBM JDK 8:
> java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 8.0.5.25 - pxa6480sr5fp25-20181030_01(SR5 FP25))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20181029_400846 (JIT enabled, AOT enabled)
> OpenJ9 - c5c78da
> OMR - 3d5ac33
> IBM - 8c1bdc2)
> JCL - 20181022_01 based on Oracle jdk8u191-b26
> Reporter: Tomas Kyjovsky
> Assignee: James Perkins
> Priority: Major
>
> When I enable JProfiler agent for the server running on IBM JDK 8 the server doesn't start, throwing classloading exceptions.
> {noformat}
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/tkyjovsk/workspace/KEYCLOAK-8983/wildfly-14.0.1.Final
> JAVA: /home/tkyjovsk/software/java/ibm-java-80/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentpath:/home/tkyjovsk/software/tools/jprofiler9/bin/linux-x64/libjprofilerti.so=port=6766 -Xshareclasses:none
> =========================================================================
> JProfiler> Protocol version 55
> JProfiler> Using JVMTI
> JProfiler> Thread status info workaround enabled.
> JProfiler> Restricted JVMTI version 1.1 detected.
> JProfiler> 64-bit library
> JProfiler> Listening on port: 6766.
> JProfiler> Instrumenting native methods.
> JProfiler> Native library initialized
> JProfiler> VM initialized
> JProfiler> Waiting for a connection from the JProfiler GUI ...
> JProfiler> Using dynamic instrumentation
> JProfiler> Time measurement: elapsed time
> JProfiler> CPU profiling enabled
> WARNING: Failed to load the specified log manager class org.jboss.logmanager.LogManager
> Nov 30, 2018 1:48:31 PM org.jboss.msc.service.ServiceContainerImpl <clinit>
> INFO: JBoss MSC version 1.4.3.Final
> Nov 30, 2018 1:48:31 PM org.jboss.threads.Version <clinit>
> INFO: JBoss Threads version 2.3.2.Final
> Nov 30, 2018 1:48:31 PM org.jboss.as.server.BootstrapImpl internalBootstrap
> WARN: WFLYSRV0071: The operating system has limited the number of open files to 1024 for this process; a value of at least 4096 is recommended
> Nov 30, 2018 1:48:31 PM org.jboss.as.server.ApplicationServerService start
> INFO: WFLYSRV0049: WildFly Full 14.0.1.Final (WildFly Core 6.0.2.Final) starting
> Nov 30, 2018 1:48:33 PM org.wildfly.security.Version <clinit>
> INFO: ELY00001: WildFly Elytron version 1.6.0.Final
> Nov 30, 2018 1:48:34 PM org.jboss.as.controller.AbstractOperationContext executeStep
> ERROR: WFLYCTL0013: Operation ("parallel-extension-add") failed - address: ([])
> java.lang.RuntimeException: WFLYCTL0079: Failed initializing module org.jboss.as.logging
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:115)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:495)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:470)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:432)
> at org.jboss.as.server.ServerService.boot(ServerService.java:427)
> at org.jboss.as.server.ServerService.boot(ServerService.java:386)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
> at java.lang.Thread.run(Thread.java:812)
> Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: WFLYLOG0078: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at java.util.concurrent.FutureTask.report(FutureTask.java:133)
> at java.util.concurrent.FutureTask.get(FutureTask.java:203)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:107)
> ... 11 more
> Caused by: java.lang.IllegalStateException: WFLYLOG0078: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:194)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:812)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Nov 30, 2018 1:48:34 PM org.jboss.as.server.ServerService$4 logExit
> FATAL: WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {noformat}
> I tried to work around this by adding "{{org.jboss.logmanager}}" to {{JBOSS_MODULES_SYSTEM_PKGS}} and adding "{{-Djava.util.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:...}}" in {{JAVA_OPTS}} but that just results in another class-loading error:
> {noformat}
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/tkyjovsk/workspace/KEYCLOAK-8983/wildfly-14.0.1.Final
> JAVA: /home/tkyjovsk/software/java/ibm-java-80/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 -agentpath:/home/tkyjovsk/software/tools/jprofiler9/bin/linux-x64/libjprofilerti.so=port=6766 -Xshareclasses:none -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:/home/tkyjovsk/workspace/KEYCLOAK-8983/wildfly-14.0.1.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.4.Final.jar
> =========================================================================
> JProfiler> Protocol version 55
> JProfiler> Using JVMTI
> JProfiler> Thread status info workaround enabled.
> JProfiler> Restricted JVMTI version 1.1 detected.
> JProfiler> 64-bit library
> JProfiler> Listening on port: 6766.
> JProfiler> Instrumenting native methods.
> JProfiler> Native library initialized
> JProfiler> VM initialized
> JProfiler> Waiting for a connection from the JProfiler GUI ...
> JProfiler> Using dynamic instrumentation
> JProfiler> Time measurement: elapsed time
> JProfiler> CPU profiling enabled
> java.lang.NoClassDefFoundError: org/wildfly/common/net/HostName
> at org.jboss.logmanager.ExtLogRecord.<init>(ExtLogRecord.java:87)
> at org.jboss.logmanager.Logger.log(Logger.java:796)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:40)
> at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:91)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:250)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:229)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.access$100(BootstrapImpl.java:219)
> at org.jboss.as.server.BootstrapImpl.<init>(BootstrapImpl.java:70)
> at org.jboss.as.server.Bootstrap$Factory.newInstance(Bootstrap.java:278)
> at org.jboss.as.server.Main.main(Main.java:106)
> 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)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-11505) XercesUsageInWebServiceTestCase fails with security manager on IBM Java 8
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11505?page=com.atlassian.jira.plugin... ]
James Perkins closed WFLY-11505.
--------------------------------
Resolution: Out of Date
I'm closing this as out of date. All the tests pass for me on the latest WildFly upstream with OpenJ9 + OpenJDK 11 and OpenJ9 + OpenJDK 8.
{code}
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.15.1, JRE 11 Linux amd64-64-Bit Compressed References 20190717_286 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - fa49279450 based on jdk-11.0.4+11)
{code}
{code}
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190717_368 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - f147086df1e based on jdk8u222-b10)
{code}
> XercesUsageInWebServiceTestCase fails with security manager on IBM Java 8
> -------------------------------------------------------------------------
>
> Key: WFLY-11505
> URL: https://issues.jboss.org/browse/WFLY-11505
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Web Services
> Affects Versions: 16.0.0.Beta1
> Environment: IBM Java 8, build 8.0.5.25 or 8.0.5.26
> Reporter: Ondrej Kotek
> Assignee: Bartosz Baranowski
> Priority: Major
>
> {{org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService}} fails with security manager on IBM Java 8 due to missing permissions:
> {noformat}
> SEVERE [org.apache.cxf.frontend.WSDLGetInterceptor] (default task-3) WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-webservice-webapp.war/WEB-INF/lib/xercesImpl.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xerces-webservice-webapp.war" from Service Module Loader"): java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-webservice-webapp.war/WEB-INF/lib/xercesImpl.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xerces-webservice-webapp.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1655)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:490)
> at java.lang.J9VMInternals$2.run(J9VMInternals.java:268)
> at java.security.AccessController.doPrivileged(AccessController.java:673)
> at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:263)
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:379)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:1734)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:519)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
> at com.ibm.wsdl.xml.WSDLWriterImpl.getDocument(WSDLWriterImpl.java:1013)
> at com.ibm.wsdl.xml.WSDLWriterImpl.getDocument(WSDLWriterImpl.java:1043)
> at org.apache.cxf.frontend.WSDLGetUtils.writeWSDLDocument(WSDLGetUtils.java:705)
> at org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:151)
> at org.apache.cxf.frontend.WSDLGetInterceptor.getDocument(WSDLGetInterceptor.java:129)
> at org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:77)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$825.000000005C9627C0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> at java.security.AccessController.doPrivileged(AccessController.java:703)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:812)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4724) DMN editor to not default to LiteralExpr when no expr defined
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-4724:
--------------------------------------
Summary: DMN editor to not default to LiteralExpr when no expr defined
Key: DROOLS-4724
URL: https://issues.jboss.org/browse/DROOLS-4724
Project: Drools
Issue Type: Enhancement
Components: DMN Editor
Reporter: Matteo Mortari
Assignee: Guilherme Gomes
Attachments: image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png
Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
However Error message is reported anyway to the user:
!image-2019-11-04-19-39-01-113.png|thumbnail!
This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
!image-2019-11-04-19-40-27-201.png|thumbnail!
so the current behavior is not consistent across re-open of the editor.
Let's revert this default.
The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
Currently, the DMN Compiler will throw 1 Warning.
Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
Currently, the DMN Validator schema check is not reporting any XSD violation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months