June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-121) Support Log4J2 API

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-121?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGMGR-121: -------------------------------------- [~xf01213] Yeah I would say so. I can probably close this now. Thanks! > Support Log4J2 API > ------------------ > > Key: LOGMGR-121 > URL: https://issues.redhat.com/browse/LOGMGR-121 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: James Livingston > Priority: Major > > The API of Log4j 1.2 is supported by https://github.com/jboss-logging/log4j-jboss-logmanager, to bridge that API to our logging implementation. > It would be useful to have an equivalent bridge for the Log4J2 API, which may be easier than for 1.2 since the API is split from the implementation. > It may be possible to http://logging.apache.org/log4j/2.x/log4j-to-slf4j/index.html as a work-around, so Log4J2 bridges to SLF4J, which is bridged to JBoss LogManager -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5454) Please bring back the IDE-based 'Guided Rule Editor'

by Edson Tirelli (Jira)

[ https://issues.redhat.com/browse/DROOLS-5454?page=com.atlassian.jira.plug... ] Edson Tirelli commented on DROOLS-5454: --------------------------------------- [~id40417-citi] [~rick_wagner] unfortunately we can no longer develop or maintain an eclipse plugin. We have been working on VSCode and CodeReady to offer an alternate solution for developers. > Please bring back the IDE-based 'Guided Rule Editor' > ---------------------------------------------------- > > Key: DROOLS-5454 > URL: https://issues.redhat.com/browse/DROOLS-5454 > Project: Drools > Issue Type: Feature Request > Components: eclipse plugin > Affects Versions: 7.39.0.Final > Reporter: Rick Wagner > Assignee: Edson Tirelli > Priority: Major > > JBoss Rules users have had access to an Eclipse/DevStudio plugin called the "Guided Rules Editor". It has been removed or replaced by non-IDE solutions. This is disappointing to some users who have business processes, training, etc. based around the plugin version. > > Please bring back the Guided Rule Editor. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1994) Ensure the Elytron build works on Java 14

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/ELY-1994?page=com.atlassian.jira.plugin.... ] Sonia Zaldana reassigned ELY-1994: ---------------------------------- Assignee: Sonia Zaldana > Ensure the Elytron build works on Java 14 > ----------------------------------------- > > Key: ELY-1994 > URL: https://issues.redhat.com/browse/ELY-1994 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Sonia Zaldana > Priority: Major > Fix For: 1.13.0.CR2 > > > Overall the build is not doing too badly and doesn't fail until we get to the main testsuite. > > {code:java} > [INFO] WildFly Elytron - Tests ............................ FAILURE [ 1.447 s] > [INFO] WildFly Elytron .................................... SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 01:46 min > [INFO] Finished at: 2020-06-11T11:25:23+01:00 > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0-jboss-1:testCompile (default-testCompile) on project wildfly-elytron-tests: Compilation failure: Compilation failure: > [ERROR] /home/darranl/src/community/wildfly-elytron/tests/base/src/test/java/org/wildfly/security/auth/TestLoginModule.java:[31,25] package java.security.acl does not exist > [ERROR] /home/darranl/src/community/wildfly-elytron/tests/base/src/test/java/org/wildfly/security/auth/TestLoginModule.java:[107,40] cannot find symbol > [ERROR] symbol: class Group > [ERROR] location: class org.wildfly.security.auth.TestLoginModule > [ERROR] -> [Help 1] {code} > If this is all that is failing for us maybe we can revisit the test and see how appropriate it is and if it can be adapted to use available APIs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1999) Upgrade JBoss Threads to 2.3.5.Final

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/ELY-1999?page=com.atlassian.jira.plugin.... ] Sonia Zaldana updated ELY-1999: ------------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1421 > Upgrade JBoss Threads to 2.3.5.Final > ------------------------------------ > > Key: ELY-1999 > URL: https://issues.redhat.com/browse/ELY-1999 > Project: WildFly Elytron > Issue Type: Component Upgrade > Components: Build > Reporter: Farah Juma > Assignee: Sonia Zaldana > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1999) Upgrade JBoss Threads to 2.3.5.Final

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/ELY-1999?page=com.atlassian.jira.plugin.... ] Sonia Zaldana reassigned ELY-1999: ---------------------------------- Assignee: Sonia Zaldana > Upgrade JBoss Threads to 2.3.5.Final > ------------------------------------ > > Key: ELY-1999 > URL: https://issues.redhat.com/browse/ELY-1999 > Project: WildFly Elytron > Issue Type: Component Upgrade > Components: Build > Reporter: Farah Juma > Assignee: Sonia Zaldana > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler

by lukas brandl (Jira)

[ https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin... ] lukas brandl commented on JGRP-2486: ------------------------------------ Thank you for the quick reply and the recommendations. To clarify: the dead node is never suspected by the surviving node in this case. The thread getting stuck on the bundler (or the tcp connection) isn’t a problem in itself but appears to be the reason why the the node is never suspected. We are aware that there are newer alternatives to FD, but we can’t easily change the protocol stack if this causes incompatibility with previous versions and therefore can’t be upgraded in a rolling fashion. > FD Monitor get stuck on TrasferQueueBundler > ------------------------------------------- > > Key: JGRP-2486 > URL: https://issues.redhat.com/browse/JGRP-2486 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.22 > Reporter: lukas brandl > Assignee: Bela Ban > Priority: Major > Attachments: Main.java, stack-trace.txt > > > Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected. > The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-2000) Add additional TRACE logging in GssapiClient when obtaining credential using Callback

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-2000: ------------------------------------- Summary: Add additional TRACE logging in GssapiClient when obtaining credential using Callback Key: ELY-2000 URL: https://issues.redhat.com/browse/ELY-2000 Project: WildFly Elytron Issue Type: Enhancement Components: SASL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.13.0.CR2 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5458) Project broken after test scenario run with possibly a class-loading issue

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5458?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5458: -------------------------------- Labels: drools-tools (was: ) > Project broken after test scenario run with possibly a class-loading issue > -------------------------------------------------------------------------- > > Key: DROOLS-5458 > URL: https://issues.redhat.com/browse/DROOLS-5458 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.39.0.Final > Reporter: Jan Stastny > Assignee: Yeser Amer > Priority: Blocker > Labels: drools-tools > Attachments: bpms_scesim-tickets.zip > > > For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central. > The ultimate error is in the DRL file validation: > {code:java|title=DRL file} > package org.jboss.qa.ba.scesim; > rule "child ticket" > when > t: Ticket ( type==TicketType.CHILD) > then > t.setPrice(5.0); > end > {code} > {code:java|title=Validation error} > [KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD: > [Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType] > [Near : {... type == TicketType.CHILD ....}] > ^ > {code} > The issue happens in given scenario: > # import project > # go to DRL file and run validation - succeeds > # go to scenario simulation and run - succeeds > # go back to DRL file and run validation - fails with the error above > # go to scenario simulation and run again - fails due to the rule not being evaluated for given facts > The issue disappears when running Build of the project in the Project perspective. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin... ] Bela Ban edited comment on JGRP-2486 at 6/26/20 8:08 AM: --------------------------------------------------------- This wouldn't happen if you used {{UDP}} or {{TCP_NIO2}}. Also, if you disabled the NIC, TCP itself would block after a while, so what's the use case here? Note that you could use {{RED}} to drop messages if the queue starts getting full... The surviving node should suspect and exclude the dead node. Note that I don't recommend FD, I suggest use FD_ALL2 or FD_ALL3 instead; there have been some nice improvements in the latter, e.g. skipping the sending of heartbeats if real traffoc is received etc was (Author: belaban): This wouldn't happen if you used {{UDP}} or {{TCP_NIO2}}. Also, if you disabled the NIC, TCP itself would block after a while, so what's the use case here? Note that you could use {{RED}} to drop messages if the queue starts getting full... > FD Monitor get stuck on TrasferQueueBundler > ------------------------------------------- > > Key: JGRP-2486 > URL: https://issues.redhat.com/browse/JGRP-2486 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.22 > Reporter: lukas brandl > Assignee: Bela Ban > Priority: Major > Attachments: Main.java, stack-trace.txt > > > Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected. > The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2486: -------------------------------- This wouldn't happen if you used {{UDP}} or {{TCP_NIO2}}. Also, if you disabled the NIC, TCP itself would block after a while, so what's the use case here? Note that you could use {{RED}} to drop messages if the queue starts getting full... > FD Monitor get stuck on TrasferQueueBundler > ------------------------------------------- > > Key: JGRP-2486 > URL: https://issues.redhat.com/browse/JGRP-2486 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.22 > Reporter: lukas brandl > Assignee: Bela Ban > Priority: Major > Attachments: Main.java, stack-trace.txt > > > Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected. > The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2020