February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4984) Enable the executable model in Optaplanner

by Geoffrey De Smet (Jira)

[ https://issues.redhat.com/browse/DROOLS-4984?page=com.atlassian.jira.plug... ] Geoffrey De Smet updated DROOLS-4984: ------------------------------------- Tester: Radovan Synek (was: Tibor Zimanyi) > Enable the executable model in Optaplanner > ------------------------------------------ > > Key: DROOLS-4984 > URL: https://issues.redhat.com/browse/DROOLS-4984 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > Currently it's disabled -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11548) RemoteExceptions and subclasses treated as ApplicationExceptions

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFLY-11548?page=com.atlassian.jira.plugi... ] Moulali Shikalwadi commented on WFLY-11548: ------------------------------------------- Hi [~hefnawio], Could you please help me reproducing this issue. > RemoteExceptions and subclasses treated as ApplicationExceptions > ---------------------------------------------------------------- > > Key: WFLY-11548 > URL: https://issues.redhat.com/browse/WFLY-11548 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 13.0.0.Final > Environment: - Windows > - Wildfly 13 final > - Java sdk 1.8 > Reporter: Omar Hefnawi > Assignee: Moulali Shikalwadi > Priority: Major > > Remote Exceptions should be treated as if they are System Exceptions > So in very old projects where they used to extend RemoteException for their own exceptions, code was written under the assumption that when one of these is caught in the container, the transaction should be rolled back as per the spec (system exceptions cause a rollback). > Currently if an ejb method throws a remote exception, this will be translated to be an Application Exception (on line 275 in EJBComponent.java) and transactions that are currently happening will no longer be rolled back; which was against the old spec, I'm unsure of what ejb 3.X says about this, but currently I felt it would make sense to mimic what happened in older application containers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13031) EAP quickstart 'messaging-clustering-singleton' shows errors after import

by Zbyněk Červinka (Jira)

[ https://issues.redhat.com/browse/WFLY-13031?page=com.atlassian.jira.plugi... ] Zbyněk Červinka commented on WFLY-13031: ---------------------------------------- [~emmartins] Still the same 3 errors. Same errors on both JDK 8 and JDK 11, reproduced on OS X 10.14.6. h3. Red Hat CodeReady Studio version: Version: 12.14.0.GA Build id: GA-v20200204-1100-B5837 Build date: 20200204-1100 > EAP quickstart 'messaging-clustering-singleton' shows errors after import > ------------------------------------------------------------------------- > > Key: WFLY-13031 > URL: https://issues.redhat.com/browse/WFLY-13031 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Reporter: Zbyněk Červinka > Assignee: Parul Sharma > Priority: Major > Attachments: Problems view.png, Project Explorer.png, jboss-ejb3.xml file.png > > > h1. EAP quickstart 'messaging-clustering-singleton' shows 3 errors in the jboss-ejb3.xml file after import: > * Referenced file contains errors (jar:file:/Applications/codereadystudio-eap-8/studio/codereadystudio.app/Contents/Eclipse/plugins/org.jboss.tools.as.catalog_3.7.0.v20190624-1620.jar!/schema/xsd/jboss-ejb-delivery-active_1_1.xsd). For more information, right click on the message in the Problems View and select "Show Details..." > * Referenced file contains errors (jar:file:/Applications/codereadystudio-eap-8/studio/codereadystudio.app/Contents/Eclipse/plugins/org.jboss.tools.as.catalog_3.7.0.v20190624-1620.jar!/schema/xsd/jboss-ejb3-2_0.xsd). For more information, right click on the message in the Problems View and select "Show Details..." > * Referenced file contains errors (jar:file:/Applications/codereadystudio-eap-8/studio/codereadystudio.app/Contents/Eclipse/plugins/org.jboss.tools.as.catalog_3.7.0.v20190624-1620.jar!/schema/xsd/jboss-ejb3-spec-2_0.xsd). For more information, right click on the message in the Problems View and select "Show Details..." -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-265) log4j2-jboss-logmanager: Service Provider wrong file

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/LOGMGR-265?page=com.atlassian.jira.plugi... ] Boris Unckel updated LOGMGR-265: -------------------------------- Description: Currently the service provider class is https://github.com/jboss-logging/log4j2-jboss-logmanager/blob/master/src/... according to https://logging.apache.org/log4j/2.x/manual/extending.html it must be META-INF/services/org.apache.logging.spi.Provider (without the log4j in its name). was: Currently the service provider class is https://github.com/jboss-logging/log4j2-jboss-logmanager/blob/master/src/... according to https://logging.apache.org/log4j/2.x/manual/extending.html it must be META-INF/services/org.apache.logging.spi.Provider (without the log4j in its name). > log4j2-jboss-logmanager: Service Provider wrong file > ----------------------------------------------------- > > Key: LOGMGR-265 > URL: https://issues.redhat.com/browse/LOGMGR-265 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: Boris Unckel > Priority: Blocker > > Currently the service provider class is > https://github.com/jboss-logging/log4j2-jboss-logmanager/blob/master/src/... > according to https://logging.apache.org/log4j/2.x/manual/extending.html it must be META-INF/services/org.apache.logging.spi.Provider (without the log4j in its name). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-265) log4j2-jboss-logmanager: Service Provider wrong file

by Boris Unckel (Jira)

Boris Unckel created LOGMGR-265: ----------------------------------- Summary: log4j2-jboss-logmanager: Service Provider wrong file Key: LOGMGR-265 URL: https://issues.redhat.com/browse/LOGMGR-265 Project: JBoss Log Manager Issue Type: Bug Reporter: Boris Unckel Currently the service provider class is https://github.com/jboss-logging/log4j2-jboss-logmanager/blob/master/src/... according to https://logging.apache.org/log4j/2.x/manual/extending.html it must be META-INF/services/org.apache.logging.spi.Provider (without the log4j in its name). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4942) DMN DT Analysis hit policy recommender

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4942?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4942: ----------------------------------- Security: (was: Red Hat Internal) > DMN DT Analysis hit policy recommender > -------------------------------------- > > Key: DROOLS-4942 > URL: https://issues.redhat.com/browse/DROOLS-4942 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1066) Allow to specify istio version for install-istio job

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1066?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1066. ---------------------------------- Resolution: Done https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/commit/... > Allow to specify istio version for install-istio job > ---------------------------------------------------- > > Key: SWSQE-1066 > URL: https://issues.redhat.com/browse/SWSQE-1066 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Currently it's downloading the latest. We need to be able to specify a version -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2448) FD_SOCK IndexOutOfBoundsException

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2448?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2448. ---------------------------- Resolution: Done Synchronized access to {{pingable_mbrs}}. Fixed in 4.x and forward-ported to master. > FD_SOCK IndexOutOfBoundsException > --------------------------------- > > Key: JGRP-2448 > URL: https://issues.redhat.com/browse/JGRP-2448 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0, 4.2.0 > > > {{PD_SOCK.pickNext()}} should iterate up to {{size - 1}}: > {noformat} > java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0 > at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248) > at java.base/java.util.Objects.checkIndex(Objects.java:372) > at java.base/java.util.ArrayList.get(ArrayList.java:458) > at java.base/java.util.Collections$SynchronizedList.get(Collections.java:2424) > at org.jgroups.util.Util.pickNext(Util.java:2686) > at org.jgroups.protocols.FD_SOCK.determinePingDest(FD_SOCK.java:762) > at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:408) > at java.base/java.lang.Thread.run(Thread.java:834) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5

by Ingo Weiss (Jira)

[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ] Ingo Weiss updated WFLY-13061: ------------------------------ Description: (was: Customer application registers Bouncy Castle as a JCE provider with in Picketlink. There is a bug in Bouncy castle when it is used with Java 11.0.5 and later that causes a crash due to a missing null pointer check. The issue is patched upstream, and they would like the patch applied to the version we release with JBoss EAP. The attached java file is the file from Bouncy castle 1.60 with the upstream patch applied so it can be compared to the originaly version Their complete report: {quote} This results in BC implementations of various crypto algorithms being used, e.g., for TLS connections. Unfortunately, all currently available releases of the BC crypto provider [1] (also Beta 1.65b02 [2]) contain a bug which breaks TLS handshakes when ECDHE key exchange is used. This key exchange mechanism requires the data transferred between the peers to be signed using RSASSA-PSS -- a signature scheme whose implementation in BC lacks a null check during its initialization phase. The problem only occurs since OpenJDK 11.0.5 and 13 due to a regression introduced in OpenJDK by [3] which fixed another compatibility issue with BC. Downgrading the installed JDK to 11.0.4 is not an option, as the issue fixed by [1] will arise and we would lose a number of JDK security fixes. I also strongly believe that BC instead of the JDK is the right place to resolve the defect. An issue has been opened with BC in [4] which has resulted in a merged pull request in [5], but since there is no ETA on a release of BC that will incorporate this fix, we need a viable interim solution to the problem, otherwise TLS connections with JBoss will not work in our environment. I've merged the fix from [5] locally to version 1.60 of the BC provider and successfully tested it by manually adjusting the Jboss module org.bouncycastle to use my own patched version of bcprov-jdk15on. Since our client insists on an official solution from Red Hat, I'd like to know if you could build a one-off patch for BC provider for us. I will attach the changed class org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi for BC 1.60 to this ticket. [1] https://www.bouncycastle.org/java.html [2] https://downloads.bouncycastle.org/betas/ [3] https://bugs.openjdk.java.net/browse/JDK-8216039 [4] https://github.com/bcgit/bc-java/issues/633 [5] https://github.com/bcgit/bc-java/pull/632 {quote}) > Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5 > ----------------------------------------------------------------------------- > > Key: WFLY-13061 > URL: https://issues.redhat.com/browse/WFLY-13061 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 19.0.0.Beta2 > Reporter: Ingo Weiss > Assignee: Bartosz Baranowski > Priority: Major > Labels: bouncycastle, java11, picketlink > Attachments: PSSSignatureSpi.java > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5

by Ingo Weiss (Jira)

[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ] Ingo Weiss updated WFLY-13061: ------------------------------ Labels: bouncycastle java11 picketlink (was: bouncycastle java11 picketlink upstream upstream-fixed) > Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5 > ----------------------------------------------------------------------------- > > Key: WFLY-13061 > URL: https://issues.redhat.com/browse/WFLY-13061 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 19.0.0.Beta2 > Reporter: Ingo Weiss > Assignee: Bartosz Baranowski > Priority: Major > Labels: bouncycastle, java11, picketlink > Attachments: PSSSignatureSpi.java > > > Customer application registers Bouncy Castle as a JCE provider with in Picketlink. There is a bug in Bouncy castle when it is used with Java 11.0.5 and later that causes a crash due to a missing null pointer check. The issue is patched upstream, and they would like the patch applied to the version we release with JBoss EAP. > The attached java file is the file from Bouncy castle 1.60 with the upstream patch applied so it can be compared to the originaly version > Their complete report: > {quote} > This results in BC implementations of various crypto algorithms being used, e.g., for TLS connections. > Unfortunately, all currently available releases of the BC crypto provider [1] (also Beta 1.65b02 [2]) contain a bug which breaks TLS handshakes when ECDHE key exchange is used. This key exchange mechanism requires the data transferred between the peers to be signed using RSASSA-PSS -- a signature scheme whose implementation in BC lacks a null check during its initialization phase. > The problem only occurs since OpenJDK 11.0.5 and 13 due to a regression introduced in OpenJDK by [3] which fixed another compatibility issue with BC. Downgrading the installed JDK to 11.0.4 is not an option, as the issue fixed by [1] will arise and we would lose a number of JDK security fixes. I also strongly believe that BC instead of the JDK is the right place to resolve the defect. > An issue has been opened with BC in [4] which has resulted in a merged pull request in [5], but since there is no ETA on a release of BC that will incorporate this fix, we need a viable interim solution to the problem, otherwise TLS connections with JBoss will not work in our environment. > I've merged the fix from [5] locally to version 1.60 of the BC provider and successfully tested it by manually adjusting the Jboss module org.bouncycastle to use my own patched version of bcprov-jdk15on. Since our client insists on an official solution from Red Hat, I'd like to know if you could build a one-off patch for BC provider for us. I will attach the changed class org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi for BC 1.60 to this ticket. > [1] https://www.bouncycastle.org/java.html > [2] https://downloads.bouncycastle.org/betas/ > [3] https://bugs.openjdk.java.net/browse/JDK-8216039 > [4] https://github.com/bcgit/bc-java/issues/633 > [5] https://github.com/bcgit/bc-java/pull/632 > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 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 February 2020