Re: Caching Appliction Level Data?

["Frank W. Zammetti" <fz...@omnytex.com>]

>> I see what you mean. I was assuming I'd just store the data in a
>> hashtable or something in the Application Context
>
> That's what I think Wendy suggested, and it's probably a better idea than
> what I do frankly :)
>
>> I have stupid question...where is your AppConfig actually getting
>> stored? I'd think you'd need to do the above at some point and do a
>

No question is stupid :)

>
>> getServletContext().setAttribute( AppConfig, "myAppInfo");
>>
>> oh boy what am I missing.. or was that implied.. OR did I miss your
>> hwhole point? I really hope it's not the last one ;)
>
Your forgetting some basic Java is all (and everyone does it from time to
time, regardless of what anyone might claim :)

A member of a class that is static is always present in the CLASS,
independent of any instance of that class.  For instance:

 public class myClass {
   public static int PI = 3.14159;
 }

Now, if you have another class that wants to use PI, you just do:

 public class test {
   public void showPI() {
     System.out.println(myClass.PI);
   }
 }

No instance of myClass is created, yet you can access the PI member of it
through the instance of the CLASS... That's sometimes confusing to
people... The way I learned to think of it is that the JVM (the class
loader specifically) in a sense does automatically creates an instance of
the myClass class, but an instance that ONLY contains the static members.
That's not actually what happens AFAIK, but IN EFFECT it is.

As long as the two classes are loader by the same class loader, your good
to go.

>> For this app it's safe to assume we'll always be using struts (btw)
>
Then a plugin is safe.  But, as others have said, it's just about as easy
to do it other ways, so you may as well have one less Struts tie-in.  And
as Vic I think said, DAOs are the best-practice (one I haven't had cause
to use yet myself, but I in *no way* disagree with his point).

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org