• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Put collection object into session

 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
I'm trying to cast a collection of beans to a session obect, so it can be used to populate a javascript drop down list. Using the struts iterate tag, these results can be found if the scope variable is set to request. If session is set, then the specified bean (resourcesList) cannot be found in scope session. In testing, I tried specifying a name equal to a prexisting form bean in the struts-config file, and changed the iterator to point to this. This resulted in a error about unable to create iterator for collection.
I think I need to specify a form bean that can be iterated, but am unsure as to how to go about it. I tried defining one based on java.util.collection, but this didn't help. Do I need to make a new bean conatininig an array, and populate that with the information in the list returned by the DAO?
Any help would be much apprieciated.
Regards,
Ols
Code:
Iterator

struts-config.xml Entry

Action Bean

Data access object method

[ January 12, 2004: Message edited by: Oliver Moore ]
 
Ranch Hand
Posts: 326
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The named item of the iterate tag must be able to be iterated. This can be a Collection, Map or an array (and some others). If you have your bean extend Collection and override iterator() to return an iterator to whatever you're trying to iterate, it should work.
Also of interest, if you omit the scope attribute, the tag will look in all scopes.
At any rate, reading the following will help: iterate tag guide
One last thing I forgot to mention, if you specify the name of your bean, you can specify the name of a propery of that bean, which the iterate tag will try to iterate. No extending needed.
so

should do it
[ January 12, 2004: Message edited by: Ray Stojonic ]
 
Oliver Moore
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ray...
Thanks for the response. I would like to drop the list into the session as this seems like the cleanest and easiest method. Could you please give me an idea of how to do this? With the current code above, the list is placed in the request scope, and displays fine. If I change the iterate tag scope to session, it can't find resourcesList...
Do I have to do someting different when I attach the collection to the request with

to place it in the session? Can you do a session.setAttribute to put it in the session rather than the request?
The only other place I can think of to modify is in the struts-config by adding a name="xx" and a xx formBean entry for it to map to. but I don't know what class I should base the formBean on in order for it to be iterated.
 
Oliver Moore
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not sure if this is a good fix, but now have the list in the session. I did this by adding the following code to the action bean previously described.
First,
import javax.servlet.http.HttpSession;
Then create a session if one is not already pressent
HttpSession session = request.getSession(true);
Then set the attribute of the session with
session.setAttribute(BeanNames.RESOURCES_LIST,col);
If this could be done better, or I'm creating some fundamenatl flaw, any comment would be helpful...
 
Ray Stojonic
Ranch Hand
Posts: 326
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


HttpSession session = request.getSession(true);
Then set the attribute of the session with
session.setAttribute(BeanNames.RESOURCES_LIST,col);


Yep, that'll do it.
note:
you can just 'cut to the chase' with
request.getSession().setAttribute( name, attribute );
the zero param getSession() does the same thing as getSession( true ) and the single line cuts down on clutter by not declaring a session you'll only use once.
 
Oliver Moore
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Ray... That's much cleaner...
Just to clarify struts a little for me, is this effectively what struts should do automatically when you specify the name="xx" and scope="session" for the action, so as to prevent you having to do all the session creation/setAttribute by hand in the action class? Or is this aspect of scope in the strut-config file used in a different context?
 
Ray Stojonic
Ranch Hand
Posts: 326
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you specify scope='session' in your action tag, then, yes, the named bean will be in the session rather than the request.
getSession will rarely create a session (to the best of my knowledge) because the user has already initiated a session if they are sumbitting a request. I believe the session is created the first time they sumbit a request, then again if the session times out and the programmer decides to continue via a new session rather than 'kicking out' the user.
Given all that, I consider things this way:
There is 1 context for my app, which may have many sessions, things stored all this level are persistant for the life of the context and accessable by any session.
There is 1 session for a user, which may have many requests (1 at a time). Things stored at this level are persistant for the life of the session and may be accessed by any request generated by the user of this session.
Requests are short lived, anything I put there may be processed once (ie: user submits to action1, result stored and displayed, user submits to action2, result stored and displayed, result from action1 is no longer there as it was a separate request)
hth
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic