Your are correct, the engine (and the parser) do use its own JexlFeatures
copies (expressionFeatures/scriptFeatures members) that are never modified
after creation. An equivalent rule applies for JexlOptions btw, copied for
isolation for each evaluation. Those classes, by themselves, even if
On Fri, 20 Oct 2023 at 19:09, Henri Biestro wrote:
>
>
> JexlPermissions concrete classes are but since this is an interface, anyone
> could create a non-thread safe instance and use it. The same way a
> JexlFeatures could be corrupted by being constructed with a non-thread safe
> namespace
JexlPermissions concrete classes are but since this is an interface, anyone
could create a non-thread safe instance and use it. The same way a JexlFeatures
could be corrupted by being constructed with a non-thread safe namespace
predicate (making side-effects etc).
And for JexlFeatures, using
In general, I assume nothing is thread-safe unless documented as such.
Gary
On Fri, Oct 20, 2023, 12:27 PM sebb wrote:
> Are instances of the classes JexlFeatures and JexlPermissions intended
> to be thread-safe?
>
> I have seen mention that they can be shared between threads.
>
> However
Are instances of the classes JexlFeatures and JexlPermissions intended
to be thread-safe?
I have seen mention that they can be shared between threads.
However JexlFeatures is does not appear to be thread-safe (has mutable
fields which are not safely published). Not looked at JexlPermissions
in
