Frank, thanks for the link to javawebparts. The source code there helped me a
great deal.
Dakota, thanks for that very detailed explanation of creating my own dispatcher,
but I chose to use a filter for now. I'm just not ready to go change the buttons
and existing actions at the moment. I'll look at the code you provided and maybe
if I get ahead of timeline (yah, right) I'll make the move.
So, I'm the big ding bat. I totally whiffed on the "what are you going to map
to" comment made by Frank because I was under the impression that you could
define <url-mappings> with something like "/Enroll*.do". I decided to just do a
path.startswith("/Enroll") to determine whether to make the check for the
session bean. It seems to be working. I started out with configurable paths and
ignorelists, but then thought "you know what, this is a very specialized filter,
I don't want someone to fiddle with configuration parms without thinking about
it."
My next question is whether there's a mechanism by which I can stick an
ActionError in the request so that the error page can display a message to the
user using the familiar Struts <html:messages> tag.
Q
> -----Original Message-----
> From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 07, 2006 10:03 PM
> To: Struts Users Mailing List
> Subject: Re: Servlet Filter?
>
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
