2009-05-26 5 views
4

Je cours Tomcat 6.0.18 sous Linux.Comportement d'erreur du langage d'expression JSP?

J'ai un JSP qui utilise un haricot comme ceci:

<jsp:useBean id="helper" 
      type="com.example.SomeType" 
      scope="request"/> 

La page fait référence à un attribut de helper avec la langue d'expression comme ceci:

<!-- This works properly, but could fail silently if the bean name is incorrect. --> 
<div><p>Here's some stuff: ${helper.stuff}</div> 

Au cours de refactoring où j'ai manqué une occurrence du nom helper, j'ai remarqué que aucune erreur n'est levée si le nom helper est écrit incorrectement. Pas sur l'écran, et pas dans mes fichiers journaux. Rien ne se produit pour l'extrait de langue d'expression dans la sortie:

<!-- Wrong name! "foo" should be "helper" but no error is observed (other than missing ouput)! --> 
<div><p>Here's some stuff: ${foo.stuff}</div> 

Maintenant, une erreur est en relief (mes affichages de page d'erreur personnalisée et je vois une exception dans mon fichier journal) si j'utilise la syntaxe JSP suivante avec un nom incorrect pour helper:

<!-- Wrong name, but an error is raised. --> 
<div><p>Here's some stuff: <jsp:getProperty name="foo" property="stuff"/></div> 

Dans ce cas, le journal enregistre cette entrée:

SEVERE: requestURI: /some.jsp servletName: jsp statusCode: 500 
org.apache.jasper.JasperException: Attempted a bean operation on a null object. 

Pour être complet, la syntaxe fonctionne correctement jsp:getProperty lorsque le nom de haricot est correct:

<!-- Works properly, protects me from an incorrect name, but is more verbose than EL. --> 
<div><p>Here's some stuff: <jsp:getProperty name="helper" property="stuff"/></div> 

Pourquoi ne vois-je pas une erreur quand j'écris $ {} foo.stuff? Y a-t-il une option de configuration qui contrôle les rapports d'erreurs dans de tels cas?

+0

Juste pour affirmer ce que les autres ont dit, cela est une caractéristique délibérée de EL. – Eddie

Répondre

5

Cette comportement est couvert dans la section 1.6 de la Expression Language Specification Version 2.1.

Pour évaluer expr-a [expr-b]:

Si la valeur a est nulle:

  • Si expr-a [expr-b] est la dernière propriété étant résolu:
    • Si l'expression est une expression de valeur et ValueExpression.getValue (contexte) a été appelé à initier cette évaluation expression , return null.
    • Sinon, lancez PropertyNotFoundException.essayant de de référence nulle pour une lvalue
  • Sinon, return null.

(EL unifie le. Et [] opérateurs)

+1

Merci pour cette réponse @McDowell. Pour clarifier: "ValueExpression.getValue (context)" == en utilisant le EL pour lire une valeur (ce que je fais dans cette question), et "essayer de dé-référencer null pour une lvalue" == en utilisant le EL écrire une valeur. La section 1.4 de la spécification discute de la justification du comportement observé. Oh, et "return null" signifie "produire la chaîne vide" dans ce contexte - Spec section 1.18.2 –

2

C'est exactement comme cela que fonctionne EL. $ {Helper} évalue à null alors EL retourne juste "" et ne tente pas d'évaluer le reste de l'expression.

Il est caractéristique un peu pratique dans certains cas:

${myBean.property1.name} 

fonctionnera si même si property1 est nulle, donc je ne dois pas écrire juste pour empêcher un NPE:

<c:if test="${not empty myBean.property1}">${myBean.property1.name}</c:if>