As a novice, but rapidly learning, Struts developer, I believe the logical place to put these checks is to subclass the RequestProcessor and override the processPreprocess() method with this logic?
I think your analysis is right on; it's not *wrong* to implement the security with a base abstract action, but when you do that, you lose your single inheritance (and incur some probably trivial extra overhead by performing more of the request processing cycle before stopping.) However, for a simple app or quick proof-of-concept, this is sometimes a good way.
Also, extending RequestProcessor can be mildly problematic if you have a few different kinds of changes you want to make to the request-processing life-cycle (again because of the limitation to single inheritance). You may be interested in experimenting with the (beta-quality) struts-chain package and it's "ComposableRequestProcessor", which allows you to define an arbitrary chain of commands for handling a request (and provides a default chain which recreates the standard RequestProcessor behavior.)
As soon as Struts 1.2.1 is released (Real Soon Now), we'll begin the process of converting the Struts core to use the chain request processor. I think that developers will find it very empowering to have fine control over the entire request processing life cycle, rather than only ever writing actions.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining."
-- Jef Raskin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
