[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop - java.lang.StackOverflowError
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins updated WFLY-11793:
----------------------------------------
Summary: JPA EntityManager merge infinite loop - java.lang.StackOverflowError (was: JPA EntityManager merge infinite loop - )
> JPA EntityManager merge infinite loop - java.lang.StackOverflowError
> --------------------------------------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Java EE 8
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Major
> Attachments: teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop - java.lang.StackOverflowError
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins updated WFLY-11793:
----------------------------------------
Priority: Critical (was: Major)
> JPA EntityManager merge infinite loop - java.lang.StackOverflowError
> --------------------------------------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Java EE 8
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop - java.lang.StackOverflowError
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins updated WFLY-11793:
----------------------------------------
Environment:
MAC OS Mojave
Java 11
Wildfly 15.0.1-Final
Data Base Postgresql
was:
MAC OS Mojave
Java 11
Java EE 8
Wildfly 15.0.1-Final
Data Base Postgresql
> JPA EntityManager merge infinite loop - java.lang.StackOverflowError
> --------------------------------------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop -
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins updated WFLY-11793:
----------------------------------------
Description:
Dear,
When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
If the same code runs outside of the Wildfly server context its execution occurs normally.
Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
Attach the source code of my test classes.
was:
Dear,
When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
If the same code runs outside of the Wildfly server context its execution occurs normally.
Attach the source code of my test classes.
> JPA EntityManager merge infinite loop -
> ----------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Java EE 8
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Major
> Attachments: teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop -
by Bruno Maioli Martins (Jira)
Bruno Maioli Martins created WFLY-11793:
-------------------------------------------
Summary: JPA EntityManager merge infinite loop -
Key: WFLY-11793
URL: https://issues.jboss.org/browse/WFLY-11793
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 15.0.1.Final
Environment: MAC OS Mojave
Java 11
Java EE 8
Wildfly 15.0.1-Final
Reporter: Bruno Maioli Martins
Assignee: Scott Marlow
Attachments: teste.zip
Dear,
When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
If the same code runs outside of the Wildfly server context its execution occurs normally.
Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop -
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins updated WFLY-11793:
----------------------------------------
Environment:
MAC OS Mojave
Java 11
Java EE 8
Wildfly 15.0.1-Final
Data Base Postgresql
was:
MAC OS Mojave
Java 11
Java EE 8
Wildfly 15.0.1-Final
> JPA EntityManager merge infinite loop -
> ----------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Java EE 8
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Major
> Attachments: teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months
[JBoss JIRA] (WFLY-11792) Error creating server pooled-connection-factory
by Claudio Miranda (Jira)
Claudio Miranda created WFLY-11792:
--------------------------------------
Summary: Error creating server pooled-connection-factory
Key: WFLY-11792
URL: https://issues.jboss.org/browse/WFLY-11792
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Claudio Miranda
Assignee: ehsavoie Hugonnet
Try to add a pooled-connection-factory, it returns as failure caused by a NullPointerException.
To reproduce:
{code}
batch
/subsystem=messaging-activemq/server=srv-foo:add
/subsystem=messaging-activemq/server=srv-foo/path=bindings-directory:add(path=byhmzspzrcxq)
/subsystem=messaging-activemq/server=srv-foo/path=journal-directory:add(path=yghaapgbokdd)
/subsystem=messaging-activemq/server=srv-foo/path=large-messages-directory:add(path=qjaagiljbwjh)
/subsystem=messaging-activemq/server=srv-foo/path=paging-directory:add(path=sbxvhqytamqe)
run-batch
/subsystem=messaging-activemq/server=srv-foo/discovery-group=dg1:add
/subsystem=messaging-activemq/server=srv-foo/pooled-connection-factory=pool1:add(discovery-group=dg1,entries=[foobar])
{code}
{code}
19:21:20,772 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.messaging-activemq.srv-update-wwavjsiodinh.jms.pooled-connection-factory.pool1: org.jboss.msc.service.StartException in service jboss.messaging-activemq.srv-update-wwavjsiodinh.jms.pooled-connection-factory.pool1: WFLYMSGAMQ0028: Failed to create resource adapter
at org.wildfly.extension.messaging.activemq.jms.PooledConnectionFactoryService.start(PooledConnectionFactoryService.java:328)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at org.wildfly.extension.messaging.activemq.jms.PooledConnectionFactoryService.createService(PooledConnectionFactoryService.java:381)
at org.wildfly.extension.messaging.activemq.jms.PooledConnectionFactoryService.start(PooledConnectionFactoryService.java:325)
... 8 more
19:21:20,773 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "messaging-activemq"),
("server" => "srv-update-wwavjsiodinh"),
("pooled-connection-factory" => "pool1")
]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.messaging-activemq.srv-update-wwavjsiodinh.jms.pooled-connection-factory.pool1" => "WFLYMSGAMQ0028: Failed to create resource adapter
Caused by: java.lang.NullPointerException"}}
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months
[JBoss JIRA] (WFLY-11720) Cannot invoke EJB over HTTP on JDK 11
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-11720?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-11720:
-----------------------------------
Okay, I'll take a closer look. jboss-ejb-client also references the older version of jboss-marshalling, similar to wildfly-http-ejb-client.
> Cannot invoke EJB over HTTP on JDK 11
> -------------------------------------
>
> Key: WFLY-11720
> URL: https://issues.jboss.org/browse/WFLY-11720
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 16.0.0.Beta1
> Environment: JDK 11
> Reporter: Jan Kašík
> Assignee: Cheng Fang
> Priority: Critical
> Attachments: classes.zip, client-app.zip
>
>
> Run of client app calling EJB over HTTP fails on JDK 11 with following log:
> {noformat}
> Feb 14, 2019 12:49:30 PM org.wildfly.naming.client.Version <clinit>
> INFO: WildFly Naming version 1.0.6.Final
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.wildfly.security.manager.GetAccessibleDeclaredFieldAction (file:/home/hudson/hudson_workspace/mod_cluster/client/wildfly-elytron-1.1.3.Final.jar) to field java.security.AccessControlContext.context
> WARNING: Please consider reporting this to the maintainers of org.wildfly.security.manager.GetAccessibleDeclaredFieldAction
> 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
> Feb 14, 2019 12:49:30 PM org.wildfly.security.Version <clinit>
> INFO: ELY00001: WildFly Elytron version 1.1.3.Final
> Feb 14, 2019 12:49:30 PM org.jboss.ejb.client.EJBClient <clinit>
> INFO: JBoss EJB Client version 4.0.2.Final
> Feb 14, 2019 12:49:30 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.6.5.Final
> Feb 14, 2019 12:49:30 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.6.5.Final
> Feb 14, 2019 12:49:30 PM org.jboss.threads.Version <clinit>
> INFO: JBoss Threads version 2.3.0.Beta2
> Feb 14, 2019 12:49:30 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 5.0.0.Final
> Feb 14, 2019 12:49:30 PM org.jboss.threads.LoggingUncaughtExceptionHandler uncaughtException
> ERROR: Thread Thread[XNIO-1 task-1,5,main] threw an uncaught exception
> java.lang.ExceptionInInitializerError
> at org.jboss.marshalling.river.RiverMarshaller.<clinit>(RiverMarshaller.java:1335)
> at org.jboss.marshalling.river.RiverMarshallerFactory.createMarshaller(RiverMarshallerFactory.java:54)
> at org.wildfly.httpclient.common.HttpTargetContext.createMarshaller(HttpTargetContext.java:132)
> at org.wildfly.httpclient.ejb.HttpEJBReceiver.marshalEJBRequest(HttpEJBReceiver.java:367)
> at org.wildfly.httpclient.ejb.HttpEJBReceiver.lambda$processInvocation$1(HttpEJBReceiver.java:185)
> at org.wildfly.httpclient.common.HttpTargetContext$1.lambda$completed$0(HttpTargetContext.java:338)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1871)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1400)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator!
> at org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:287)
> ... 9 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months
[JBoss JIRA] (WFLY-11639) mod_cluster and HTTP2 enabled (the default) not working
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11639?page=com.atlassian.jira.plugin... ]
Radoslav Husar resolved WFLY-11639.
-----------------------------------
Fix Version/s: 16.0.0.CR1
Resolution: Done
Should be fixed with undertow ugrade.
> mod_cluster and HTTP2 enabled (the default) not working
> -------------------------------------------------------
>
> Key: WFLY-11639
> URL: https://issues.jboss.org/browse/WFLY-11639
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 15.0.1.Final
> Environment: Mac OS X 10.14.3
> Tested on both
> AdoptOpenJDK 1.8.0_202-b08
> AdoptOpenJDK 11.0.1+13
> Reporter: Andreas Asplund
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 16.0.0.CR1
>
>
> mod cluster and HTTP2 enabled (the default) when using listener default in the modcluster subsystem. When turning off HTTP2 the clustering starts working again. Nothing is printed in the logs by default so DEBUG logging has to be turned on for undertow.
> Steps to reproduce:
> {code}
> unzip wildfly-dist-15.0.1.Final.zip
> # Terminal 1
> cd wildfly-15.0.1.Final/bin/
> ./standalone.sh -c standalone-load-balancer.xml -Djava.net.preferIPv4Stack=true -b 127.0.0.1 -Djboss.modcluster.multicast.address=230.0.0.4
> # Terminal 2
> cd wildfly-15.0.1.Final/bin/
> ./standalone.sh -c standalone-ha.xml -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=100 -Djboss.modcluster.multicast.address=230.0.0.4
> # Terminal 3
> cd wildfly-15.0.1.Final/bin/
> ./standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=200 -Djboss.modcluster.multicast.address=230.0.0.4
> # Terminal 4
> cd wildfly-15.0.1.Final/bin/
> ./jboss-cli.sh -c
> /subsystem=logging/logger=io.undertow:add(level=ALL)
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> connect localhost:10090
> /subsystem=logging/logger=io.undertow:add(level=ALL)
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> /subsystem=modcluster/proxy=default:write-attribute(name=listener,value=default)
> reload
> connect localhost:10190
> /subsystem=logging/logger=io.undertow:add(level=ALL)
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> /subsystem=modcluster/proxy=default:write-attribute(name=listener,value=default)
> reload
> {code}
> The following can be seen in the logs on the proxied servers:
> {code}
> 16:30:23,409 TRACE [io.undertow.request] (default I/O-7) Opened connection with /127.0.0.1:50002
> 16:30:23,410 DEBUG [io.undertow.request.error-response] (default I/O-7) Setting error code 500 for exchange HttpServerExchange{ OPTIONS * request {HTTP2-Settings=[AAEAABAAAAIAAAABAAQAAP//AAUAAEAA], Connection=[Upgrade, HTTP2-Settings], Upgrade=[h2c], User-Agent=[mod_cluster ping], Host=[127.0.0.1]} response {}}: java.lang.RuntimeException
> at io.undertow.server.HttpServerExchange.setStatusCode(HttpServerExchange.java:1410)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:393)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> 16:30:23,410 DEBUG [io.undertow.request.io] (default I/O-7) UT005013: An IOException occurred: java.io.IOException: Invalid base64 character encountered: 47
> at io.undertow.util.FlexBase64$Decoder.nextByte(FlexBase64.java:1048)
> at io.undertow.util.FlexBase64$Decoder.nextByte(FlexBase64.java:1015)
> at io.undertow.util.FlexBase64$Decoder.decode(FlexBase64.java:1277)
> at io.undertow.util.FlexBase64$Decoder.decode(FlexBase64.java:1347)
> at io.undertow.util.FlexBase64$Decoder.decode(FlexBase64.java:1413)
> at io.undertow.util.FlexBase64$Decoder.access$500(FlexBase64.java:983)
> at io.undertow.util.FlexBase64.decodeURL(FlexBase64.java:320)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleHttp2Upgrade(Http2UpgradeHandler.java:158)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleUpgradeBody(Http2UpgradeHandler.java:107)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:97)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> 16:30:23,411 TRACE [io.undertow.server.HttpServerExchange] (default I/O-7) Starting to write response for HttpServerExchange{ OPTIONS * request {HTTP2-Settings=[AAEAABAAAAIAAAABAAQAAP//AAUAAEAA], Connection=[Upgrade, HTTP2-Settings], Upgrade=[h2c], User-Agent=[mod_cluster ping], Host=[127.0.0.1]} response {Connection=[keep-alive], Content-Length=[0], Date=[Wed, 23 Jan 2019 15:30:23 GMT]}}
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months
[JBoss JIRA] (LOGMGR-239) Allow the DelayedHandler to perform a level check on each message
by David Lloyd (Jira)
David Lloyd created LOGMGR-239:
----------------------------------
Summary: Allow the DelayedHandler to perform a level check on each message
Key: LOGMGR-239
URL: https://issues.jboss.org/browse/LOGMGR-239
Project: JBoss Log Manager
Issue Type: Enhancement
Components: core
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 3.0.0.Final
When the delayed handler is replaying log messages, it will play them as if the log levels of the various categories were configured to accept them all. There should be a way to get the logger of each record and check if the record is still loggable before printing it.
Since handlers don't have access to the log manager or log context, {{DelayedHandler}} needs an optional {{LogContext}} parameter which, if present, can be queried for log levels.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 2 months