Joe had mentioned wanting to move module init code to the
ModuleConfigFactory.

I did? ;-)

Seriously, though, I don't quite remember the details of that discussion -- do you happen to have any pointers to the archives?

I think in general, the idea is to make ActionServlet do little more than receive requests and broker them off, with the more general idea of making Struts clean of unnecessary dependencies on the Servlet API. Thus, moving as much setup as possible out of there seems theoretically good, although I don't know if it needs to be the first step -- considering how Action and ActionForm have direct dependencies on that API, it may be a lot of ceremony for relatively little payoff.

As a general strategy, I think stuff in ActionServlet now should move off to a "StrutsApplication" which would deal with bootstrapping and with assigning requests to modules for processing. (As today, the per-module request processor would do the bulk of the work, referring to its own ModuleConfig for necessary information and resources.)

Was there some detail that I'm forgetting now which makes the factory the right place for it? But assuming I was harping on the same old riffs, I was probably somehow trying to get at "reduce direct dependencies on Servlet API".

But most importantly, I think it would be best to get decent working code in place; we will be continually refactoring, so adding/changing stuff where it already is would be no great sin. And if we don't have many use cases in mind for non-Servlet Struts usage, we may make some errors in generalizing certain things, so no need to rush. (Always remember, though, that unit testing is a non-Servlet Struts use case, so just thinking about how to make things more testable may help reach a good generalization.)

On the other hand, if it seems easy and straightforward to make an incremental improvement as part of this process, great!

Joe

--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to