December 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-5901) Support promotion to BigDecimal from integer variables in executable model

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5901?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-5901: --------------------------------- Steps to Reproduce: (6b) BigDecimal_type_property <op> Numeric_variable ($bus.weight and ivar are initialized to 12000B, 1000 respectively) $bus.weight += ivar ==> 1000 // incorrect $bus.weight -= ivar ==> Error $bus.weight *= ivar ==> Error $bus.weight /= ivar ==> Error > Support promotion to BigDecimal from integer variables in executable model > -------------------------------------------------------------------------- > > Key: DROOLS-5901 > URL: https://issues.redhat.com/browse/DROOLS-5901 > Project: Drools > Issue Type: Bug > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5901) Support promotion to BigDecimal from integer variables in executable model

by Luca Molteni (Jira)

Luca Molteni created DROOLS-5901: ------------------------------------ Summary: Support promotion to BigDecimal from integer variables in executable model Key: DROOLS-5901 URL: https://issues.redhat.com/browse/DROOLS-5901 Project: Drools Issue Type: Bug Reporter: Luca Molteni Assignee: Luca Molteni -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14232) Setting proxy-address-forwarding=true per default?

by ralph Soika (Jira)

ralph Soika created WFLY-14232: ---------------------------------- Summary: Setting proxy-address-forwarding=true per default? Key: WFLY-14232 URL: https://issues.redhat.com/browse/WFLY-14232 Project: WildFly Issue Type: Enhancement Components: Web (Undertow) Affects Versions: 21.0.1.Final Reporter: ralph Soika Assignee: Flavia Rainone I want to suggest to set the http-listener flag {{"proxy-address-forwarding}}" to true per default. The background is: if you run Wildfly in a container environment with a reverse proxy in front of it doing the HTTPS termination, you can run into a problem. In JSF Applications a navigation rule <redirect/> leads to a 301 with a HTTP address even if the initial request was HTTPS. For example in a Form based login page this leads to a situation that the session cookie information is send out via HTTP. Adding proxy-address-forwarding=true to the default http-listner in the standalone.xml file solves this problem. There was also a discussion a long time ago here: [https://developer.jboss.org/message/948533] My question is: Why not setting this flag per default to true? Currently I need to build custom Wildfly Docker Images just because of this missing flag in the standalone.xml file. Otherwise it seems not be save to run the container in a container environment with a SSL Reverse Proxy. The problem get worse since yesterday as a new Chrome Browser update for is available. Because of this update users can no longer use JSF applications in this scenario. The user is shown the browser message "Die Angaben, die Sie senden möchten, sind nicht sicher" (in german). And the browser bocks the request. What do you think about adding proxy-address-forwarding=true per default? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1056) Try OCP 4.6 on IPv6 in PSI

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1056?page=com.atlassian.jira.plugi... ] Filip Brychta commented on SWSQE-1056: -------------------------------------- We will need this for SM 2.1 > Try OCP 4.6 on IPv6 in PSI > -------------------------- > > Key: SWSQE-1056 > URL: https://issues.redhat.com/browse/SWSQE-1056 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1089) Remove hardcoded waiting for webhook "smcp.validation.maistra.io"

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1089?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1089. ---------------------------------- Resolution: Done Filed https://issues.redhat.com/browse/MAISTRA-2044 to increase default timeouts are removed our hardcoded sleep > Remove hardcoded waiting for webhook "smcp.validation.maistra.io" > ----------------------------------------------------------------- > > Key: SWSQE-1089 > URL: https://issues.redhat.com/browse/SWSQE-1089 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Optional > Labels: infrastructure > > https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/blob/ma... > There is no need to wait that long. We need some dynamic check. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ] Boris Unckel updated WFLY-14219: -------------------------------- Attachment: 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z > Utilize JBoss Modules version 1.9 in module descriptors > ------------------------------------------------------- > > Key: WFLY-14219 > URL: https://issues.redhat.com/browse/WFLY-14219 > Project: WildFly > Issue Type: Task > Components: Server > Affects Versions: 22.0.0.Alpha1 > Reporter: Boris Unckel > Assignee: Brian Stansberry > Priority: Major > Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt, 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z > > > There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency. > List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt > Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13164) When "corrupted" public key is supplied to server, user is not informed

by Jan Kasik (Jira)

[ https://issues.redhat.com/browse/WFLY-13164?page=com.atlassian.jira.plugi... ] Jan Kasik commented on WFLY-13164: ---------------------------------- Hello [~szaldana], sorry, I forgot to include the whole URL. It is {{http://127.0.0.1:8080/CorruptedKeyTest/secured-endpoint}}, Entire test can be found in our QE MP testsuite https://github.com/jboss-eap-qe/eap-microprofile-test-suite/blob/master/m... > When "corrupted" public key is supplied to server, user is not informed > ----------------------------------------------------------------------- > > Key: WFLY-13164 > URL: https://issues.redhat.com/browse/WFLY-13164 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Affects Versions: 19.0.0.Beta2, 20.0.0.Beta1 > Reporter: Jan Kasik > Priority: Critical > Attachments: CorruptedKeyTest.war > > > When corrupted public key (a valid key cannot be extracted from the string value) is supplied to JWT verifier, user is not informed since there is no error message in log and clients receives 401 status code in response instead of an error code of 500. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (SWSQE-603) Migrate Jenkins2 CI Pipeline to PSI

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-603?page=com.atlassian.jira.plugin... ] Filip Brychta commented on SWSQE-603: ------------------------------------- [~mmahoney] that task is not done yet. We still run our own jenkins master and workers are running in our own OCP cluster. > Migrate Jenkins2 CI Pipeline to PSI > ------------------------------------ > > Key: SWSQE-603 > URL: https://issues.redhat.com/browse/SWSQE-603 > Project: Kiali QE > Issue Type: Story > Reporter: Matthew Mahoney > Assignee: Matthew Mahoney > Priority: Major > Labels: infrastructure > > QE CI/CP Integration -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5232) The bootable JAR temporary files are not cleaned up properly on Windows

by James Perkins (Jira)

James Perkins created WFCORE-5232: ------------------------------------- Summary: The bootable JAR temporary files are not cleaned up properly on Windows Key: WFCORE-5232 URL: https://issues.redhat.com/browse/WFCORE-5232 Project: WildFly Core Issue Type: Bug Components: Bootable JAR Reporter: James Perkins Assignee: James Perkins On Windows when an executable JAR is cancelled, {{CTRL+C}}, the temporary files seem to not be deleted. Heaps of warning messages are logged indicating this. This is likely due to JBoss Modules holding onto files which Windows sees as a lock and does not allow the file to be deleted. One possible option might be to launch a separate process which deletes the files. We could introduce a temporary PID type of file that gets deleted at the end of the main process ending the new process could look for and once removed the process could attempt to delete the files. This replaces the issue https://github.com/wildfly-extras/wildfly-jar-maven-plugin/issues/174. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13886) Remoting outbound channels are not closed

by Pankaj Narkhede (Jira)

[ https://issues.redhat.com/browse/WFLY-13886?page=com.atlassian.jira.plugi... ] Pankaj Narkhede commented on WFLY-13886: ---------------------------------------- Thanks Flavia for the updates. Could you please provide ETA for the same? > Remoting outbound channels are not closed > ----------------------------------------- > > Key: WFLY-13886 > URL: https://issues.redhat.com/browse/WFLY-13886 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 18.0.1.Final, 20.0.1.Final > Reporter: Pankaj Narkhede > Assignee: Flavia Rainone > Priority: Major > Labels: downstream_dependency > > We are seeing below issue in Wildfly 18 and 20 which is blocking our migration from wildfly10 but not seeing same issue in wildfly10. > It seems similar issue has been opened in JBEAP, https://issues.redhat.com/browse/JBEAP-18322 > > Suppressed: org.jboss.remoting3.ProtocolException: Too many channels open > at org.jboss.remoting3.remote.RemoteConnectionHandler.handleOutboundChannelOpen(RemoteConnectionHandler.java:194) > at org.jboss.remoting3.remote.RemoteConnectionHandler.open(RemoteConnectionHandler.java:335) > at org.jboss.remoting3.ConnectionImpl.openChannel(ConnectionImpl.java:109) > at org.jboss.remoting3.ClientServiceHandle.getClientService(ClientServiceHandle.java:80) > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

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 December 2020