struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <>
Subject RE: DO NOT REPLY [Bug 21821] - taglibs requesting certain RequestUtil methods fail if page access not through ActionServlet
Date Thu, 24 Jul 2003 00:43:50 GMT
I think Steve's limited patch to solve the backward compatibility problem
is reasonable.  I don't think we should be changing any tags or other code
to support direct JSP access.


--- Steve Raeburn <> wrote:
> > What is the point of having a front controller if you then have
> > to have code
> > all over the place that checks to see if it was invoked, and if
> > not, do its
> > job for it? This issue is much bigger than just getting taglibs
> > and modules
> > to work together. The implication is that tags should continue to work
> > correctly in the absence of *any* per-request processing the
> controller
> > does. Think about that for a minute. You'll also bypass the Tiles
> request
> > processor, and then expect Tiles to work correctly in your JSP pages.
> Who
> > knows what else?
> If a developer wants to use features such as Tiles or Modules then I
> think
> the onus is on them to understand the implications of that decision. If
> a
> requirement of the feature is that the request must go via the
> ActionServlet
> then that's just one of the things that needs to be documented and
> adhered
> to.
> With a simple JSP, such as a Welcome page you don't actually need to go
> via
> the ActionServlet but you may want to use a Struts tag in the page. This
> might not be best practice but it's easy and (arguably) appropriate for
> very
> simple pages. And lots of people do it, including us as evidenced by the
> Struts web apps.
> I'm not suggesting checks all over the place and I'm not suggesting that
> *all* tags should operate independently of the RequestProcessor.
> However,
> many tags do not *need* that environment to function. Struts has allowed
> this up until now and what you are suggesting is IMHO a significant
> change.
> I don't think it's reasonable to enforce restrictions on other users who
> don't need that feature UNLESS there's no alternative. I'm not convinced
> that there is no alternative because it appears that a minor fix allows
> the
> status quo to continue and doesn't interfere with the modules
> enhancements.
> > > Any directly accessed JSP would be assumed to be
> > > part of the default module and the message resources obtained
> > accordingly.
> > > If  you try to access a JSP directly *and* expect it to work as
> > part of a
> > > module *then* you deserve all that's coming to you ;-)
> >
> > The problem is that this behaviour will cause even *more* confusion
> when
> > people try to use modules. We specifically tell people that their
> existing
> > apps should "just work" when dropped in as a non-default module.
> > But if they
> > are accessing JSP pages without going through the controller, they
> will
> > suddenly find that the wrong message resources are being picked
> > up. Wouldn't
> > it be better for them to see an error message, rather than having
> > to figure
> > out what happened by themselves?
> >
> > --
> > Martin Cooper
> >
> At the moment, anyone who tries to upgrade to the nightly build would
> get an
> nasty NullPointerException which I definitely don't think is better. If
> it's
> a choice between explaining to *everyone* that they *must* go via an
> Action
> and amending the advice to modules users that they can only drop their
> app
> into a module if they don't directly access JSPs then I'm for the
> latter.
> I'm certainly not bent on ensuring at all costs that we allow developers
> to
> directly access JSP pages, but that if we can continue to do so without
> compromising the new features then we should.
> The suggested patch allows existing applications, including the struts
> web
> apps, to keep on working while allowing the additional module changes to
> work. I'd say that was win-win :-)
> Steve
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message