[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)
4 years, 5 months
[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)
4 years, 5 months
[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)
4 years, 5 months
[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)
4 years, 5 months
[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)
4 years, 5 months
[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)
4 years, 5 months
[JBoss JIRA] (WFLY-13381) Unable to disable security on EJB over Http endpoint
by Flavia Rainone (Jira)
Flavia Rainone created WFLY-13381:
-------------------------------------
Summary: Unable to disable security on EJB over Http endpoint
Key: WFLY-13381
URL: https://issues.redhat.com/browse/WFLY-13381
Project: WildFly
Issue Type: Bug
Reporter: Flavia Rainone
Assignee: Flavia Rainone
For EJB over remote+http / http-remoting , removing the security-realm from the http-connector disables security and allows any remote client to connect to the endpoint without authenticating.
{code}
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
</subsystem>
{code}
For EJB over Http it goes over the http-invoker in undertow, removing the ApplicationRealm
{code}
<subsystem xmlns="urn:jboss:domain:undertow:7.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
...
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<http-invoker security-realm="ApplicationRealm"/>
</host>
</server>
{code}
It fails with:
{code}
18:10:16,660 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: EJB Invocation failed on component Hello for method public abstract java.lang.String com.jboss.examples.ejb.Hello.sayHello(java.lang.String): java.lang.IllegalArgumentException: Parameter 'identity' may not be null
at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:71)
at org.wildfly.common.Assert.checkNotNullParam(Assert.java:49)
at org.wildfly.security.auth.server.SecurityDomain.forIdentity(SecurityDomain.java:187)
at org.jboss.as.security.service.SimpleSecurityManager.push(SimpleSecurityManager.java:313)
at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:52)
at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:49)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:97)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:556)
at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:537)
at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:195)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (DROOLS-5243) [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header
by Guilherme Gomes (Jira)
[ https://issues.redhat.com/browse/DROOLS-5243?page=com.atlassian.jira.plug... ]
Guilherme Gomes updated DROOLS-5243:
------------------------------------
Description:
Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*:
!bug.gif|width=600!
However, users can insert new output columns by using regular table cells. See the *workaround*:
!workaround.gif|width=600!
was:
Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*:
!bug.gif|width=600!
However, users are able to insert new columns by using regular table cells. See the *workaround*:
!workaround.gif|width=600!
> [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header
> -----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5243
> URL: https://issues.redhat.com/browse/DROOLS-5243
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Daniel José dos Santos
> Priority: Critical
> Labels: drools-tools
> Attachments: bug.gif, workaround.gif
>
>
> Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*:
> !bug.gif|width=600!
> However, users can insert new output columns by using regular table cells. See the *workaround*:
> !workaround.gif|width=600!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by James Perkins (Jira)
[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGMGR-263:
---------------------------------
Fix Version/s: 2.1.15.Final
2.2.0.Final
3.0.0.Final
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.redhat.com/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Assignee: James Perkins
> Priority: Critical
> Fix For: 2.1.15.Final, 2.2.0.Final, 3.0.0.Final
>
> Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, logger-demo.war, responsetimes.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months