Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

JSTL: getting a map's keys

716 views
Skip to first unread message

Chris Riesbeck

unread,
Mar 19, 2012, 2:15:52 PM3/19/12
to
Can anyone help me figure out why the following is happening, or further
experiments I can run? (I have workarounds but I'd like to know what I'm
misunderstanding.)

Given:
- SimTable, a subclass of HashTable that defines getKeys() to call
keyset()
- a session variable "data" which is a HashTable with "rates" set to
an instance of a SimTable

Why does ${rates.keys} generate nothing in these lines of JSP?

<c:set var="rates" value='${data["rates"]}'/>

<p>rates: ${rates}</p>

<p>jstl: ${rates.keys}</p>

<p>jsp: <%= ((edu.northwestern.ils.simulator.SimTable)
pageContext.findAttribute("rates")).getKeys() %></p>

Here's the generated HTML output:

<p>rates: {Bill=100.0, Fred=75.0, Jane=75.0, Mary=50.0, Sam=75.0,
Sarah=150.0}</p>

<p>jstl: </p>

<p>jsp: [Bill, Fred, Jane, Mary, Sam, Sarah]</p>

Lew

unread,
Mar 19, 2012, 3:57:42 PM3/19/12
to
On Monday, March 19, 2012 11:15:52 AM UTC-7, Chris Riesbeck wrote:
> Can anyone help me figure out why the following is happening, or further
> experiments I can run? (I have workarounds but I'd like to know what I'm
> misunderstanding.)
>
> Given:
> - SimTable, a subclass of HashTable [sic] that defines getKeys() to call

If you mean 'java.util.Hashtable', that's a rather obsolete class. You should stick with 'java.util.HashMap'.

> keyset()

Joshua Bloch recommends to prefer composition over inheritance.

> - a session variable "data" which is a HashTable with "rates" set to
> an instance of a SimTable

If "rates" is set to an instance of a 'HashTable', or whatever, is 'data' then a 'Map<String,Map<?,?>>'?

> Why does ${rates.keys} generate nothing in these lines of JSP?

How about you follow the advice here:
http://sscce.org/
and then maybe we can help you. It would make it easier for you to answer the questions I'm asking.

I think perhaps you're overthinking the session vars. Why can't your 'rates' Map go in there directly?

> <c:set var="rates" value='${data["rates"]}'/>
>
>
> rates: ${rates}</p>
>
>
> jstl: ${rates.keys}</p>
>
>
> jsp: <%= ((edu.northwestern.ils.simulator.SimTable)
> pageContext.findAttribute("rates")).getKeys() %></p>
>
> Here's the generated HTML output:
>
>
> rates: {Bill=100.0, Fred=75.0, Jane=75.0, Mary=50.0, Sam=75.0,
> Sarah=150.0}</p>
>
>
> jstl: </p>
>
>
> jsp: [Bill, Fred, Jane, Mary, Sam, Sarah]</p>

Your example code is fragmented and incomplete. Give us something we can work with, please.

--
Lew

Tim Slattery

unread,
Mar 19, 2012, 4:08:28 PM3/19/12
to
Chris Riesbeck <Chris.R...@gmail.com> wrote:


> <p>jstl: ${rates.keys}</p>

The EL here finds the object "rates" and looks for an attribute named
"keys". That means that if rates doesn't have a public method named
getKeys, the EL won't find anything.

--
Tim Slattery
Slatt...@bls.gov

Chris Riesbeck

unread,
Mar 19, 2012, 5:06:08 PM3/19/12
to
On 3/19/2012 3:08 PM, Tim Slattery wrote:
> Chris Riesbeck<Chris.R...@gmail.com> wrote:
>
>
>> <p>jstl: ${rates.keys}</p>
>
> The EL here finds the object "rates" and looks for an attribute named
> "keys". That means that if rates doesn't have a public method named
> getKeys, the EL won't find anything.
>
Which it does. Here's a complete example, class and test JSP, and the
HTML output I get

****** CLASS

package example;

import java.util.HashMap;
import java.util.Set;

public class SimTable extends HashMap<String, Object> {

public Set<String> getKeys() {
return keySet();
}
}

****** JSP

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<%
final example.SimTable data = new example.SimTable();
data.put("Bill", 100); data.put("Mary", 150); data.put("Fred", 200);
pageContext.setAttribute("data", data);
%>

<!doctype HTML>
<html>
<head>
<title>Test</title>
</head>
<body>
<p>data: ${data}</p>
<p>data.keys: ${data.keys}</p>
<p>data.getKeys():
<%= ((example.SimTable) pageContext.findAttribute("data")).getKeys() %>
</p>
</body>
</html>


****** HTML output

<!doctype HTML>
<html>
<head>
<title>Test</title>
</head>
<body>
<p>data: {Bill=100, Mary=150, Fred=200}</p>
<p>data.keys: </p>
<p>data.getKeys():
[Bill, Mary, Fred]
</p>

</body>
</html>

Chris Riesbeck

unread,
Mar 19, 2012, 5:39:31 PM3/19/12
to
And I added these lines to my JSP to see if "keys" was appearing as a
property via the Introspector and it was

****** additional JSP

<c:set var="props"
value='<%=
java.beans.Introspector.getBeanInfo(pageContext.findAttribute("data").getClass()).getPropertyDescriptors()
%>' />
<ul>
<c:forEach var="prop" items="${props}">
<li>${prop.name}</li>
</c:forEach>
</ul>

****** additional HTML output

<ul>

<li>class</li>

<li>empty</li>

<li>keys</li>

</ul>

markspace

unread,
Mar 19, 2012, 6:27:48 PM3/19/12
to
On 3/19/2012 1:08 PM, Tim Slattery wrote:
> Chris Riesbeck<Chris.R...@gmail.com> wrote:
>
>
>> <p>jstl: ${rates.keys}</p>
>
> The EL here finds the object "rates" and looks for an attribute named
> "keys". That means that if rates doesn't have a public method named
> getKeys, the EL won't find anything.
>


Up before the part you snipped, the OP mentioned that he did sub-class
HashTable and add a "getKeys()" method.

Hmm, maybe there's a clue there. Are there coercion rules for JSTL?
It's been a long while since I looked at it. Is it possible that JSTL
is coercing SimTable (the one with getKeys()) to a HashTable, which does
not have "getKeys()" defined?

You might want to uncompile the .class file for this JSTL, it might show
you what is actually being produced. There may be a clue there.


Daniel Pitts

unread,
Mar 19, 2012, 7:59:24 PM3/19/12
to
My guess is that ${rates.keys} is interpreted as equivalent to
${rates['keys']}, so it is looking for a key of "keys", not a java bean
property.

You *can* use c:forEach to iterate over the entry set (Map.Entry) in a
map.

Hopefully this helps,
Daniel.

Chris Riesbeck

unread,
Mar 20, 2012, 1:19:42 PM3/20/12
to
Ah! This would explain why ${rates.class} doesn't work either.
Basically, name.key will always be taken as name[key] for a Map, even if
key is a property of name. If I'm reading the JSP EL resolver
specification correctly, that's just what is happening.

>
> You *can* use c:forEach to iterate over the entry set (Map.Entry) in a map.

Yes, that's what I've been doing instead for looping.

>
> Hopefully this helps,
> Daniel.

Indeed. Thanks, Daniel

Chris Riesbeck

unread,
Mar 20, 2012, 1:52:46 PM3/20/12
to
On 3/20/2012 12:19 PM, Chris Riesbeck wrote:
> On 3/19/2012 6:59 PM, Daniel Pitts wrote:
>> On 3/19/12 11:15 AM, Chris Riesbeck wrote:
>>>
>>> [summary: rates is an instance of a subclass of Map that
>>> implements getKeys()]
>>>
>>> Why does ${rates.keys} generate nothing in these lines of JSP?
>>>
>> My guess is that ${rates.keys} is interpreted as equivalent to
>> ${rates['keys']}, so it is looking for a key of "keys", not a java bean
>> property.

Just to nail the coffin lid shut on this. The JSP EL defines name.key as
just shorthand for name["key"]. To interpret [] expressions, JSP uses
the first answer it gets from this chain of resolvers:

ImplicitObjectELResolver
registered custom ELResolvers
MapELResolver
ListELResolver
ArrayELResolver
BeanELResolver
ScopedAttributeELResolver


http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html

So the Map interpretation will always override the Bean interpretation.

Lew

unread,
Mar 20, 2012, 2:05:14 PM3/20/12
to
Chris Riesbeck wrote:
> Chris Riesbeck wrote:
>> Daniel Pitts wrote:
>>> Chris Riesbeck wrote:
>>>>
>>>> [summary: rates is an instance of a subclass of Map that
>>>> implements getKeys()]
>>>>
>>>> Why does ${rates.keys} generate nothing in these lines of JSP?
>>>>
>>> My guess is that ${rates.keys} is interpreted as equivalent to
>>> ${rates['keys']}, so it is looking for a key of "keys", not a java bean
>>> property.
>
> Just to nail the coffin lid shut on this. The JSP EL defines name.key as
> just shorthand for name["key"]. To interpret [] expressions, JSP uses
> the first answer it gets from this chain of resolvers:
>
> ImplicitObjectELResolver
> registered custom ELResolvers
> MapELResolver
> ListELResolver
> ArrayELResolver
> BeanELResolver
> ScopedAttributeELResolver
>
>
> http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html
>
> So the Map interpretation will always override the Bean interpretation.

Now that your main question is answered, a couple of comments are in order.

- Don't have scriptlet in your JSPs.
- If you had *composed* a 'Map' into a custom class rather than inheriting 'Map', you would not have had the problem. Your custom class would have been resolved by the bean resolver.
- This in turn would make for a better design overall. Instead of your view artifact (the JSP) caring about the implementation details of the map and its set of keys, you'd have a controller call like 'getKeys()' or whatever that would cleanly separate the logic of how you get them from presentation concerns.

--
Lew

Daniel Pitts

unread,
Mar 20, 2012, 2:28:38 PM3/20/12
to
Another interesting side-effect of this approach is that
SomeObject.property might attempt to parse "property" as a number if
SomeObject implements List. We've had this problem where a generic class
which converts XML->Maps/Lists/Strings used different types depending on
the multiplicity of specific tags. (It was bad design IMO, but I was
politically unable to have it designed otherwise).

markspace

unread,
Mar 20, 2012, 2:29:17 PM3/20/12
to
On 3/20/2012 10:52 AM, Chris Riesbeck wrote:

> http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html
>


By the way, I appreciate you sharing the problem's resolution with us,
and also this second post on root cause. It's nice to help someone who
then helps you back.

Daniel Pitts

unread,
Mar 20, 2012, 3:10:22 PM3/20/12
to
Yes, I actually new the "answer", but not the official "reason". It was
interesting to see that "there's a spec for that".

Chris Riesbeck

unread,
Mar 21, 2012, 2:09:05 PM3/21/12
to
On 3/20/2012 1:05 PM, Lew wrote:
> Chris Riesbeck wrote:

>> http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html
>>
>> So the Map interpretation will always override the Bean interpretation.
>
> Now that your main question is answered, a couple of comments are in order.
>
> - Don't have scriptlet in your JSPs.

I never do. That was in the original JSP just to show that getKeys() was
functioning and returning a non-empty result

> - If you had *composed* a 'Map' into a custom class rather than
> inheriting 'Map', you would not have had the problem. Your custom
> class would have been resolved by the bean resolver. - This in turn
> would make for a better design overall. Instead of your view artifact
> (the JSP) caring about the implementation details of the map and its
> set of keys, you'd have a controller call like 'getKeys()' or
> whatever that would cleanly separate the logic of how you get them
> from presentation concerns.

Using delegation (my preference also) doesn't support the JSP EL form
${rates["Bill"]}. If I had a custom class, I'd need a custom tag or
custom EL resolver to make that work.

The original goal was to get the JSTL away from knowing about Map's, in
particular about entry.key and entry.value.



Lew

unread,
Mar 22, 2012, 10:51:00 AM3/22/12
to
Chris Riesbeck wrote:
> Lew wrote:
>> - If you had *composed* a 'Map' into a custom class rather than
>> inheriting 'Map', you would not have had the problem. Your custom
>> class would have been resolved by the bean resolver. - This in turn
>> would make for a better design overall. Instead of your view artifact
>> (the JSP) caring about the implementation details of the map and its
>> set of keys, you'd have a controller call like 'getKeys()' or
>> whatever that would cleanly separate the logic of how you get them
>> from presentation concerns.
>
> Using delegation (my preference also) doesn't support the JSP EL form
> ${rates["Bill"]}. If I had a custom class, I'd need a custom tag or custom EL
> resolver to make that work.

No, you most certainly would not.

Just define an appropriate method in your class.

> The original goal was to get the JSTL away from knowing about Map's [sic], in
> particular about entry.key and entry.value.

Which would be neatly accomplished by my suggestion.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Chris Riesbeck

unread,
Mar 22, 2012, 1:53:36 PM3/22/12
to
On 3/22/2012 9:51 AM, Lew wrote:
> Chris Riesbeck wrote:
>> Lew wrote:
>>> - If you had *composed* a 'Map' into a custom class rather than
>>> inheriting 'Map', you would not have had the problem. Your custom
>>> class would have been resolved by the bean resolver. - This in turn
>>> would make for a better design overall. Instead of your view artifact
>>> (the JSP) caring about the implementation details of the map and its
>>> set of keys, you'd have a controller call like 'getKeys()' or
>>> whatever that would cleanly separate the logic of how you get them
>>> from presentation concerns.
>>
>> Using delegation (my preference also) doesn't support the JSP EL form
>> ${rates["Bill"]}. If I had a custom class, I'd need a custom tag or
>> custom EL
>> resolver to make that work.
>
> No, you most certainly would not.
>
> Just define an appropriate method in your class.

Color me totally dense. Maybe I'm missing what method I should be defining.

If my class implements the Map interface, then MAPElResolver will be
invoked and do the same thing with name.key and name["key"]: call
name.get("key"). The JSP EL won't be able to call any bean method of name.

If my class doesn't implement Map, then BeanELResolver will be invoked
and do the same thing with name.key and name["key"]: call name.getKey().
The JSP EL won't be able to call name.get() via [].

So I don't see how I can have a class such that in the JSP EL I can call
a method to get all the keys, and also retrieve data with a key using [].

Lew

unread,
Mar 22, 2012, 4:23:34 PM3/22/12
to
I was thinking along the lines of this incompletely worked-through notion:

public class ContactScreenBacker
{
private final Map<String, Rate> rates = howeverYouSetItUp();
public Map<String, Rate> getRates() { return Collections.unmodifiableMap(rates); }
public Set<String> getKeys() { return Collections.unmodifiableSet(rates.getKeys(); }
// ...
}

You should be able to use an EL like '#{thingie.rates["Bill"]}'. I haven't tried it, but this is what I had in mind.

--
Lew

Chris Riesbeck

unread,
Mar 23, 2012, 1:23:32 PM3/23/12
to
On 3/22/2012 3:23 PM, Lew wrote:
> Chris Riesbeck wrote:
>> Lew wrote:
>>> Chris Riesbeck wrote:
>>
>> So I don't see how I can have a class such that in the JSP EL I can call
>> a method to get all the keys, and also retrieve data with a key using [].
>
> I was thinking along the lines of this incompletely worked-through notion:
>
> public class ContactScreenBacker
> {
> private final Map<String, Rate> rates = howeverYouSetItUp();
> public Map<String, Rate> getRates() { return Collections.unmodifiableMap(rates); }
> public Set<String> getKeys() { return Collections.unmodifiableSet(rates.getKeys(); }
> // ...
> }
>
> You should be able to use an EL like '#{thingie.rates["Bill"]}'. I
> haven't tried it, but this is what I had in mind.

Yes, that's probably the approach I'll take. Not quite what I'd wanted,
but close enough and I can't see why it shouldn't work.

Thanks, all.

Lew

unread,
Mar 23, 2012, 4:50:55 PM3/23/12
to
Let us know how it plays out, please.

Chris Riesbeck

unread,
Mar 26, 2012, 3:10:48 PM3/26/12
to
On 3/23/2012 3:50 PM, Lew wrote:
> Chris Riesbeck wrote:
>> Lew wrote:
>>>
>>> I was thinking along the lines of this incompletely worked-through
>>> notion:
>>>
>>> public class ContactScreenBacker
>>> {
>>> private final Map<String, Rate> rates = howeverYouSetItUp();
>>> public Map<String, Rate> getRates() { return
>>> Collections.unmodifiableMap(rates); }
>>> public Set<String> getKeys() { return
>>> Collections.unmodifiableSet(rates.getKeys(); }
>>> // ...
>>> }
>> Yes, that's probably the approach I'll take. Not quite what I'd
>> wanted, but
>> close enough and I can't see why it shouldn't work.
>
> Let us know how it plays out, please.

So far, fine. Only time will tell if it pays off in how my JSP looks.

Thanks

0 new messages