At 5:34 PM -0700 6/28/06, Paul Benedict wrote:
I have two concerns on the 1.3.x line. What do you think?
1) Spring 2.0 has fabulous support for dependency injection for
Struts. In particular, the great Autowiring(Tiles)RequestProcessor
will automatically inject dependencies into the actions as they are
created. This supports the "legacy" RequestProcessor and I have no
personal plans to depart from its use. So my question today is: does
the RP in 1.3 function just as it did in 1.2? If not, I may not want
to upgrade to 1.3.x until it does.
You can use an AutowiringRequestProcessor in Struts 1.3, but you will
not gain any behavior which has only been implemented in commands
since Struts 1.2. Specifically, any action mapping or forward
mapping can specify a chain command which should be executed as part
of processing.
As far as I can remember (but don't bet money), none of the other
major functional changes in 1.3 are in the chain commands only. You
could probably go for a while using some other subclass of
RequestProcessor instead of ComposableRequestProcessor, but I think
everyone is on board in general with deprecating the original request
processing functionality, so over time, this statement is likely to
become less true.
Also, as Frank noted, it is pretty easy to write custom commands that
get actions in a different way, and in fact, in general, the whole
point of this is that it is much easier now to make changes to the
request processing cycle without having to have an infinite
combination of request processor classes which all have different
lineages depending on whether you want or don't want Tiles
processing, want or don't want X, want or don't want Y, etc.
Admittedly, if lots of people embrace casually changing the RP chain,
we will have some work to do in making that a little more
straightforward, but it's far from a huge burden now.
2) I learned the tough way that it is [a] impossible to write a
stateless application in Struts and [b] use Struts' locality
features at the same time. This is because Struts only stores the
locale in the session, and there is no way (currently) to move that
into a cookie, or into request scope. I found scattered code among
RequestProcessor, RequestUtils and TaglibUtils which look only into
the session for the current locale.
I propose (and I will write this) that we allow pluggable
implementations into how to store the locale. It will be defaulted
into the session, with other pluggable implementations provided.
However (sorry fans of CoR) this implementation must be wrapped into
a bean so that other libraries, like Tiles and Taglibs, can retrieve
the locale and set it without knowing the pluggable strategy. So the
solution itself cannot be limited to the RP chain, even though that
is where it is initiated.
I don't see any problem with that. Being a fan of the composable
request processor isn't the same as being a zealot who wants the CRP
to do everything!
I think this just raises one of the fundamental weaknesses of Struts
1.x - the lack of a dependency injection management system leaves the
process of setting up services for use by multiple components in a
fragile and awkward state. I have really soured on the idea that
everything should just be thrown into the ServletContext to be found
by whomever needs it.
That said, I don't think you should not do the work you describe,
just because you may have to leave the Localizer (or whatever you
call it) in the ServletContext under a well known key. It's just
that it feels so outdated!
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]
