[JBoss JIRA] (WFLY-13462) Issues in readme for microprofile-config QS
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13462?page=com.atlassian.jira.plugi... ]
Eduardo Martins resolved WFLY-13462.
------------------------------------
Fix Version/s: 20.0.0.Final
(was: 20.0.0.Beta1)
Resolution: Done
> Issues in readme for microprofile-config QS
> -------------------------------------------
>
> Key: WFLY-13462
> URL: https://issues.redhat.com/browse/WFLY-13462
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Critical
> Fix For: 20.0.0.Final
>
>
> (2) Consider adding standard sections - see other (non-MP - because these were not yet tested)
> * Use of the EAP_HOME and QUICKSTART_HOME Variables
> * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
> * Also consider using standard sections "Build and Deploy the Quickstart" and "Access the Application" instead of "Solution"
> (3) {{EAP_HOME}} is used when starting the server, but {{JBOSS_HOME}} is used later in the step-by-step instructions to refer to the same path. Consider updating the text (and code accordingly) to use one of {{ EAP_HOME}} / {{JBOSS_HOME}} throughout the quickstart.
> (4) The quickstart contains arquillian tests but readme does not mention them. Please also add prerequisites for running the tests because when running them with out-of-the-box server and QS there are failures:
> {code}
> [ERROR] Tests run: 7, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 4.372 s <<< FAILURE! - in org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT
> [ERROR] testConfigSourceReloadedValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.029 s <<< ERROR!
> java.nio.file.NoSuchFileException: null/custom.properties
> at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigSourceReloadedValue(MicroProfileConfigIT.java:181)
> [ERROR] testConfigPropertiesValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.013 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<My[PropertyFile]ConfigValue> but was:<My[EnvProp]ConfigValue>
> at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigPropertiesValue(MicroProfileConfigIT.java:84)
> {code}
> (5) Missing section on how to undeploy the QS. Standard section {{Undeploy the Quickstart}} can be used.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (WFLY-13462) Issues in readme for microprofile-config QS
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13462?page=com.atlassian.jira.plugi... ]
Eduardo Martins reopened WFLY-13462:
------------------------------------
> Issues in readme for microprofile-config QS
> -------------------------------------------
>
> Key: WFLY-13462
> URL: https://issues.redhat.com/browse/WFLY-13462
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Critical
> Fix For: 20.0.0.Final
>
>
> (2) Consider adding standard sections - see other (non-MP - because these were not yet tested)
> * Use of the EAP_HOME and QUICKSTART_HOME Variables
> * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
> * Also consider using standard sections "Build and Deploy the Quickstart" and "Access the Application" instead of "Solution"
> (3) {{EAP_HOME}} is used when starting the server, but {{JBOSS_HOME}} is used later in the step-by-step instructions to refer to the same path. Consider updating the text (and code accordingly) to use one of {{ EAP_HOME}} / {{JBOSS_HOME}} throughout the quickstart.
> (4) The quickstart contains arquillian tests but readme does not mention them. Please also add prerequisites for running the tests because when running them with out-of-the-box server and QS there are failures:
> {code}
> [ERROR] Tests run: 7, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 4.372 s <<< FAILURE! - in org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT
> [ERROR] testConfigSourceReloadedValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.029 s <<< ERROR!
> java.nio.file.NoSuchFileException: null/custom.properties
> at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigSourceReloadedValue(MicroProfileConfigIT.java:181)
> [ERROR] testConfigPropertiesValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.013 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<My[PropertyFile]ConfigValue> but was:<My[EnvProp]ConfigValue>
> at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigPropertiesValue(MicroProfileConfigIT.java:84)
> {code}
> (5) Missing section on how to undeploy the QS. Standard section {{Undeploy the Quickstart}} can be used.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (WFLY-13462) Issues in readme for microprofile-config QS
by Martin Stefanko (Jira)
[ https://issues.redhat.com/browse/WFLY-13462?page=com.atlassian.jira.plugi... ]
Martin Stefanko updated WFLY-13462:
-----------------------------------
Git Pull Request: https://github.com/wildfly/quickstart/pull/414, https://github.com/wildfly/quickstart/pull/430 (was: https://github.com/wildfly/quickstart/pull/414)
> Issues in readme for microprofile-config QS
> -------------------------------------------
>
> Key: WFLY-13462
> URL: https://issues.redhat.com/browse/WFLY-13462
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Critical
> Fix For: 20.0.0.Beta1
>
>
> (2) Consider adding standard sections - see other (non-MP - because these were not yet tested)
> * Use of the EAP_HOME and QUICKSTART_HOME Variables
> * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
> * Also consider using standard sections "Build and Deploy the Quickstart" and "Access the Application" instead of "Solution"
> (3) {{EAP_HOME}} is used when starting the server, but {{JBOSS_HOME}} is used later in the step-by-step instructions to refer to the same path. Consider updating the text (and code accordingly) to use one of {{ EAP_HOME}} / {{JBOSS_HOME}} throughout the quickstart.
> (4) The quickstart contains arquillian tests but readme does not mention them. Please also add prerequisites for running the tests because when running them with out-of-the-box server and QS there are failures:
> {code}
> [ERROR] Tests run: 7, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 4.372 s <<< FAILURE! - in org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT
> [ERROR] testConfigSourceReloadedValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.029 s <<< ERROR!
> java.nio.file.NoSuchFileException: null/custom.properties
> at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigSourceReloadedValue(MicroProfileConfigIT.java:181)
> [ERROR] testConfigPropertiesValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.013 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<My[PropertyFile]ConfigValue> but was:<My[EnvProp]ConfigValue>
> at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigPropertiesValue(MicroProfileConfigIT.java:84)
> {code}
> (5) Missing section on how to undeploy the QS. Standard section {{Undeploy the Quickstart}} can be used.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JGRP-2470) JBDC_PING can face a split-brain issue when restarting a coordinator node
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2470?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2470:
--------------------------------
What's the rationale for reverting JGRP-2199? If the old coord removes all information, the new one will re-insert it (actually multiple times, if configured)...
> JBDC_PING can face a split-brain issue when restarting a coordinator node
> -------------------------------------------------------------------------
>
> Key: JGRP-2470
> URL: https://issues.redhat.com/browse/JGRP-2470
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9, 4.0.22
> Reporter: Masafumi Miura
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 4.2.5
>
>
> After [the change|https://github.com/belaban/JGroups/commit/215cdb6] for JGRP-2199, JDBC_PING deletes all entries from the table during the shutdown of the coordinator node.
> This behavior has a possibility to cause a split-brain when restarting a coordinator node. Because, as all entries are lost in the following scenario, the restarting node can not find any information about existing nodes from the table and does not form a cluster.
> 0. node1 and node2 form a cluster. The node1 is a coordinator.
> 1. Trigger a restart of the node1
> 2. The node1 removes their node information from the table
> 3. The node2 becomes a new coordinator
> 4. The node2 updates their node information in the table
> 5. The node1 clears all entries from the table
> 6. The node1 starts again
> 7. The node1 does not join the existing cluster because there's no node information in the table
> Note: If step 5 happens before step 4, the split-brain issue does not happen. However, as step 4 and step 5 happen on different nodes, these steps can happen in parallel. So, the order is undefined. So, for example, if the shutdown of node1 takes a long time, there's a high possibility to face this issue.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[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-
-PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
->
-PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context);-
-Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method-
-PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
-AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations-
-Actual implementations should then extend AbstractPMMLModelExecutor-
The PMMLModelExecutor API should be intended as private API, i.e. users should not invoke it directly, nor they should need to retrieve the KiePMMLModel.
Unfortunately, for the moment being the KiePMMLModel is needed to retrieve the actual implementation of PMMLModelExecutor, so it is not possible to invoke
{code:java}
PMMLModelExecutor.evaluate(...)
{code}
on it using only the model name without retrieve the KiePMMLModel itself before.
For the moment being this ticket will remove usage of PMMLModelExecutor implementation inside integrations tests.
Moreover, there will also be a small name refactoring to uniform the name of the classes in the hierarchy, so that the main interface will be
PMMLModelEvaluator, and all the implementing class will end with "Evaluator"
was:
-Change PMMLModelExecutor public API so that user should not retrieve the KiePMMLModel to invoke the "evaluate" method-
-PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
->
-PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context);-
-Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method-
-PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
-AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations-
-Actual implementations should then extend AbstractPMMLModelExecutor-
The PMMLModelExecutor API should be intended as private API, i.e. users should not invoke it directly, nor they should need to retrieve the KiePMMLModel.
Unfortunately, for the moment being the KiePMMLModel is needed to retrieve the actual implementation of PMMLModelExecutor, so it is not possible to invoke
{code}
PMMLModelExecutor.evaluate(...)
{/code}
on it using only the model name without retrieve the KiePMMLModel itself before.
For the moment being this ticket will remove usage of PMMLModelExecutor implementation inside integrations tests.
Moreover, there will also be a small name refactoring to uniform the name of the classes in the hierarchy, so that the main interface will be
PMMLModelEvaluator, and all the implementing class will end with "Evaluator"
> 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-
> -PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
> ->
> -PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context);-
> -Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method-
> -PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
> -AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations-
> -Actual implementations should then extend AbstractPMMLModelExecutor-
> The PMMLModelExecutor API should be intended as private API, i.e. users should not invoke it directly, nor they should need to retrieve the KiePMMLModel.
> Unfortunately, for the moment being the KiePMMLModel is needed to retrieve the actual implementation of PMMLModelExecutor, so it is not possible to invoke
> {code:java}
> PMMLModelExecutor.evaluate(...)
> {code}
> on it using only the model name without retrieve the KiePMMLModel itself before.
> For the moment being this ticket will remove usage of PMMLModelExecutor implementation inside integrations tests.
> Moreover, there will also be a small name refactoring to uniform the name of the classes in the hierarchy, so that the main interface will be
> PMMLModelEvaluator, and all the implementing class will end with "Evaluator"
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[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-
-PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
->
-PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context);-
-Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method-
-PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
-AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations-
-Actual implementations should then extend AbstractPMMLModelExecutor-
The PMMLModelExecutor API should be intended as private API, i.e. users should not invoke it directly, nor they should need to retrieve the KiePMMLModel.
Unfortunately, for the moment being the KiePMMLModel is needed to retrieve the actual implementation of PMMLModelExecutor, so it is not possible to invoke
{code}
PMMLModelExecutor.evaluate(...)
{/code}
on it using only the model name without retrieve the KiePMMLModel itself before.
For the moment being this ticket will remove usage of PMMLModelExecutor implementation inside integrations tests.
Moreover, there will also be a small name refactoring to uniform the name of the classes in the hierarchy, so that the main interface will be
PMMLModelEvaluator, and all the implementing class will end with "Evaluator"
was:
-Change PMMLModelExecutor public API so that user should not retrieve the KiePMMLModel to invoke the "evaluate" method-
-PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
->
-PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context);-
-Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method-
-PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
-AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations-
-Actual implementations should then extend AbstractPMMLModelExecutor-
The
> 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-
> -PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
> ->
> -PMML4Result evaluate(final KieBase knowledgeBase, String modelName, PMMLContext context);-
> -Create AbstractPMMLModelExecutor that implement the above interface and declare an abstract method-
> -PMML4Result evaluate(final KieBase knowledgeBase, KiePMMLModel model, PMMLContext context)-
> -AbstractPMMLModelExecutor should then use KnoweledgeBaseUtils to retrieve the KiePMMLModel and invoke/delegate to actual implementations-
> -Actual implementations should then extend AbstractPMMLModelExecutor-
> The PMMLModelExecutor API should be intended as private API, i.e. users should not invoke it directly, nor they should need to retrieve the KiePMMLModel.
> Unfortunately, for the moment being the KiePMMLModel is needed to retrieve the actual implementation of PMMLModelExecutor, so it is not possible to invoke
> {code}
> PMMLModelExecutor.evaluate(...)
> {/code}
> on it using only the model name without retrieve the KiePMMLModel itself before.
> For the moment being this ticket will remove usage of PMMLModelExecutor implementation inside integrations tests.
> Moreover, there will also be a small name refactoring to uniform the name of the classes in the hierarchy, so that the main interface will be
> PMMLModelEvaluator, and all the implementing class will end with "Evaluator"
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years