struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject Re: Thoughts on 1.3.x
Date Thu, 29 Jun 2006 13:45:55 GMT
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
Joe@Germuska.com * 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message