September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13900) Upgrade to MyFaces 2.3.6

by Christian Beikov (Jira)

Christian Beikov created WFLY-13900: --------------------------------------- Summary: Upgrade to MyFaces 2.3.6 Key: WFLY-13900 URL: https://issues.redhat.com/browse/WFLY-13900 Project: WildFly Issue Type: Component Upgrade Components: JSF Affects Versions: 21.0.0.Beta1 Reporter: Christian Beikov Assignee: Farah Juma Fix For: 21.0.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13899) JSF-Installer fails to deploy because it uses the wrong digester version

by Christian Beikov (Jira)

[ https://issues.redhat.com/browse/WFLY-13899?page=com.atlassian.jira.plugi... ] Christian Beikov updated WFLY-13899: ------------------------------------ Fix Version/s: 21.0.0.Final (was: 20.0.0.Final) > JSF-Installer fails to deploy because it uses the wrong digester version > ------------------------------------------------------------------------ > > Key: WFLY-13899 > URL: https://issues.redhat.com/browse/WFLY-13899 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 21.0.0.Beta1 > Reporter: Christian Beikov > Assignee: Brian Stansberry > Priority: Major > Fix For: 21.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13899) JSF-Installer fails to deploy because it uses the wrong digester version

by Christian Beikov (Jira)

[ https://issues.redhat.com/browse/WFLY-13899?page=com.atlassian.jira.plugi... ] Christian Beikov updated WFLY-13899: ------------------------------------ Affects Version/s: 21.0.0.Beta1 (was: 20.0.0.Beta1) > JSF-Installer fails to deploy because it uses the wrong digester version > ------------------------------------------------------------------------ > > Key: WFLY-13899 > URL: https://issues.redhat.com/browse/WFLY-13899 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 21.0.0.Beta1 > Reporter: Christian Beikov > Assignee: Brian Stansberry > Priority: Major > Fix For: 20.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13899) JSF-Installer fails to deploy because it uses the wrong digester version

by Christian Beikov (Jira)

[ https://issues.redhat.com/browse/WFLY-13899?page=com.atlassian.jira.plugi... ] Christian Beikov updated WFLY-13899: ------------------------------------ Fix Version/s: 20.0.0.Final > JSF-Installer fails to deploy because it uses the wrong digester version > ------------------------------------------------------------------------ > > Key: WFLY-13899 > URL: https://issues.redhat.com/browse/WFLY-13899 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 20.0.0.Beta1 > Reporter: Christian Beikov > Assignee: Brian Stansberry > Priority: Major > Fix For: 20.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13899) JSF-Installer fails to deploy because it uses the wrong digester version

by Christian Beikov (Jira)

[ https://issues.redhat.com/browse/WFLY-13899?page=com.atlassian.jira.plugi... ] Christian Beikov updated WFLY-13899: ------------------------------------ Component/s: JSF > JSF-Installer fails to deploy because it uses the wrong digester version > ------------------------------------------------------------------------ > > Key: WFLY-13899 > URL: https://issues.redhat.com/browse/WFLY-13899 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Christian Beikov > Assignee: Brian Stansberry > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13899) JSF-Installer fails to deploy because it uses the wrong digester version

by Christian Beikov (Jira)

[ https://issues.redhat.com/browse/WFLY-13899?page=com.atlassian.jira.plugi... ] Christian Beikov updated WFLY-13899: ------------------------------------ Affects Version/s: 20.0.0.Beta1 > JSF-Installer fails to deploy because it uses the wrong digester version > ------------------------------------------------------------------------ > > Key: WFLY-13899 > URL: https://issues.redhat.com/browse/WFLY-13899 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 20.0.0.Beta1 > Reporter: Christian Beikov > Assignee: Brian Stansberry > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13899) JSF-Installer fails to deploy because it uses the wrong digester version

by Christian Beikov (Jira)

Christian Beikov created WFLY-13899: --------------------------------------- Summary: JSF-Installer fails to deploy because it uses the wrong digester version Key: WFLY-13899 URL: https://issues.redhat.com/browse/WFLY-13899 Project: WildFly Issue Type: Bug Reporter: Christian Beikov Assignee: Brian Stansberry -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13898) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFLY-13898?page=com.atlassian.jira.plugi... ] Jean Francois Denise commented on WFLY-13898: --------------------------------------------- The resteasy-validator-provider is not provisioned with Beta1. FYI, it is provisioned with 21.0.0.Final-SNAPSHOT (the order in which the packages are processed is slightly different and by luck we provision the resteasy-validator-provider) That is a side effect of passive dependencies. resteasy-validator-provider[passive] > org.jboss.resteasy.resteasy-cdi[passive] > org.eclipse.microprofile.restclient When resteasy-validator-provider is processed, org.eclipse.microprofile.restclient has not yet been included, so org.jboss.resteasy.resteasy-cdi is not included, in turn resteasy-validator-provider is not included. The problem is due to the order in which Galleon processes the packages, org.eclipse.microprofile.restclient is a required dependency of org.jboss.resteasy.resteasy-client-microprofile. So is provisioned once org.jboss.resteasy.resteasy-client-microprofile. The problem is that org.jboss.resteasy.resteasy-client-microprofile is processed AFTER org.jboss.resteasy.resteasy-cdi. I have isolated in a simplified testcase, will log a Galleon Issue. > Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests > ------------------------------------------------------------------ > > Key: WFLY-13898 > URL: https://issues.redhat.com/browse/WFLY-13898 > Project: WildFly > Issue Type: Task > Components: Build System > Affects Versions: 21.0.0.Beta1 > Reporter: Fabio Burzigotti > Assignee: Jean Francois Denise > Priority: Blocker > > I set the component to {{Build System}} because this only happens with Bootable JAR and - as [~jdenise] noticed - it's related with Galleon. > This is about some tests in the RESTEasy TS which has been adapted to execute against bootable JARs through a specific profile [1]. > The tests are running successfully with WildFly 20.0.1.Final (the {{ejb}} layer needs to be removed for this experiment to be run [2]) but fail against 21.0.0.Beta1, so it is a regression. > Also, the tests are passing when the TS is executed against a distributed WildFly version, and only fail when the server is packaged via the {{wildfly-jar-maven-plugin}}. > There are 108 tests failing but htis JIRA focuses on those failing because of the following error: > {code} > RESTEASY002005: Failed executing POST /all/a/z: org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: org.jboss.resteasy.test.validation.resource.ValidationFoo of media type: application/xml;charset=UTF-8 > {code} > hence I guess serialization issues when the request accept header is not {{application/json}}, e.g. {{org.jboss.resteasy.test.validation.ValidationTest}} > *Steps to reproduce*: > 1. clone https://github.com/fabiobrz/Resteasy/tree/bootable-jar-support > 2. build RESTEasy: > {code} > $ mvn install -Dmaven.test.skip=true -Dmaven.repo.local=/home/my-local-repo > {code} > 3. run the test against WF 21.0.0.Beta1: > {code} > cd testsuite > {code} > {code} > mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.validation.ValidationTest > {code} > The test should *pass* > 4. run the test against WF 21.0.0.Beta1 with bootable JAR: > {code} > mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.validation.ValidationTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable > {code} > The test should *fail* > 5. run the test against WF 20.0.1.Final with bootable JAR: > {code} > mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=20.0.1.Final -Dtest=org.jboss.resteasy.test.validation.ValidationTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable > {code} > The test should *pass* > [1] > https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... > [2] > https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2502) If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace

by Sebastian Laskawiec (Jira)

[ https://issues.redhat.com/browse/JGRP-2502?page=com.atlassian.jira.plugin... ] Sebastian Laskawiec commented on JGRP-2502: ------------------------------------------- Closing. New tracker: https://github.com/jgroups-extras/jgroups-kubernetes/issues/109 > If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace > ------------------------------------------------------------------------------------ > > Key: JGRP-2502 > URL: https://issues.redhat.com/browse/JGRP-2502 > Project: JGroups > Issue Type: Bug > Affects Versions: 5.0.4 > Reporter: Filippe Spolti > Assignee: Bela Ban > Priority: Minor > > If no namespace is set it defaults to the "default" ocp namespace which will case the warn as described in the log message below: > > {code:java} > WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-9,ee,hdm78-kieserver-1-nggcf) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:937#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@69991c01] for cluster [ee], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods]] > {code} > IMHO the default namespace should not be used in this case since this namespace should not be used to deploy applications. > > If the namespace is not set it means that we do not want to enable the clustering feature, as the namespace is set if the namespace is not set, this condition [1] is not satisfied and the configuration will proceed. > > Another problem found in the tests is that, if we do set the KUBERNETES_NAMESPACE with no value, it will detect that the env has an value and will try to use a blank namespace: > > {code:java} > failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:874#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@17978314] for cluster [ee], namespace [], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/pods ]] > {code} > > [1] - https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src/main/java/org/jgroups/protocols/kubernetes/KUBE_PING.java#L145 > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2502) If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace

by Sebastian Laskawiec (Jira)

[ https://issues.redhat.com/browse/JGRP-2502?page=com.atlassian.jira.plugin... ] Sebastian Laskawiec reassigned JGRP-2502: ----------------------------------------- Assignee: Sebastian Laskawiec (was: Bela Ban) > If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace > ------------------------------------------------------------------------------------ > > Key: JGRP-2502 > URL: https://issues.redhat.com/browse/JGRP-2502 > Project: JGroups > Issue Type: Bug > Affects Versions: 5.0.4 > Reporter: Filippe Spolti > Assignee: Sebastian Laskawiec > Priority: Minor > > If no namespace is set it defaults to the "default" ocp namespace which will case the warn as described in the log message below: > > {code:java} > WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-9,ee,hdm78-kieserver-1-nggcf) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:937#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@69991c01] for cluster [ee], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods]] > {code} > IMHO the default namespace should not be used in this case since this namespace should not be used to deploy applications. > > If the namespace is not set it means that we do not want to enable the clustering feature, as the namespace is set if the namespace is not set, this condition [1] is not satisfied and the configuration will proceed. > > Another problem found in the tests is that, if we do set the KUBERNETES_NAMESPACE with no value, it will detect that the env has an value and will try to use a blank namespace: > > {code:java} > failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:874#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@17978314] for cluster [ee], namespace [], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/pods ]] > {code} > > [1] - https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src/main/java/org/jgroups/protocols/kubernetes/KUBE_PING.java#L145 > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2020