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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
