[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)
4 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)
4 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)
4 years, 6 months
[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/JGRP-2394?page=com.atlassian.jira.plugin.... ]
Nistor Adrian updated JGRP-2394:
--------------------------------
Description:
The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
So we propose adding someting like this:
JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names.
was:
The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
So we propose adding someting like this:
JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the callers task to ensure this leads to generation of unique names.
> Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2394
> URL: https://issues.jboss.org/browse/JGRP-2394
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.6
> Reporter: Nistor Adrian
> Assignee: Bela Ban
> Priority: Major
>
> The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
> So we propose adding someting like this:
> JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
> which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
by Nistor Adrian (Jira)
Nistor Adrian created JGRP-2394:
-----------------------------------
Summary: Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
Key: JGRP-2394
URL: https://issues.jboss.org/browse/JGRP-2394
Project: JGroups
Issue Type: Enhancement
Affects Versions: 4.1.6
Reporter: Nistor Adrian
Assignee: Bela Ban
The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
So we propose adding someting like this:
JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the callers task to ensure this leads to generation of unique names.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-4715) [DMN Designer] Structure is lost when user doesn't drag it enough
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4715?page=com.atlassian.jira.plugi... ]
Guilherme Gomes updated DROOLS-4715:
------------------------------------
Description:
This issue is caused by DROOLS-4484
If user drag a structure not enough == no reordering/reorganization caused by that drag, the structure is lost. See the attached video.
---
⚠️ Notice: this issue is caused by the absence of reference, like the the scenario mentioned on DROOLS-4710. This JIRA must be marked as resolved only when both scenarios are solved.
was:
This issue is caused by DROOLS-4484
If user drag a structure not enough == no reordering/reorganization caused by that drag, the structure is lost. See the attached video.
> [DMN Designer] Structure is lost when user doesn't drag it enough
> -----------------------------------------------------------------
>
> Key: DROOLS-4715
> URL: https://issues.jboss.org/browse/DROOLS-4715
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.30.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: drag-not-enough.webm
>
>
> This issue is caused by DROOLS-4484
> If user drag a structure not enough == no reordering/reorganization caused by that drag, the structure is lost. See the attached video.
> ---
> ⚠️ Notice: this issue is caused by the absence of reference, like the the scenario mentioned on DROOLS-4710. This JIRA must be marked as resolved only when both scenarios are solved.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months