| Summary: | EL cannot resolve JavaBean properties that throw an exception | ||
|---|---|---|---|
| Product: | Taglibs | Reporter: | Alex Blewitt <alex_blewitt> |
| Component: | Standard Taglib | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.0.2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
I also forgot to note that the property 'content' is declared in a super-class (javax.mail. internet.MimeMessage) and not in the base class com.sun....POP3Message This may be a bug in the way that the MimeMessage is written, rather than the EL (and/or the Introspector). Doing a Introspector.getBeanInfo() on the javax.mail.internet.MimeMessage results in a PropertyDescriptor 'content' that has a write method (public void setContent(Multipart)) but the read method is not present (should be public Object getContent()). Since the introspector isn't reporting it, there's not a lot that we can do here in order to find it from EL. As for why the introspector isn't reporting it, that's another question. It could be to do with the fact that the return type and set type of the method are different, and as such they're not considered to be the same type. I'd close this INVALID and just put it down to a badly written MimeMessage class. Last comment by Alex says it all. [Self resolving bugs... I like that :-)] |
I was writing a WebMail system based on JSTL, and wanted to display the contents of a message with JSTL/EL. I used ${message.subject} which worked fine, but ${message.content} resulted in the exception [30/07/03 14:22:58:965 BST] 22eeff03 WebGroup E SRVE0026E: [Servlet Error] -[An error occurred while evaluating custom action attribute "value" with value "${message['from']}": Unable to find a value for "from" in object of class "com.sun.mail.pop3.POP3Message" using operator "[]"]: javax.servlet.jsp.JspException: An error occurred while evaluating custom action attribute "value" with value "${message['from']}": Unable to find a value for "from" in object of class "com. sun.mail.pop3.POP3Message" using operator "[]" at org.apache.taglibs.standard.lang.jstl.Evaluator.evaluate(Evaluator.java: 140) at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager. evaluate(ExpressionEvaluatorManager.java:112) at org.apache.taglibs.standard.tag.el.core.ExpressionUtil. evalNotNull(ExpressionUtil.java:85) at org.apache.taglibs.standard.tag.el.core.OutTag. evaluateExpressions(OutTag.java:137) at org.apache.taglibs.standard.tag.el.core.OutTag.doStartTag(OutTag.java: 95) at org.apache.jsp._message._jspService(_message.java:115) at com.ibm.ws.webcontainer.jsp.runtime.HttpJspBase.service(HttpJspBase. java:89) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.ibm.ws.webcontainer.jsp.servlet.JspServlet$JspServletWrapper. service(JspServlet.java:344) at com.ibm.ws.webcontainer.jsp.servlet.JspServlet. serviceJspFile(JspServlet.java:598) at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.service(JspServlet.java: 696) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) This uses JavaMail 1.3.1, which /does/ have a message.getContent() method (doing so by code works fine, it's just EL that cannot resolve it). I suspect this may be due to the fact that the method getContent() throws an IOException. The specs are ambiguous on this point: Otherwise (a JavaBeans object), coerce value-b[property name] to String > If value-b[property name] is a readable property of value-a[bean] > > if getter throws an exception: error > > otherwise: return result of getter call > otherwise: error I believe this is meant to convey that if an exception is thrown during the execution of this method, throw an error, as opposed to if the method declares an exception. I'm not sure if the code is filtering out all methods that declares an exception; that would certainly explain the behaviour I'm seeing. If this is the case, then IMHO the restriction should be removed since if the property access works there is no reason to stop the method from behaving. In any case, if a non-checked exception occurs during the evaluation of an EL expression, the current behaviour is to raise that error; IMHO it shouldn't be any different for the checked exceptions. Note that the only workaround is to dump back into code to specifically extract all the individual properties that may have an exception which is certainly undesirable. Also, the addition of declared exceptions to existing beans will render current EL expressions invalid which may be very undesirable in other applications. If there is any other reason why it's not resolving ${message.content} (when ${message.subject}, ${message.content} work then please let me know ...