May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13437) Upgrade wildfly-transaction-client to 1.1.11.Final

by Tomasz Adamski (Jira)

[ https://issues.redhat.com/browse/WFLY-13437?page=com.atlassian.jira.plugi... ] Tomasz Adamski updated WFLY-13437: ---------------------------------- Priority: Blocker (was: Critical) > Upgrade wildfly-transaction-client to 1.1.11.Final > -------------------------------------------------- > > Key: WFLY-13437 > URL: https://issues.redhat.com/browse/WFLY-13437 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Priority: Blocker > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13437) Upgrade wildfly-transaction-client to 1.1.11.Final

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-13437: ------------------------------------- Summary: Upgrade wildfly-transaction-client to 1.1.11.Final Key: WFLY-13437 URL: https://issues.redhat.com/browse/WFLY-13437 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: Tomasz Adamski Assignee: Tomasz Adamski -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4964) Upgrade jboss-classfilewriter from 1.2.4.Final to 1.2.5.Final

by Lin Gao (Jira)

Lin Gao created WFCORE-4964: ------------------------------- Summary: Upgrade jboss-classfilewriter from 1.2.4.Final to 1.2.5.Final Key: WFCORE-4964 URL: https://issues.redhat.com/browse/WFCORE-4964 Project: WildFly Core Issue Type: Component Upgrade Reporter: Lin Gao Assignee: Jeff Mesnil -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4589) Refactor of Scorecards

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4589?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-4589. ------------------------------------ > Refactor of Scorecards > ---------------------- > > Key: DROOLS-4589 > URL: https://issues.redhat.com/browse/DROOLS-4589 > Project: Drools > Issue Type: Task > Components: PMML > Reporter: Lance Leverich > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > _{color:#C1C7D0}(Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be... > * Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data > * Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete. > * Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format > * Scorecard models are -applied- via a service interface old specs){color}_ > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5308) Not able to read number of times rule fire in Scenario Coverage Report if rule name is longer than 27 characters

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5308?page=com.atlassian.jira.plug... ] Yeser Amer updated DROOLS-5308: ------------------------------- Description: When we run scenarios for rules with name longer than 27 characters and click on the Coverage Report. We can’t read the number of times the rule ran because the rule name overlaps it, even if I expand the frame. Take a look at the attached screenshot. Expected Result: The numbers should always be visible no matter how long the name or how narrow/wide the frame is. > Not able to read number of times rule fire in Scenario Coverage Report if rule name is longer than 27 characters > ---------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-5308 > URL: https://issues.redhat.com/browse/DROOLS-5308 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing, Test Scenarios Editor > Affects Versions: 7.36.0.Final > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: drools-tooling > > When we run scenarios for rules with name longer than 27 characters and click on the Coverage Report. We can’t read the number of times the rule ran because the rule name overlaps it, even if I expand the frame. Take a look at the attached screenshot. > Expected Result: The numbers should always be visible no matter how long the name or how narrow/wide the frame is. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5308) Not able to read number of times rule fire in Scenario Coverage Report if rule name is longer than 27 characters

by Yeser Amer (Jira)

Yeser Amer created DROOLS-5308: ---------------------------------- Summary: Not able to read number of times rule fire in Scenario Coverage Report if rule name is longer than 27 characters Key: DROOLS-5308 URL: https://issues.redhat.com/browse/DROOLS-5308 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing, Test Scenarios Editor Affects Versions: 7.36.0.Final Reporter: Yeser Amer Assignee: Yeser Amer -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFLY-13433: ----------------------------------------- Subsystems should not cross reference other subsystems Capabilities directly anyway, by doing so the module for the other subsystem must be present for a subsystem to even define it's dependency - in other cases the same capability could be provided by an alternative subsystem - as an example all of the security capabilities could potentially be advertised by a completely different subsystem. > Improve capability support in EJB3 subsystem > -------------------------------------------- > > Key: WFLY-13433 > URL: https://issues.redhat.com/browse/WFLY-13433 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 20.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > > Survey all external subsystem dependencies and introduce capability based dependencies where required. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2474: -------------------------------- The leaving channel should block until it either receives a LEAVE-RSP, or runs into {{GMS.leave_timeout}}. Which JIRA are you referring to? > Messages about dropped queued message when using IpAddressUUID > -------------------------------------------------------------- > > Key: JGRP-2474 > URL: https://issues.redhat.com/browse/JGRP-2474 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.3 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Attachments: JGR.java, log-fail-1.txt > > > We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like > {code} > Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages > WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1) > {code} > when ever an application is restarted. Our setup is as follows (most due to network restrictions): > * Fixed port numbers > * JDBC_PING > * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table > I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above. > I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine. > I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this. > While running this on higher debug levels, I observed the following: 4.1.2 will not require an > ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used, -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID

by Mirko Streckenbach (Jira)

[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ] Mirko Streckenbach commented on JGRP-2474: ------------------------------------------ [~belaban] Thanks for the info, using UUID solved the obvious problem. The change from 4.1.2 to 4.1.3 that causes the coordinate to send the LEAVE_RSP message long after the second channel was stopped: is this problematic (or even intended) ? > Messages about dropped queued message when using IpAddressUUID > -------------------------------------------------------------- > > Key: JGRP-2474 > URL: https://issues.redhat.com/browse/JGRP-2474 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.3 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Attachments: JGR.java, log-fail-1.txt > > > We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like > {code} > Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages > WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1) > {code} > when ever an application is restarted. Our setup is as follows (most due to network restrictions): > * Fixed port numbers > * JDBC_PING > * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table > I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above. > I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine. > I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this. > While running this on higher debug levels, I observed the following: 4.1.2 will not require an > ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used, -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-316) Different behaviour of ADMIN_PASSWORD and securing management interface

by Martin Choma (Jira)

[ https://issues.redhat.com/browse/WFWIP-316?page=com.atlassian.jira.plugin... ] Martin Choma updated WFWIP-316: ------------------------------- Priority: Blocker (was: Major) > Different behaviour of ADMIN_PASSWORD and securing management interface > ----------------------------------------------------------------------- > > Key: WFWIP-316 > URL: https://issues.redhat.com/browse/WFWIP-316 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > > With XP image started to fail test where {{ADMIN_PASSWORD}} env var is empty. Because test is expecting management interface to be unsecured in that case. But this does not happen and management interface is secured with SASL authentication factory. Test is using CLI so it is SASL which is used for accessing management interface. > Seems in other images CD, 7.3.0.GA (with legacy security in place) when {{ADMIN_PASSWORD}} was empty management interface was left unsecured. > Seems to me we should be consistent between legacy security and Elytron approach of securing OpenShift images. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020