Its probably academic, but since CRP extends RP then it seems
incorrect to deprecate the whole class with a view to removing in the
future. Wouldn't it be more correct to deprecate all the protected
methods (e.g. processActionCreate(), processActionForm etc.)?
Perhaps we should consider what the desirable end point is - IMO CRP
becoming the RP seems like a good idea...so maybe the steps should be
something like the following:
1) Deprecate the protected methods in the RP.
2) Remove RP deprecated methods and move the CRP logic into RP.
Deprecate the CRP.
3) Remove deprecated CRP.
I would agree that this is more correct. However, deprecating CRP
would be annoying if people had reason to extend the
ComposableRequestProcessor, which for a brief while was the only way
to cause Struts to use a custom implementation of the ActionContext
interface; that specific issue has been corrected now that you can
instead provide an implementation class name, but there are still
some potential bootstrapping issues if you wanted to have your custom
ActionContext class be initialized in some special way before it was
launched on its path down the chain.
I'm an avid user of custom ActionContext implementations to provide
typesafe control of key application objects stored as request and
session attributes (i.e. context.getAuthenticatedUser(), etc). I
have not needed any special initialization, and I suspect that you
could achieve that kind of stuff in a command at the beginning of
your chain, since the RequestProcessor doesn't have references to
anything that isn't also in the ActionContext. Still, it might be
worth a few other sets of eyes looking at how that works.
For actual request processing, it seems clear that all those
protected methods are superceded by commands; it's just the set-up
(and possibly teardown?) that are still new enough that it's hard to
know.
Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
