April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12681) Provide a 'microprofile' Galleon layer

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12681?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12681: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/12948 (was: https://github.com/wildfly/wildfly/pull/12948, https://github.com/wildfly/wildfly/pull/13023) > Provide a 'microprofile' Galleon layer > -------------------------------------- > > Key: WFLY-12681 > URL: https://issues.redhat.com/browse/WFLY-12681 > Project: WildFly > Issue Type: Feature Request > Components: Build System, MP Config, MP Fault Tolerance, MP Health, MP JWT, MP Metrics, MP OpenAPI, MP OpenTracing > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Labels: Microprofile > > We used to have a 'microprofile' layer spec aggregating all MP specs which at the moment only contained config, health and metrics which got renamed to 'observability' by WFLY-11774. > With the introduction of new specs fault tolerance, openapi, etc. we should reintroduce the 'microprofile' layer spec which contains all of the MP specs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13308) wildfly-ejb-client-bom version incorrectly managed by wildfly parent

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13308?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13308: ------------------------------------ Fix Version/s: 19.0.1.Final > wildfly-ejb-client-bom version incorrectly managed by wildfly parent > -------------------------------------------------------------------- > > Key: WFLY-13308 > URL: https://issues.redhat.com/browse/WFLY-13308 > Project: WildFly > Issue Type: Bug > Components: Build System > Environment: Patched Galleon to obey dependency management (issue forthcoming) > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Major > Fix For: 19.0.1.Final, 20.0.0.Beta1 > > > {{wildfly-ejb-client-bom}} is defined as having version {{${ee.maven.version}}}, but the main codebase does not produce this artifact. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

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

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13333?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13333: ------------------------------------ Fix Version/s: 19.0.1.Final > 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 > Fix For: 19.0.1.Final, 20.0.0.Beta1 > > > 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)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13338) Add the ability to pass custom predicates to the LoggingUtil log scanning methods

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13338: --------------------------------------- Summary: Add the ability to pass custom predicates to the LoggingUtil log scanning methods Key: WFLY-13338 URL: https://issues.redhat.com/browse/WFLY-13338 Project: WildFly Issue Type: Enhancement Components: Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry LoggingUtil includes a couple methods for scanning log content looking for a particular string. Add a varargs Predicate<String> parameter to allow further analysis of a line that contains the primary string. Doing this kind of thing was useful in a test associated with JBEAP-19148. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4746) UX for DMN "quick test" tool

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4746?page=com.atlassian.jira.plug... ] Guilherme Gomes commented on DROOLS-4746: ----------------------------------------- [~uxdlc], any type of boxed expression :) > UX for DMN "quick test" tool > ---------------------------- > > Key: DROOLS-4746 > URL: https://issues.redhat.com/browse/DROOLS-4746 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Elizabeth Clayton > Priority: Major > Labels: UX, UXTeam, drools-tools > > As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test. > When the user run the test he can get back the results of the DMN execution. > Moreover, it would be handy to add those input/output to an existing (or new) test scenario. > *Acceptance criteria* > Users are able to: > * Execute a single node boxed expression by providing node inputs (within the DMN editor.) > * Explore the DMN model and provide inputs necessary to run a scenario test. > * Obtain results (Expected) within the DMN editor once the test is run. > Notes: > * Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output. > * Out of scope: Saving or exporting the "quick test." -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4746) UX for DMN "quick test" tool

by Elizabeth Clayton (Jira)

[ https://issues.redhat.com/browse/DROOLS-4746?page=com.atlassian.jira.plug... ] Elizabeth Clayton commented on DROOLS-4746: ------------------------------------------- [~karreiro] [~danielezonca] or [~tirelli] - this can be run against any type of boxed logic expression, or only Decision tables? > UX for DMN "quick test" tool > ---------------------------- > > Key: DROOLS-4746 > URL: https://issues.redhat.com/browse/DROOLS-4746 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Elizabeth Clayton > Priority: Major > Labels: UX, UXTeam, drools-tools > > As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test. > When the user run the test he can get back the results of the DMN execution. > Moreover, it would be handy to add those input/output to an existing (or new) test scenario. > *Acceptance criteria* > Users are able to: > * Execute a single node boxed expression by providing node inputs (within the DMN editor.) > * Explore the DMN model and provide inputs necessary to run a scenario test. > * Obtain results (Expected) within the DMN editor once the test is run. > Notes: > * Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output. > * Out of scope: Saving or exporting the "quick test." -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 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 edited comment on DROOLS-5180 at 4/3/20 3:59 PM: --------------------------------------------------------------- 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 have 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 reproduce this issue was (Author: mbhalodi_intuit): 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)

4 years, 6 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: --------------------------------------- Thanks for your help. we were finally able to find the root cause. > 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)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3580) [DMN Designer] Decision Table: Add support for merged view

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-3580?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-3580: ------------------------------------ Sprint: (was: 2020 Week 13-15 (from Mar 23)) > [DMN Designer] Decision Table: Add support for merged view > ---------------------------------------------------------- > > Key: DROOLS-3580 > URL: https://issues.redhat.com/browse/DROOLS-3580 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.17.0.Final > Reporter: Edson Tirelli > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > Add support for viewing the {{DecisionTableGrid}} in _merged_ mode. > The underlying widget supports merging however I need to check about model synchronisation and where how we'd add a button to toggle merged/unmerged.. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1110) E2E job - Swagger Version Always 'master'

by Matthew Mahoney (Jira)

[ https://issues.redhat.com/browse/SWSQE-1110?page=com.atlassian.jira.plugi... ] Matthew Mahoney updated SWSQE-1110: ----------------------------------- Comment: was deleted (was: Also please change KIALI_CLIENT default to '0.9.3' https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/blob/ma...) > E2E job - Swagger Version Always 'master' > ----------------------------------------- > > Key: SWSQE-1110 > URL: https://issues.redhat.com/browse/SWSQE-1110 > Project: Kiali QE > Issue Type: Bug > Reporter: Matthew Mahoney > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Issue is that the swagger json is always 'master'. > prepare-e2e-tests-env.sh needs to set the swagger file version/path appropriately based on KIALI_REVISION_SHA1 > https://github.com/kiali/kiali/blob/master/tests/e2e/config/env.yaml#L10 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020