tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Coty Sutherland <>
Subject Questions about BeanELResolver behavior
Date Mon, 09 May 2016 19:45:41 GMT
Hi all,

I have a question regarding the way that the ResourceBundleELResolver (and
the BeanELResolver) function as part of investigations into the changes
made for and then
reverted in  (very old
stuff, I know). What I've come to find is that whenever you provide a
non-existent basename the var.resourceBundle.keys call returns an empty
string. This behavior is consistent between all tomcat versions. For my
testing I'm using the reproducer from bz-46915, but here is a snippet of
the JSP:

    <%@ taglib uri="" prefix="fmt"%>
    <fmt:setBundle basename="IDontExist" scope="session"
var="messageString" />
    <script type="text/javascript">
        var value = "${messageString.resourceBundle.keys}";

I did a bit of debugging and I can see that the bundle is null which seems
expected (section 8.7 of the JSTL 1.2 spec states that if its null, empty,
or invalid a null resource bundle should be added to the context), but it
doesn't give any warnings or anything when you try and access it's
resourceBundle's keys. I tried to find the behavior definition in the JSP
spec also, but I don't see anything for this particular behavior. From the
JSP 2.1 spec, section 2.21.7 getValue(ELContext, Object, Object) shows that
getValue can return null, which it does. In the JasperELResolver class'
getValue method there is a tight loop that iterates over all of the
Resolver's resolvers to resolve the property and return it's value. When
you pass in the non-existent basename such as above, the resolver that
"resolves" the property ends up being the BeanELResolver. The context isn't
null and the base and property variables aren't null, so the resolver sets
the property as resolved (though I think that's wrong) and does some
reflection to invoke the following method:

public java.util.ResourceBundle

which returns null again. Null is an acceptable response there also.

So the question is, does this behavior seem correct?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message