Joerg Hoh created SLING-12873:
---------------------------------
Summary: ScriptBase.getNativeObject can return incorrect data
Key: SLING-12873
URL: https://issues.apache.org/jira/browse/SLING-12873
Project: Sling
Issue Type: Task
Components: Scripting
Reporter: Joerg Hoh
When doublechecking the PR for SLING-12519 ("doublechecked locking") I wonder
if an instance of the ScriptableBase does even work properly, if
[ScriptableBase.getNativei()|https://github.com/apache/sling-org-apache-sling-scripting-javascript/blob/28a85705bfd89abcb86fc194ae3017911f5eeb61/src/main/java/org/apache/sling/scripting/javascript/wrapper/ScriptableBase.java#L39-L58]
is called twice with different parameters from the same thread:
Example:
{noformat}
ScriptableBase sb = ...
Object o1 = sb.getNativeObject("name1", scriptable1); // # case 1
Object o1 = sb.getNativeObject("name2", scriptable2) // # case 2
{noformat}
for case 1 the field {{njo}} is initialized like this:
{{njo = new NativeJavaObject(scriptable1, wrapped, getStaticType())}}
and {{njo}} will be same when the 2nd call is made (case 2).
At the end of {{getNativeObject()}} this call is made:
{noformat}
protected Object getNative(String name, Scriptable start) {
[...]
njo = ...
[...]
return njo.get(name, start);
{noformat}
According to [the sourcecode of
NativeJavaObject|https://github.com/mozilla/rhino/blob/1e1f9c4770ba11bd1b06846bd985532fb9b5c6c7/rhino/src/main/java/org/mozilla/javascript/NativeJavaObject.java#L87-L97]
this method does not even use the provided parameter {{Scriptable start}}, but
relies internally on the scriptable provided in the constructor.
Which means, that in the case 2, if invoked with a different Scriptable, the
result will be incorrect, because the object is still based on scriptable1, but
will ignore scriptable2 entirely.
Which means, that in the generic case (a single Scriptable instance is used for
multiple calls with potentially different parameters) the results can be
incorrect.
Probably this problem was not showing up, because this case (getNativeObject
invoked with different scriptables) never happens in the context of Sling
Scripting (which needs to be confirmed). And at the same time it's also very
likely that this code is never invoked from multiple threads (which would
render the synchronisation redundant, being an easy fix for SLING-12519).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
