Sorry Craig, I just realized I misread some of what you originally
wrote. You were talking about sharing 'across' applications and I
wasn't concerned with that so much. You can ignore my previous post. I
apologize.

Rick

On Wednesday, June 26, 2002, 3:16:11 PM, Rick wrote:

RR> Thanks so much Craig, this has been tremendously helpful! Some
RR> comments below...

RR> 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.

RR>      Ok, you've started to clear some things up for me. I always
RR>      thought thought that classes in my: myAppDir/WEB-INF/classes
RR>      directory if they had static members they were shared across the
RR>      entire application scope? This definitely is wrong though? (and
RR>      it's only session scope?).

RR>      In your above code, though, each user session would then end up
RR>      loading a new list of stores. I don't really need that. I only
RR>      need that list being loaded once and shared amongst all the
RR>      sessions.

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().

RR>      How would I grab this "global" attribute from a business layer
RR>      object though? I guess that's where I'm getting confused. Say I
RR>      have my Action class call a business object:
RR>      BO.getStoresList()
RR>      Well now I want the BO to return me a List of StoreBeans, but I
RR>      only want that list populated ONE time and want all the sessions
RR>      to share it.It looks like if I want all the sessions to share the information
RR>      I have to pass servlet classes into my model layer? Am I wrong
RR>      there?

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.

RR>        Ok, I have set up some like this in the init() method of an
RR>        IntializationServlet I call on startup:
RR>        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>>     }

RR>          OK! Perfect this is exactly what I should do. Thank you.
RR>          (I take it there weren't be any issues doing this to my
RR>          controller which extends DispatchAction).


RR>          Thanks Craig,

RR>          Rick


RR> --
RR> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
RR> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




-- 

Rick
mailto:[EMAIL PROTECTED]

"Sometimes you have to be careful when selecting a new name for
yourself. For instance, let's say you have chosen the nickname 'Fly
Head. Normally you would think that 'fly Head' would mean a person who
has beautiful swept-back features, as if flying through the air. But
think again. Couldn't it also mean 'having a head like a fly'? I'm
afraid some people might actually think that." 
  -Jack Handey


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to