On Wed, 26 Jun 2002, Rick Reumann wrote:
> Date: Wed, 26 Jun 2002 15:16:11 -0400
> From: Rick Reumann <[EMAIL PROTECTED]>
> To: Craig R. McClanahan <[EMAIL PROTECTED]>
> Cc: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re[3]: what to store in session?
>
> Thanks so much Craig, this has been tremendously helpful! Some
> comments below...
>
> On Wednesday, June 26, 2002, 2:38:54 PM, Craig wrote:
>
> CRM> My suggestion is to implement this logic inside a bean that hides whether
> CRM> or not you are really caching the data or not -- say a StoresBean
> CRM> something like this:
>
> CRM> public class StoresBean {
>
> CRM> public ArrayList stores = null;
>
> CRM> public synchronized Iterator getStores() {
> CRM> if (stores == null) {
> CRM> stores = new ArrayList();
> CRM> ... fill in the objects in this list ...
> CRM> }
> CRM> return (stores.iterator());
> CRM> }
>
> CRM> }
>
> CRM> That way, the relevant stuff will get loaded the first time and then
> CRM> reused.
>
> Ok, you've started to clear some things up for me. I always
> thought thought that classes in my: myAppDir/WEB-INF/classes
> directory if they had static members they were shared across the
> entire application scope? This definitely is wrong though? (and
> it's only session scope?).
>
No, you've got that right. It's just that classes loaded from something
like the "common/lib" dirctory in Tomcat are shared across *all* web
applications, not just yours.
> In your above code, though, each user session would then end up
> loading a new list of stores. I don't really need that. I only
> need that list being loaded once and shared amongst all the
> sessions.
>
Some people do need per-user-specific stuff for some things. The same
design pattern works for both scenarios -- it's just a matter of where you
store the bean (and how it builds the list of available stuff).
> CRM> But your calling application doesn't know that -- all it needs to
> CRM> do is grab StoresBean out of the session attributes (if this is user
> CRM> specific) or context attributes (if this is global), and call getStores().
>
> How would I grab this "global" attribute from a business layer
> object though? I guess that's where I'm getting confused. Say I
> have my Action class call a business object:
> BO.getStoresList()
> Well now I want the BO to return me a List of StoreBeans, but I
> only want that list populated ONE time and want all the sessions
> to share it.It looks like if I want all the sessions to share the information
> I have to pass servlet classes into my model layer? Am I wrong
> there?
>
As a servlet context attribute, the simplest way would be to have your
Action grab it (getServle().getServletContext().getAttribute()) and pass
it to the business object. But we're getting into territory where there
are a number of different approaches -- I would suggest consulting some of
the good design pattern books like the J2EE Blueprints series from Sun, my
favorite design patterns book "Core J2EE Patterns" by Alur, Crupi, and
Malks, and others. The issues of how business objects get access to data
(or JDBC connections, or ...) are universal, not limited to Struts apps or
even web apps.
> CRM> If the StoresBean bean is in application scope (i.e. a servlet context
> CRM> attribute), then getStores() will go load up the list the first time *any*
> CRM> user requests it, then everyone will share. This makes sense if the data
> CRM> is global to all users. You would want to create this bean as part of
> CRM> your application startup, by either:
>
> CRM> * In servlet 2.2 or later, create a servlet that is configured for
> CRM> load-on-startup, and set it up in the init() method.
>
> Ok, I have set up some like this in the init() method of an
> IntializationServlet I call on startup:
> context.setAttribute( "storeList", storeList );
>
> CRM> * In servlet 2.2 or later, subclass the ActionServlet class in Struts,
> CRM> and override the init() method like this:
>
> CRM> public void init() throws ServletException {
> CRM> super.init();
> CRM> ... initialize context attributes here ...
> CRM> }
>
> OK! Perfect this is exactly what I should do. Thank you.
> (I take it there weren't be any issues doing this to my
> controller which extends DispatchAction).
>
Well, you can certainly do it there ... but it feels sort of hidden away
to me. You also have to be aware of thread safety for this, where the
init() method (or servlet context listener) is guaranteed to complete
before any request can be processed.
>
> Thanks Craig,
>
> Rick
>
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
