: Tuesday, September 10, 2002 2:11 PM
To: 'Tomcat Users List'
Subject: RE: Managing a Listener
Craig,
I have had some of the same issues to deal with. I accomplished this using
a filter instead of a listener. The reason I used a filter is because it
had access to the request and response information
, etc.
If this is not enough to get you started, I would be happy to fill in some
more specifics.
Doug Srofe
WDS interaktiv
-Original Message-
From: Craig Longman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 1:56 PM
To: tomcat-user
Subject: Managing a Listener
i have a need
Why not just use a properties file?
John
-Original Message-
From: Craig Longman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 2:19 PM
To: Tomcat Users List
Subject: RE: Managing a Listener
On Tue, 2002-09-10 at 14:11, Srofe, Douglas (c) wrote:
Craig
need to do anything with sessions).
-Original Message-
From: Craig Longman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 1:56 PM
To: tomcat-user
Subject: Managing a Listener
i have a need for some data that is needed by every page. Ideally, this
would
i have a need for some data that is needed by every page. Ideally, this
would simply be a class that is shared by everything else in one webapp
subdirectory, and available in the page context or session.
the only way i can see to do this (based on the docs at least) is to
configure a Listener
Why not create a singleton class to hold the information?
-Original Message-
From: Craig Longman [mailto:[EMAIL PROTECTED]]
Sent: 10 September, 2002 11:56 AM
To: tomcat-user
Subject: Managing a Listener
i have a need for some data that is needed by every page. Ideally, this
would
be anything you want, like a pointer to a properties file
or anything else.
John
-Original Message-
From: Craig Longman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 2:54 PM
To: Tomcat Users List
Subject: RE: Managing a Listener
On Tue, 2002-09-10 at 14:21
: Managing a Listener
On Tue, 2002-09-10 at 14:58, Turner, John wrote:
From the 4.0 docs:
where did you find this? i'm trying to figure out how the
listener can
obtain basic site configuration info like loggers and directories now,
but i can't seem to find anything that takes about
want it to be configured
from the server.xml file as much as possible, hard-coding things always
seems to cause problems at some point.
-Original Message-
From: Craig Longman [mailto:[EMAIL PROTECTED]]
Sent: 10 September, 2002 11:56 AM
To: tomcat-user
Subject: Managing a Listener
-Original Message-
From: Milt Epstein [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 2:14 PM
To: Tomcat Users List
Subject: RE: Managing a Listener
On Tue, 10 Sep 2002, Turner, John wrote:
From the 4.0 docs:
If you have implemented a Java object that needs
-
From: Craig Longman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 1:56 PM
To: tomcat-user
Subject: Managing a Listener
i have a need for some data that is needed by every page. Ideally, this
would simply be a class that is shared by everything else in one webapp
logger from a
filter. whew.
-Original Message-
From: Craig Longman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 10, 2002 2:19 PM
To: Tomcat Users List
Subject: RE: Managing a Listener
On Tue, 2002-09-10 at 14:11, Srofe, Douglas (c) wrote:
Craig,
[...snip
it to be configured
from the server.xml file as much as possible, hard-coding things always
seems to cause problems at some point.
-Original Message-
From: Craig Longman [mailto:[EMAIL PROTECTED]]
Sent: 10 September, 2002 11:56 AM
To: tomcat-user
Subject: Managing a Listener
i
On 10 Sep 2002, Craig Longman wrote:
On Tue, 2002-09-10 at 15:48, Durham David Cntr 805CSS/SCBE wrote:
Here's an example:
web-app
listener
listener-classpackage.Listener/listener-class
/listener
/web-app
I think this is what you should do if you are just initializing
On Tue, 2002-09-10 at 14:58, Turner, John wrote:
From the 4.0 docs:
[...snip...]
Note that a Listener can have any number of additional properties that may
be configured from this element. Attribute names are matched to
corresponding JavaBean property names using the standard property
On 10 Sep 2002, Craig Longman wrote:
On Tue, 2002-09-10 at 18:16, Milt Epstein wrote:
Remember, you're talking about a context listener, not a servlet
listener. Their lifecycles are different. The servlet lifecycle is
pretty well known -- that is, it is possible that servlets can be
On Tue, 2002-09-10 at 14:58, Turner, John wrote:
From the 4.0 docs:
where did you find this? i'm trying to figure out how the listener can
obtain basic site configuration info like loggers and directories now,
but i can't seem to find anything that takes about listeners
--
On Tue, 2002-09-10 at 15:48, Durham David Cntr 805CSS/SCBE wrote:
Here's an example:
web-app
listener
listener-classpackage.Listener/listener-class
/listener
/web-app
I think this is what you should do if you are just initializing
some objects. I'm using this on a project to
On Tue, 2002-09-10 at 18:16, Milt Epstein wrote:
Remember, you're talking about a context listener, not a servlet
listener. Their lifecycles are different. The servlet lifecycle is
pretty well known -- that is, it is possible that servlets can be
created and destroyed by the servlet
On Tue, 2002-09-10 at 19:53, Milt Epstein wrote:
On 10 Sep 2002, Craig Longman wrote:
well, i'm going to have to be very careful. i have no idea what context
i'm receiving, but it doesn't appear to be the ActionServlet, there are
no init parameters in it at all.
I'm confused (or
On 11 Sep 2002, Craig Longman wrote:
On Tue, 2002-09-10 at 19:53, Milt Epstein wrote:
[ ... ]
As to init parameters, I'm not sure what you're trying to do with
them, but note that you can set up context parameters in the web.xml,
and that you can get the context (via the
On Wed, 2002-09-11 at 02:08, Milt Epstein wrote:
On 11 Sep 2002, Craig Longman wrote:
Back to basics: A servlet container will have a bunch of contexts (aka
web applications), and each context will have a bunch of servlets/JSPs
(where a bunch of basically means one or more).
with ya.
Each
22 matches
Mail list logo
