[Red Hat JIRA] (WFLY-10862) Log warning when MP Health reports DOWN
by Martin Stefanko (Jira)
[ https://issues.redhat.com/browse/WFLY-10862?page=com.atlassian.jira.plugi... ]
Martin Stefanko commented on WFLY-10862:
----------------------------------------
WildFly doesn't use SmallRyeHealthReporter so the logs are not reflected even after the update.
> Log warning when MP Health reports DOWN
> ---------------------------------------
>
> Key: WFLY-10862
> URL: https://issues.redhat.com/browse/WFLY-10862
> Project: WildFly
> Issue Type: Enhancement
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Martin Stefanko
> Priority: Major
>
> Enhance MP Health functionality to log warning when MP Health reports DOWN.
> This can be useful when working on investigation / retrospective analysis.
> Open Liberty prints following warning when http://localhost:9080/health reports DOWN
> {code}
> [WARNING ] CWMH0051W: The class com.ibm.ws.microprofile.health.impl.HealthCheckResponseImpl implementing HealthCheckResponse
> in the microprofile-health application in module microprofile-health.war,
> reported a DOWN outcome DOWN with data Optional[{availability=not available}].
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6035) Some combination of characters in the rule name breaks the ANTLR grammar
by Luca Molteni (Jira)
Luca Molteni created DROOLS-6035:
------------------------------------
Summary: Some combination of characters in the rule name breaks the ANTLR grammar
Key: DROOLS-6035
URL: https://issues.redhat.com/browse/DROOLS-6035
Project: Drools
Issue Type: Bug
Reporter: Luca Molteni
Assignee: Luca Molteni
See https://stackoverflow.com/questions/66212287/what-characters-are-allowed-...
I think I have discovered, anecdotally, that some "grouping" characters do not work in rule names (seems rules named with can't be found or aren't included) - or at least, in extension rules (the extended rule seems to work with grouping chars, but not its extension; example below): The grouping chars include parentheses "()", square brackets "[]", and "curly braces" "{}". Although less than & greater than "<>" work, so I'm so far replacing the former with the latter.
Or are there escape chars for the problematic grouping chars?
Example:
rule "(grouping chars, and commas, work here)"
when
// conditions LHS
then
end
// removing parentheses, or replacing with < >,
// from below line works
rule "(grouping chars DON'T work here)"
extends "(grouping chars, and commas, work here)"
when
then
// consequences RHS
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6030) Evaluate "KieBase.addPackage" replacement effort from PMML
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-6030?page=com.atlassian.jira.plug... ]
Gabriele Cardosi commented on DROOLS-6030:
------------------------------------------
[~mfusco]
Following our conversation, there are two possible alternatives
1) consider creation of "clean" kiebases at origin -i.e. modify maven plugin/kogito codegen to automatically generate a kmodule.xml to have all models already splitted in different kiebases, witout asking the user to manually write one
2) consider create a "KieBase.of" "native" method, inside KieBase itself, to return a subset of the original KieBase,
> Evaluate "KieBase.addPackage" replacement effort from PMML
> ----------------------------------------------------------
>
> Key: DROOLS-6030
> URL: https://issues.redhat.com/browse/DROOLS-6030
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> Currently, the method KieBase.addPackage(s) is used inside PMML in two classes
> 1) PMMLLoaderService.loadPMMLRuleMappers
> 2) PMMLRuntimeFactoryInternal.getPMMLRuntime(String, String, KieBase)
> 3) PMMLRuntimeFactoryInternal.createKieBase(KnowledgeBuilderImpl)
> In all those cases the needs is to create a "clean" kiebase that contains only the model-specific packages, to avoid name/session clashing.
> Scope of the current ticket is to evaluate an alternative, since the method itself is going to be deprecated.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6034) Unable to build project inserting and updating a fact of same rule running with an executable model
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-6034?page=com.atlassian.jira.plug... ]
Luca Molteni moved RHDM-1610 to DROOLS-6034:
--------------------------------------------
Component/s: executable model
(was: BRE)
Docs QE Status: NEW
Key: DROOLS-6034 (was: RHDM-1610)
QE Status: NEW
Affects Version/s: (was: 7.9.0.GA)
(was: 7.9.1.GA)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Environment: (was: * Red Hat Decision Manager
** 7.9.0)
Project: Drools (was: Red Hat Decision Manager)
> Unable to build project inserting and updating a fact of same rule running with an executable model
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-6034
> URL: https://issues.redhat.com/browse/DROOLS-6034
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
> Attachments: RuleIssue_02864136.zip, pom.xml
>
>
> Customer has rule which look like as:
>
> ~~~
> rule "Testrule"
> dialect "mvel"
> when
> then
> com.Employee e = new Employee();
> e.setId("1");
> insert( e );
> e.setName("abc");
> update( e );
> end
> ~~~
>
> If we try to build project it fails with below exception:
> ~~~
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.44.0.Final-redhat-00003:generateModel (default-generateModel) on project RuleIssue_02864136: Execution default-generateModel of goal org.kie:kie-maven-plugin:7.44.0.Final-redhat-00003:generateModel failed.: RuntimeException -> [Help 1]
> [ERROR]
> ~~~
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6033) LocaldateTime guided rule presents it incorrectly.
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-6033?page=com.atlassian.jira.plug... ]
Toni Rikkola updated DROOLS-6033:
---------------------------------
Description: (was: A customer is facing issue regarding LocalDateTime. Once they use free form DRL with the temporal operator (screenshot-1),er saving and reopening the rule it will changes to (screenshot-2) and the rule still captures the condition correctly, but the guided rule presents it incorrectly, which creates confusion for rule authors.
)
> LocaldateTime guided rule presents it incorrectly.
> ---------------------------------------------------
>
> Key: DROOLS-6033
> URL: https://issues.redhat.com/browse/DROOLS-6033
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor, Guided Rule Editor, Guided Template Editor
> Reporter: Amit Nijhawan
> Assignee: Toni Rikkola
> Priority: Major
> Labels: Field, Support, drools-tools, guided_rule_editor
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Andrew K (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Andrew K commented on DROOLS-5973:
----------------------------------
Thanks again [~tari_manga] for engaging with this.
I'd be very happy for any functionality that handles the mapping in a sensible way. Your suggestion regarding toString() is a good one that would cover my use case well.
As you say it wouldn't handle DMN item restrictions that map to numbers, but I also think that it's obvious enough that that situation wouldn't "just work" - but for most use cases where the Enum can be considered equivalent to a string it should "just work" and that's great!
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6033) LocaldateTime guided rule presents it incorrectly.
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-6033?page=com.atlassian.jira.plug... ]
Toni Rikkola moved RHPAM-3464 to DROOLS-6033:
---------------------------------------------
Component/s: Guided Decision Table Editor
Guided Rule Editor
Guided Template Editor
(was: Business Central)
Docs QE Status: NEW
Key: DROOLS-6033 (was: RHPAM-3464)
QE Status: NEW
Affects Version/s: (was: 7.7.0.GA)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Project: Drools (was: Red Hat Process Automation Manager)
> LocaldateTime guided rule presents it incorrectly.
> ---------------------------------------------------
>
> Key: DROOLS-6033
> URL: https://issues.redhat.com/browse/DROOLS-6033
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor, Guided Rule Editor, Guided Template Editor
> Reporter: Amit Nijhawan
> Assignee: Toni Rikkola
> Priority: Major
> Labels: Field, Support, drools-tools, guided_rule_editor
>
> A customer is facing issue regarding LocalDateTime. Once they use free form DRL with the temporal operator (screenshot-1),er saving and reopening the rule it will changes to (screenshot-2) and the rule still captures the condition correctly, but the guided rule presents it incorrectly, which creates confusion for rule authors.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6032) Class name conflict by class "D" in exec-model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-6032?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-6032 at 2/16/21 4:21 AM:
--------------------------------------------------------------------
Thanks [~lucamolteni] , I took a look at the patch and I agree that it would be easier if we can remove FLOW first. I think it's okay to change the fact class name "D" to "X" (or whatever) as a workaround in the meantime so this JIRA is not urgent.
Btw, the linked PR (https://github.com/kiegroup/drools/pull/3385) is not a fix of this issue so please ignore it (just mentioned this JIRA in a commit message)
was (Author: tkobayashi):
Thanks [~lucamolteni] , I took a look at the patch and I agree that it would be easier if we can remove FLOW first. I think it's okay to change "D" to "X" (or whatever) as a workaround in the meantime so this JIRA is not urgent.
Btw, the linked PR (https://github.com/kiegroup/drools/pull/3385) is not a fix of this issue so please ignore it (just mentioned this JIRA in a commit message)
> Class name conflict by class "D" in exec-model
> ----------------------------------------------
>
> Key: DROOLS-6032
> URL: https://issues.redhat.com/browse/DROOLS-6032
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.50.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Attachments: FQN_first_draft,_uses_static_fields.patch
>
>
> If you use a fact class named "D", you will hit errors during executable-model code generation.
> {code:java}
> @Test
> public void testClassNameConflict() {
> String str =
> "import " + D.class.getCanonicalName() + ";" +
> "rule R when\n" +
> " D(name == \"John\")\n" +
> "then\n" +
> "end";
> KieSession ksession = getKieSession( str );
> D fact = new D("John");
> ksession.insert( fact );
> assertEquals(1, ksession.fireAllRules());
> }
> public static class D {
> private String name;
> public D(String name) {
> this.name = name;
> }
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> }
> {code}
> {noformat}
> [ERROR] CompilerTest.testClassNameConflict:2573->BaseModelTest.getKieSession:111->BaseModelTest.getKieSession:115->BaseModelTest.getKieContainer:119->BaseModelTest.getKieContainer:126->BaseModelTest.createKieBuilder:137->BaseModelTest.createKieBuilder:164 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=5, column=1
> text=a type with the same simple name is already defined by the single-type-import of org.drools.modelcompiler.dsl.pattern.D], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=0, column=0
> text=Java source of src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java in error:
> package defaultpkg;
> import org.drools.modelcompiler.dsl.pattern.D;
> import org.drools.model.Index.ConstraintType;
> import org.drools.modelcompiler.CompilerTest.D;
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Matteo Mortari edited comment on DROOLS-5973 at 2/16/21 4:20 AM:
-----------------------------------------------------------------
[~andrew__k], thank you for providing some more information. I am happy to reopen this jira to investigate it as "feature request".
One thing however, I doubt it will be equivalently of calling internally .name(), since that would never cover the case where the DMN string restriction contains an invalid token character for Java (say a space, etc.) as in
{code:java}
public enum Frequency { Daily, Every_other_day }
{code}
and in that case it would never be possible to remap it on a DMN string restricted say as in:
{code}
"daily", "every other day"
{code}
but maybe there are some cases where I can reasonably internally default in the engine to calling toString() as a default.
Because in that case the Java Enum can be redefined as:
{code:java}
public enum Frequency { Daily("daily"), Every_other_day("every other day"); ... }
{code}
etc.
I will focus the analysis of this feature request in this way.
Naturally, it will never be possible to cover automatically to remap a Java's Enum to a DMN's ItemDefinition which is not a string. e.g.: the previous example of restricting the domain of a number can't be covered equivalently.
If you have more details about your use case which you believe connected to this feature, don't hesitate to share.
was (Author: tari_manga):
[~andrew__k], thank you for providing some more information. I am happy to reopen this jira to investigate it as "feature request".
One thing however, I doubt it will be equivalently of calling internally .name(), since that would never cover the case where the DMN string restriction contains an invalid token character for Java (say a space, etc.) as in
{code:java}
public enum Frequency { Daily, Every_other_day }
{code}
and in that case it would never be possible to remap it on a DMN string restricted say as in:
{code}
"daily", "every other day"
{code}
but maybe there are some cases where I can reasonably internally default in the engine to calling toString() as a default.
I will focus the analysis of this feature request in this way.
Naturally, it will never be possible to cover automatically to remap a Java's Enum to a DMN's ItemDefinition which is not a string. e.g.: the previous example of restricting the domain of a number can't be covered equivalently.
If you have more details about your use case which you believe connected to this feature, don't hesitate to share.
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Matteo Mortari reopened DROOLS-5973:
------------------------------------
[~andrew__k], thank you for providing some more information. I am happy to reopen this jira to investigate it as "feature request".
One thing however, I doubt it will be equivalently of calling internally .name(), since that would never cover the case where the DMN string restriction contains an invalid token character for Java (say a space, etc.) as in
{code:java}
public enum Frequency { Daily, Every_other_day }
{code}
and in that case it would never be possible to remap it on a DMN string restricted say as in:
{code}
"daily", "every other day"
{code}
but maybe there are some cases where I can reasonably internally default in the engine to calling toString() as a default.
I will focus the analysis of this feature request in this way.
Naturally, it will never be possible to cover automatically to remap a Java's Enum to a DMN's ItemDefinition which is not a string. e.g.: the previous example of restricting the domain of a number can't be covered equivalently.
If you have more details about your use case which you believe connected to this feature, don't hesitate to share.
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month