On 09/05/2016 20:45, Coty Sutherland wrote: <snip/>
> <%@ taglib uri="http://java.sun.com/jsp/jstl/fmt"; 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) That isn't what is happening. fmt:setBundle creates a LocalizationContext instance with a null ResourceBundle and places it in session scope with the name "messageString" All resolution is done with an instance of JasperELResolver. See JSP.2.9. First: base = null property = messageString This is handled by the ScopedAttributeELResolver and returns the LocalizationContext instance. It is left as an exercise for the reader to determine why it is correct that the previous 9 resolvers in the the JasperELResolver do not resolve this. Second: base = messageString (LocalizationContext) property = resourceBundle This is handled by the BeanELResolver and returns null. Again, why the BeanELResolver handles this is an exercise for the reader. Finally, we have base = null property = keys and section 1.6 of the EL spec explains how to handle that. Returning null is the correct thing to do. > So the question is, does this behavior seem correct? Yes. Long, painful experience with this code has taught me to be very, very cautious before changing anything. While I am certain there are some bugs in the code somewhere, I'm going to need a lot of convincing that any given behaviour is invalid. The most convincing evidence would be the simplest possible test case that demonstrates the problem along with a step by step explanation of the spec mandated behaviour and how Tomcat differs from that. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
