July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12307) The build-legacy module does not build correctly

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-12307?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-12307: --------------------------------- Description: The {{build-legacy}} module cannot be built as there are two profiles with the same name which means only one will be activated. (was: The {{build-legacy}} module cannot be built as there are two profiles with the same name so only one will be activated.) > The build-legacy module does not build correctly > ------------------------------------------------ > > Key: WFLY-12307 > URL: https://issues.jboss.org/browse/WFLY-12307 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > > The {{build-legacy}} module cannot be built as there are two profiles with the same name which means only one will be activated. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4288) Infinite recursion in drools after version change from v7.20 to v7.21

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4288?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-4288. --------------------------------- Fix Version/s: 7.25.0.Final Resolution: Done This was an edge case and I fixed it with this commit https://github.com/kiegroup/drools/commit/98b48584b7469768a3e655697152405... A getter should be considered a "real" getter and then a method sensible for property reactivity only when it has no arguments. However remember that when you find questionable cases like this you can have total control on property reactivity by using the @watch annotation on patterns. > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4288 > URL: https://issues.jboss.org/browse/DROOLS-4288 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final > Environment: Both Mac and Windows > Reporter: Geogie Tom > Assignee: Mario Fusco > Priority: Major > Fix For: 7.25.0.Final > > Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png > > > When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively. > *Code in github:* > [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20] > [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21] > [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *More details* > When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part: > {code:java} > rule "rule 1.1" > when > $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable") > then > System.out.println("Rule 1.1 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it doesn't loop recursively. > But when I call another rule which call a static function from another class: > {code:java} > rule "rule 1.2" > when > $sampleDomain: SampleDomain(CoreUtils.anotherFunction()) > then > System.out.println("Rule 1.2 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it loops recursively. > The class with static function is > {code:java} > import com.drool_issue.domain.SampleDomain; > public class CoreUtils { > > public static boolean anotherFunction() { > System.out.println("anotherFunction() inside CoreUtils"); > return true; > } > > public static boolean anotherFunction(SampleDomain sampleDomain) { > System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils"); > return true; > } > } > {code} > My domain file is: > {code:java} > public class SampleDomain { > private int instanceVariable1; > private String instanceVariable2; > private int instanceVariable3; > > > public int getInstanceVariable1() { > return instanceVariable1; > } > public void setInstanceVariable1(int instanceVariable1) { > this.instanceVariable1 = instanceVariable1; > } > public String getInstanceVariable2() { > return instanceVariable2; > } > public void setInstanceVariable2(String instanceVariable2) { > this.instanceVariable2 = instanceVariable2; > } > public int getInstanceVariable3() { > return instanceVariable3; > } > public void setInstanceVariable3(int instanceVariable3) { > this.instanceVariable3 = instanceVariable3; > } > > > } > {code} > This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be? > When I further looked into the problem I saw this too. > When we add two functions into the `SampleDomain` class ie > {code:java} > public boolean anotherFunction() { > return true; > } > > public boolean anotherFunction(SampleDomain sampleDomain) { > return true; > } > {code} > and use this in the rule like: > {code:java} > rule "rule 1.4" > when > $sampleDomain: SampleDomain(anotherFunction()) > then > System.out.println("Rule 1.4 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > and > {code:java} > rule "rule 1.5" > when > $sampleDomain: SampleDomain(anotherFunction($sampleDomain)) > then > System.out.println("Rule 1.5 fired"); > modify($sampleDomain){ > setInstanceVariable3(4) > } > end > {code} > these also loops recursively. > *Code in github:* > [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule. > *Code portions to be noted here are:* > [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *Code in github:* > [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`* -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1715) Remove 'wildfly-elytron-auth-server-deprecated'

by Ashley Abdel-Sayed (Jira)

[ https://issues.jboss.org/browse/ELY-1715?page=com.atlassian.jira.plugin.s... ] Ashley Abdel-Sayed reassigned ELY-1715: --------------------------------------- Assignee: Ashley Abdel-Sayed > Remove 'wildfly-elytron-auth-server-deprecated' > ----------------------------------------------- > > Key: ELY-1715 > URL: https://issues.jboss.org/browse/ELY-1715 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Blocker > Fix For: 2.0.0.Alpha5 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12306) Transition OpenTracing to the latest supported version by Thorntail

by Emmanuel Hugonnet (Jira)

[ https://issues.jboss.org/browse/WFLY-12306?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet updated WFLY-12306: ------------------------------------- Description: Upgrading MP opentracing to Microprofile 3.0 was: This feature is about supporting the MP OpenTrancing API for internal purposes for Kiali integration The feature remains as tech preview for external users. > Transition OpenTracing to the latest supported version by Thorntail > -------------------------------------------------------------------- > > Key: WFLY-12306 > URL: https://issues.jboss.org/browse/WFLY-12306 > Project: WildFly > Issue Type: Feature Request > Components: MP OpenTracing > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Labels: EAP-CD18, OS_Observability, tp_candidate > > Upgrading MP opentracing to Microprofile 3.0 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12306) Transition OpenTracing to the latest supported version by Thorntail

by Emmanuel Hugonnet (Jira)

[ https://issues.jboss.org/browse/WFLY-12306?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet moved EAP7-1318 to WFLY-12306: ------------------------------------------------ Project: WildFly (was: EAP 7 Planning Pilot) Key: WFLY-12306 (was: EAP7-1318) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0) Component/s: MP OpenTracing (was: OpenShift) EAP PT Pre-Checked (PC): (was: TODO) Target Release: (was: 7.3.0.GA) EAP PT Community Docs (CD): (was: TODO) EAP PT Product Docs (PD): (was: New) EAP PT Test Dev (TD): (was: TODO) EAP PT Docs Analysis (DA): (was: TODO) EAP PT Test Plan (TP): (was: TODO) EAP PT Analysis Document (AD): (was: TODO) Writer: (was: Tomas Radej) > Transition OpenTracing to the latest supported version by Thorntail > -------------------------------------------------------------------- > > Key: WFLY-12306 > URL: https://issues.jboss.org/browse/WFLY-12306 > Project: WildFly > Issue Type: Feature Request > Components: MP OpenTracing > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Labels: EAP-CD18, OS_Observability, tp_candidate > > This feature is about supporting the MP OpenTrancing API for internal purposes for Kiali integration > The feature remains as tech preview for external users. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-3239) Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-3239?page=com.atlassian.jira.plugi... ] Luca Molteni commented on DROOLS-3239: -------------------------------------- Just a reminder that we have to add them also to the BOM > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > ------------------------------------------------------------------------------------------------------ > > Key: DROOLS-3239 > URL: https://issues.jboss.org/browse/DROOLS-3239 > Project: Drools > Issue Type: Task > Components: tools > Reporter: Matteo Mortari > Assignee: Luca Molteni > Priority: Major > > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > For reference this kind of dependencies described at step2: https://docs.jboss.org/drools/release/7.12.0.Final/drools-docs/html_singl... > {quote}it would be a lot better if we could inject these dependencies either automatically into the generated kjar/pom or if we could add them transitively. {quote} > Deliverable in case not possible is a reference (in the manual) about why adding these dependencies manually in the pom.xml is necessary --analogy to JavaEE/JakartaEE and jOOQ as an example? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-3239) Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin

by Stetson Robinson (Jira)

[ https://issues.jboss.org/browse/DROOLS-3239?page=com.atlassian.jira.plugi... ] Stetson Robinson commented on DROOLS-3239: ------------------------------------------ [~volothamp], I suppose you're right if we consider the exec model dependencies to be just another packaging requirement in the pom.xml for DM/PAM projects. Today, step one in the [packaging procedure|https://access.redhat.com/documentation/en-us/red_hat_process_a...] is to set the packaging type to kjar and add the kie-maven-plugin. I thought this exec model behavior change _was_ meant to be part of the kie-maven-plugin and thus covered by that step now, but if not, then I guess the second step would remain the same for adding those org.drools dependencies as part of the initial packaging process. Even still, the question remains about how the same procedure is impacted in a [Java application|https://access.redhat.com/documentation/en-us/red_hat_process...] (where `kieBuilder.buildAll( ExecutableModelProject.class )` is used) rather than in Maven. Can talk later on that, as we discussed. > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > ------------------------------------------------------------------------------------------------------ > > Key: DROOLS-3239 > URL: https://issues.jboss.org/browse/DROOLS-3239 > Project: Drools > Issue Type: Task > Components: tools > Reporter: Matteo Mortari > Assignee: Luca Molteni > Priority: Major > > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > For reference this kind of dependencies described at step2: https://docs.jboss.org/drools/release/7.12.0.Final/drools-docs/html_singl... > {quote}it would be a lot better if we could inject these dependencies either automatically into the generated kjar/pom or if we could add them transitively. {quote} > Deliverable in case not possible is a reference (in the manual) about why adding these dependencies manually in the pom.xml is necessary --analogy to JavaEE/JakartaEE and jOOQ as an example? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-3239) Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-3239?page=com.atlassian.jira.plugi... ] Luca Molteni commented on DROOLS-3239: -------------------------------------- [~stetson.robinson] It'd be weird from a migration point of view, definitely. But please note that those dependency are not required by the plugin itself, but by the source code that the plugin generates. Therefore they're going to be needed anyway by the runtime, and eventually every Drools project will have them. So it'd be even weirder if the kie-maven-plugin added them automatically without following the usual convention. Does this make sense? > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > ------------------------------------------------------------------------------------------------------ > > Key: DROOLS-3239 > URL: https://issues.jboss.org/browse/DROOLS-3239 > Project: Drools > Issue Type: Task > Components: tools > Reporter: Matteo Mortari > Assignee: Luca Molteni > Priority: Major > > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > For reference this kind of dependencies described at step2: https://docs.jboss.org/drools/release/7.12.0.Final/drools-docs/html_singl... > {quote}it would be a lot better if we could inject these dependencies either automatically into the generated kjar/pom or if we could add them transitively. {quote} > Deliverable in case not possible is a reference (in the manual) about why adding these dependencies manually in the pom.xml is necessary --analogy to JavaEE/JakartaEE and jOOQ as an example? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-3239) Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-3239?page=com.atlassian.jira.plugi... ] Luca Molteni edited comment on DROOLS-3239 at 7/19/19 11:00 AM: ---------------------------------------------------------------- [~stetson.robinson] It'd be weird from a migration point of view, definitely. But please note that those dependencies are not required by the plugin itself, but by the source code that the plugin generates. Therefore they're going to be needed anyway by the runtime, and eventually every Drools project will have them. So it'd be even weirder if the kie-maven-plugin added them automatically without following the usual convention. Does this make sense? was (Author: volothamp): [~stetson.robinson] It'd be weird from a migration point of view, definitely. But please note that those dependency are not required by the plugin itself, but by the source code that the plugin generates. Therefore they're going to be needed anyway by the runtime, and eventually every Drools project will have them. So it'd be even weirder if the kie-maven-plugin added them automatically without following the usual convention. Does this make sense? > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > ------------------------------------------------------------------------------------------------------ > > Key: DROOLS-3239 > URL: https://issues.jboss.org/browse/DROOLS-3239 > Project: Drools > Issue Type: Task > Components: tools > Reporter: Matteo Mortari > Assignee: Luca Molteni > Priority: Major > > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > For reference this kind of dependencies described at step2: https://docs.jboss.org/drools/release/7.12.0.Final/drools-docs/html_singl... > {quote}it would be a lot better if we could inject these dependencies either automatically into the generated kjar/pom or if we could add them transitively. {quote} > Deliverable in case not possible is a reference (in the manual) about why adding these dependencies manually in the pom.xml is necessary --analogy to JavaEE/JakartaEE and jOOQ as an example? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-3239) Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin

by Stetson Robinson (Jira)

[ https://issues.jboss.org/browse/DROOLS-3239?page=com.atlassian.jira.plugi... ] Stetson Robinson commented on DROOLS-3239: ------------------------------------------ IMO, we shouldn't make this default behavior change unless all dependencies, etc., are in place by default as well. It's odd for a default behavior to generate an error by default that is avoided only if the user manually adds the dependencies as a prerequisite or postrequisite. > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > ------------------------------------------------------------------------------------------------------ > > Key: DROOLS-3239 > URL: https://issues.jboss.org/browse/DROOLS-3239 > Project: Drools > Issue Type: Task > Components: tools > Reporter: Matteo Mortari > Assignee: Luca Molteni > Priority: Major > > Investigate if possible to inject dependencies required by maven compiler plugin from kie-maven-plugin > For reference this kind of dependencies described at step2: https://docs.jboss.org/drools/release/7.12.0.Final/drools-docs/html_singl... > {quote}it would be a lot better if we could inject these dependencies either automatically into the generated kjar/pom or if we could add them transitively. {quote} > Deliverable in case not possible is a reference (in the manual) about why adding these dependencies manually in the pom.xml is necessary --analogy to JavaEE/JakartaEE and jOOQ as an example? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 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 July 2019