-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom ELResolver's setValue with a null base cannot be called #37
Comments
@glassfishrobot Commented |
@glassfishrobot Commented |
|
This needs further investigation / thought. The code was changed after the EL 3.0 release (but the Javadoc was not) while under the JCP process. The code was then transferred to Eclipse. The change was, therefore present in the Jakarta EE 8 release but not in the Java EE 8 release. (Actually, there was no EL update for Java EE 8 so the 3.0 version from Java EE 7 was used.) We either need to revert this change or update the Javadoc and spec doc to reflect the change. |
Reverts this commit: javaee/uel-ri@e0390e9 The change is being reverted because: - the problem statement in the bug report that led to the change (#37) is incorrect - this was an undocumented functional change made between Java EE 8 and Jakarta EE 8 Signed-off-by: Mark Thomas <markt@apache.org>
My reading of the code is that the problem statement is not The change made after the EL 3.0 has been reverted for Jakarta EL 4.0.0. |
I think there's no way that a custom ELResolver's setValue with null 'base' argument is called.
That's because in StandardELContext the call of a LocalBeanNameResolver precedes the customResolvers:
( The correct order would be
)
Futhermore, there's no way to replace the StandardELContext,
because the ELManager puts a wrapper to the ELContext argument.
( I think the correct code would be the following, because the attribute elContext may have only ELContext type not StandardELContext:
)
Moreover, it is not possible to replace the ELManager in the ELProcessor (it is private field) not even using inheritance (a subclass), because the code of the ELProcessor references directly to the private field and not uses the getELProcessor() getter method.
Test:
Workaround:
To create subclasses using small modifications mentioned above in the StandardELContext and ELManager, and create a subclass but a whole replacement of the ELProcessor that uses the ELManager subclass.
The text was updated successfully, but these errors were encountered: