tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Coty Sutherland <csuth...@redhat.com>
Subject Re: Questions about BeanELResolver behavior
Date Tue, 10 May 2016 00:25:24 GMT
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 <markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

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