[JBoss JIRA] (WFLY-13306) Deployment of empty war with 2.3 faces-config.xml fails
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-13306?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-13306:
-------------------------------------
Hi [~fjuma] are you working on this issue?
Thanks,
Parul Sharma
> Deployment of empty war with 2.3 faces-config.xml fails
> -------------------------------------------------------
>
> Key: WFLY-13306
> URL: https://issues.redhat.com/browse/WFLY-13306
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 19.0.0.Final
> Reporter: Wolfgang Knauf
> Assignee: Farah Juma
> Priority: Major
> Attachments: JsfSample.zip
>
>
> Attached sample is created from the archetype "wildfly-jakartaee-webapp-archetype" found at [https://github.com/wildfly/wildfly-archetypes/] (still 18.0, an update for WildFly 19.0 is currently in work). It is an empty project, the only change is that in "faces-config.xml" the version was changed from 2.2 to 2.3.
> Deployment fails with this exception:
> {quote}
> 2020-03-30 20:05:45,200 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 83) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:357)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:205)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:217)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Unknown Source)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.NullPointerException
> at com.sun.faces.facelets.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:40)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.init(DefaultFaceletFactory.java:129)
> at com.sun.faces.application.ApplicationAssociate.createFaceletFactory(ApplicationAssociate.java:849)
> at com.sun.faces.application.ApplicationAssociate.initializeFacelets(ApplicationAssociate.java:342)
> at com.sun.faces.application.ApplicationAssociate.getCompiler(ApplicationAssociate.java:420)
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:217)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:341)
> ... 23 more
> 2020-03-30 20:05:45,207 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 83) MSC000001: Failed to start service jboss.deployment.unit."JsfSample.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."JsfSample.war".undertow-deployment: java.lang.RuntimeException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Unknown Source)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:254)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> ... 8 more
> Caused by: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:283)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:217)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
> ... 10 more
> Caused by: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:357)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:205)
> ... 22 more
> Caused by: java.lang.NullPointerException
> at com.sun.faces.facelets.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:40)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.init(DefaultFaceletFactory.java:129)
> at com.sun.faces.application.ApplicationAssociate.createFaceletFactory(ApplicationAssociate.java:849)
> at com.sun.faces.application.ApplicationAssociate.initializeFacelets(ApplicationAssociate.java:342)
> at com.sun.faces.application.ApplicationAssociate.getCompiler(ApplicationAssociate.java:420)
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:217)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:341)
> ... 23 more
> {quote}
> When adding an empty "beans.xml" file or any CDI annotated class, the error disappears.
> It also works when declaring JSF version 2.2.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5237) Wrong property reactivity with non getter chain of non-direct statements
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5237?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5237:
--------------------------------------
Description:
DROOLS-5025 solves a case like this by excluding getter property from property reactivity mask.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name = " + $p.getName());
modify($p) { setAge(41) };
end
{noformat}
However, there are still some cases which cause unexpected property reactivity.
For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name.length = " + $p.getName().length());
modify($p) { setAge(41) };
end
{noformat}
update() without modify block has the same issue.
In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
was:
DROOLS-5025 solves a case like this by exclude getter property from property reactivity mask.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name = " + $p.getName());
modify($p) { setAge(41) };
end
{noformat}
However, there are still some cases which cause unexpected property reactivity.
For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name.length = " + $p.getName().length());
modify($p) { setAge(41) };
end
{noformat}
update() without modify block has the same issue.
In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
> Wrong property reactivity with non getter chain of non-direct statements
> ------------------------------------------------------------------------
>
> Key: DROOLS-5237
> URL: https://issues.redhat.com/browse/DROOLS-5237
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> DROOLS-5025 solves a case like this by excluding getter property from property reactivity mask.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name = " + $p.getName());
> modify($p) { setAge(41) };
> end
> {noformat}
> However, there are still some cases which cause unexpected property reactivity.
> For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name.length = " + $p.getName().length());
> modify($p) { setAge(41) };
> end
> {noformat}
> update() without modify block has the same issue.
> In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
> However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5237) Wrong property reactivity with non getter chain of non-direct statements
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5237?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5237:
--------------------------------------
Description:
DROOLS-5025 solved a case like this by excluding getter property from property reactivity mask.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name = " + $p.getName());
modify($p) { setAge(41) };
end
{noformat}
However, there are still some cases which cause unexpected property reactivity.
For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name.length = " + $p.getName().length());
modify($p) { setAge(41) };
end
{noformat}
update() without modify block has the same issue.
In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
was:
DROOLS-5025 solves a case like this by excluding getter property from property reactivity mask.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name = " + $p.getName());
modify($p) { setAge(41) };
end
{noformat}
However, there are still some cases which cause unexpected property reactivity.
For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name.length = " + $p.getName().length());
modify($p) { setAge(41) };
end
{noformat}
update() without modify block has the same issue.
In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
> Wrong property reactivity with non getter chain of non-direct statements
> ------------------------------------------------------------------------
>
> Key: DROOLS-5237
> URL: https://issues.redhat.com/browse/DROOLS-5237
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> DROOLS-5025 solved a case like this by excluding getter property from property reactivity mask.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name = " + $p.getName());
> modify($p) { setAge(41) };
> end
> {noformat}
> However, there are still some cases which cause unexpected property reactivity.
> For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name.length = " + $p.getName().length());
> modify($p) { setAge(41) };
> end
> {noformat}
> update() without modify block has the same issue.
> In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
> However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5237) Wrong property reactivity with non getter chain of non-direct statements
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5237?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5237:
--------------------------------------
Description:
DROOLS-5025 solves a case like this by exclude getter property from property reactivity mask.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name = " + $p.getName());
modify($p) { setAge(41) };
end
{noformat}
However, there are still some cases which cause unexpected property reactivity.
For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name.length = " + $p.getName().length());
modify($p) { setAge(41) };
end
{noformat}
update() without modify block has the same issue.
In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
was:
DROOLS-5025 solves a case like this by exclude getter property from property reactivity mask.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name = " + $p.getName());
modify($p) { setAge(41) };
end
{noformat}
However, there are still some cases which cause unexpected property reactivity.
For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name.length = " + $p.getName().length());
modify($p) { setAge(41) };
end
{noformat}
In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
> Wrong property reactivity with non getter chain of non-direct statements
> ------------------------------------------------------------------------
>
> Key: DROOLS-5237
> URL: https://issues.redhat.com/browse/DROOLS-5237
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> DROOLS-5025 solves a case like this by exclude getter property from property reactivity mask.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name = " + $p.getName());
> modify($p) { setAge(41) };
> end
> {noformat}
> However, there are still some cases which cause unexpected property reactivity.
> For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name.length = " + $p.getName().length());
> modify($p) { setAge(41) };
> end
> {noformat}
> update() without modify block has the same issue.
> In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
> However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5237) Wrong property reactivity with non getter chain of non-direct statements
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5237?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5237:
--------------------------------------
Summary: Wrong property reactivity with non getter chain of non-direct statements (was: Wrong property reactivity with non getter chain of argume)
> Wrong property reactivity with non getter chain of non-direct statements
> ------------------------------------------------------------------------
>
> Key: DROOLS-5237
> URL: https://issues.redhat.com/browse/DROOLS-5237
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> DROOLS-5025 solves a case like this by exclude getter property from property reactivity mask.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name = " + $p.getName());
> modify($p) { setAge(41) };
> end
> {noformat}
> However, there are still some cases which cause unexpected property reactivity.
> For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name.length = " + $p.getName().length());
> modify($p) { setAge(41) };
> end
> {noformat}
> In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
> However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5237) Wrong property reactivity with non getter chain of argume
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5237?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5237:
--------------------------------------
Description:
DROOLS-5025 solves a case like this by exclude getter property from property reactivity mask.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name = " + $p.getName());
modify($p) { setAge(41) };
end
{noformat}
However, there are still some cases which cause unexpected property reactivity.
For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name.length = " + $p.getName().length());
modify($p) { setAge(41) };
end
{noformat}
In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
was:
The rule below causes infinite loop with executable model because "name" is considered as modified property.
{noformat}
rule R1 when
$p : Person( name == "Mario" )
then
System.out.println("name.length = " + $p.getName().length());
modify($p) { setAge(41) };
end
{noformat}
In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified.
https://github.com/kiegroup/drools/blob/master/drools-compiler/src/main/j...
Executable model follows the approach in this commit:
https://github.com/kiegroup/drools/commit/fc924465437919d5b6bd99849ee595e...
but executable model evaluates method calls outside of modify block while standard-drl evaluates only inside modify block.
> Wrong property reactivity with non getter chain of argume
> ---------------------------------------------------------
>
> Key: DROOLS-5237
> URL: https://issues.redhat.com/browse/DROOLS-5237
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> DROOLS-5025 solves a case like this by exclude getter property from property reactivity mask.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name = " + $p.getName());
> modify($p) { setAge(41) };
> end
> {noformat}
> However, there are still some cases which cause unexpected property reactivity.
> For example, the rule below causes an infinite loop with executable model because "name" is considered as modified property.
> {noformat}
> rule R1 when
> $p : Person( name == "Mario" )
> then
> System.out.println("name.length = " + $p.getName().length());
> modify($p) { setAge(41) };
> end
> {noformat}
> In standard-drl (DialectUtil.parseModifiedProperties), "getter + otherMethod" chain is considered that the property is modified. So excutable model follows the same.
> However, executable model evaluates all method calls in RHS while standard-drl evaluates only direct statements like "setName("AAA");" or "getName().xxx();". executable model also should follow.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years