May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5360) Avoid direct invocation of PMMLModelExecutor.evaluate

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5360?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5360: ------------------------------------- Description: -Change PMMLModelExecutor public API so that user should not retrieve the KiePMMLModel to invoke the "evaluate" method {code:java} PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) {code} -> {code:java} PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context); {code} Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method {code:java} PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) {code} AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations Actual implementations should then extend AbstractPMMLModelExecutor- was: Change PMMLModelExecutor public API so that user should not retrieve the KiePMMLModel to invoke the "evaluate" method {code:java} PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) {code} -> {code:java} PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context); {code} Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method {code:java} PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) {code} AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations Actual implementations should then extend AbstractPMMLModelExecutor > Avoid direct invocation of PMMLModelExecutor.evaluate > ----------------------------------------------------- > > Key: DROOLS-5360 > URL: https://issues.redhat.com/browse/DROOLS-5360 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > -Change PMMLModelExecutor public API so that user should not retrieve the KiePMMLModel to invoke the "evaluate" method > {code:java} > PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) > {code} > -> > {code:java} > PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context); > {code} > Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method > {code:java} > PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) > {code} > AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations > Actual implementations should then extend AbstractPMMLModelExecutor- -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5360) Avoid direct invocation of PMMLModelExecutor.evaluate

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5360?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5360: ------------------------------------- Description: -Change PMMLModelExecutor public API so that user should not retrieve the KiePMMLModel to invoke the "evaluate" method- {code:java} PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) {code} -> {code:java} PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context); {code} Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method {code:java} PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) {code} AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations Actual implementations should then extend AbstractPMMLModelExecutor- was: -Change PMMLModelExecutor public API so that user should not retrieve the KiePMMLModel to invoke the "evaluate" method {code:java} PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) {code} -> {code:java} PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context); {code} Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method {code:java} PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) {code} AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations Actual implementations should then extend AbstractPMMLModelExecutor- > Avoid direct invocation of PMMLModelExecutor.evaluate > ----------------------------------------------------- > > Key: DROOLS-5360 > URL: https://issues.redhat.com/browse/DROOLS-5360 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > -Change PMMLModelExecutor public API so that user should not retrieve the KiePMMLModel to invoke the "evaluate" method- > {code:java} > PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) > {code} > -> > {code:java} > PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context); > {code} > Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method > {code:java} > PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) > {code} > AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations > Actual implementations should then extend AbstractPMMLModelExecutor- -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5384) Clicking rightmost column's header in DMN decision table raises an error

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5384?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5384: -------------------------------- Tester: Jozef Marko Labels: drools-tools (was: ) > Clicking rightmost column's header in DMN decision table raises an error > ------------------------------------------------------------------------ > > Key: DROOLS-5384 > URL: https://issues.redhat.com/browse/DROOLS-5384 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.38.0.Final > Reporter: Toshiya Kobayashi > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: dmn-decision-table-error-popup-7.38.0.png > > > When I import Traffic_Violation sample, opened a "Fine" decision table. The rightmost column's header is empty ("Enter Text") and I get an error pop-up when clicked. > See screenshot. > Chrome 80.0.3987.122 > Firefox 60.6.2 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5360) Avoid direct invocation of PMMLModelExecutor.evaluate

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5360?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5360: ------------------------------------- Summary: Avoid direct invocation of PMMLModelExecutor.evaluate (was: Replace KiePMMLModel with modelname in PMMLModelExecutor.evaluate) > Avoid direct invocation of PMMLModelExecutor.evaluate > ----------------------------------------------------- > > Key: DROOLS-5360 > URL: https://issues.redhat.com/browse/DROOLS-5360 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Change PMMLModelExecutor public API so that user should not retrieve the KiePMMLModel to invoke the "evaluate" method > {code:java} > PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) > {code} > -> > {code:java} > PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context); > {code} > Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method > {code:java} > PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context) > {code} > AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations > Actual implementations should then extend AbstractPMMLModelExecutor -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8571) Ugrapde apache maven to 3.5.0

by Paul Gier (Jira)

[ https://issues.redhat.com/browse/WFLY-8571?page=com.atlassian.jira.plugin... ] Paul Gier closed WFLY-8571. --------------------------- Resolution: Out of Date > Ugrapde apache maven to 3.5.0 > ----------------------------- > > Key: WFLY-8571 > URL: https://issues.redhat.com/browse/WFLY-8571 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Affects Versions: 11.0.0.Beta1 > Reporter: Frank Langelage > Assignee: Paul Gier > Priority: Major > > Upgrade apache maven to latest version 3.5.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5367) Fixing model name/package name management during kiepmmlmodel generation/instantiation

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5367?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5367: ------------------------------------- Description: Current code is written with the assumption that model name is provided by all model definitions. That is not enforced by the specification itself, so we need to provide a way to generate a predictable model name. Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. Code-generate kmodule.xml was: Current code is written with the assumption that model name is provided by all model definitions. That is not enforced by the specification itself, so we need to provide a way to generate a predictable model name. Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file > Fixing model name/package name management during kiepmmlmodel generation/instantiation > -------------------------------------------------------------------------------------- > > Key: DROOLS-5367 > URL: https://issues.redhat.com/browse/DROOLS-5367 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Current code is written with the assumption that model name is provided by all model definitions. > That is not enforced by the specification itself, so we need to provide a way to generate a predictable model name. > Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file. > Code-generate kmodule.xml -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1164) Operator source will be probably removed in OCP 4.5

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1164: ------------------------------------ Summary: Operator source will be probably removed in OCP 4.5 Key: SWSQE-1164 URL: https://issues.redhat.com/browse/SWSQE-1164 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta We need to use Catalog source instead of Operator source in OCP 4.5 https://docs.openshift.com/container-platform/4.4/release_notes/ocp-4-4-r... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5367) Fixing model name/package name management during kiepmmlmodel generation/instantiation

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5367?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5367: ------------------------------------- Description: Current code is written with the assumption that model name is provided by all model definitions. That is not enforced by the specification itself, so we need to provide a way to generate a predictable model name. Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file was: Current code is written with the assumption that model name is provided by all model definitions. That is not enforced by the specification itself, so we need to provide a way to generate a predictable model name. > Fixing model name/package name management during kiepmmlmodel generation/instantiation > -------------------------------------------------------------------------------------- > > Key: DROOLS-5367 > URL: https://issues.redhat.com/browse/DROOLS-5367 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Current code is written with the assumption that model name is provided by all model definitions. > That is not enforced by the specification itself, so we need to provide a way to generate a predictable model name. > Beside that, verify if for every model there must be a specific package, or if it is fine to have one package for all the models defined in the same file -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5367) Fixing model name/package name management during kiepmmlmodel generation/instantiation

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5367?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5367: ------------------------------------- Summary: Fixing model name/package name management during kiepmmlmodel generation/instantiation (was: Manage missing model name during kiepmmlmodel generation/instantiation) > Fixing model name/package name management during kiepmmlmodel generation/instantiation > -------------------------------------------------------------------------------------- > > Key: DROOLS-5367 > URL: https://issues.redhat.com/browse/DROOLS-5367 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Current code is written with the assumption that model name is provided by all model definitions. > That is not enforced by the specification itself, so we need to provide a way to generate a predictable model name. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13514) Huge memory leak in WildFly

by Matěj Novotný (Jira)

[ https://issues.redhat.com/browse/WFLY-13514?page=com.atlassian.jira.plugi... ] Matěj Novotný commented on WFLY-13514: -------------------------------------- First of all, huge thanks for this reproducer! It makes it so much easier to discuss things on a common ground. As for the issue, the scope here is definitely going to matter. You cannot get OOM when you use {{@ApplicationScoped}} as you will have only one instance active. Try adding {{@Named}} and {{@ApplicationScoped}} on that bean instead of {{@Model}} and it won't crash. Likewise, when you use {{@SessionScoped}} you will run OOM because for each {{curl{{ you create new session and you do that much faster then those session can timeout (or be anyhow invalidated) hence your post construct code allocating bytes will cause the OOM eventually. So I think we should specifically talk about request scope where the behaviour is really awkward. I can see that for each request, we correctly create a bean instance and I can also see that after each request we attempt to destroy it (if you add {{@PreDestroy}} callback, you can see that it will be invoked). I'm going to look at the heap dump and what keeps the references... > Huge memory leak in WildFly > --------------------------- > > Key: WFLY-13514 > URL: https://issues.redhat.com/browse/WFLY-13514 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 18.0.1.Final, 19.1.0.Final, 20.0.0.Beta1 > Reporter: Konrad Bak > Assignee: Matěj Novotný > Priority: Critical > > https://github.com/konbk/bug-report-wildfly-oome > The project shows a huge memory leak introduced in recent WildFly versions that can crash a real-world Java EE application in a matter of hours. > When a JSF page contains any component bound to page variable, all CDI beans (regardless of scope) used on that page stay in memory. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 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 May 2020