struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <ted.hus...@gmail.com>
Subject Re: Struts 1.3.x: Using multiple chain configurations
Date Fri, 30 Jun 2006 12:02:31 GMT
That's exactly what Struts 2 does with interceptors, and S2 takes it a
step farther by allowing each action to have its own sequence, if you
like.

An important question is whether we want to stick with Chain in the
Struts 1.x series or consider moving to Interceptors for Struts 1.4.

I didn't understand interceptors when we started the Commons Chain
work, but now that I do, it looks like we reinvented the wheel.

-Ted.

On 6/30/06, Phil Zoio <philip.zoio@iogloballtd.com> wrote:
> Joe,
>
> Could Struts 1.3 set up to have a separate chain per module? Suppose you
> wanted to partition your app so that certain parts use one chain
> configuration and other parts use another. In 1.2 you'd use separate
> subclasses of RequestProcessor. With Struts 1.3, ideally you should be
> able to use separate chains. You could for example build a lightweight
> chain to handle parts of the application with specific performance
> requirements, and the standard chain for other parts.
>
> Bearing in mind that a chain is a pretty lightweight object - there will
> only be one instance of each command in memory per chain.
>
> Any module would by default get the basic pre-supplied chain
> configuration. However, you would be able to override this using a
> web.xml entry in the same way that you set up modules.
>
> Phil
>
>
> > Joe Germuska wrote:
> >
> >> At 9:09 PM +0100 6/14/06, Phil Zoio wrote:
> >>
> >>> I can't comment on how people are actually using it, but changing
> >>> the request processor workflow on a per module basis is quite easy
> >>> with Struts 1.2. Assuming that this is something which some people
> >>> are doing, then it would seem to make sense to support this for
> >>> Struts 1.3 as well, at least for the interests of consistency with
> >>> previous versions, especially if the 1.2 request processor has been
> >>> earmarked for deprecation.
> >>
> >>
> >>
> >> Phil:
> >>
> >> Have you looked at what is required to change the workflow in Struts
> >> 1.3 on a per-module basis?  Can you point out where you think it's
> >> unnecessarily complicated?  Do you have any ideas about how to do it
> >> differently?
> >>
> >> Joe
> >>
> >>
> >>> At 9:23 PM +0100 6/13/06, Phil Zoio wrote:
> >>>
> >>>> Is it possible to have multiple chain configurations for the same
> >>>> Struts 1.3 app. For example, can you configure one module to use
> >>>> tiles and another to not do so?
> >>>
> >>>
> >>>
> >>>
> >>> It is technically possible to change which command is looked up in
> >>> the catalogs and executed to process the request as part of the
> >>> controller-config on  per-module basis.  However, you'd need to go
> >>> to some greater lengths to define the necessary commands and
> >>> catalogs, because the distributed chain-config.xml in both
> >>> struts-core and struts-tiles use the same catalog name.  The idea
> >>> was to minimize the places where a user would need to change
> >>> configurations to use Tiles.
> >>
> >>
> >>
> >>>
> >>> For the specific case you cite, there's really no need to do
> >>> anything special, since if you are using the Tiles request
> >>> processing chain, nothing prevents you from using ActionForwards
> >>> which do not point to tiles paths intermixed with those which do.
> >>> Just use the chain-config packaged in struts-tiles (as indicated at
> >>> http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d)
> >>>
> >>>
> >>> If people end up doing a lot of mixing and matching of chain
> >>> catalogs, we would want to make this easier than it is now, but so
> >>> far we just don't know enough about if or how people are likely to
> >>> want to do this, so it's hard to know how to make it easier.
> >>>
> >>
> >>> Joe
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >
> >>
> >>
> >>
> >
> >
>
>
> iO global limited, Registered in England No. 05269056 Reg. Offices: G10 B83 Columba House,
Martlesham Heath, Ipswich, Suffolk. IP5 3RE
>
> This electronic message contains information from iO global limited which may be privileged
or confidential. The information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any disclosure, copying,
distribution or use of the contents of this information is prohibited. If you have received
this electronic message in error, please notify us by telephone or email (to the numbers or
address above) immediately.
>
> This email does not constitute a contract. E&OE
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


-- 
HTH, Ted.
* http://www.husted.com/struts/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message