Yeah, that's all reasonable. Well, back to the filter then :)
One thing you may want to do is have a look at the filters in Java Web
Parts (http://javawebparts.sourceforge.net). We have them all
implemented with some added flexibility in mapping to paths. At least
that way you can only fire it when really appropriate... well... in
reality, it's *still* firing, but hopefully doing a lot less work than
it might otherwise need to. You can rip off the code for that extra
ability (it's in the FilterHelpers class).
Then again, I may be micro-optimizing here... maybe for what your filter
is doing it won't be that heavyweight anyway. Sounds like that may be
the case. So, even if you mapped it to *.do for instance, it might not
really be a problem.
Frank
Quinn Stone wrote:
OK. I contemplated creating a base class, but didn't like the idea of having to
create a basically empty Action class for Actions that use ActionForward to
forward to a jsp for display without calling an Action. And, frankly, thought it
would be more complex to go learn the order of method calls of
LookupDispatchAction to figure out what to override and when and how I return
without bypassing some necessary processing. Sometimes I like the easy way out
(as long as it's not crappy).
Q
-----Original Message-----
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Friday, April 07, 2006 8:24 PM
To: Struts Users Mailing List
Subject: Re: Servlet Filter?
Hi Quinn,
Quinn Stone wrote:
1. Does the Servlet filter seem a good solution?
Yes, but not quite as described, and ironically its because of the
answer to #2 :)
2. If I throw an EnrollmentDingBat exception from said Servlet Filter, will a
handler defined in <global-exceptions> catch it? My suspicion is that the
filter
might executing too early, before struts mechanics cut in.
No, it won't. As you suspect, the filter fires before Struts gets involved.
However, what you *can* do, is simply forward somewhere from the filter.
It could be straight to a JSP, or it could be to an Action mapping,
whatever is appropriate.
I think using a filter is generally a decent idea, but one thing to
consider: what are you going to map it to? It sounds like you have many
possible URLs that you would need to check, hence the reason for wanting
some "central" checkpoint in the first place. The problem is, the
filter is of course going to fire for *any* mapped request
indiscriminately. While filters, unless poorly written, tend to not add
a horrible amount of overhead, you may not want to add any at all where
it isn't necessary. So, onto #3...
No, three questions:
3. Any better ideas?
I would probably do it instead with a custom Action base class that your
other Actions extend from. Then, only extend from it those Actions
where this check is needed. I mean, if you determine its needed for all
of them, or nearly all of them, then I'd probably go with the filter.
If you can narrow it down to just a handful though, the custom base
Action might be a better answer.
Q
HTH,
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
