Perhaps I'm missing something, but I don't think moving initialisation into the *request processor* is tidy at all. Initialisation should happen before any requests come in.
Well, it would, in the sense that RequestProcessor has a "init" method. We're not talking about totally lazy initialization here, just whether the ActionServlet should have any concern for initializing commons-chain behavior if the only component which uses commons-chain is the ComposableRequestProcessor
I do believe that we should be splitting out the whole config / init mechanism so that we can provide alternative ways of doing that. That's something that's been on my personal to-do list for some time, but hasn't bubbled to the top yet.
+1 - all that config doesn't belong in ActionServlet as it is now. but it's not my top priority either.
> More immediately, though, whether we change it or move it into thedefault RequestProcessor, I have no problem with having it check first for the presence of the tiles version of the chain config and then for the default; since it's just a String value (for the classpath URI), it's not a true dependency, and I think the value for users would be considerable.
Does anyone object to testing for the tiles config first? And does anyone have any strong feelings about where the chain initialization code lives?
I do, I guess. The goal should be *no* knowledge of Tiles outside of Tiles itself. If we can't do that, then we're not properly extensible. I know we're not there yet, but testing for Tiles first is a step in the opposite direction, IMO.
Fair enough. It's not like we can't express in extremely simple terms how to set up Struts to use the tiles version of chain-config.xml -- I think packaging it in the struts-tiles.jar is good-enough for user friendliness.
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]
