[Red Hat JIRA] (DROOLS-5937) Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL.
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5937?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-5937:
-------------------------------------------
Fixed by https://github.com/mvel/mvel/pull/257
Once drools consumes mvel 2.4.12+, this JIRA will be closed.
> Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL.
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5937
> URL: https://issues.redhat.com/browse/DROOLS-5937
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.48.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: support
> Attachments: reproducer_02801729_6_mvel.zip, reproducer_02801729_6e_6f.zip
>
>
> Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL (org.mvel2).
> When using MVEL.eval method, the result of "+=" operation is incorrect, and "-=", "*=", "/=" operations result in an error.
> - BigDecimal_type_property <op> Numeric_value (Initial value of $bus.weight is 12000B)
> -- $bus.weight += 1000 ==> 1000 // incorrect result
> -- $bus.weight -= 1000 ==> Error
> -- $bus.weight *= 1000 ==> Error
> -- $bus.weight /= 1000 ==> Error
> - BigDecimal_type_property <op> BigDecimal_value (Initial value of $bus.weight and bdv are 12000B and 1000B respectively)
> -- $bus.weight += bdv ==> 1000 // incorrect result
> -- $bus.weight -= bdv ==> Error
> -- $bus.weight *= bdv ==> Error
> -- $bus.weight /= bdv ==> Error
> When using MVEL.executeExpression method, the result of "+=" operation is correct, while "-=", "*=", "/=" operations cause an error.
> - BigDecimal_type_property <op> Numeric_value (Initial value of $bus.weight is 12000B)
> -- $bus.weight += 1000 ==> 13000 // correct
> -- $bus.weight -= 1000 ==> Error
> -- $bus.weight *= 1000 ==> Error
> -- $bus.weight /= 1000 ==> Error
> - BigDecimal_type_property <op> BigDecimal_value (Initial value of $bus.weight and bdv are 12000B and 1000B respectively)
> -- $bus.weight += bdv ==> 13000 // correct
> -- $bus.weight -= bdv ==> Error
> -- $bus.weight *= bdv ==> Error
> -- $bus.weight /= bdv ==> Error
> $bus.weight is a BigDecimal type property.
> MVEL library should return correct result for any operations above.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (DROOLS-5937) Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL.
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5937?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5937 at 1/11/21 9:00 PM:
--------------------------------------------------------------------
Fixed by https://github.com/mvel/mvel/commit/0f34afbd1a5f4b0b6c0c836e2c932eac3b6d9cce
Once drools consumes mvel 2.4.12+, this JIRA will be closed.
was (Author: tkobayashi):
Fixed by https://github.com/mvel/mvel/pull/257
Once drools consumes mvel 2.4.12+, this JIRA will be closed.
> Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL.
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5937
> URL: https://issues.redhat.com/browse/DROOLS-5937
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.48.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: support
> Attachments: reproducer_02801729_6_mvel.zip, reproducer_02801729_6e_6f.zip
>
>
> Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL (org.mvel2).
> When using MVEL.eval method, the result of "+=" operation is incorrect, and "-=", "*=", "/=" operations result in an error.
> - BigDecimal_type_property <op> Numeric_value (Initial value of $bus.weight is 12000B)
> -- $bus.weight += 1000 ==> 1000 // incorrect result
> -- $bus.weight -= 1000 ==> Error
> -- $bus.weight *= 1000 ==> Error
> -- $bus.weight /= 1000 ==> Error
> - BigDecimal_type_property <op> BigDecimal_value (Initial value of $bus.weight and bdv are 12000B and 1000B respectively)
> -- $bus.weight += bdv ==> 1000 // incorrect result
> -- $bus.weight -= bdv ==> Error
> -- $bus.weight *= bdv ==> Error
> -- $bus.weight /= bdv ==> Error
> When using MVEL.executeExpression method, the result of "+=" operation is correct, while "-=", "*=", "/=" operations cause an error.
> - BigDecimal_type_property <op> Numeric_value (Initial value of $bus.weight is 12000B)
> -- $bus.weight += 1000 ==> 13000 // correct
> -- $bus.weight -= 1000 ==> Error
> -- $bus.weight *= 1000 ==> Error
> -- $bus.weight /= 1000 ==> Error
> - BigDecimal_type_property <op> BigDecimal_value (Initial value of $bus.weight and bdv are 12000B and 1000B respectively)
> -- $bus.weight += bdv ==> 13000 // correct
> -- $bus.weight -= bdv ==> Error
> -- $bus.weight *= bdv ==> Error
> -- $bus.weight /= bdv ==> Error
> $bus.weight is a BigDecimal type property.
> MVEL library should return correct result for any operations above.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (DROOLS-5933) NullPointerException at ConstraintEvaluator.findPatternAndRequiredDeclaration() in accumulate with exec-model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5933?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-5933:
-------------------------------------------
Fixed by https://github.com/kiegroup/drools/commit/5f9a27a83fca99427383e722efaa803...
> NullPointerException at ConstraintEvaluator.findPatternAndRequiredDeclaration() in accumulate with exec-model
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5933
> URL: https://issues.redhat.com/browse/DROOLS-5933
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.48.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> With exec-model, a rule like this:
> {noformat}
> when
> Number( ) from accumulate (
> FactA( $valueA : value )
> and
> FactB( $valueB : value, eval($valueB.compareTo($valueA) <= 0) )
> ;max($valueB.intValue())
> )
> then
> {noformat}
> generates the following PATTERN_DSL:
> {code:java}
> org.drools.model.Rule rule = D.rule("org.drools.mvel.compiler",
> "r1").build(D.pattern(var_GENERATED_$pattern_Number$1$),
> D.accumulate(D.and(D.pattern(var_GENERATED_$pattern_FactA$2$).bind(var_$valueA,
> org.drools.mvel.compiler.P46.LambdaExtractor468EFEB3BE9EA6494C88709DE97051CB.INSTANCE,
> D.reactOn("value")),
> D.pattern(var_GENERATED_$pattern_FactB$3$).bind(var_6C0A578A2EA3D5A5C82ABB0FA0DE5C71,
> org.drools.mvel.compiler.P18.LambdaExtractor18D900ABC004631DF004CDA316CD34FD.INSTANCE,
> D.reactOn("value")).expr("A574527869CA97E0B100815026E8E8FA",
> var_$valueB,
> var_$valueA,
> org.drools.mvel.compiler.P3E.LambdaPredicate3E396A3A5FB9CCA4FC041866C27E4A3A.INSTANCE)),
> D.accFunction(org.drools.core.base.accumulators.IntegerMaxAccumulateFunction::new,
> var_6C0A578A2EA3D5A5C82ABB0FA0DE5C71).as(var_GENERATED_$pattern_Number$1$)),
> D.execute(org.drools.mvel.compiler.P97.LambdaConsequence97C360F7B2C85569E6224ABDE862C784.INSTANCE));
> {code}
> It misses bind() for var_$valueB. It results in NPE during kbase build.
> {noformat}
> java.lang.NullPointerException
> at org.drools.modelcompiler.constraints.ConstraintEvaluator.findPatternAndRequiredDeclaration(ConstraintEvaluator.java:97)
> at org.drools.modelcompiler.constraints.ConstraintEvaluator.<init>(ConstraintEvaluator.java:67)
> at org.drools.modelcompiler.KiePackagesBuilder.createSingleConstraint(KiePackagesBuilder.java:1064)
> at org.drools.modelcompiler.KiePackagesBuilder.createConstraint(KiePackagesBuilder.java:1049)
> at org.drools.modelcompiler.KiePackagesBuilder.addConstraintsToPattern(KiePackagesBuilder.java:1043)
> at org.drools.modelcompiler.KiePackagesBuilder.buildPattern(KiePackagesBuilder.java:730)
> at org.drools.modelcompiler.KiePackagesBuilder.recursivelyAddConditions(KiePackagesBuilder.java:624)
> at org.drools.modelcompiler.KiePackagesBuilder.buildAccumulate(KiePackagesBuilder.java:581)
> at org.drools.modelcompiler.KiePackagesBuilder.conditionToElement(KiePackagesBuilder.java:493)
> at org.drools.modelcompiler.KiePackagesBuilder.addSubConditions(KiePackagesBuilder.java:655)
> at org.drools.modelcompiler.KiePackagesBuilder.populateLHS(KiePackagesBuilder.java:449)
> at org.drools.modelcompiler.KiePackagesBuilder.compileRule(KiePackagesBuilder.java:249)
> at org.drools.modelcompiler.KiePackagesBuilder.build(KiePackagesBuilder.java:220)
> at org.drools.modelcompiler.CanonicalKieModule.createKiePackages(CanonicalKieModule.java:306)
> at org.drools.modelcompiler.CanonicalKieModule.lambda$1(CanonicalKieModule.java:213)
> at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
> at org.drools.modelcompiler.CanonicalKieModule.createKieBase(CanonicalKieModule.java:213)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:470)
> {noformat}
> ====
> Even this rule causes the issue. So the key factor is the method invocation $valueB.intValue()
> {noformat}
> when
> Number( ) from accumulate (
> FactB( $valueB : value, $valueB > 0 )
> ;max($valueB.intValue())
> )
> then
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-14189) The RunAs annotation doesn't work in EJBs with Elytron
by Diana Vilkolakova (Jira)
[ https://issues.redhat.com/browse/WFLY-14189?page=com.atlassian.jira.plugi... ]
Diana Vilkolakova commented on WFLY-14189:
------------------------------------------
[~alessandromoscatelli] Please try to specify org.jboss.ejb3.annotation.SecurityDomain annotation on your Test1 class and point it to your security domain, in your example it should be "other".
> The RunAs annotation doesn't work in EJBs with Elytron
> ------------------------------------------------------
>
> Key: WFLY-14189
> URL: https://issues.redhat.com/browse/WFLY-14189
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 21.0.0.Final
> Reporter: Alessandro Moscatelli
> Assignee: Diana Vilkolakova
> Priority: Major
> Labels: ejb, elytron, regression, runas, security, startup
> Attachments: standalone-full-ha.new.xml, test.zip
>
>
> Role is not correctly assigned when using @RunAs annotation and Elytron Security Domain. Everything works correctly with legacy picketbox Security Domain.
> Wildfly is configured to use default "other" application-security-domain, also using default security domain ApplicationDomain.
> This exception is rised when deploying the application.
> Caused by: javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract void org.visiontech.test.TestInterface.test() of bean: Test2 is not allowedCaused by: javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract void org.visiontech.test.TestInterface.test() of bean: Test2 is not allowed at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.security.JaccInterceptor.hasPermission(JaccInterceptor.java:120)
> Test/Sample project: [^test.zip]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFCORE-4516) Allow server-identities expression resolution to support Base64 encoded system properties.
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4516?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-4516:
------------------------------------------
I also don't think we should change anything other that the free form text of an attribute, and perhaps some docs if that text is driving any docs.
The existing code is designed to handle two cases – Base64 encoded text or an expression which resolves to plain text. AFAICT this works fine. What doesn't work is using an expression that resolves to Base64 encoded text. I don't think we should try and make that work, as there is a tiny chance of it breaking people, and discussion on https://github.com/wildfly/wildfly-core/pull/3814 leads me to believe Darran Lofthouse is not looking to change the functionality of these legacy resources either.
We should not say that expressions are not allowed because they work fine if the expression resolves to a valid plain text password.
We should change
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/r...
to say
core.management.security-realm.server-identity.secret.value=The secret / password - Base64 encoded text or an expression that resolves to the plain text value.
The fact the current text doesn't say that is a bug, as that's how the software works.
> Allow server-identities expression resolution to support Base64 encoded system properties.
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-4516
> URL: https://issues.redhat.com/browse/WFCORE-4516
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management, Security
> Reporter: Indrajit Ingawale
> Priority: Major
>
> The expression for secret value under server-identities in test-security-realm does not work , even though it shows "expressions-allowed" to true like below .
> ----------------------------
> [standalone@localhost:9990 /] /core-service=management/security-realm=test-security-realm/server-identity=secret:read-resource-description()
> {
> "outcome" => "success",
> .
> .
> "attributes" =>
> {. . . . . }
> ,
> "value" =>
> { "type" => STRING, "description" => "The secret / password - Base64 Encoded.", "expressions-allowed" => true, "required" => true, "nillable" => true, "alternatives" => ["credential-reference"], "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }
> },
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {}
> }
> }
> ----------------------------
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-14034) New health/ready check fails with RBAC enabled
by Claudio Weiler (Jira)
[ https://issues.redhat.com/browse/WFLY-14034?page=com.atlassian.jira.plugi... ]
Claudio Weiler updated WFLY-14034:
----------------------------------
Attachment: WhatsApp Image 2021-01-07 at 08.07.37 (1).jpeg
> New health/ready check fails with RBAC enabled
> ----------------------------------------------
>
> Key: WFLY-14034
> URL: https://issues.redhat.com/browse/WFLY-14034
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 21.0.0.Final
> Reporter: Claudio Weiler
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 21.0.1.Final, 22.0.0.Beta1
>
> Attachments: WhatsApp Image 2021-01-07 at 08.07.37 (1).jpeg
>
>
> See https://github.com/wildfly/wildfly/pull/13397
> When RBAC is enabled, new MicroProfile ready health check shows DOWN status to http requests or in management console, but shows UP in jboss cli.
> {code}
> // Jboss cli
> /subsystem=microprofile-health-smallrye:check-ready > results UP
> // HTTP request
> curl http://localhost:9990/health/ready > results DOWN
> // HAL
> Menu Runtime > Server > MicroProfileHealth > results DOWN
> {code}
> Also, when workaround is applied, HAL continue to show DOWN status, but only with datasources status displayed.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-14275) Large job repository is blocking deployment
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-14275?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-14275:
-----------------------------------
To optimize it with one single query will need changes to jberet-core (as outlined in JBERET-506), which will offer a long-term fix.
As a partial fix directly in WildFly, I propose the following improvements to https://github.com/wildfly/wildfly/blob/master/batch-jberet/src/main/java...
1, limit the max number of job instances (e.g., 50) to retrieve during refreshing process;
2, avoid excessive refreshing, by keeping track of the last refreshing time, and only refresh after certain interval (e.g., 1000 ms) elapses.
> Large job repository is blocking deployment
> -------------------------------------------
>
> Key: WFLY-14275
> URL: https://issues.redhat.com/browse/WFLY-14275
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Gunther vw
> Assignee: Cheng Fang
> Priority: Critical
> Attachments: jberet-deploy.zip
>
>
> We are updating from WildFly 13 (jberet 1.2.4) to WildFly 21.0.2 (jberet 1.3.7).
> In our production environment we are running about 50 jobs, some of them in a frequency of 2 or 4 minutes. For documentation reasons we only can delete job information older than 3 months. So we have 20000 and more jobinstances per job in our job repository - an oracle database job repo.
> Deploying of our Job-Module to WildFly 21 is never finished - sometimes a out of memory exception is thrown.
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months