Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (hermes.apache.org: domain of chachany@gmail.com designates
 64.233.170.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=t0AMVNun9fBgDI8rrpXklx0fUskOD01ePR9ZNHdiQ3PoxBXy2U1cqiBqyH+BSV+Y7zalKPmDdph3fgCAHcFl4h3KkmdCzmpy4jv88P6I7FZDefLJ9uv0p5TM49MTJU/2kQxCqSBfA/n/aIhaP7gOmYRMDxRc+secbZTm9rcVR0M=
Message-ID: <8aef647c05021411203ee1a1a8@mail.gmail.com>
Date: Mon, 14 Feb 2005 14:20:50 -0500
From: David Johnson <chachany@gmail.com>
Reply-To: ChaChaNY@GMail.com
To: Struts Users Mailing List <user@struts.apache.org>, craigmcc@apache.org
Subject: Re: Caching Appliction Level Data?
In-Reply-To: <8aef647c05021411161afea1d0@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <02b401c512bf$6fe55080$28ad93d1@irm.local>
	 <20050214190325.5142.qmail@web53804.mail.yahoo.com>
	 <f8b39ace0502141110297f021e@mail.gmail.com>
	 <8aef647c05021411161afea1d0@mail.gmail.com>

Another question....

Currently, I'm modifying an alplication that HAS a struts plug-in for
creating Application wide stuff... the thing I want to create will
depend on that "stuff" already being there, so would it be safe to
assume that it will exist if I simply implement a vanilla
ContextListener and try to load up stuff in the ContextInitialized?

My fear is that in the ContectInitialized, I need things like my DB
info, and some other stuff that gets attended to in the struts plug
in... and what if it's not there?

Would it be safer to create ANOTHER struts plug in below the existing
one that does the loading up of my application wide data (country
codes etc)

Discuss

P.S., I'm reading furiously in the "professional java server
programming" book as I write this ha ha ha


 14 Feb 2005 14:16:17 -0500, David Johnson <chachany@gmail.com> wrote:
> I see your points. We arent sure yet what version of Weblogic we'll be
> deploying to, but I'm developing in Tomcat. Sounds like an open
> question to me.
> 
> Where would you point me to learn how to do this the  ContextListener way?
> 
> 
> On Mon, 14 Feb 2005 11:10:19 -0800, Craig McClanahan <craigmcc@gmail.com> wrote:
> > On Mon, 14 Feb 2005 11:03:24 -0800 (PST), Martin Wegner
> > <marty_wegner@yahoo.com> wrote:
> > >
> > > A PlugIn works nicely as well.  I am not sure which is the recommended
> > > Struts practice.
> >
> > If you're on a Servlet 2.3 or later container (which is when
> > ServletContextListener was introduced), you should use it instead of
> > plugins:
> >
> > * There are also other listeners that you should
> >  explore which are available in this version -- did
> >  you know, for example, that you can be notified
> >  whenever anyone else in your app adds, removes,
> >  or replaces an application or session scope attribute?
> >  (In Servlet 2.4 you can do this for request scope too.)
> >
> > * The way a Struts plugin is implemented is to have
> >  the init() and destroy() methods called from the
> >  corresponding methods on ActionServlet.  Technically,
> >  an app server is allowed to destroy servlet instances
> >  any time it wants to, so you're not guaranteed that destroy()
> >  *really* means the application is shutting down.
> >
> > * Context listeners work in non-Struts apps too;
> >  one less concept to learn.
> >
> > Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> 
> --
> -Dave
> ChaChaNY@Gmail.com
> 


-- 
-Dave
ChaChaNY@Gmail.com

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