[JBoss JIRA] (WFLY-12770) Quickstart for MP Fault Tolerance
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12770?page=com.atlassian.jira.plugin... ]
Radoslav Husar moved EAP7-1382 to WFLY-12770:
---------------------------------------------
Project: WildFly (was: EAP 7 Planning Pilot)
Key: WFLY-12770 (was: EAP7-1382)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0)
Component/s: Quickstarts
(was: MicroProfile)
(was: Quickstarts)
EAP PT Pre-Checked (PC): (was: TODO)
Target Release: (was: 7.4.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)
> Quickstart for MP Fault Tolerance
> ---------------------------------
>
> Key: WFLY-12770
> URL: https://issues.jboss.org/browse/WFLY-12770
> Project: WildFly
> Issue Type: Feature Request
> Components: Quickstarts
> Reporter: Radoslav Husar
> Assignee: Martin Stefanko
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2395) LOCAL_PING fails when 2 nodes start at the same time
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2395?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2395.
----------------------------
Resolution: Done
> LOCAL_PING fails when 2 nodes start at the same time
> ----------------------------------------------------
>
> Key: JGRP-2395
> URL: https://issues.jboss.org/browse/JGRP-2395
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.6
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.8
>
>
> We have a test that starts 2 nodes in parallel ({{ConcurrentStartTest}} and it is randomly failing since we started using {{LOCAL_PING}}.
> {noformat}
> 01:02:11,930 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 3 ms, members: 1 rsps (0 coords) [done]
> 01:02:11,930 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: discovery took 3 ms, members: 1 rsps (0 coords) [done]
> 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: I (Test-NodeB-43694) am the first of the nodes, will become coordinator
> 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator
> 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 0 ms, members: 1 rsps (0 coords) [done]
> 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> ...
> 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator
> 01:02:11,942 WARN (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: too many JOIN attempts (10): becoming singleton
> 01:02:11,942 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: installing view [Test-NodeA-29550|0] (1) [Test-NodeA-29550]
> 01:02:11,977 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: created cluster (first member). My view is [Test-NodeB-43694|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> 01:02:11,977 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: created cluster (first member). My view is [Test-NodeA-29550|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> The problem seems to be that it takes longer for the coordinator to install the initial view and update {{LOCAL_PING}}'s {{PingData}} then it takes the other node to retry the discovery process 10 times.
> In some cases there is no retry, because one node starts slightly faster, but it's not yet coordinator when the 2nd node does its discovery, and both nodes decide they should be coordinator:
> {noformat}
> 01:13:44,460 INFO (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: no members discovered after 3 ms: creating cluster as first member
> 01:13:44,463 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: discovery took 1 ms, members: 1 rsps (0 coords) [done]
> 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: nodes to choose new coord from are: [Test-NodeB-51165, Test-NodeA-5386]
> 01:13:44,466 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: I (Test-NodeB-51165) am the first of the nodes, will become coordinator
> 01:13:44,466 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: installing view [Test-NodeB-51165|0] (1) [Test-NodeB-51165]
> 01:13:44,466 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: installing view [Test-NodeA-5386|0] (1) [Test-NodeA-5386]
> {noformat}
> This second failure mode seems to go away if I move the {{discovery}} map access inside the {{synchronized}} block both in {{findMembers()}} and in {{down()}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2395) LOCAL_PING fails when 2 nodes start at the same time
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2395?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2395:
--------------------------------
OK, so I fixed both SHARED_LOOPBACK/SHARED_LOOPBACK_PING and LOCAL_PING to adopt the above scheme.
Committed to master. Let me know if this works, so I can release 4.1.8.
Cheers,
> LOCAL_PING fails when 2 nodes start at the same time
> ----------------------------------------------------
>
> Key: JGRP-2395
> URL: https://issues.jboss.org/browse/JGRP-2395
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.6
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.8
>
>
> We have a test that starts 2 nodes in parallel ({{ConcurrentStartTest}} and it is randomly failing since we started using {{LOCAL_PING}}.
> {noformat}
> 01:02:11,930 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 3 ms, members: 1 rsps (0 coords) [done]
> 01:02:11,930 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: discovery took 3 ms, members: 1 rsps (0 coords) [done]
> 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: I (Test-NodeB-43694) am the first of the nodes, will become coordinator
> 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator
> 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 0 ms, members: 1 rsps (0 coords) [done]
> 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> ...
> 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
> 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator
> 01:02:11,942 WARN (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: too many JOIN attempts (10): becoming singleton
> 01:02:11,942 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: installing view [Test-NodeA-29550|0] (1) [Test-NodeA-29550]
> 01:02:11,977 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: created cluster (first member). My view is [Test-NodeB-43694|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> 01:02:11,977 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: created cluster (first member). My view is [Test-NodeA-29550|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> The problem seems to be that it takes longer for the coordinator to install the initial view and update {{LOCAL_PING}}'s {{PingData}} then it takes the other node to retry the discovery process 10 times.
> In some cases there is no retry, because one node starts slightly faster, but it's not yet coordinator when the 2nd node does its discovery, and both nodes decide they should be coordinator:
> {noformat}
> 01:13:44,460 INFO (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: no members discovered after 3 ms: creating cluster as first member
> 01:13:44,463 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: discovery took 1 ms, members: 1 rsps (0 coords) [done]
> 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: could not determine coordinator from rsps 1 rsps (0 coords) [done]
> 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: nodes to choose new coord from are: [Test-NodeB-51165, Test-NodeA-5386]
> 01:13:44,466 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: I (Test-NodeB-51165) am the first of the nodes, will become coordinator
> 01:13:44,466 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: installing view [Test-NodeB-51165|0] (1) [Test-NodeB-51165]
> 01:13:44,466 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: installing view [Test-NodeA-5386|0] (1) [Test-NodeA-5386]
> {noformat}
> This second failure mode seems to go away if I move the {{discovery}} map access inside the {{synchronized}} block both in {{findMembers()}} and in {{down()}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12769) Make standalone.sh more classpath friendly
by Dominik Derwiński (Jira)
[ https://issues.jboss.org/browse/WFLY-12769?page=com.atlassian.jira.plugin... ]
Dominik Derwiński updated WFLY-12769:
-------------------------------------
Description:
Java 9+ no longer has jre/lib/ext, which was easiest way to add custom charset provider for use by JDBC data sources. The way to handle it now is to add charset jar on classpath or put it in app-specific lib/ext counterpart. It works well for apps like NetBeans or SquirrelSQL. I have found adding charset provider nearly impossible WildFly, which prevents migrating from Java 8 to 11, but a simple change to standalone.sh allows to solve that issue.
I have tried various approaches:
* classpath argument in JAVA_OPTS
* custom global module with services set to true
* JDBC driver module depending on custom module with services set to import
* JDBC driver module with charset jar as resource (along driver jar)
None of those method work. Finally I have found why the classpath argument doesn't work, it's because standalone.sh uses -jar option, which causes it to ignore classpath settings. By changing this line:
{noformat}
-jar \""$JBOSS_HOME"/jboss-modules.jar\" \
{noformat}
to
{noformat}
-cp \""$JBOSS_HOME"/jboss-modules.jar:"$JBOSS_BASE_DIR"/lib/ext/*\" org.jboss.modules.Main \
{noformat}
I was able to add charset jar on classpath by placing it in my profile/lib/ext directory.
Please consider changing this code in standalone.sh to make the standalone/lib/ext directory actually useful for something.
You may also try to investigate why isn't the charser provider loaded when using module approach. That might be some kind of bug.
was:
Java 9+ no longer has jre/lib/ext, which was easiest way to add custom charset provider for use by JDBC data sources. The way to handle it now is to add charset jar on classpath or put it in app-specific lib/ext counterpart. It works well for apps like NetBeans or SquirrelSQL. I have found adding charset provider nearly impossible WildFly, which prevents migrating from Java 8 to 11, but a simple change to standalone.sh allows to solve that issue.
I have tried other approaches:
* classpath argument in JAVA_OPTS
* custom global module with services set to true
* JDBC driver module depending on custom module with services set to import
* JDBC driver module with charset jar as resource (along driver jar)
None of those method work. Finally I have found why the classpath argument doesn't work, it's because standalone.sh uses -jar option, which causes it to ignore classpath settings. By changing this line:
{noformat}
-jar \""$JBOSS_HOME"/jboss-modules.jar\" \
{noformat}
to
{noformat}
-cp \""$JBOSS_HOME"/jboss-modules.jar:"$JBOSS_BASE_DIR"/lib/ext/*\" org.jboss.modules.Main \
{noformat}
I was able to add charset jar on classpath by placing it in my profile/lib/ext directory.
Please consider changing this code in standalone.sh to make the standalone/lib/ext directory actually useful for something.
You may also try to investigate why isn't the charser provider loaded when using module approach. That might be some kind of bug.
> Make standalone.sh more classpath friendly
> ------------------------------------------
>
> Key: WFLY-12769
> URL: https://issues.jboss.org/browse/WFLY-12769
> Project: WildFly
> Issue Type: Enhancement
> Components: Class Loading
> Affects Versions: 18.0.0.Final
> Reporter: Dominik Derwiński
> Assignee: Richard Opalka
> Priority: Minor
>
> Java 9+ no longer has jre/lib/ext, which was easiest way to add custom charset provider for use by JDBC data sources. The way to handle it now is to add charset jar on classpath or put it in app-specific lib/ext counterpart. It works well for apps like NetBeans or SquirrelSQL. I have found adding charset provider nearly impossible WildFly, which prevents migrating from Java 8 to 11, but a simple change to standalone.sh allows to solve that issue.
> I have tried various approaches:
> * classpath argument in JAVA_OPTS
> * custom global module with services set to true
> * JDBC driver module depending on custom module with services set to import
> * JDBC driver module with charset jar as resource (along driver jar)
> None of those method work. Finally I have found why the classpath argument doesn't work, it's because standalone.sh uses -jar option, which causes it to ignore classpath settings. By changing this line:
> {noformat}
> -jar \""$JBOSS_HOME"/jboss-modules.jar\" \
> {noformat}
> to
> {noformat}
> -cp \""$JBOSS_HOME"/jboss-modules.jar:"$JBOSS_BASE_DIR"/lib/ext/*\" org.jboss.modules.Main \
> {noformat}
> I was able to add charset jar on classpath by placing it in my profile/lib/ext directory.
> Please consider changing this code in standalone.sh to make the standalone/lib/ext directory actually useful for something.
> You may also try to investigate why isn't the charser provider loaded when using module approach. That might be some kind of bug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12769) Make standalone.sh more classpath friendly
by Dominik Derwiński (Jira)
Dominik Derwiński created WFLY-12769:
----------------------------------------
Summary: Make standalone.sh more classpath friendly
Key: WFLY-12769
URL: https://issues.jboss.org/browse/WFLY-12769
Project: WildFly
Issue Type: Enhancement
Components: Class Loading
Affects Versions: 18.0.0.Final
Reporter: Dominik Derwiński
Assignee: Richard Opalka
Java 9+ no longer has jre/lib/ext, which was easiest way to add custom charset provider for use by JDBC data sources. The way to handle it now is to add charset jar on classpath or put it in app-specific lib/ext counterpart. It works well for apps like NetBeans or SquirrelSQL. I have found adding charset provider nearly impossible WildFly, which prevents migrating from Java 8 to 11, but a simple change to standalone.sh allows to solve that issue.
I have tried other approaches:
* classpath argument in JAVA_OPTS
* custom global module with services set to true
* JDBC driver module depending on custom module with services set to import
* JDBC driver module with charset jar as resource (along driver jar)
None of those method work. Finally I have found why the classpath argument doesn't work, it's because standalone.sh uses -jar option, which causes it to ignore classpath settings. By changing this line:
{noformat}
-jar \""$JBOSS_HOME"/jboss-modules.jar\" \
{noformat}
to
{noformat}
-cp \""$JBOSS_HOME"/jboss-modules.jar:"$JBOSS_BASE_DIR"/lib/ext/*\" org.jboss.modules.Main \
{noformat}
I was able to add charset jar on classpath by placing it in my profile/lib/ext directory.
Please consider changing this code in standalone.sh to make the standalone/lib/ext directory actually useful for something.
You may also try to investigate why isn't the charser provider loaded when using module approach. That might be some kind of bug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4731) Working with Long field
by Pavel Tavoda (Jira)
[ https://issues.jboss.org/browse/DROOLS-4731?page=com.atlassian.jira.plugi... ]
Pavel Tavoda updated DROOLS-4731:
---------------------------------
Description:
Setting long field value in THEN:
This are 3 different problems:
1) package as kjar with 'mvn clean install' result in "Error: unable to resolve method using strict-mode: org.drools.core.spi.Activation.setValue(java.lang.Integer)"
RESULT:
IntInRuleJava.drl - FAIL
IntInRuleMvel.drl - FAIL
LongInRuleJava.drl - OK
LongInRuleMvel.drl - FAIL
LongError.gdst - FAIL
2) package as kjar with 'mvn clean install -Ddrools.dialect.mvel.strict=false', same error on different files:
IntInRuleJava.drl - FAIL
IntInRuleMvel.drl - OK
LongInRuleJava.drl - OK
LongInRuleMvel.drl - OK
LongError.gdst - OK
3) with 'mvn clean install -DgenerateModel=YES' it result in 'incompatible types: int cannot be converted to java.lang.Long', setting strict false have no influence on result
IntInRuleJava.drl - FAIL
IntInRuleMvel.drl - FAIL
LongInRuleJava.drl - OK
LongInRuleMvel.drl - OK
LongError.gdst - FAIL
Setting 'drools.dialect.mvel.strict' in kmodule.xml doesn't work.
Example project attached.
was:
Setting long field value in THEN:
This are two problems:
1) package as kjar 'mvn clean install' result in "Error: unable to resolve method using strict-mode: org.drools.core.spi.Activation.setValue(java.lang.Integer)"
RESULT:
IntInRuleJava.drl - FAIL
IntInRuleMvel.drl - FAIL
LongInRuleJava.drl - OK
LongInRuleMvel.drl - FAIL
LongError.gdst - FAIL
2) with 'mvn clean install -DgenerateModel=YES' it result in 'incompatible types: int cannot be converted to java.lang.Long'
IntInRuleJava.drl - FAIL
IntInRuleMvel.drl - FAIL
LongInRuleJava.drl - OK
LongInRuleMvel.drl - OK
LongError.gdst - FAIL
I don't know how to turn off strict mode for maven plugin. Setting 'drools.dialect.mvel.strict' in kmodule.xml doesn't work.
Example project attached.
> Working with Long field
> -----------------------
>
> Key: DROOLS-4731
> URL: https://issues.jboss.org/browse/DROOLS-4731
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.28.0.Final
> Reporter: Pavel Tavoda
> Assignee: Mario Fusco
> Priority: Major
> Attachments: error-with-long.zip
>
>
> Setting long field value in THEN:
> This are 3 different problems:
> 1) package as kjar with 'mvn clean install' result in "Error: unable to resolve method using strict-mode: org.drools.core.spi.Activation.setValue(java.lang.Integer)"
> RESULT:
> IntInRuleJava.drl - FAIL
> IntInRuleMvel.drl - FAIL
> LongInRuleJava.drl - OK
> LongInRuleMvel.drl - FAIL
> LongError.gdst - FAIL
> 2) package as kjar with 'mvn clean install -Ddrools.dialect.mvel.strict=false', same error on different files:
> IntInRuleJava.drl - FAIL
> IntInRuleMvel.drl - OK
> LongInRuleJava.drl - OK
> LongInRuleMvel.drl - OK
> LongError.gdst - OK
> 3) with 'mvn clean install -DgenerateModel=YES' it result in 'incompatible types: int cannot be converted to java.lang.Long', setting strict false have no influence on result
> IntInRuleJava.drl - FAIL
> IntInRuleMvel.drl - FAIL
> LongInRuleJava.drl - OK
> LongInRuleMvel.drl - OK
> LongError.gdst - FAIL
> Setting 'drools.dialect.mvel.strict' in kmodule.xml doesn't work.
> Example project attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months