[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 closed JGRP-2502.
-------------------------------------
Resolution: Rejected
> 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
[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:
-------------------------------------------
{quote}
I can open there. (https://github.com/jgroups-extras/jgroups-kubernetes/issues/109)
About the warning message, I am ok with it,m since this message is printed only once on the logs, not every X seconds as it is happening today.
{quote}
Thank you! That makes perfect sense.
{quote}
And would be very great was well to provide a way to disable clustering configuration, most of the time we just scale up standalone apps that does not need to have this feature enabled. the way it is done today, I didn't find a way to totally disable clustering.
{quote}
Doing this by misconfiguring an application is not the right way. Depending on the application you're running, there needs to be an option to disable clustering and run it in standalone mode. Please refer to the project/product manual how to do that. If that's RHSSO/Keycloak, please contact me by email and I should be able to help you.
> 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
[JBoss JIRA] (JGRP-2417) Ref-counting for messages
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2417?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2417.
----------------------------
Resolution: Done
> Ref-counting for messages
> -------------------------
>
> Key: JGRP-2417
> URL: https://issues.redhat.com/browse/JGRP-2417
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done.
> However, the return of a {{Channel.send()}} call does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table.
> Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool.
> This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie.
> {code:java}
> Message release() {
> if(refcount <= 0)
> // give associated memory area back to pool
> }
> {code}
> See if this needs to be integrated with {{MessageFactory}} as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-13898) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFLY-13898?page=com.atlassian.jira.plugi... ]
Fabio Burzigotti updated WFLY-13898:
------------------------------------
Description:
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...
was:
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) 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...
> 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
[JBoss JIRA] (WFLY-13898) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFLY-13898?page=com.atlassian.jira.plugi... ]
Fabio Burzigotti updated WFLY-13898:
------------------------------------
Affects Version/s: 21.0.0.Beta1
> 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) 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...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-13898) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFLY-13898?page=com.atlassian.jira.plugi... ]
Fabio Burzigotti updated WFLY-13898:
------------------------------------
Description:
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) 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...
was:
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) 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}
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...
> 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
> 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) 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...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-13898) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFLY-13898?page=com.atlassian.jira.plugi... ]
Fabio Burzigotti updated WFLY-13898:
------------------------------------
Description:
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) 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}
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...
was:
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) 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}
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.0.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...
> 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
> 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) 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}
> 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...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-13898) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFLY-13898?page=com.atlassian.jira.plugi... ]
Fabio Burzigotti updated WFLY-13898:
------------------------------------
Description:
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) 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}
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.0.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...
was:
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) 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}
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.repp.local=/home/my-local-repo -Dserver.version=20.0.0.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...
> 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
> 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) 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}
> 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.0.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...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-13898) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFLY-13898?page=com.atlassian.jira.plugi... ]
Fabio Burzigotti updated WFLY-13898:
------------------------------------
Description:
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) 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}
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.repp.local=/home/my-local-repo -Dserver.version=20.0.0.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...
was:
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) 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.reppo.local=/home/my-local-repo
{code}
3. run the test against WF 21.0.0.Beta1:
{code}
mvn clean verify -am -pl integration-tests -Dmaven.reppo.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.reppo.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.reppo.local=/home/my-local-repo -Dserver.version=20.0.0.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...
> 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
> 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) 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}
> 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.repp.local=/home/my-local-repo -Dserver.version=20.0.0.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...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years