June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1983) Release WildFly Elytron 2.0.0.Alpha7

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1983?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved ELY-1983. ----------------------------------- Resolution: Done > Release WildFly Elytron 2.0.0.Alpha7 > ------------------------------------ > > Key: ELY-1983 > URL: https://issues.redhat.com/browse/ELY-1983 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 2.0.0.Alpha7 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1168) Document alternatives for PSI OpenStack

by Matthew Mahoney (Jira)

[ https://issues.redhat.com/browse/SWSQE-1168?page=com.atlassian.jira.plugi... ] Matthew Mahoney commented on SWSQE-1168: ---------------------------------------- Slack OCP Bot: https://app.slack.com/client/T027F3GAJ/D011E5UGDC6 > Document alternatives for PSI OpenStack > --------------------------------------- > > Key: SWSQE-1168 > URL: https://issues.redhat.com/browse/SWSQE-1168 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > When the PSI OpenStack is down, we need to use something else to provisioning OCP clusters. > We need to document options: > * AWS > * https://quicklab.upshift.redhat.com/clusters > * bot on coreos slack -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1168) Document alternatives for PSI OpenStack

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1168: ------------------------------------ Summary: Document alternatives for PSI OpenStack Key: SWSQE-1168 URL: https://issues.redhat.com/browse/SWSQE-1168 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta When the PSI OpenStack is down, we need to use something else to provisioning OCP clusters. We need to document options: * AWS * https://quicklab.upshift.redhat.com/clusters * bot on coreos slack -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[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: standalone_18.0.0.final.xml standalone_19.1.0.final.xml > 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 > Assignee: Brian Stansberry > Priority: Major > Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml > > > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1983) Release WildFly Elytron 2.0.0.Alpha7

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1983: ------------------------------------- Summary: Release WildFly Elytron 2.0.0.Alpha7 Key: ELY-1983 URL: https://issues.redhat.com/browse/ELY-1983 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 2.0.0.Alpha7 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ] Gabriele Cardosi edited comment on DROOLS-5372 at 6/4/20 10:59 AM: ------------------------------------------------------------------- Most cost-effective solution would be: # create a new _Command_ with API tailored for new kie-pmml (see {code:java} ApplyPmmlModelCommand {code} as example) # verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "_property_" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # inside DMN: ## inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath was (Author: gabriolo): Most cost-effective solution would be: # 1) create a new _Command_ with API tailored for new kie-pmml (see {code:java} ApplyPmmlModelCommand {code} as example) # 2) verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "_property_" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # 2) inside DMN: ## 1) inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath > Investigate PMML abstraction/coexistence > ----------------------------------------- > > Key: DROOLS-5372 > URL: https://issues.redhat.com/browse/DROOLS-5372 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > New and old PMML implementations should live together for some time. > USer should be able to choose implementation. > Consider creating a "proxy" pmml-module that > 1) declare PMMLAssemblerService > 2) declare PMMLRuntime > 3) delegate actuial executioin based on some variable to actual implementation (ppml-old - pmml-new, jpmml) > This "wrapper" should also be invoked by ApplyPmmlModelCommandExecutorImpl -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ] Gabriele Cardosi edited comment on DROOLS-5372 at 6/4/20 10:59 AM: ------------------------------------------------------------------- Most cost-effective solution would be: # 1) create a new _Command_ with API tailored for new kie-pmml (see {code:java} ApplyPmmlModelCommand {code} as example) # 2) verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "_property_" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # 2) inside DMN: ## 1) inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath was (Author: gabriolo): Most cost-effective solution would be: # 1) create a new Command with API tailored for new kie-pmml (see ApplyPmmlModelCommand as example) # 2) verify the behavior when *both* `PMMLAssemblerService`s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "property" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshofit/docker" images wher both modules are expected to be present in the classpath # 2) inside DMN: ## 1) inside `AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...)` add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath > Investigate PMML abstraction/coexistence > ----------------------------------------- > > Key: DROOLS-5372 > URL: https://issues.redhat.com/browse/DROOLS-5372 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > New and old PMML implementations should live together for some time. > USer should be able to choose implementation. > Consider creating a "proxy" pmml-module that > 1) declare PMMLAssemblerService > 2) declare PMMLRuntime > 3) delegate actuial executioin based on some variable to actual implementation (ppml-old - pmml-new, jpmml) > This "wrapper" should also be invoked by ApplyPmmlModelCommandExecutorImpl -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ] Gabriele Cardosi commented on DROOLS-5372: ------------------------------------------ Most cost-effective solution would be: # 1) create a new Command with API tailored for new kie-pmml (see ApplyPmmlModelCommand as example) # 2) verify the behavior when *both* `PMMLAssemblerService`s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "property" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshofit/docker" images wher both modules are expected to be present in the classpath # 2) inside DMN: ## 1) inside `AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...)` add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath > Investigate PMML abstraction/coexistence > ----------------------------------------- > > Key: DROOLS-5372 > URL: https://issues.redhat.com/browse/DROOLS-5372 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > New and old PMML implementations should live together for some time. > USer should be able to choose implementation. > Consider creating a "proxy" pmml-module that > 1) declare PMMLAssemblerService > 2) declare PMMLRuntime > 3) delegate actuial executioin based on some variable to actual implementation (ppml-old - pmml-new, jpmml) > This "wrapper" should also be invoked by ApplyPmmlModelCommandExecutorImpl -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13560) Enhance Elytron AuditLogging Document

by Darran Lofthouse (Jira)

Darran Lofthouse created WFLY-13560: --------------------------------------- Summary: Enhance Elytron AuditLogging Document Key: WFLY-13560 URL: https://issues.redhat.com/browse/WFLY-13560 Project: WildFly Issue Type: Feature Request Components: Documentation, Security Reporter: Darran Lofthouse The audit logging documentation covers the resources that can be defined but really it needs to have further information on how to enable audit logging within the event handling framework. Additionally we should have documentation for the kinds of events we can emit. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields

by Alexandru Ciouca (Jira)

Alexandru Ciouca created WFLY-13559: --------------------------------------- Summary: 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 Assignee: Brian Stansberry 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, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2020