July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4532) Investigate new JDK 13 regressions

by Jaikiran Pai (Jira)

[ https://issues.jboss.org/browse/WFCORE-4532?page=com.atlassian.jira.plugi... ] Jaikiran Pai commented on WFCORE-4532: -------------------------------------- More of a FYI - there's a discussion going on, for this specific change, in the OpenJDK mailing list http://mail.openjdk.java.net/pipermail/security-dev/2019-July/020308.html > Investigate new JDK 13 regressions > ---------------------------------- > > Key: WFCORE-4532 > URL: https://issues.jboss.org/browse/WFCORE-4532 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Richard Opalka > Assignee: Darran Lofthouse > Priority: Critical > Labels: jdk13 > > Latest Open JDK 13 Early Access 25 introduced six new regressions in our test suites. > Failing tests in WILDFLY-CORE are: > * wildfly-core/elytron/src/test/java/org/wildfly/extension/elytron/TlsTestCase.java > * wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosHttpMgmtSaslTestCase.java > * wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java > Failing tests in WILDFLY are: > * wildfly/testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/CertificateRolesLoginModuleTestCase.java > * wildfly/testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/DatabaseCertLoginModuleTestCase.java > * wildfly/testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/HTTPSWebConnectorTestCase.java > Could somebody from our security team have a look what is going on [~darran] ? -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4278) Applying PMML model on kie-server fails

by Lance Leverich (Jira)

[ https://issues.jboss.org/browse/DROOLS-4278?page=com.atlassian.jira.plugi... ] Lance Leverich updated DROOLS-4278: ----------------------------------- Labels: CustomerFocus drools-tools support (was: CustomerFocus sustaining) > Applying PMML model on kie-server fails > --------------------------------------- > > Key: DROOLS-4278 > URL: https://issues.jboss.org/browse/DROOLS-4278 > Project: Drools > Issue Type: Bug > Components: kie server, PMML > Reporter: Lance Leverich > Assignee: Lance Leverich > Priority: Major > Labels: CustomerFocus, drools-tools, support > > If a kjar contains multiple KieBases, and that kjar is loaded into a container owned by a KieServer, calling the ApplyPmmlModelCommand results in a ClassCastException when the command tries to cast the org.kie.api.runtime.Context to a org.drools.core.command.RequestContextImpl. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4278) Applying PMML model on kie-server fails

by Lance Leverich (Jira)

Lance Leverich created DROOLS-4278: -------------------------------------- Summary: Applying PMML model on kie-server fails Key: DROOLS-4278 URL: https://issues.jboss.org/browse/DROOLS-4278 Project: Drools Issue Type: Bug Components: kie server, PMML Reporter: Lance Leverich Assignee: Lance Leverich If a kjar contains multiple KieBases, and that kjar is loaded into a container owned by a KieServer, calling the ApplyPmmlModelCommand results in a ClassCastException when the command tries to cast the org.kie.api.runtime.Context to a org.drools.core.command.RequestContextImpl. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-806) Brew Repo Support on ocp4-kqe OCP4 Clusterts

by Matthew Mahoney (Jira)

Matthew Mahoney created SWSQE-806: ------------------------------------- Summary: Brew Repo Support on ocp4-kqe OCP4 Clusterts Key: SWSQE-806 URL: https://issues.jboss.org/browse/SWSQE-806 Project: Kiali QE Issue Type: QE Task Reporter: Matthew Mahoney Assignee: Filip Brychta The new ocp4-kqe OCP4 clusters will need to support being able to pull builds from Brew. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4525) Fix failing tests on IBM JDK

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-4525?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-4525: --------------------------------------- [~ropalka] this should fix those tests https://github.com/wildfly/wildfly-core/pull/3850. The embedded ones should have been ignored. > Fix failing tests on IBM JDK > ---------------------------- > > Key: WFCORE-4525 > URL: https://issues.jboss.org/browse/WFCORE-4525 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Richard Opalka > Assignee: James Perkins > Priority: Major > Attachments: forked-booter.png, ibm-jdk8.png, oracle-jdk.png > > > The following tests are failing on latest IBM JDK 8: > --- > # testsuite/standalone > SilentModeTestCase > # testsuite/manualmode > CLIEmbedHostControllerTestCase > CLIEmbedServerTestCase > --- > Tested on: > --- > java version "1.8.0_211" > Java(TM) SE Runtime Environment (build 8.0.5.36 - pxa6480sr5fp36-20190510_01(SR5 FP36)) > IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled) > OpenJ9 - 46e57f9 > OMR - 06a046a > IBM - 0b909bf) > JCL - 20190409_01 based on Oracle jdk8u211-b25 > --- -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12101) Integration test for EJBCLIENT-335, display host:port on connecting to server error

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-12101?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-12101: --------------------------------- Fix Version/s: 17.0.1.Final > Integration test for EJBCLIENT-335, display host:port on connecting to server error > ----------------------------------------------------------------------------------- > > Key: WFLY-12101 > URL: https://issues.jboss.org/browse/WFLY-12101 > Project: WildFly > Issue Type: Task > Reporter: Teresa Miyar Gil > Assignee: Teresa Miyar Gil > Priority: Major > Fix For: 17.0.1.Final, 18.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12200) Upgrade jboss-ejb-client from 4.0.18 to 4.0.20

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-12200?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-12200: --------------------------------- Fix Version/s: 17.0.1.Final > Upgrade jboss-ejb-client from 4.0.18 to 4.0.20 > ---------------------------------------------- > > Key: WFLY-12200 > URL: https://issues.jboss.org/browse/WFLY-12200 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Affects Versions: 17.0.0.Final > Reporter: Teresa Miyar Gil > Assignee: Cheng Fang > Priority: Major > Fix For: 17.0.1.Final, 18.0.0.Beta1 > > > compare between 4.0.18.Final and the next version (4.0.20.Final): > https://github.com/wildfly/jboss-ejb-client/compare/4.0.18.Final...4.0.20... > Any particular fixes are you expecting? -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12266) Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created.

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12266?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12266: -------------------------------- Description: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision (since session timeouts only have second precision). However, we assume that a given distributed session is "new" if its last access duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. was: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. > Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12266 > URL: https://issues.jboss.org/browse/WFLY-12266 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision (since session timeouts only have second precision). However, we assume that a given distributed session is "new" if its last access duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. > Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12266) Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created.

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12266?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12266: -------------------------------- Description: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. was: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. > Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12266 > URL: https://issues.jboss.org/browse/WFLY-12266 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. > Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12266) Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created.

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12266?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12266: -------------------------------- Description: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. was:As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. > Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12266 > URL: https://issues.jboss.org/browse/WFLY-12266 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. > Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 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 July 2019