Frank,
I think I get it. Static classes I get, but I guess I didnt consider
that any static member of a static class is always accessible. It
still strains my brain a little, actually, but I guess it makes sense.
so you'd recommend this above creating some hashtable and just
plunking it in Application scope then. What are the advantages of this
way over the "sticking it in app scope" method?
My only issue is that the application already has a few things hanging
off the ServletContext as attributes, and it would seem inconsistent
for maintenance I suppose..
----Separate thing-----
what about the problem where some of the stuff I'd need in my listener
is actually being set up in a struts plug-in (that's the way it is
currently)
On Mon, 14 Feb 2005 14:34:23 -0500 (EST), Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> On Mon, February 14, 2005 2:26 pm, David Johnson said:
> > Frank
> >
> > 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
>
> >
> > On Mon, 14 Feb 2005 14:15:28 -0500 (EST), Frank W. Zammetti
> > <[EMAIL PROTECTED]> wrote:
> >> Using a plugin only tells you WHERE your going to read the information
> >> in,
> >> not where your going to STORE it. I think that's the question you
> >> really
> >> want to ask. Plugins are pretty standard practice when dealing with
> >> Struts, but if you have a concern that you might not be using Struts at
> >> some point, you might want to do something else.
> >>
> >> In any case, where you put the data is the question. I'd still put my
> >> vote down for a static "storage" class. I do that, read the data in a
> >> plugin, stick it in the storage class, and I'm done. The storage class
> >> is
> >> pretty much nothing more than this:
> >>
> >> import java.util.HashMap;
> >> public class AppConfig {
> >> private static HasMap config = new HashMap();
> >> public static void setConfig(HashMap config) {
> >> this.config = config;
> >> }
> >> public static HashMap getConfig() {
> >> return config;
> >> }
> >> }
> >>
> >> I start my plugin by doing:
> >>
> >> HashMap config = AppConfig.getConfig();
> >>
> >> ...then read in whatever data I need, shove it in config, and final do:
> >>
> >> AppConfig.setConfig(config);
> >>
> >> Again, so long as this data isn't going to change, and it's not a huge
> >> amount of data, that's all there is to it. I don't know if this would
> >> be
> >> considered "best practice', but it's certainly "common practive" AFAIK
> >> :)
> >>
> >> --
> >> Frank W. Zammetti
> >> Founder and Chief Software Architect
> >> Omnytex Technologies
> >> http://www.omnytex.com
> >>
> >> On Mon, February 14, 2005 2:08 pm, David Johnson said:
> >> > Ah!
> >> >
> >> > After reading up on the Struts Plugins, I have the following question
> >> >
> >> > Are struts plugins a perfectly acceptable way to handle Application
> >> > level caching? How about best practices-wise?
> >> >
> >> > Thoughts?
> >> >
> >> > D
> >> >
> >> >
> >> > On Mon, 14 Feb 2005 11:03:24 -0800 (PST), Martin Wegner
> >> > <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> A PlugIn works nicely as well. I am not sure which is the
> >> recommended
> >> >> Struts practice.
> >> >>
> >> >>
> >> >> --- Wendy Smoak <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> > From: "David Johnson" <[EMAIL PROTECTED]>
> >> >> > > I have a need in an app I'm working on to cache data that is
> >> valid
> >> >> and
> >> >> > > shared across users, like standard country codes, region codes,
> >> >> > > industry codes... stuff like that.
> >> >> > >
> >> >> > > What's the best way to do that with my struts 1.2 application? Is
> >> >> > > there something built in that I'm not aware of that I can
> >> leverage
> >> >> or
> >> >> > > any best practices you guys can point me toward?
> >> >> >
> >> >> > I use a ServletContextListener that puts a bunch of Maps and other
> >> >> > resources
> >> >> > in application scope. (Then I use a HttpSessionListener to set up
> >> >> > user-specific things.)
> >> >> >
> >> >> > --
> >> >> > Wendy Smoak
> >> >> >
> >> >> >
> >> >> > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >> >
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > -Dave
> >> > [EMAIL PROTECTED]
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> > --
> > -Dave
> > [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
--
-Dave
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
