[JBoss JIRA] (DROOLS-3653) Unexpected node sharing by function with equals
by Toshiya Kobayashi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3653?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi commented on DROOLS-3653:
-------------------------------------------
Sent a unit test PR
https://github.com/kiegroup/drools/pull/2255
> Unexpected node sharing by function with equals
> -----------------------------------------------
>
> Key: DROOLS-3653
> URL: https://issues.jboss.org/browse/DROOLS-3653
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.17.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
>
> Under the condition:
> - LHS has a constraint which calls a function
> - The function's argument contains "=="
> - The constraint itself uses "==" for comparison
> So the rules look like this:
> {noformat}
> package com.sample
> import org.drools.compiler.Person;
> function int myFunction(String expression, int value) {
> if (expression.equals("param == 10") && value == 10) {
> return 1;
> }
> return 0;
> }
> rule R1
> when
> $p: Person(myFunction("param == 10", age) == 1)
> then
> end
> rule R2
> when
> $p: Person(myFunction("param == 20", age) == 1)
> then
> end
> {noformat}
> In this case, AlphaNodes are shared so both rules match against a fact which should match only R1 (Person(age = 10)).
> Dump by ReteDumper
> {noformat}
> [EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
> [ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
> [ObjectTypeNode(3)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.compiler.Person] expiration=-1ms ] on Partition(MAIN)
> [AlphaNode(4) constraint=myFunction("param == 10", age) == 1] on Partition(1) d 0 i 0
> [LeftInputAdapterNode(5)] on Partition(1) Ld 0 Li 0
> [RuleTerminalNode(6): rule=R1] on Partition(1) d 0 i 0
> [RuleTerminalNode(7): rule=R2] on Partition(1) d 0 i 0
> {noformat}
> It seems to relate to MvelConstraint.equals() logic. (It doesn't take account of the text between "==" and "==")
> https://github.com/kiegroup/drools/blob/master/drools-core/src/main/java/...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (DROOLS-3653) Unexpected node sharing by function with equals
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-3653:
-----------------------------------------
Summary: Unexpected node sharing by function with equals
Key: DROOLS-3653
URL: https://issues.jboss.org/browse/DROOLS-3653
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.17.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
Under the condition:
- LHS has a constraint which calls a function
- The function's argument contains "=="
- The constraint itself uses "==" for comparison
So the rules look like this:
{noformat}
package com.sample
import org.drools.compiler.Person;
function int myFunction(String expression, int value) {
if (expression.equals("param == 10") && value == 10) {
return 1;
}
return 0;
}
rule R1
when
$p: Person(myFunction("param == 10", age) == 1)
then
end
rule R2
when
$p: Person(myFunction("param == 20", age) == 1)
then
end
{noformat}
In this case, AlphaNodes are shared so both rules match against a fact which should match only R1 (Person(age = 10)).
Dump by ReteDumper
{noformat}
[EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
[ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
[ObjectTypeNode(3)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.compiler.Person] expiration=-1ms ] on Partition(MAIN)
[AlphaNode(4) constraint=myFunction("param == 10", age) == 1] on Partition(1) d 0 i 0
[LeftInputAdapterNode(5)] on Partition(1) Ld 0 Li 0
[RuleTerminalNode(6): rule=R1] on Partition(1) d 0 i 0
[RuleTerminalNode(7): rule=R2] on Partition(1) d 0 i 0
{noformat}
It seems to relate to MvelConstraint.equals() logic. (It doesn't take account of the text between "==" and "==")
https://github.com/kiegroup/drools/blob/master/drools-core/src/main/java/...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (DROOLS-3519) [DMN Designer] Data Types - Constraints - Change the "Placeholder" accordingly to the type
by Guilherme Carreiro (Jira)
[ https://issues.jboss.org/browse/DROOLS-3519?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro updated DROOLS-3519:
---------------------------------------
Summary: [DMN Designer] Data Types - Constraints - Change the "Placeholder" accordingly to the type (was: [DMN Designer] Data Types - Constraints - Change the "Placeholder" accordingly to the type (for Enumeration and Expression component))
> [DMN Designer] Data Types - Constraints - Change the "Placeholder" accordingly to the type
> ------------------------------------------------------------------------------------------
>
> Key: DROOLS-3519
> URL: https://issues.jboss.org/browse/DROOLS-3519
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Priority: Major
> Labels: drools-tools
> Attachments: DROOLS-3519.png
>
>
> Currently, the _Syntax tip_ is a fixed text that considers that the user selected the {{Date}} type, however, when the user changes the type, the _Syntax tip_ should change too.
> !DROOLS-3519.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (DROOLS-3519) [DMN Designer] Data Types - Constraints - Change the "Placeholder" accordingly to the type (for Enumeration and Expression component)
by Guilherme Carreiro (Jira)
[ https://issues.jboss.org/browse/DROOLS-3519?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro updated DROOLS-3519:
---------------------------------------
Summary: [DMN Designer] Data Types - Constraints - Change the "Placeholder" accordingly to the type (for Enumeration and Expression component) (was: [DMN Designer] Data Types - Constraints - Change the "Syntax tip" accordingly to the type (for Enumeration and Expression component))
> [DMN Designer] Data Types - Constraints - Change the "Placeholder" accordingly to the type (for Enumeration and Expression component)
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-3519
> URL: https://issues.jboss.org/browse/DROOLS-3519
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Priority: Major
> Labels: drools-tools
> Attachments: DROOLS-3519.png
>
>
> Currently, the _Syntax tip_ is a fixed text that considers that the user selected the {{Date}} type, however, when the user changes the type, the _Syntax tip_ should change too.
> !DROOLS-3519.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFLY-11716) Deployment Fails with @Transactional in Passivating Scope Bean
by Cody Lerum (Jira)
[ https://issues.jboss.org/browse/WFLY-11716?page=com.atlassian.jira.plugin... ]
Cody Lerum updated WFLY-11716:
------------------------------
Environment: Java 8, Ubuntu Xenial
> Deployment Fails with @Transactional in Passivating Scope Bean
> --------------------------------------------------------------
>
> Key: WFLY-11716
> URL: https://issues.jboss.org/browse/WFLY-11716
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 16.0.0.Beta1
> Environment: Java 8, Ubuntu Xenial
> Reporter: Cody Lerum
> Assignee: Brian Stansberry
> Priority: Major
>
> On Wildfly 16.0.0.Beta1 deployment fails
> {code}
> org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean@12e2cb9f
> at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480)
> at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFLY-11716) Deployment Fails with @Transactional in Passivating Scope Bean
by Cody Lerum (Jira)
[ https://issues.jboss.org/browse/WFLY-11716?page=com.atlassian.jira.plugin... ]
Cody Lerum commented on WFLY-11716:
-----------------------------------
To clarify this is an application that deploys fine on 14.0.1.Final.
> Deployment Fails with @Transactional in Passivating Scope Bean
> --------------------------------------------------------------
>
> Key: WFLY-11716
> URL: https://issues.jboss.org/browse/WFLY-11716
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 16.0.0.Beta1
> Reporter: Cody Lerum
> Assignee: Brian Stansberry
> Priority: Major
>
> On Wildfly 16.0.0.Beta1 deployment fails
> {code}
> org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean@12e2cb9f
> at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480)
> at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFLY-11716) Deployment Fails with @Transactional in Passivating Scope Bean
by Cody Lerum (Jira)
Cody Lerum created WFLY-11716:
---------------------------------
Summary: Deployment Fails with @Transactional in Passivating Scope Bean
Key: WFLY-11716
URL: https://issues.jboss.org/browse/WFLY-11716
Project: WildFly
Issue Type: Bug
Affects Versions: 16.0.0.Beta1
Reporter: Cody Lerum
Assignee: Brian Stansberry
On Wildfly 16.0.0.Beta1 deployment fails
{code}
org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean@12e2cb9f
at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480)
at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFLY-11641) Layers for servlet and full galleon feature-packs
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11641?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11641:
------------------------------------
Issue Type: Feature Request (was: Enhancement)
> Layers for servlet and full galleon feature-packs
> -------------------------------------------------
>
> Key: WFLY-11641
> URL: https://issues.jboss.org/browse/WFLY-11641
> Project: WildFly
> Issue Type: Feature Request
> Components: Build System
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Priority: Major
> Fix For: 16.0.0.Beta1
>
>
> In order to take benefit from galleon layers feature, the servlet and full galleon feature-packs should define layers that could then be used to build custom installation. The layers are not intended to be exposed as a public contract, they are an implementation detail allowing for internal custom provisioning.
> Only standalone configurations are impacted by layers.
> We are proposing:
> 1) Define a set of servlet layers:
> ee
> legacy-security
> naming
> undertow
> undertow-load-balancer
> vault
> web-server (complete servlet container)
> 2) Express the servlet default standalone configurations by a set of layers. The default configuration based on layers would be identical to the current one (based on feature-groups). feature-groups are the place where feature configuration occurs, layers are referencing feature-groups. The default configuration extends layers with legacy security aspects and undertow welcome content.
> 3) Define a first set of full layers that target standalone kind of configurations.
> List of layers, layers defined in this feature-pack depend at least on web-server servlet layer.
> cdi
> h2-database
> jaxrs
> jms-activemq
> jpa
> microprofile
> resource-adapters
> 4) Some servlet layers are extended to include packages present in full feature-pack:
> ee
> undertow
> vault
> 5) Cloud profile layer
> cloud-profile (aggregation layer of cdi, jaxrs, jms-activemq,jpa,microprofile,resource-adapters)
> 6) Resource management API is used to advertise modules injected in deployment units. Impacted subsystems: ee, security, connector, microprofile, jpa, jaxrs, weld, bean-validation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-1598:
----------------------------------------
This seems like a Feature Request, not an Enhancement, and not a subtask any more as the parent is closed.
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Management, Security
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 16.0.0.CR1
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3947:
-------------------------------------
Priority: Major (was: Critical)
> Support SSL Certificate revocation using OCSP
> ---------------------------------------------
>
> Key: WFCORE-3947
> URL: https://issues.jboss.org/browse/WFCORE-3947
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 6.0.0.Alpha2
> Reporter: Jan Kalina
> Assignee: Martin Mazanek
> Priority: Major
> Fix For: 8.0.0.Beta6
>
>
> - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP.
> (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months