Understood. Thanks for the walk through; I think I understand what's going on. I am going to read through the spec a bit more and verify though since I don't know much of anything about EL :(
Thanks again! On Mon, May 9, 2016 at 5:14 PM, Mark Thomas <ma...@apache.org> wrote: > 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 > >
