[JBoss JIRA] (WFLY-13589) Add support for configuring RHDG authentication over hotrod
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13589?page=com.atlassian.jira.plugi... ]
Paul Ferraro moved EAP7-1507 to WFLY-13589:
-------------------------------------------
Project: WildFly (was: JBoss EAP Planning for version 7 and above)
Key: WFLY-13589 (was: EAP7-1507)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0)
Component/s: Clustering
(was: Clustering)
EAP PT Pre-Checked (PC): (was: TODO)
EAP PT Community Docs (CD): (was: TODO)
EAP PT Product Docs (PD): (was: New)
Affects Version/s: 20.0.0.Final
(was: 7.4.0.CD19)
EAP PT Test Dev (TD): (was: TODO)
EAP PT Docs Analysis (DA): (was: TODO)
EAP PT Test Plan (TP): (was: TODO)
EAP PT Analysis Document (AD): (was: TODO)
> Add support for configuring RHDG authentication over hotrod
> -----------------------------------------------------------
>
> Key: WFLY-13589
> URL: https://issues.redhat.com/browse/WFLY-13589
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 20.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> RHDG 8.1 (based on Infinispan 11.0.x) will require authentication by default. Consequently, we need the ability to configure authentication for a remote-cache-container.
> See: [https://infinispan.org/blog/2020/06/04/server-secure-by-default/]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields
by Alexandru Ciouca (Jira)
[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ]
Alexandru Ciouca edited comment on WFLY-13559 at 6/15/20 11:32 AM:
-------------------------------------------------------------------
[~brian.stansberry]
I created a small project to replicate this and [~blaghed] is right.
Please find the project here: [https://github.com/alexciouca/wildfly-bug-endpoint]
Basically, I have 3 scenarios:
1. The working scenario:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/master]
* WAR file: [^test-endpoint-WORKING.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Cache-Control: no-store, no-cache, must-revalidate
Access-Control-Allow-Headers: origin, content-type, accept, X-XSRF-TOKEN
Test-Header: This should appear
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:43:56 GMT
{"randomContent":"UEGmvucxBi","randomId":24}
{code}
2. Not working scenario by adding beans.xml:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-beans]
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/fd599e19c893cfe...]
* WAR file: [^test-endpoint-BEANS-XML.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:58:09 GMT
{"randomContent":"xhLyKvutVG","randomId":99}
{code}
3. Not working scenario by adding RequestContext bean:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-req...
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/285cd705e956ec5...]
* WAR file: [^test-endpoint-CONTEXT.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 15:02:01 GMT
{"randomContent":"OPESyexMIJ","randomId":71}
{code}
As you can see, in the working scenario (1), there are 3 headers there that were properly added by the [ResponseContextProviderFilter|https://github.com/alexciouca/wildfly-bug-e.... In the other two scenarios (2 and 3) the filter stops working when I enable the CDI and the headers are totally missing.
This was tested and replicated on all versions 19.0.0, 19.1.0 and 20.0.0, and it's not reproduced on version 18.0.0. So this bug was introduced with version 19.0.0.
was (Author: alex.ciouca):
[~brian.stansberry]
I created a small project to replicate this and [~blaghed] is right.
Please find the project here: [https://github.com/alexciouca/wildfly-bug-endpoint]
Basically, I have 3 scenarios:
1. The working scenario:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/master]
* WAR file: [^test-endpoint-WORKING.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Cache-Control: no-store, no-cache, must-revalidate
Access-Control-Allow-Headers: origin, content-type, accept, X-XSRF-TOKEN
Test-Header: This should appear
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:43:56 GMT
{"randomContent":"UEGmvucxBi","randomId":24}
{code}
2. Not working scenario by adding beans.xml:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-beans]
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/fd599e19c893cfe...]
* WAR file: [^test-endpoint-BEANS-XML.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:58:09 GMT
{"randomContent":"xhLyKvutVG","randomId":99}
{code}
3. Not working scenario by adding RequestContext bean:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-req...
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/285cd705e956ec5...]
* WAR file: [^test-endpoint-CONTEXT.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 15:02:01 GMT
{"randomContent":"OPESyexMIJ","randomId":71}
{code}
As you can see, in the working scenario (1), there are 3 headers there that were properly added by the [ResponseContextProviderFilter|[https://github.com/alexciouca/wildfly-bug-.... In the other two scenarios (2 and 3) the filter stops working when I enable the CDI and the headers are totally missing.
This was tested and replicated on all versions 19.0.0, 19.1.0 and 20.0.0, and it's not reproduced on version 18.0.0. So this bug was introduced with version 19.0.0.
> Header response has changed and missing fields
> ----------------------------------------------
>
> Key: WFLY-13559
> URL: https://issues.redhat.com/browse/WFLY-13559
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 19.0.0.Final, 19.1.0.Final, 20.0.0.Final
> Reporter: Alexandru Ciouca
> Priority: Major
> Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml, test-endpoint-BEANS-XML.war, test-endpoint-CONTEXT.war, test-endpoint-WORKING.war
>
>
> I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19?
> Response WildFly 18.0.0.final:
> {code}
> HTTP/2 500
> cache-control: no-store, no-cache, must-revalidate
> set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices
> access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN
> content-type: application/json
> content-length: 182
> link: <http://test.com/afs/rest>; rel="profile"
> date: Thu, 04 Jun 2020 07:34:10 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> Response WildFly 19.1.0.final:
> {code}
> HTTP/2 200
> set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices
> content-type: application/json
> content-length: 182
> date: Thu, 04 Jun 2020 07:27:57 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure
> cache-control: private
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing.
> I am attaching also the standalone.xml for both versions.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields
by Alexandru Ciouca (Jira)
[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ]
Alexandru Ciouca edited comment on WFLY-13559 at 6/15/20 11:31 AM:
-------------------------------------------------------------------
[~brian.stansberry]
I created a small project to replicate this and [~blaghed] is right.
Please find the project here: [https://github.com/alexciouca/wildfly-bug-endpoint]
Basically, I have 3 scenarios:
1. The working scenario:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/master]
* WAR file: [^test-endpoint-WORKING.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Cache-Control: no-store, no-cache, must-revalidate
Access-Control-Allow-Headers: origin, content-type, accept, X-XSRF-TOKEN
Test-Header: This should appear
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:43:56 GMT
{"randomContent":"UEGmvucxBi","randomId":24}
{code}
2. Not working scenario by adding beans.xml:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-beans]
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/fd599e19c893cfe...]
* WAR file: [^test-endpoint-BEANS-XML.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:58:09 GMT
{"randomContent":"xhLyKvutVG","randomId":99}
{code}
3. Not working scenario by adding RequestContext bean:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-req...
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/285cd705e956ec5...]
* WAR file: [^test-endpoint-CONTEXT.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 15:02:01 GMT
{"randomContent":"OPESyexMIJ","randomId":71}
{code}
As you can see, in the working scenario (1), there are 3 headers there that were properly added by the [ResponseContextProviderFilter|[https://github.com/alexciouca/wildfly-bug-.... In the other two scenarios (2 and 3) the filter stops working when I enable the CDI and the headers are totally missing.
This was tested and replicated on all versions 19.0.0, 19.1.0 and 20.0.0, and it's not reproduced on version 18.0.0. So this bug was introduced with version 19.0.0.
was (Author: alex.ciouca):
[~brian.stansberry]
I created a small project to replicate this and [~blaghed] is right.
Please find the project here: [https://github.com/alexciouca/wildfly-bug-endpoint]
Basically, I have 3 scenarios:
1. The working scenario:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/master]
* WAR file: [^test-endpoint-WORKING.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Cache-Control: no-store, no-cache, must-revalidate
Access-Control-Allow-Headers: origin, content-type, accept, X-XSRF-TOKEN
Test-Header: This should appear
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:43:56 GMT
{"randomContent":"UEGmvucxBi","randomId":24}
{code}
2. Not working scenario by adding beans.xml:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-beans]
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/fd599e19c893cfe...]
* WAR file: [^test-endpoint-BEANS-XML.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:58:09 GMT
{"randomContent":"xhLyKvutVG","randomId":99}
{code}
3. Not working scenario by adding RequestContext bean:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-req...
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/285cd705e956ec5...]
* WAR file: [^test-endpoint-CONTEXT.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 15:02:01 GMT
{"randomContent":"OPESyexMIJ","randomId":71}
{code}
As you can see, in the working scenario (1), there are 3 headers there that were properly added by the [ResponseContextProviderFilter]([https://github.com/alexciouca/wildfly-bug... filter. In the other two scenarios (2 and 3) the filter stops working when I enable the CDI and the headers are totally missing.
This was tested and replicated on all versions 19.0.0, 19.1.0 and 20.0.0, and it's not reproduced on version 18.0.0. So this bug was introduced with version 19.0.0.
> Header response has changed and missing fields
> ----------------------------------------------
>
> Key: WFLY-13559
> URL: https://issues.redhat.com/browse/WFLY-13559
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 19.0.0.Final, 19.1.0.Final, 20.0.0.Final
> Reporter: Alexandru Ciouca
> Priority: Major
> Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml, test-endpoint-BEANS-XML.war, test-endpoint-CONTEXT.war, test-endpoint-WORKING.war
>
>
> I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19?
> Response WildFly 18.0.0.final:
> {code}
> HTTP/2 500
> cache-control: no-store, no-cache, must-revalidate
> set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices
> access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN
> content-type: application/json
> content-length: 182
> link: <http://test.com/afs/rest>; rel="profile"
> date: Thu, 04 Jun 2020 07:34:10 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> Response WildFly 19.1.0.final:
> {code}
> HTTP/2 200
> set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices
> content-type: application/json
> content-length: 182
> date: Thu, 04 Jun 2020 07:27:57 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure
> cache-control: private
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing.
> I am attaching also the standalone.xml for both versions.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13234) WF17 vs. WF18: org.infinispan.hibernate-cache
by Daniel Wehrle (Jira)
[ https://issues.redhat.com/browse/WFLY-13234?page=com.atlassian.jira.plugi... ]
Daniel Wehrle closed WFLY-13234.
--------------------------------
> WF17 vs. WF18: org.infinispan.hibernate-cache
> ---------------------------------------------
>
> Key: WFLY-13234
> URL: https://issues.redhat.com/browse/WFLY-13234
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final
> Reporter: Daniel Wehrle
> Assignee: Scott Marlow
> Priority: Major
>
> Hi.
> Why has the entity cache transaction in org.infinispan.hibernate-cache been changed from NON_XA to NONE (default) and what are the implications? Can this lead to performance problems?
> WF17
> {code}
> <cache-container name="hibernate" module="org.infinispan.hibernate-cache">
> <local-cache name="entity">
> <transaction mode="NON_XA"/>
> <object-memory size="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> {code}
> WF18
> {code}
> <cache-container name="hibernate" module="org.infinispan.hibernate-cache">
> <local-cache name="entity">
> <object-memory size="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> {code}
> Best regards,
> Daniel
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields
by Alexandru Ciouca (Jira)
[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ]
Alexandru Ciouca commented on WFLY-13559:
-----------------------------------------
[~brian.stansberry]
I created a small project to replicate this and [~blaghed] is right.
Please find the project here: [https://github.com/alexciouca/wildfly-bug-endpoint]
Basically, I have 3 scenarios:
1. The working scenario:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/master]
* WAR file: [^test-endpoint-WORKING.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Cache-Control: no-store, no-cache, must-revalidate
Access-Control-Allow-Headers: origin, content-type, accept, X-XSRF-TOKEN
Test-Header: This should appear
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:43:56 GMT
{"randomContent":"UEGmvucxBi","randomId":24}
{code}
2. Not working scenario by adding beans.xml:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-beans]
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/fd599e19c893cfe...]
* WAR file: [^test-endpoint-BEANS-XML.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 14:58:09 GMT
{"randomContent":"xhLyKvutVG","randomId":99}
{code}
3. Not working scenario by adding RequestContext bean:
* Branch: [https://github.com/alexciouca/wildfly-bug-endpoint/tree/with-req...
* Commit: [https://github.com/alexciouca/wildfly-bug-endpoint/commit/285cd705e956ec5...]
* WAR file: [^test-endpoint-CONTEXT.war]
* Result:
{code:java}
λ curl -i -k --request GET localhost:8080/wildfly/test/api/ping
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 44
Date: Mon, 15 Jun 2020 15:02:01 GMT
{"randomContent":"OPESyexMIJ","randomId":71}
{code}
As you can see, in the working scenario (1), there are 3 headers there that were properly added by the [ResponseContextProviderFilter]([https://github.com/alexciouca/wildfly-bug... filter. In the other two scenarios (2 and 3) the filter stops working when I enable the CDI and the headers are totally missing.
This was tested and replicated on all versions 19.0.0, 19.1.0 and 20.0.0, and it's not reproduced on version 18.0.0. So this bug was introduced with version 19.0.0.
> Header response has changed and missing fields
> ----------------------------------------------
>
> Key: WFLY-13559
> URL: https://issues.redhat.com/browse/WFLY-13559
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 19.1.0.Final
> Reporter: Alexandru Ciouca
> Priority: Major
> Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml, test-endpoint-BEANS-XML.war, test-endpoint-CONTEXT.war, test-endpoint-WORKING.war
>
>
> I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19?
> Response WildFly 18.0.0.final:
> {code}
> HTTP/2 500
> cache-control: no-store, no-cache, must-revalidate
> set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices
> access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN
> content-type: application/json
> content-length: 182
> link: <http://test.com/afs/rest>; rel="profile"
> date: Thu, 04 Jun 2020 07:34:10 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> Response WildFly 19.1.0.final:
> {code}
> HTTP/2 200
> set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices
> content-type: application/json
> content-length: 182
> date: Thu, 04 Jun 2020 07:27:57 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure
> cache-control: private
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing.
> I am attaching also the standalone.xml for both versions.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields
by Alexandru Ciouca (Jira)
[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ]
Alexandru Ciouca updated WFLY-13559:
------------------------------------
Affects Version/s: 20.0.0.Final
19.0.0.Final
> Header response has changed and missing fields
> ----------------------------------------------
>
> Key: WFLY-13559
> URL: https://issues.redhat.com/browse/WFLY-13559
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 19.0.0.Final, 19.1.0.Final, 20.0.0.Final
> Reporter: Alexandru Ciouca
> Priority: Major
> Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml, test-endpoint-BEANS-XML.war, test-endpoint-CONTEXT.war, test-endpoint-WORKING.war
>
>
> I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19?
> Response WildFly 18.0.0.final:
> {code}
> HTTP/2 500
> cache-control: no-store, no-cache, must-revalidate
> set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices
> access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN
> content-type: application/json
> content-length: 182
> link: <http://test.com/afs/rest>; rel="profile"
> date: Thu, 04 Jun 2020 07:34:10 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> Response WildFly 19.1.0.final:
> {code}
> HTTP/2 200
> set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices
> content-type: application/json
> content-length: 182
> date: Thu, 04 Jun 2020 07:27:57 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure
> cache-control: private
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing.
> I am attaching also the standalone.xml for both versions.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13234) WF17 vs. WF18: org.infinispan.hibernate-cache
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13234?page=com.atlassian.jira.plugi... ]
Scott Marlow resolved WFLY-13234.
---------------------------------
Resolution: Explained
> WF17 vs. WF18: org.infinispan.hibernate-cache
> ---------------------------------------------
>
> Key: WFLY-13234
> URL: https://issues.redhat.com/browse/WFLY-13234
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final
> Reporter: Daniel Wehrle
> Assignee: Scott Marlow
> Priority: Major
>
> Hi.
> Why has the entity cache transaction in org.infinispan.hibernate-cache been changed from NON_XA to NONE (default) and what are the implications? Can this lead to performance problems?
> WF17
> {code}
> <cache-container name="hibernate" module="org.infinispan.hibernate-cache">
> <local-cache name="entity">
> <transaction mode="NON_XA"/>
> <object-memory size="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> {code}
> WF18
> {code}
> <cache-container name="hibernate" module="org.infinispan.hibernate-cache">
> <local-cache name="entity">
> <object-memory size="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> {code}
> Best regards,
> Daniel
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13234) WF17 vs. WF18: org.infinispan.hibernate-cache
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13234?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFLY-13234:
-------------------------------------
[~daniel.wehrle] the change was made for [WFLY-10638]
{quote}
Why has the entity cache transaction in org.infinispan.hibernate-cache been changed from NON_XA to NONE (default) and what are the implications?
{quote}
The NON_XA was being ignored, except that a warning would be logged. So, there should be zero impact from this change.
{quote}
Can this lead to performance problems?
{quote}
There shouldn't be any, the Infinispan internal code was updated, to not need/support the NON_XA mode anymore.
> WF17 vs. WF18: org.infinispan.hibernate-cache
> ---------------------------------------------
>
> Key: WFLY-13234
> URL: https://issues.redhat.com/browse/WFLY-13234
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final
> Reporter: Daniel Wehrle
> Assignee: Scott Marlow
> Priority: Major
>
> Hi.
> Why has the entity cache transaction in org.infinispan.hibernate-cache been changed from NON_XA to NONE (default) and what are the implications? Can this lead to performance problems?
> WF17
> {code}
> <cache-container name="hibernate" module="org.infinispan.hibernate-cache">
> <local-cache name="entity">
> <transaction mode="NON_XA"/>
> <object-memory size="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> {code}
> WF18
> {code}
> <cache-container name="hibernate" module="org.infinispan.hibernate-cache">
> <local-cache name="entity">
> <object-memory size="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> {code}
> Best regards,
> Daniel
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields
by Alexandru Ciouca (Jira)
[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ]
Alexandru Ciouca updated WFLY-13559:
------------------------------------
Attachment: test-endpoint-BEANS-XML.war
test-endpoint-WORKING.war
test-endpoint-CONTEXT.war
> Header response has changed and missing fields
> ----------------------------------------------
>
> Key: WFLY-13559
> URL: https://issues.redhat.com/browse/WFLY-13559
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 19.1.0.Final
> Reporter: Alexandru Ciouca
> Priority: Major
> Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml, test-endpoint-BEANS-XML.war, test-endpoint-CONTEXT.war, test-endpoint-WORKING.war
>
>
> I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19?
> Response WildFly 18.0.0.final:
> {code}
> HTTP/2 500
> cache-control: no-store, no-cache, must-revalidate
> set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices
> access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN
> content-type: application/json
> content-length: 182
> link: <http://test.com/afs/rest>; rel="profile"
> date: Thu, 04 Jun 2020 07:34:10 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> Response WildFly 19.1.0.final:
> {code}
> HTTP/2 200
> set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices
> content-type: application/json
> content-length: 182
> date: Thu, 04 Jun 2020 07:27:57 GMT
> set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure
> cache-control: private
> strict-transport-security: max-age=31536000; includeSubdomains
> x-xss-protection: 1; mode=block
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> {code}
> As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing.
> I am attaching also the standalone.xml for both versions.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months