[JBoss JIRA] (DROOLS-5147) [DMN Designer] DMN Decision Table - Input/Output clauses enhancements (UX)
by Elizabeth Clayton (Jira)
[ https://issues.redhat.com/browse/DROOLS-5147?page=com.atlassian.jira.plug... ]
Elizabeth Clayton updated DROOLS-5147:
--------------------------------------
Labels: UXTeam drools-tools (was: drools-tools)
> [DMN Designer] DMN Decision Table - Input/Output clauses enhancements (UX)
> --------------------------------------------------------------------------
>
> Key: DROOLS-5147
> URL: https://issues.redhat.com/browse/DROOLS-5147
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Elizabeth Clayton
> Priority: Minor
> Labels: UXTeam, drools-tools
> Attachments: prototype.png
>
>
> Currently, the DMN Decision Tables input/output clauses work fine, but they have the following unpractical scenarios:
> - When users have a structure input node "associated" with an input clause (input column), they frequently need to go back to the data types page and remember the name of some field.
> - When users select a structure data type as the type of an output clause, they need to create sub-columns for each field manually.
> The goal for this JIRA is to get input from UX to enhance interactions with input and output clauses.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5332) [DMN Designer] Unable to open BKM editor
by Guilherme Gomes (Jira)
[ https://issues.redhat.com/browse/DROOLS-5332?page=com.atlassian.jira.plug... ]
Guilherme Gomes updated DROOLS-5332:
------------------------------------
Sprint: 2020 Week 25-27 (from Jun 15)
> [DMN Designer] Unable to open BKM editor
> -----------------------------------------
>
> Key: DROOLS-5332
> URL: https://issues.redhat.com/browse/DROOLS-5332
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.38.0.Final
> Reporter: Michael Anstis
> Assignee: Valentino Pellegrino
> Priority: Major
> Labels: drools-tools, field, kogito-tooling, support
>
> Using the referenced file:
> https://kiegroup.github.io/kogito-online/?file=https://gist.githubusercon...
> The User is unable to edit the Business Knowledge Model nodes for the following nodes:
> - Risk Rating for Last Transaction Amount
> - Risk Rating for last 24 hours Transactions
> The {{kogito-tooling}} version reports the following to the console.
> {code}
> Error: JavaScriptException: (TypeError) : Cannot read property 'd' of null
> at Xys (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:30330)
> at tes.a6r [as FW] (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:31966)
> at Ist (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:27657)
> at ntt.ptt [as yW] (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:31973)
> at Q4r (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:29779)
> at roy.soy [as J7] (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:31999)
> at _Vr (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:13043)
> {code}
> Sorry I have no debugged myself further.
> h3. Acceptance criteria:
> - Open BKM editor on business central
> - VS Code
> - Online editor
> - Desktop app
> - Github extension
> - Check the Documentation tab can be viewed too
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[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)
6 years, 1 month
[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)
6 years, 1 month
[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)
6 years, 1 month
[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)
6 years, 1 month
[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)
6 years, 1 month