April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1124) Automate filters by 2 names

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1124?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan reopened SWSQE-1124: ----------------------------------- > Automate filters by 2 names > --------------------------- > > Key: SWSQE-1124 > URL: https://issues.redhat.com/browse/SWSQE-1124 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > https://issues.redhat.com/browse/OSSM-93 > https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5061) DMN codegen DMNContext and DMNResult

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5061?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5061: ----------------------------------- Description: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition. Surface and interface common to: * BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model * Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN ** for Quarkus based, use RegisterForReflection annotation ** use MP validation for allowedvalues * DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class was: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition. Surface and interface common to: * BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model * Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN * DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class > DMN codegen DMNContext and DMNResult > ------------------------------------ > > Key: DROOLS-5061 > URL: https://issues.redhat.com/browse/DROOLS-5061 > Project: Drools > Issue Type: Epic > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Luca Molteni > Priority: Major > > A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition. > Surface and interface common to: > * BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model > * Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN > ** for Quarkus based, use RegisterForReflection annotation > ** use MP validation for allowedvalues > * DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4860) Performance degradation with the LogContextSelector on Java 11

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFCORE-4860?page=com.atlassian.jira.plug... ] Ilia Vassilev updated WFCORE-4860: ---------------------------------- Labels: downstream_dependency (was: ) > Performance degradation with the LogContextSelector on Java 11 > --------------------------------------------------------------- > > Key: WFCORE-4860 > URL: https://issues.redhat.com/browse/WFCORE-4860 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Labels: downstream_dependency > Fix For: 12.0.0.Beta1 > > > As described in LOGMGR-263 there is a performance impact on Java 11 when using the {{ClassLoaderLogContextSelector}}. In WildFly for users that do not use per-deployment logging we could get around this by not using that log context selector. This would not fix the performance impact for users using Java 11 and per-deployment logging however. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13273) Create tests for WFCORE-4860

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-13273?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-13273: --------------------------------- Labels: downstream_dependency (was: ) > Create tests for WFCORE-4860 > ---------------------------- > > Key: WFLY-13273 > URL: https://issues.redhat.com/browse/WFLY-13273 > Project: WildFly > Issue Type: Task > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Labels: downstream_dependency > Fix For: 20.0.0.Beta1 > > > WFCORE-4860 makes some change in behavior for how the log context selector works. This is to help with some performance issues with Java 9+. The tests need to live in WildFly as we need multiple deployments and EAR's which the core test suite cannot handle. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13389) (7.3.z) WFLY-13273 - Create tests for WFCORE-4860

by Ilia Vassilev (Jira)

Ilia Vassilev created WFLY-13389: ------------------------------------ Summary: (7.3.z) WFLY-13273 - Create tests for WFCORE-4860 Key: WFLY-13389 URL: https://issues.redhat.com/browse/WFLY-13389 Project: WildFly Issue Type: Task Components: Logging Reporter: Ilia Vassilev Assignee: James Perkins Fix For: 20.0.0.Beta1 WFCORE-4860 makes some change in behavior for how the log context selector works. This is to help with some performance issues with Java 9+. The tests need to live in WildFly as we need multiple deployments and EAR's which the core test suite cannot handle. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13389) (7.3.z) WFLY-13273 - Create tests for WFCORE-4860

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-13389?page=com.atlassian.jira.plugi... ] Ilia Vassilev reassigned WFLY-13389: ------------------------------------ Assignee: Ilia Vassilev (was: James Perkins) > (7.3.z) WFLY-13273 - Create tests for WFCORE-4860 > ------------------------------------------------- > > Key: WFLY-13389 > URL: https://issues.redhat.com/browse/WFLY-13389 > Project: WildFly > Issue Type: Task > Components: Logging > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > > WFCORE-4860 makes some change in behavior for how the log context selector works. This is to help with some performance issues with Java 9+. The tests need to live in WildFly as we need multiple deployments and EAR's which the core test suite cannot handle. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4933) (7.3.z) WFCORE-4860 - Performance degradation with the LogContextSelector on Java 11

by Ilia Vassilev (Jira)

Ilia Vassilev created WFCORE-4933: ------------------------------------- Summary: (7.3.z) WFCORE-4860 - Performance degradation with the LogContextSelector on Java 11 Key: WFCORE-4933 URL: https://issues.redhat.com/browse/WFCORE-4933 Project: WildFly Core Issue Type: Enhancement Components: Logging Reporter: Ilia Vassilev Assignee: James Perkins Fix For: 12.0.0.Beta1 As described in LOGMGR-263 there is a performance impact on Java 11 when using the {{ClassLoaderLogContextSelector}}. In WildFly for users that do not use per-deployment logging we could get around this by not using that log context selector. This would not fix the performance impact for users using Java 11 and per-deployment logging however. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4933) (7.3.z) WFCORE-4860 - Performance degradation with the LogContextSelector on Java 11

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFCORE-4933?page=com.atlassian.jira.plug... ] Ilia Vassilev reassigned WFCORE-4933: ------------------------------------- Assignee: Ilia Vassilev (was: James Perkins) > (7.3.z) WFCORE-4860 - Performance degradation with the LogContextSelector on Java 11 > ------------------------------------------------------------------------------------- > > Key: WFCORE-4933 > URL: https://issues.redhat.com/browse/WFCORE-4933 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > Fix For: 12.0.0.Beta1 > > > As described in LOGMGR-263 there is a performance impact on Java 11 when using the {{ClassLoaderLogContextSelector}}. In WildFly for users that do not use per-deployment logging we could get around this by not using that log context selector. This would not fix the performance impact for users using Java 11 and per-deployment logging however. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13144) Resource Adapter can't be deleted after restarting server

by Dmitrii Pogorelov (Jira)

[ https://issues.redhat.com/browse/WFLY-13144?page=com.atlassian.jira.plugi... ] Dmitrii Pogorelov commented on WFLY-13144: ------------------------------------------ thx [~shawkins] for your comment, I'll try your idea once I have free time. I'll write here about any results. > Resource Adapter can't be deleted after restarting server > --------------------------------------------------------- > > Key: WFLY-13144 > URL: https://issues.redhat.com/browse/WFLY-13144 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 14.0.1.Final, 11.0.0.Final, 17.0.1.Final > Reporter: Dmitrii Pogorelov > Assignee: Ivo Studensky > Priority: Critical > Attachments: jca-demo-1.0.rar, jcademo-source-code.rar > > > The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error: > {code:noformat} > [standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL", > "rolled-back" => true > } > {code} > After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13144) Resource Adapter can't be deleted after restarting server

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13144?page=com.atlassian.jira.plugi... ] Steven Hawkins commented on WFLY-13144: --------------------------------------- In the teiid admin code when we remove a source we remove both the connection-definitions and the resource-adapter, have you tried this sequence but with removing the connection-definitions before removing the resource-adapter? > Resource Adapter can't be deleted after restarting server > --------------------------------------------------------- > > Key: WFLY-13144 > URL: https://issues.redhat.com/browse/WFLY-13144 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 14.0.1.Final, 11.0.0.Final, 17.0.1.Final > Reporter: Dmitrii Pogorelov > Assignee: Ivo Studensky > Priority: Critical > Attachments: jca-demo-1.0.rar, jcademo-source-code.rar > > > The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error: > {code:noformat} > [standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL", > "rolled-back" => true > } > {code} > After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

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