April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5215) With executable model drools keyword is not found when used in a method call

by Matteo Casalino (Jira)

[ https://issues.redhat.com/browse/DROOLS-5215?page=com.atlassian.jira.plug... ] Matteo Casalino updated DROOLS-5215: ------------------------------------ Description: Executable model rule compilation fails on rule consequents using the _drools_ keyword as a parameter of a method call. Example of DRL that fails to compile: {noformat} function printRuleName(String ruleName) { System.out.println(ruleName); } rule "drools keyword in method call" when then printRuleName(drools.getRule().getName()); end {noformat} The example works fine when compiling without executable model. was: Executable model rule compilation fails on rule consequents using the _drools _ keyword as a parameter of a method call. Example of DRL that fails to compile: {noformat} function printRuleName(String ruleName) { System.out.println(ruleName); } rule "drools keyword in method call" when then printRuleName(drools.getRule().getName()); end {noformat} The example works fine when compiling without executable model. > With executable model drools keyword is not found when used in a method call > ---------------------------------------------------------------------------- > > Key: DROOLS-5215 > URL: https://issues.redhat.com/browse/DROOLS-5215 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.35.0.Final > Reporter: Matteo Casalino > Assignee: Mario Fusco > Priority: Major > Attachments: drools-keyword-in-method-call.zip > > > Executable model rule compilation fails on rule consequents using the _drools_ keyword as a parameter of a method call. > Example of DRL that fails to compile: > {noformat} > function printRuleName(String ruleName) { > System.out.println(ruleName); > } > > rule "drools keyword in method call" > when > then > printRuleName(drools.getRule().getName()); > end > {noformat} > The example works fine when compiling without executable model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5215) With executable model drools keyword is not found when used in a method call

by Matteo Casalino (Jira)

Matteo Casalino created DROOLS-5215: --------------------------------------- Summary: With executable model drools keyword is not found when used in a method call Key: DROOLS-5215 URL: https://issues.redhat.com/browse/DROOLS-5215 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.35.0.Final Reporter: Matteo Casalino Assignee: Mario Fusco Attachments: drools-keyword-in-method-call.zip Executable model rule compilation fails on rule consequents using the _drools _ keyword as a parameter of a method call. Example of DRL that fails to compile: {noformat} function printRuleName(String ruleName) { System.out.println(ruleName); } rule "drools keyword in method call" when then printRuleName(drools.getRule().getName()); end {noformat} The example works fine when compiling without executable model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5214) Executable model compilation fails with constraints containing static method calls

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5214?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5214: -------------------------------- Sprint: 2020 Week 13-15 (from Mar 23) > Executable model compilation fails with constraints containing static method calls > ---------------------------------------------------------------------------------- > > Key: DROOLS-5214 > URL: https://issues.redhat.com/browse/DROOLS-5214 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.35.0.Final > Reporter: Matteo Casalino > Assignee: Mario Fusco > Priority: Major > Attachments: static-methods-in-contraint.zip > > > Executable model rule compilation fails on patterns containing Java static method calls as constraints > Example of DRL that fails to compile: > {noformat} > rule "Array asList" > when Pojo(java.util.Arrays.asList(1,5,2,3).containsAll(integerList)) > then > end > {noformat} > or > {noformat} > rule "collections disjoint" > when $p : Pojo($boundList : integerList) Pojo(id > $p.id, !java.util.Collections.disjoint( integerList , $boundList )) > then > end > {noformat} > or > {noformat} > rule "containsAll" > when Pojo(integerList.containsAll(java.util.Arrays.asList(1,3)), integerList.size() == 2) > then > end > {noformat} > All above examples work fine when compiling without executable model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10554) OpenSAML 3.3.0 complains for missing class from "metrics-core"

by Jim Ma (Jira)

[ https://issues.redhat.com/browse/WFLY-10554?page=com.atlassian.jira.plugi... ] Jim Ma commented on WFLY-10554: ------------------------------- [~rady66] Missed your comment and sorry for very late reply. The reason I suggested to create your own opensaml module is opensmal is private module as you already noticed. It means this module is : {quote}Intended for internal use only. Only tested according to internal usage. May not be safe for end user applications to use directly.Could change significantly or be removed in a future release without notice.(From https://docs.wildfly.org/19/Developer_Guide.html#the-jboss.api-property-a... Given opensaml works for wss4j and Wildfly without dropwizard dependency(we have widlfly and jbossws tests to verify this), dropwizard can be optional for opensaml functionality. I'll try to talk with opensaml developer to see if this is the case and anything can be improved there. If missing dropwizard makes opensaml error prone, I'll definitely go to add it in opensaml module. In the mean time , can you please give us some lines of example code for the opensaml usage in your application to better understand this ? > OpenSAML 3.3.0 complains for missing class from "metrics-core" > -------------------------------------------------------------- > > Key: WFLY-10554 > URL: https://issues.redhat.com/browse/WFLY-10554 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 13.0.0.Final > Reporter: Radoslav Ivanov > Assignee: Jim Ma > Priority: Major > Fix For: 19.0.1.Final > > Attachments: screenshot-1.png > > > Module OpenSAML 3.3.0 requires depedency to module "io.dropwizard.metrics:metrics-core" but it does not present. As a result ClassNotFoundException is thrown. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5214) Executable model compilation fails with constraints containing static method calls

by Matteo Casalino (Jira)

Matteo Casalino created DROOLS-5214: --------------------------------------- Summary: Executable model compilation fails with constraints containing static method calls Key: DROOLS-5214 URL: https://issues.redhat.com/browse/DROOLS-5214 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.35.0.Final Reporter: Matteo Casalino Assignee: Mario Fusco Attachments: static-methods-in-contraint.zip Executable model rule compilation fails on patterns containing Java static method calls as constraints Example of DRL that fails to compile: {noformat} rule "Array asList" when Pojo(java.util.Arrays.asList(1,5,2,3).containsAll(integerList)) then end {noformat} or {noformat} rule "collections disjoint" when $p : Pojo($boundList : integerList) Pojo(id > $p.id, !java.util.Collections.disjoint( integerList , $boundList )) then end {noformat} or {noformat} rule "containsAll" when Pojo(integerList.containsAll(java.util.Arrays.asList(1,3)), integerList.size() == 2) then end {noformat} All above examples work fine when compiling without executable model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11565) WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-11565?page=com.atlassian.jira.plugi... ] Bartosz Baranowski resolved WFLY-11565. --------------------------------------- Resolution: Out of Date > WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204 > ------------------------------------------------------------------------------------------- > > Key: WFLY-11565 > URL: https://issues.redhat.com/browse/WFLY-11565 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.0.Final > Reporter: Deepak Sahu > Assignee: Bartosz Baranowski > Priority: Major > Attachments: API.war > > > I am using WildFly Server 9.0.0 Final, Javax ws, Jersey for developing Rest APIs. For all the responses whose httpStatus code is 204, the wildfly server adds Transfer encoding Chunked in the response header, which is not correct as per the Rest Standards. Because of this behavior some of the RestAPI clients hang, as they keep waiting for the response (which is not at all there). > To verify the issue, I tried the same with Springboot instead of deploying the war in WildFly and the Response Header was not added with Transfer Encoding Chuncked. > Let me know if some other information is required to fix this issue, if this is already fixed is there any patch for this issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5198) Infinite loop induced by backward chaining

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5198?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5198: -------------------------------- Sprint: (was: 2020 Week 13-15 (from Mar 23)) > Infinite loop induced by backward chaining > ------------------------------------------ > > Key: DROOLS-5198 > URL: https://issues.redhat.com/browse/DROOLS-5198 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.34.0.Final > Reporter: Ivan Zilotti > Assignee: Mario Fusco > Priority: Major > > I could not find an out-of-the-box mechanism in Drools for stopping loops induced by backward chaining. I've found some research e.g., [Avoiding Infinite Loops in Rule-Based Systems with Backward Chaining|http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.38.8356...], indicating this is a recurring problem. > When undeterred, these loops cause an OutOfMemoryError. > I've already tried to: > * Find configuration options in Drools to limit the behavior, but apparently there are't any; > * Step through the code, trying to find ways to break the recursive behavior; > * Change my rules to check for possible loops but that resulted either in partial facts being added to working memory (WM) or computationally expensive logic. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5213) OOPath: cannot use ! in constraint with a boolean function

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5213?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5213: -------------------------------- Sprint: 2020 Week 13-15 (from Mar 23) > OOPath: cannot use ! in constraint with a boolean function > ---------------------------------------------------------- > > Key: DROOLS-5213 > URL: https://issues.redhat.com/browse/DROOLS-5213 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Edoardo Vacchi > Assignee: Mario Fusco > Priority: Major > Labels: drools-core > > reproducer: > https://github.com/evacchi/kogito-examples/blob/oopath-bug-not/onboarding... > build the subproject -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5180) Kie-scanner update container API doesn't refresh container with latest jar after new year

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5180?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-5180. --------------------------------- Resolution: Explained Your versioning scheme breaks the lexicographic order. To clarify, in your example the version number {code} 10.23.2019-06-30-00 {code} comes lexicographically AFTER than {code} 04.02.2020-15-00-04 {code} and that's why maven (and then the kie-server) doesn't recognize the second as a newer version. If you want to use the date as version number use the format YYYY.MM.DD instead of the current DD.MM.YYYY and this should fix the problem. > Kie-scanner update container API doesn't refresh container with latest jar after new year > ----------------------------------------------------------------------------------------- > > Key: DROOLS-5180 > URL: https://issues.redhat.com/browse/DROOLS-5180 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.18.0.Final > Reporter: Minal Bhalodi > Assignee: Mario Fusco > Priority: Critical > > We are using kie-server as a stand alone application. we use kie scanner to update kie container when there is a new DRL file in our .m2 folder. > we don't have scanner polling but we use Scanner update container API to update kie container. > Every year when date changes after new year, we are facing issue where kie scanner is not able to update container with latest jar in m2 with new year date. > When we check the container version it shows latest with new year date but internally kie is still using old jar. > We fixed this issue with create container API instead update container. > kie-server-spring-boot-starter-drools :7.18.0.Final > Please let me know if this issue is already fixed or discussed before or if you need more details. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13336) Add a "Smoke" JWT test case to use as a basis for further tests.

by Ingo Weiss (Jira)

Ingo Weiss created WFLY-13336: --------------------------------- Summary: Add a "Smoke" JWT test case to use as a basis for further tests. Key: WFLY-13336 URL: https://issues.redhat.com/browse/WFLY-13336 Project: WildFly Issue Type: Task Components: MP JWT, Test Suite Reporter: Ingo Weiss Assignee: Darran Lofthouse Fix For: 19.0.1.Final, 20.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020