how do you manage cross container caches if you are clustered - when
you are using static members on classes? How do guarantee sameness on
different physical machines? We do have a few caches in our
application and are facing issues due to this design or an improperly
implemented version of this design.
Thanks.
On Mon, 14 Feb 2005 15:01:21 -0500 (EST), Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> On Mon, February 14, 2005 2:53 pm, David Johnson said:
> > 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.
>
> Yeah, static is one of those things that people tend to get confused about
> early on. Don't worry, time will make it rather clear and you'll
> eventually wonder how there was ever a time it didn't make 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?
>
> Hmm... Honestly, I never thought much about benefits over anything else :)
> Thinking about it NOW though, the only one that comes to mind is that
> "sticking is in app scope" is tieing you to a servlet environment. Think
> of it this way... ideally, each part of your application should be
> testable on it's own, even OUTSIDE Tomcat or whatever servlet container
> your using (I think you said Tomcat and maybe Weblogic eventually?)
>
> If you just have a static class, it's a POJO (Plain Old Java Object),
> which means you can test it to your hearts' content without Tomcat.
>
> Not this the class I posted would need much testing :) But still.
>
> > 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..
>
> That's a fair point, especially to someone like me who tends to be overly
> anal about consistency :) I would argue that you may not want whatever
> you have hanging off ServletContext to be there either, for the same
> reason as above. If you know your app would never need a different
> presentation then it's not really a concern, but building flexibility into
> a design at all levels makes life easier later when the inevitable scope
> creep comes out to bite you :)
>
> Frank
>
> > ----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]
> >
> >
>
> ---------------------------------------------------------------------
> 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]
