BUG: JWTAuthenticationMechanism.java about payara-examples HOT 5 OPEN

@OndrejM it has to be an expression delimited with the #{} or ${} syntax. The confusion comes perhaps from the earlier EE Security revision (pre 1.0) where I didn't put in the check for that syntax yet. The reasoning was indeed that if the attribute could only hold an expression, why require the syntax. But, as we implemented EL support across the spec, it became clear that it looked quite inconsistent if for one annotation that had String members already the syntax was required (to distinguish from a plain string) and for other attributes (those that are specifically for expressions) not. So at long lost we made the decision to simply require the syntax everywhere for expressions. The added benefit is that some IDE editors have an easier time recognising them as well. In the code you see this here: public static boolean evalELExpression(ELProcessor getELProcessor, String expression, boolean defaultValue) { if (!isELExpression(expression)) { return defaultValue; } return (Boolean) getELProcessor(getELProcessor).eval(toRawExpression(expression)); } If it's not an EL expression, the default value is taken, which in this case is the value of the boolean isRememberMe. I'll try to clarify this in the JavaDoc. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

El 6/06/2018, a las 6:44 a. m., Arjan Tijms ***@***.***> escribió: @OndrejM <https://github.com/OndrejM> it has to be an expression delimited with the #{} or ${} syntax. The confusion comes perhaps from the earlier EE Security revision (pre 1.0) where I didn't put in the check for that syntax yet. The reasoning was indeed that if the attribute could only hold an expression, why require the syntax. But, as we implemented EL support across the spec, it became clear that it looked quite inconsistent if for one annotation that had String members already the syntax was required (to distinguish from a plain string) and for other attributes (those that are specifically for expressions) not. So at long lost we made the decision to simply require the syntax everywhere for expressions. The added benefit is that some IDE editors have an easier time recognising them as well. In the code you see this here: public static boolean evalELExpression(ELProcessor getELProcessor, String expression, boolean defaultValue) { if (!isELExpression(expression)) { return defaultValue; } return (Boolean) getELProcessor(getELProcessor).eval(toRawExpression(expression)); } If it's not an EL expression, the default value is taken, which in this case is the value of the boolean isRememberMe. I'll try to clarify this in the JavaDoc. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#81 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD9Mmdto528z41Nr_7j7XDh2W0Ze2kxKks5t58CwgaJpZM4UcAKe>.