This problem can occur in any taglib. Many people have reported over the past year or so the following type of error: "An error occurred while evaluating custom action attribute "value" with value "${qItems.title}": Unable to find a value for "title" in object of class "java.lang.String" using operator "." (null)" I was able to determine that this is due to the taglib (jstl.lib and/or standard.lib) not being in the application classpath at runtime. This happens often in the Forte (Sun 1 studio) environment because it does not copy the application libs. You need to manually put them into the Forte common/lib (e.g., D:\Program Files\s1studio_jdk\s1studio\tomcat401\common\lib). HOWEVER the taglib bug is that it gives a bogus error message that just confuses people. I'm sure the base error is some kind of class not found exception (which would be helpful), but is instead being swallowed, resulting eventually in the incorrect and unhelpful error above. Proper error handling and reporting is an important part of any product- quality code. This problem needs to be fixed to report a better error. -- Frank
Frank, Are you sure the problem is a ClassNotFoundException? What is the class of qItems, is it a String? Is it a collection? Anyway, could you try to isolate the error (like writing a very small jsp page that generates it)? I could take a look on that if I could reproduce the error (although I don't have Forte - neither Windows - installed on my machines). Felipe PS: please note that I'm not a member of the Jakarta Taglibs developers team, so this is my particular opinion/suggestion
Felipe, Thanks for the response. As I indicated I don't know what the original exception really was (since it isn't shown), but my experience with this type of thing is usually getting a ClassNotFound or an access exception. qItems is of type QItems (my own application class). It is an Enumeration. I meant to include an example of the tag code which causes this: <c_rt:forEach items='<%=pageContext.getRequest().getAttribute("foo")%>' var="qItems" varStatus="status"> <tr> <td class=SITErowodd align="right"><c:out value="${qItems.memberid}" /></td> ... You should be able to reporoduce this by taking any JSP with this type of tag and removing jstl.lib and/or standard.lib from tomcat (e.g., make sure it isn't in <tomcat>/common/lib or the <webapp>/WEB-INF/lib). In short, everything is fine when the libs are provided and throw the specified type of error when they are removed. The problem is that the message is too meaningless to give people a clue to the problem (thus it has been unsolved for over a year despite many complaints in the forums). I've had this same kind of problem with my libs that try to introspect on application classes when I failed to put my lib in one of the above Tomcat locations. The behavior is very misleading since non-introspection uses of the lib are no problem so long as the lib is somewhere in the classpath. -- Frank
Hi again, I tried to reproduce this error on Tomcat 4.1.24, but it didn't happened. When I removed both jars or only standard.jar, I got this error: org.apache.jasper.JasperException: /hello.jsp(2,0) Unable to load class forEach at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94) When I removed only jstl.jar, I got this: javax.servlet.ServletException: javax/servlet/jsp/jstl/core/LoopTagSupport at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) I still think the problem is other than the missing jars (although you say that's the only way you can reproduce the error). Normally, when I get these kinds of errors, it's a problem in my get/set methods. For instance, if your bean has an int variable and the get is a int get() but the set is a void set(String) or vice-versa, you would get an error like that. Felipe
I guess I need to clarify the error situation. The jars still need to be in runtime path (which they normally will be), but just not in the application lib or common/lib. Then you will get the problem.
Changed component
Frank, I've been in situations similar to yours, where a getter/setter has thrown an exception and JSTL reported that "an error occurred while evaluating...", while the real exception got lost in the limbo/log. I will try to reproduce the situation so we can verify if it is really a JSTL bug or not.
I did some aditional tests, and the right exception is always been thrown. So, I'm closing this bug. If it happens again with a recent version of JSTL (like 1.0.5), please re-open it with more information on how to reproduce it.