jsinovassin commented on PR #892: URL: https://github.com/apache/unomi/pull/892#issuecomment-5909446061
## The integration suite of this line refused the change, and it was right The first push of this backport failed with 36 failures and 5 errors on 209 integration tests. Every failing case is a rule action that evaluates an MVEL expression: `IncrementPropertyIT`, `PropertiesUpdateActionIT`, `ProfileMergeIT`, `CopyPropertiesActionIT`, `ModifyConsentIT`, `SendEventActionIT`, `RuleServiceIT`. One error names the cause: `ClassNotFound org.mvel2.compiler.Accessor`. The javadoc this pull request brings over states the premise the change rests on: > MVEL's own compiler internals are loaded by the MVEL bundle class loader, not through this filtering loader. That premise holds on `master`, where #877 and its merge commit are both green on the same suite. It does not hold here. `MvelScriptExecutor` sets the thread context class loader to the filtering loader while an expression runs, and on this line MVEL asks that loader for `org.mvel2.compiler.Accessor`. `org.mvel2.compiler.Accessor` is now exempt from the allow list, and from that list only. Both forbid lists still apply to it, so a loosened configuration cannot use the exemption to reach an eval entry point. `Accessor` is the interface a compiled property accessor implements: it carries no compiler and no parser, so naming it from an expression buys nothing, and every compiler entry point stays behind the allow list. `loadClass_theRuntimeInternalExemptionDoesNotReachAnEvalApi` pins that by asserting that `org.mvel2.compiler.ExpressionCompiler` is still refused. The javadoc on this branch now says what this branch measured, rather than repeating master's premise. Worth asking upstream: whether the difference is the MVEL version, the accessor optimizer in use, or something `master` received elsewhere. The answer decides whether this exemption belongs on `master` too, or stays specific to the 3.0 line. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
