Add an option to raise an error for undefined EL identifiers

[glassfishrobot]

An undefined EL identifier in a JSP page has a default value of "", making it difficult to debug EL expressions evaluation in s JSP page. The spec should allow an option to raise an error in this case.

The RI should also be fixed to send back a message in the response in this case. The message should include the offending EL expression and undefined identifier.

[glassfishrobot]

@glassfishrobot Commented
Reported by kchung

[glassfishrobot]

@glassfishrobot Commented
darkling said:
I'd like this capability for JSF as well.

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA JSP-40

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/javaee-jsp-api/issues/40
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[markt-asf]

This will need to wait for Jakarta EE 10.

[markt-asf]

With the refactoring of the ScopedAttributeELResolver into three separate ELResolvers this would be simple to add to the NotFoundELResolver. As is often the case, the part I am finding the hardest is naming the configuration settings. Possible options are:

JSP Property Group sub-element	Page Directive
el-unresolved-invalid	isELUnresolvedInvalid
el-unresolved-error	isELUnresolvedError
el-not-found-invalid	isELNotFoundInvalid
el-not-found-error	isELNotFoundError

or something else?

My current preference is for el-not-found-invalid but I am open to better / alternative suggestions. I'd like to get started on this later this week.

[joakime]

The naming on the "JSP Property Group sub-element" seems fine to me.

Do we have any other Page Directives that use acronyms that we can crib from? (do we use isELUnresolvedInvalid or isElUnresolvedInvalid?)
Do we even want to mention the EL?
Example isExpressionUnresolvedInvalid?

Why 4 page directives like that?
The combination of "resolved" and "not-found" with "invalid" and "error" seem awkward to me.
How about ? ...

• isExpressionResolved
• isExpressionFound
• isExpressionValid
• hasExpressionError

Or is the history of JSP always been a 1::1 mapping of JSP Property Group sub-element to Page Directive?

[markt-asf]

Do we have any other Page Directives that use acronyms that we can crib from? (do we use isELUnresolvedInvalid or isElUnresolvedInvalid?)

isELIgnored and the equivalent <el-ignored>

Do we even want to mention the EL?

I think we should for consistency.

Why 4 page directives like that?

I'm only intending to create one new Page Directive. The 4 were different options for the single new setting "Throw a PropertyNotFoundException if an EL expression contains an identifier that cannot be resolved."

And I have thought of a better name:

<error-on-el-not-found> / errorOnELNotFound

It is a little verbose but much more expressive. It is shorter than the already existing deferredSyntaxAllowedAsLiteral. WDYT?

Or is the history of JSP always been a 1::1 mapping of JSP Property Group sub-element to Page Directive?

Some settings are replicated between property groups and page directives but both have settings the other does not. Replicating this one looks to be consistent with the current set of replicated settings.

[joakime]

I'm only intending to create one new Page Directive. The 4 were different options for the single new setting "Throw a PropertyNotFoundException if an EL expression contains an identifier that cannot be resolved."

And I have thought of a better name:

<error-on-el-not-found> / errorOnELNotFound

It is a little verbose but much more expressive. It is shorter than the already existing deferredSyntaxAllowedAsLiteral. WDYT?

As a setting, yeah, i like it.
Lets go with it.

[markt-asf]

Just a note that since this option impacts runtime, what looked like a trivial change requires a significant amount of plumbing and wider API changes (including in the Servlet API) to implement. I'm not at the point where I declare that I don't think this feature is worth the effort but the thought has crossed my mind.