April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5180) Kie-scanner update container API doesn't refresh container with latest jar after new year

by Minal Bhalodi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5180?page=com.atlassian.jira.plug... ] Minal Bhalodi reopened DROOLS-5180: ----------------------------------- I added in comments, I am able to reproduce this issue > Kie-scanner update container API doesn't refresh container with latest jar after new year > ----------------------------------------------------------------------------------------- > > Key: DROOLS-5180 > URL: https://issues.redhat.com/browse/DROOLS-5180 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.18.0.Final > Reporter: Minal Bhalodi > Assignee: Mario Fusco > Priority: Critical > > We are using kie-server as a stand alone application. we use kie scanner to update kie container when there is a new DRL file in our .m2 folder. > we don't have scanner polling but we use Scanner update container API to update kie container. > Every year when date changes after new year, we are facing issue where kie scanner is not able to update container with latest jar in m2 with new year date. > When we check the container version it shows latest with new year date but internally kie is still using old jar. > We fixed this issue with create container API instead update container. > kie-server-spring-boot-starter-drools :7.18.0.Final > Please let me know if this issue is already fixed or discussed before or if you need more details. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5180) Kie-scanner update container API doesn't refresh container with latest jar after new year

by Minal Bhalodi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5180?page=com.atlassian.jira.plug... ] Minal Bhalodi commented on DROOLS-5180: --------------------------------------- I am able to reproduce this problem. 1)First in .m2 folder first I added jar with version name person-10.23.2019-06-30-00.jar and started kie server. Kie-server created container with jar version 10.23.2019-06-30-00. 2)While server was running, I added person-10.23.2019-20-30-00.jar and kie container was updated with latest jar. Though I was adding this jar manually in S3, I also updated maven-metadata-local.xml manually to modify release and version with person-10.23.2019-20-30-00.jar 3)Then again without stopping server, I added person-04.02.2020-15-00-04.jar and updated release and version in maven-metadata-local.xml. This time kie server was not updated with version 04.02.2020-15-00-04. our maven-metadata-local.xml <?xml version="1.0" encoding="UTF-8"?> <metadata> <groupId><value></groupId> <artifactId><value></artifactId> <versioning> <release>10.23.2019-20-30-00</release> <versions> <version>10.23.2019-06-30-00</version> <version>04.02.2020-15-00-04</version> <version>10.23.2019-20-30-00</version> </versions> <lastUpdated>1585869333000</lastUpdated> </versioning> </metadata> I don't sample code to reproduce this issue but if you can share a sample code where kie-server updates container in reference to .m2 folder then I might be able to reproudce this issue there > Kie-scanner update container API doesn't refresh container with latest jar after new year > ----------------------------------------------------------------------------------------- > > Key: DROOLS-5180 > URL: https://issues.redhat.com/browse/DROOLS-5180 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.18.0.Final > Reporter: Minal Bhalodi > Assignee: Mario Fusco > Priority: Critical > > We are using kie-server as a stand alone application. we use kie scanner to update kie container when there is a new DRL file in our .m2 folder. > we don't have scanner polling but we use Scanner update container API to update kie container. > Every year when date changes after new year, we are facing issue where kie scanner is not able to update container with latest jar in m2 with new year date. > When we check the container version it shows latest with new year date but internally kie is still using old jar. > We fixed this issue with create container API instead update container. > kie-server-spring-boot-starter-drools :7.18.0.Final > Please let me know if this issue is already fixed or discussed before or if you need more details. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5212) Latest Drools-compiler version has dependency of xstream-1.4.11.1.jar which causing HIGH vulnerability CVE-2013-7285

by Priti Rane (Jira)

Priti Rane created DROOLS-5212: ---------------------------------- Summary: Latest Drools-compiler version has dependency of xstream-1.4.11.1.jar which causing HIGH vulnerability CVE-2013-7285 Key: DROOLS-5212 URL: https://issues.redhat.com/browse/DROOLS-5212 Project: Drools Issue Type: Enhancement Reporter: Priti Rane Assignee: Mario Fusco All drools compiler versions after 7.21.0.Final are using xstream version 1.14.11.1. We are using anchore engine for vulnerability scan and it is giving HIGH vulnerability CVE-2013-7285 - https://nvd.nist.gov/vuln/detail/CVE-2013-7285. There is a workaround to implement the security framework. However we are using kie-ci jar which has the drools-compiler dependency. So to resolve this , we have to implement the workaround in drools-compiler source code and build the jar and use it. But this solution is not maintainable. Is there any plans to implement the security framework in next version of drools-compiler ? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13223) Upgrade HAL to 3.2.8.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13223?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13223: ------------------------------------ Description: https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12314020&vers... > Upgrade HAL to 3.2.8.Final > -------------------------- > > Key: WFLY-13223 > URL: https://issues.redhat.com/browse/WFLY-13223 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Bartosz Spyrko > Assignee: Harald Pehl > Priority: Major > Labels: downstream_dependency > Fix For: 20.0.0.Beta1 > > > https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12314020&vers... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13322) Ability to configure JSF Implementation that uses the jsf-injection module instead of copying jars

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13322?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13322: ----------------------------------------- IMO any further enhancement related to installing a different JSF impl should involve a Galleon feature pack. ^^^ is a very hand-wavy statement but generally our provisioning strategy should be Galleon. > Ability to configure JSF Implementation that uses the jsf-injection module instead of copying jars > -------------------------------------------------------------------------------------------------- > > Key: WFLY-13322 > URL: https://issues.redhat.com/browse/WFLY-13322 > Project: WildFly > Issue Type: Enhancement > Components: JSF > Reporter: Brad Maxwell > Assignee: Farah Juma > Priority: Major > > Currently to configure a different JSF Implementation in a module, these steps below are followed: > 1. $ mkdir -p modules/com/sun/jsf-impl/JSF_IMPL_NAME-JSF_VERSION > 2. Copy the wildfly-jsf-injection and weld-core-jsf JAR files from EAP_HOME/modules/system/layers/base/org/jboss/as/jsf-injection/main/ to the modules/com/sun/jsf-impl/JSF_IMPL_NAME-JSF_VERSION/ subdirectory. > For initial setup, the jars that need to be copied may be from modules/system/layers/base/org/jboss/as/jsf-injection/main or if an Update is applied, then it should be from the latest dir of the form system/layers/base/.overlays/layer-base-jboss-eap-7.2.z.CP/org/jboss/as/jsf-injection/main > After a new Update, if a bug gets fixed in the jars, then the user needs to copy the updated jars into their custom module. > It would be better if the user can just create a module with their jars and depend on the org/jboss/as/jsf-injection module and then the JSF subsystem make it work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1108) Update job parameters descriptions

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1108: ------------------------------------ Summary: Update job parameters descriptions Key: SWSQE-1108 URL: https://issues.redhat.com/browse/SWSQE-1108 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta Currently a user without any knowledge can't run jenkins pipelines. We need to update description of job parameters so it's clear even for user without knowledge about operator sources etc. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1105) install maistra job fails for 1.12.6 operator version

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1105?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1105. ---------------------------------- Resolution: Done > install maistra job fails for 1.12.6 operator version > ----------------------------------------------------- > > Key: SWSQE-1105 > URL: https://issues.redhat.com/browse/SWSQE-1105 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > KIALI_OPERATOR_TAG 1.12.6 is passed directly to OPERATOR_VERSION_LABEL which is looking for 1.12.6 branch which does not exists. It must be v1.12 branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1106) Update install istio to checkout deploy-kiali-operator.sh from given branch instead of using OPERATOR_VERSION_LABEL

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1106?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1106. ---------------------------------- Resolution: Done > Update install istio to checkout deploy-kiali-operator.sh from given branch instead of using OPERATOR_VERSION_LABEL > ------------------------------------------------------------------------------------------------------------------- > > Key: SWSQE-1106 > URL: https://issues.redhat.com/browse/SWSQE-1106 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Current solution is not testing changes in yamls in given PR -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13333) Openapi endpoint returns empty file if schema definition contains non ASCII character

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13333?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13333: -------------------------------- Priority: Blocker (was: Major) > Openapi endpoint returns empty file if schema definition contains non ASCII character > ------------------------------------------------------------------------------------- > > Key: WFLY-13333 > URL: https://issues.redhat.com/browse/WFLY-13333 > Project: WildFly > Issue Type: Bug > Components: MP OpenAPI > Affects Versions: 19.0.0.Final > Reporter: Márk Petrényi > Assignee: Paul Ferraro > Priority: Blocker > > Currently the {{/openapi}} endpoint returns empty file if the OpenAPI schema definition contains non ASCII characters (ie. accented letters like á,í...). > I extended the openapi quickstart for demonstration: https://github.com/petrenyi-mark/quickstart/commit/44096980ff36ff2655859f... > It seems like it is related to the content-length, since in {{OpenAPIHttpHandler}} the content-length header is set by {{String.length()}} (line 125). However before the response is actually returned, undertow validates that the actual content-length based on ByteBuffer size is not greater then the one declared in the response header. Since non ASCII characters are usually represented by 2 bytes undertow will fail, thus no content will be returned. > In {{OpenAPIHttpHandler}} setting {{string.getBytes(charset).length}} as Conetnt-Length instead of {{String.length()}} would likely resolve this issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13333) Openapi endpoint returns empty file if schema definition contains non ASCII character

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13333?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13333: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13171, https://github.com/wildfly/wildfly/pull/13172 (was: https://github.com/wildfly/wildfly/pull/13171) > Openapi endpoint returns empty file if schema definition contains non ASCII character > ------------------------------------------------------------------------------------- > > Key: WFLY-13333 > URL: https://issues.redhat.com/browse/WFLY-13333 > Project: WildFly > Issue Type: Bug > Components: MP OpenAPI > Affects Versions: 19.0.0.Final > Reporter: Márk Petrényi > Assignee: Paul Ferraro > Priority: Major > > Currently the {{/openapi}} endpoint returns empty file if the OpenAPI schema definition contains non ASCII characters (ie. accented letters like á,í...). > I extended the openapi quickstart for demonstration: https://github.com/petrenyi-mark/quickstart/commit/44096980ff36ff2655859f... > It seems like it is related to the content-length, since in {{OpenAPIHttpHandler}} the content-length header is set by {{String.length()}} (line 125). However before the response is actually returned, undertow validates that the actual content-length based on ByteBuffer size is not greater then the one declared in the response header. Since non ASCII characters are usually represented by 2 bytes undertow will fail, thus no content will be returned. > In {{OpenAPIHttpHandler}} setting {{string.getBytes(charset).length}} as Conetnt-Length instead of {{String.length()}} would likely resolve this issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020