[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
[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
[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
[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
[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
[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
[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
[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