You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2004/12/17 21:13:21 UTC
"extends" (was Struts chain integration)
Personally, I favor the approach Cocoon takes to "modules". Cocoon is
configured to use one sitemap (config file), but that sitemap can mount
or include other sitemaps through the "mount" element. See
http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Mounting+sitemaps
Using wildcards, we could support a <mount> element which would
basically mount a module config. <mount> could also be used as an
include to include another struts config file full of definitions for
the current module. Therefore, a module mount in Struts would look like
this:
<action-mapping path="foo/*">
<mount uri-prefix="foo" src="/WEB-INF/struts-config-foo.xml" />
</action-mapping>
This simplifies the config and, IMO, makes the module design much more
readable and straight-forward.
Getting back to the "extends" idea, if we adopted an approach like
described above, the main config file could have configuration elements
that would automatically be inherited by modules, unless overridden.
This would also let us break up config files for single modules, and
even enable module hierarchies. Course the devil is in the
implementation details :)
Don
Martin Cooper wrote:
<snip />
>I'm not keen on adding init params in general, and even less keen on
>adding such params that take lists of files.
>
>I do think we need to have a mechanism for specifying global stuff,
>but I think we can come up with a better way. For example, I don't
>like that I have to replicate the <controller> config in each module's
>struts-config.xml in a multi-module app. That's error prone.
>
>We've talked about allowing for <extend> for things like form bean
>definitions. What about having this concept right at the top of the
>config scheme? So I could define a global struts-config.xml file
>(which wouldn't be used directly by any module), and then <extend>
>that file to provide module-specific config files.
>
>If we added an optional section to struts-config, we could then
>specify a list of Chain config files in there.
>
>
>
>>I would suggest skipping the chainConfig and chainCommand parameters
>>in the web.xml in favor of explicitly setting them in each
>>controller. Too many config options can be more trouble than they
>>are worth.
>>
>>
>
>+1
>
>
>
>>The discussion of how to configure the Controller or the
>>RequestProcessor touched off a lot of talk earlier on struts-dev, but
>>I'd be happy to settle for two properties on ControllerConfig just to
>>move forward.
>>
>>
>>
>>>>>struts-config.xml
>>>>>- The default request processor class would now be
>>>>>ComposableRequestProcessor, but the legacy ones would still be available
>>>>>(deprecated)
>>>>>
>>>>>
>>>>+1. One thing that I'm a little confused about, though, is that the
>>>>new request processor is (currently) in a package that includes
>>>>'legacy'. Anyone know why that is?
>>>>
>>>>
>>I don't know, but I think we should move it out to
>>o.a.s.chain.ComposableRequestProcessor.
>>
>>
>
>Fine with me.
>
>
>
>>>>>- The controller would have additional optional attributes:
>>>>>
>>>>>
>>I think the controller should simply have optional command and
>>catalog attributes which would be used like this:
>>
>>CatalogFactory.getCatalog(catalog).getCommand(command)
>>
>>if no catalog is specified, the "default" catalog is retrieved with
>>getCatalog(). If no command is specified, then these default values
>>would be used:
>>catalog = struts
>>command = servlet-complete
>>
>>
>
>I believe that's what's in place now.
>
>
>
>>If catalog were specified without a command, an exception would be thrown.
>>
>>I am still inclined to package most of what is now struts-chain
>>separately from the core.
>>
>>
>
>I'm not so sure I agree here. Most, if not all, of the commands you
>list below are used by the chain that you suggest as a default above.
>I think if we want the ComposableRequestProcessor to be the default
>for 1.3, we really need to keep the commands in the core as well.
>
>However, I do think they should be pushed into a separate package.
>Just as we have o.a.s.actions, we could have o.a.s.chain.commands for
>these.
>
>--
>Martin Cooper
>
>
>
>
>>This may be part of why I haven't moved as
>>quickly. Here are all the classes in struts-chain:
>>
>>org.apache.struts.chain.legacy.CatalogConfiguratorPlugIn
>>becomes obsolete
>>
>>org.apache.struts.chain.legacy.TilesPlugin
>>can be made obsolete if we remove the check in the base TilesPlugin
>>which insists on a specific request processor. I don't see any
>>reason not to do that.
>>
>>org.apache.struts.chain.legacy.ComposableRequestProcessor
>>org.apache.struts.chain.legacy.DispatchAction
>>org.apache.struts.chain.legacy.ChainAction
>>Move these three to core and up to o.a.s.chain
>>
>>org.apache.struts.chain.AbstractAuthorizeAction
>>org.apache.struts.chain.AbstractExceptionHandler
>>org.apache.struts.chain.AbstractExecuteAction
>>org.apache.struts.chain.AbstractPerformForward
>>org.apache.struts.chain.AbstractPerformInclude
>>org.apache.struts.chain.AbstractPopulateActionForm
>>org.apache.struts.chain.AbstractRequestNoCache
>>org.apache.struts.chain.AbstractSelectAction
>>org.apache.struts.chain.AbstractSelectForward
>>org.apache.struts.chain.AbstractSelectInput
>>org.apache.struts.chain.AbstractSelectLocale
>>org.apache.struts.chain.AbstractSelectModule
>>org.apache.struts.chain.AbstractSetContentType
>>org.apache.struts.chain.AbstractValidateActionForm
>>org.apache.struts.chain.Constants
>>org.apache.struts.chain.CreateAction
>>org.apache.struts.chain.CreateActionForm
>>org.apache.struts.chain.ExceptionCatcher
>>org.apache.struts.chain.SelectInclude
>>org.apache.struts.chain.UnauthorizedActionException
>>org.apache.struts.chain.util.ClassUtils
>>org.apache.struts.chain.servlet.AuthorizeAction
>>org.apache.struts.chain.servlet.ExceptionHandler
>>org.apache.struts.chain.servlet.ExecuteAction
>>org.apache.struts.chain.servlet.PerformForward
>>org.apache.struts.chain.servlet.PerformInclude
>>org.apache.struts.chain.servlet.PopulateActionForm
>>org.apache.struts.chain.servlet.RequestNoCache
>>org.apache.struts.chain.servlet.SelectAction
>>org.apache.struts.chain.servlet.SelectForward
>>org.apache.struts.chain.servlet.SelectInput
>>org.apache.struts.chain.servlet.SelectLocale
>>org.apache.struts.chain.servlet.SelectModule
>>org.apache.struts.chain.servlet.SetContentType
>>org.apache.struts.chain.servlet.TilesPreProcessor
>>org.apache.struts.chain.servlet.ValidateActionForm
>>
>>Move all of these to a Struts TLP like "legacy-chain" or perhaps just
>>"struts-chain". I wasn't involved in the initial implementation, but
>>I don't think these are something that belongs in the core. They
>>work fine, but I think the Abstract classes are over-engineered.
>>Also, I think we should move towards actions which operate on a
>>StrutsContext or ActionContext rather than having such a highly
>>configurable mechanism for looking up context-relevant objects (like
>>ActionMapping and ActionForward). I think the config for setting
>>context keys for each important object is an example of over
>>abstraction which make these harder to understand. This TLP would
>>also include a default chain-config which works with this set of
>>classes in the JAR.
>>
>>Is there a compelling reason to put specific command implementations
>>in the core? I kind of feel like it would be nice to feel less bound
>>to them.
>>
>>If we do this repackaging, perhaps it would make sense to change the
>>Java package for these classes. I don't have a strong opinion.
>>
>>Joe
>>
>>--
>>Joe Germuska
>>Joe@Germuska.com
>>http://blog.germuska.com
>>"Narrow minds are weapons made for mass destruction" -The Ex
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: "extends" (was Struts chain integration)
Posted by Don Brown <mr...@twdata.org>.
Martin Cooper wrote:
>On Fri, 17 Dec 2004 12:13:21 -0800, Don Brown <mr...@twdata.org> wrote:
>
>
>>Personally, I favor the approach Cocoon takes to "modules". Cocoon is
>>configured to use one sitemap (config file), but that sitemap can mount
>>or include other sitemaps through the "mount" element. See
>>http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Mounting+sitemaps
>>
>>Using wildcards, we could support a <mount> element which would
>>basically mount a module config. <mount> could also be used as an
>>include to include another struts config file full of definitions for
>>the current module. Therefore, a module mount in Struts would look like
>>this:
>>
>><action-mapping path="foo/*">
>> <mount uri-prefix="foo" src="/WEB-INF/struts-config-foo.xml" />
>></action-mapping>
>>
>>This simplifies the config and, IMO, makes the module design much more
>>readable and straight-forward.
>>
>>
>
>Interesting idea. I *really* need to find some time to read up on
>Cocoon! ;-) (Are there good books to read, or is the web site best?)
>
>The only thing that I'm not so keen on here is that the main site map
>needs to be modified to add or remove a "module". (Of course, the way
>modules are in Struts today requires the modification of web.xml,
>which is essentially equivalent.)
>
>In one of the larger apps I've done, I needed to be able to add and
>remove modules as product components were installed and removed. Since
>I don't trust installers much, I didn't want them to have to modify
>any files. So I adopted an approach whereby I had each module live
>under WEB-INF/modules/foo, and I customised the Struts initialisation
>code to read all the module configs from there. Installing a module,
>then, meant dropping in a new subdirectory, and uninstalling it meant
>simply blowing that directory away.
>
>
Good point. To dynamically allow modules, you could just use this mount:
<action-mapping path="*/*">
<mount uri-prefix="{1}" src="/WEB-INF/modules/{1}/struts-config.xml" />
</action-mapping>
Don
>
>
>>Getting back to the "extends" idea, if we adopted an approach like
>>described above, the main config file could have configuration elements
>>that would automatically be inherited by modules, unless overridden.
>>This would also let us break up config files for single modules, and
>>even enable module hierarchies. Course the devil is in the
>>implementation details :)
>>
>>
>
>This is effectively the inverse of "extends", right? It's push rather
>than pull, in that the master pushes config down into the subs, rather
>than the subs pulling config from the master. I need to think a bit
>about the pros and cons of each of these...
>
>--
>Martin Cooper
>
>
>
>
>>Don
>>
>>Martin Cooper wrote:
>><snip />
>>
>>
>>
>>>I'm not keen on adding init params in general, and even less keen on
>>>adding such params that take lists of files.
>>>
>>>I do think we need to have a mechanism for specifying global stuff,
>>>but I think we can come up with a better way. For example, I don't
>>>like that I have to replicate the <controller> config in each module's
>>>struts-config.xml in a multi-module app. That's error prone.
>>>
>>>We've talked about allowing for <extend> for things like form bean
>>>definitions. What about having this concept right at the top of the
>>>config scheme? So I could define a global struts-config.xml file
>>>(which wouldn't be used directly by any module), and then <extend>
>>>that file to provide module-specific config files.
>>>
>>>If we added an optional section to struts-config, we could then
>>>specify a list of Chain config files in there.
>>>
>>>
>>>
>>>
>>>
>>>>I would suggest skipping the chainConfig and chainCommand parameters
>>>>in the web.xml in favor of explicitly setting them in each
>>>>controller. Too many config options can be more trouble than they
>>>>are worth.
>>>>
>>>>
>>>>
>>>>
>>>+1
>>>
>>>
>>>
>>>
>>>
>>>>The discussion of how to configure the Controller or the
>>>>RequestProcessor touched off a lot of talk earlier on struts-dev, but
>>>>I'd be happy to settle for two properties on ControllerConfig just to
>>>>move forward.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>>struts-config.xml
>>>>>>>- The default request processor class would now be
>>>>>>>ComposableRequestProcessor, but the legacy ones would still be available
>>>>>>>(deprecated)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>+1. One thing that I'm a little confused about, though, is that the
>>>>>>new request processor is (currently) in a package that includes
>>>>>>'legacy'. Anyone know why that is?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>I don't know, but I think we should move it out to
>>>>o.a.s.chain.ComposableRequestProcessor.
>>>>
>>>>
>>>>
>>>>
>>>Fine with me.
>>>
>>>
>>>
>>>
>>>
>>>>>>>- The controller would have additional optional attributes:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>I think the controller should simply have optional command and
>>>>catalog attributes which would be used like this:
>>>>
>>>>CatalogFactory.getCatalog(catalog).getCommand(command)
>>>>
>>>>if no catalog is specified, the "default" catalog is retrieved with
>>>>getCatalog(). If no command is specified, then these default values
>>>>would be used:
>>>>catalog = struts
>>>>command = servlet-complete
>>>>
>>>>
>>>>
>>>>
>>>I believe that's what's in place now.
>>>
>>>
>>>
>>>
>>>
>>>>If catalog were specified without a command, an exception would be thrown.
>>>>
>>>>I am still inclined to package most of what is now struts-chain
>>>>separately from the core.
>>>>
>>>>
>>>>
>>>>
>>>I'm not so sure I agree here. Most, if not all, of the commands you
>>>list below are used by the chain that you suggest as a default above.
>>>I think if we want the ComposableRequestProcessor to be the default
>>>for 1.3, we really need to keep the commands in the core as well.
>>>
>>>However, I do think they should be pushed into a separate package.
>>>Just as we have o.a.s.actions, we could have o.a.s.chain.commands for
>>>these.
>>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>
>>>
>>>
>>>
>>>>This may be part of why I haven't moved as
>>>>quickly. Here are all the classes in struts-chain:
>>>>
>>>>org.apache.struts.chain.legacy.CatalogConfiguratorPlugIn
>>>>becomes obsolete
>>>>
>>>>org.apache.struts.chain.legacy.TilesPlugin
>>>>can be made obsolete if we remove the check in the base TilesPlugin
>>>>which insists on a specific request processor. I don't see any
>>>>reason not to do that.
>>>>
>>>>org.apache.struts.chain.legacy.ComposableRequestProcessor
>>>>org.apache.struts.chain.legacy.DispatchAction
>>>>org.apache.struts.chain.legacy.ChainAction
>>>>Move these three to core and up to o.a.s.chain
>>>>
>>>>org.apache.struts.chain.AbstractAuthorizeAction
>>>>org.apache.struts.chain.AbstractExceptionHandler
>>>>org.apache.struts.chain.AbstractExecuteAction
>>>>org.apache.struts.chain.AbstractPerformForward
>>>>org.apache.struts.chain.AbstractPerformInclude
>>>>org.apache.struts.chain.AbstractPopulateActionForm
>>>>org.apache.struts.chain.AbstractRequestNoCache
>>>>org.apache.struts.chain.AbstractSelectAction
>>>>org.apache.struts.chain.AbstractSelectForward
>>>>org.apache.struts.chain.AbstractSelectInput
>>>>org.apache.struts.chain.AbstractSelectLocale
>>>>org.apache.struts.chain.AbstractSelectModule
>>>>org.apache.struts.chain.AbstractSetContentType
>>>>org.apache.struts.chain.AbstractValidateActionForm
>>>>org.apache.struts.chain.Constants
>>>>org.apache.struts.chain.CreateAction
>>>>org.apache.struts.chain.CreateActionForm
>>>>org.apache.struts.chain.ExceptionCatcher
>>>>org.apache.struts.chain.SelectInclude
>>>>org.apache.struts.chain.UnauthorizedActionException
>>>>org.apache.struts.chain.util.ClassUtils
>>>>org.apache.struts.chain.servlet.AuthorizeAction
>>>>org.apache.struts.chain.servlet.ExceptionHandler
>>>>org.apache.struts.chain.servlet.ExecuteAction
>>>>org.apache.struts.chain.servlet.PerformForward
>>>>org.apache.struts.chain.servlet.PerformInclude
>>>>org.apache.struts.chain.servlet.PopulateActionForm
>>>>org.apache.struts.chain.servlet.RequestNoCache
>>>>org.apache.struts.chain.servlet.SelectAction
>>>>org.apache.struts.chain.servlet.SelectForward
>>>>org.apache.struts.chain.servlet.SelectInput
>>>>org.apache.struts.chain.servlet.SelectLocale
>>>>org.apache.struts.chain.servlet.SelectModule
>>>>org.apache.struts.chain.servlet.SetContentType
>>>>org.apache.struts.chain.servlet.TilesPreProcessor
>>>>org.apache.struts.chain.servlet.ValidateActionForm
>>>>
>>>>Move all of these to a Struts TLP like "legacy-chain" or perhaps just
>>>>"struts-chain". I wasn't involved in the initial implementation, but
>>>>I don't think these are something that belongs in the core. They
>>>>work fine, but I think the Abstract classes are over-engineered.
>>>>Also, I think we should move towards actions which operate on a
>>>>StrutsContext or ActionContext rather than having such a highly
>>>>configurable mechanism for looking up context-relevant objects (like
>>>>ActionMapping and ActionForward). I think the config for setting
>>>>context keys for each important object is an example of over
>>>>abstraction which make these harder to understand. This TLP would
>>>>also include a default chain-config which works with this set of
>>>>classes in the JAR.
>>>>
>>>>Is there a compelling reason to put specific command implementations
>>>>in the core? I kind of feel like it would be nice to feel less bound
>>>>to them.
>>>>
>>>>If we do this repackaging, perhaps it would make sense to change the
>>>>Java package for these classes. I don't have a strong opinion.
>>>>
>>>>Joe
>>>>
>>>>--
>>>>Joe Germuska
>>>>Joe@Germuska.com
>>>>http://blog.germuska.com
>>>>"Narrow minds are weapons made for mass destruction" -The Ex
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: "extends" (was Struts chain integration)
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 17 Dec 2004 12:13:21 -0800, Don Brown <mr...@twdata.org> wrote:
> Personally, I favor the approach Cocoon takes to "modules". Cocoon is
> configured to use one sitemap (config file), but that sitemap can mount
> or include other sitemaps through the "mount" element. See
> http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Mounting+sitemaps
>
> Using wildcards, we could support a <mount> element which would
> basically mount a module config. <mount> could also be used as an
> include to include another struts config file full of definitions for
> the current module. Therefore, a module mount in Struts would look like
> this:
>
> <action-mapping path="foo/*">
> <mount uri-prefix="foo" src="/WEB-INF/struts-config-foo.xml" />
> </action-mapping>
>
> This simplifies the config and, IMO, makes the module design much more
> readable and straight-forward.
Interesting idea. I *really* need to find some time to read up on
Cocoon! ;-) (Are there good books to read, or is the web site best?)
The only thing that I'm not so keen on here is that the main site map
needs to be modified to add or remove a "module". (Of course, the way
modules are in Struts today requires the modification of web.xml,
which is essentially equivalent.)
In one of the larger apps I've done, I needed to be able to add and
remove modules as product components were installed and removed. Since
I don't trust installers much, I didn't want them to have to modify
any files. So I adopted an approach whereby I had each module live
under WEB-INF/modules/foo, and I customised the Struts initialisation
code to read all the module configs from there. Installing a module,
then, meant dropping in a new subdirectory, and uninstalling it meant
simply blowing that directory away.
> Getting back to the "extends" idea, if we adopted an approach like
> described above, the main config file could have configuration elements
> that would automatically be inherited by modules, unless overridden.
> This would also let us break up config files for single modules, and
> even enable module hierarchies. Course the devil is in the
> implementation details :)
This is effectively the inverse of "extends", right? It's push rather
than pull, in that the master pushes config down into the subs, rather
than the subs pulling config from the master. I need to think a bit
about the pros and cons of each of these...
--
Martin Cooper
> Don
>
> Martin Cooper wrote:
> <snip />
>
> >I'm not keen on adding init params in general, and even less keen on
> >adding such params that take lists of files.
> >
> >I do think we need to have a mechanism for specifying global stuff,
> >but I think we can come up with a better way. For example, I don't
> >like that I have to replicate the <controller> config in each module's
> >struts-config.xml in a multi-module app. That's error prone.
> >
> >We've talked about allowing for <extend> for things like form bean
> >definitions. What about having this concept right at the top of the
> >config scheme? So I could define a global struts-config.xml file
> >(which wouldn't be used directly by any module), and then <extend>
> >that file to provide module-specific config files.
> >
> >If we added an optional section to struts-config, we could then
> >specify a list of Chain config files in there.
> >
> >
> >
> >>I would suggest skipping the chainConfig and chainCommand parameters
> >>in the web.xml in favor of explicitly setting them in each
> >>controller. Too many config options can be more trouble than they
> >>are worth.
> >>
> >>
> >
> >+1
> >
> >
> >
> >>The discussion of how to configure the Controller or the
> >>RequestProcessor touched off a lot of talk earlier on struts-dev, but
> >>I'd be happy to settle for two properties on ControllerConfig just to
> >>move forward.
> >>
> >>
> >>
> >>>>>struts-config.xml
> >>>>>- The default request processor class would now be
> >>>>>ComposableRequestProcessor, but the legacy ones would still be available
> >>>>>(deprecated)
> >>>>>
> >>>>>
> >>>>+1. One thing that I'm a little confused about, though, is that the
> >>>>new request processor is (currently) in a package that includes
> >>>>'legacy'. Anyone know why that is?
> >>>>
> >>>>
> >>I don't know, but I think we should move it out to
> >>o.a.s.chain.ComposableRequestProcessor.
> >>
> >>
> >
> >Fine with me.
> >
> >
> >
> >>>>>- The controller would have additional optional attributes:
> >>>>>
> >>>>>
> >>I think the controller should simply have optional command and
> >>catalog attributes which would be used like this:
> >>
> >>CatalogFactory.getCatalog(catalog).getCommand(command)
> >>
> >>if no catalog is specified, the "default" catalog is retrieved with
> >>getCatalog(). If no command is specified, then these default values
> >>would be used:
> >>catalog = struts
> >>command = servlet-complete
> >>
> >>
> >
> >I believe that's what's in place now.
> >
> >
> >
> >>If catalog were specified without a command, an exception would be thrown.
> >>
> >>I am still inclined to package most of what is now struts-chain
> >>separately from the core.
> >>
> >>
> >
> >I'm not so sure I agree here. Most, if not all, of the commands you
> >list below are used by the chain that you suggest as a default above.
> >I think if we want the ComposableRequestProcessor to be the default
> >for 1.3, we really need to keep the commands in the core as well.
> >
> >However, I do think they should be pushed into a separate package.
> >Just as we have o.a.s.actions, we could have o.a.s.chain.commands for
> >these.
> >
> >--
> >Martin Cooper
> >
> >
> >
> >
> >>This may be part of why I haven't moved as
> >>quickly. Here are all the classes in struts-chain:
> >>
> >>org.apache.struts.chain.legacy.CatalogConfiguratorPlugIn
> >>becomes obsolete
> >>
> >>org.apache.struts.chain.legacy.TilesPlugin
> >>can be made obsolete if we remove the check in the base TilesPlugin
> >>which insists on a specific request processor. I don't see any
> >>reason not to do that.
> >>
> >>org.apache.struts.chain.legacy.ComposableRequestProcessor
> >>org.apache.struts.chain.legacy.DispatchAction
> >>org.apache.struts.chain.legacy.ChainAction
> >>Move these three to core and up to o.a.s.chain
> >>
> >>org.apache.struts.chain.AbstractAuthorizeAction
> >>org.apache.struts.chain.AbstractExceptionHandler
> >>org.apache.struts.chain.AbstractExecuteAction
> >>org.apache.struts.chain.AbstractPerformForward
> >>org.apache.struts.chain.AbstractPerformInclude
> >>org.apache.struts.chain.AbstractPopulateActionForm
> >>org.apache.struts.chain.AbstractRequestNoCache
> >>org.apache.struts.chain.AbstractSelectAction
> >>org.apache.struts.chain.AbstractSelectForward
> >>org.apache.struts.chain.AbstractSelectInput
> >>org.apache.struts.chain.AbstractSelectLocale
> >>org.apache.struts.chain.AbstractSelectModule
> >>org.apache.struts.chain.AbstractSetContentType
> >>org.apache.struts.chain.AbstractValidateActionForm
> >>org.apache.struts.chain.Constants
> >>org.apache.struts.chain.CreateAction
> >>org.apache.struts.chain.CreateActionForm
> >>org.apache.struts.chain.ExceptionCatcher
> >>org.apache.struts.chain.SelectInclude
> >>org.apache.struts.chain.UnauthorizedActionException
> >>org.apache.struts.chain.util.ClassUtils
> >>org.apache.struts.chain.servlet.AuthorizeAction
> >>org.apache.struts.chain.servlet.ExceptionHandler
> >>org.apache.struts.chain.servlet.ExecuteAction
> >>org.apache.struts.chain.servlet.PerformForward
> >>org.apache.struts.chain.servlet.PerformInclude
> >>org.apache.struts.chain.servlet.PopulateActionForm
> >>org.apache.struts.chain.servlet.RequestNoCache
> >>org.apache.struts.chain.servlet.SelectAction
> >>org.apache.struts.chain.servlet.SelectForward
> >>org.apache.struts.chain.servlet.SelectInput
> >>org.apache.struts.chain.servlet.SelectLocale
> >>org.apache.struts.chain.servlet.SelectModule
> >>org.apache.struts.chain.servlet.SetContentType
> >>org.apache.struts.chain.servlet.TilesPreProcessor
> >>org.apache.struts.chain.servlet.ValidateActionForm
> >>
> >>Move all of these to a Struts TLP like "legacy-chain" or perhaps just
> >>"struts-chain". I wasn't involved in the initial implementation, but
> >>I don't think these are something that belongs in the core. They
> >>work fine, but I think the Abstract classes are over-engineered.
> >>Also, I think we should move towards actions which operate on a
> >>StrutsContext or ActionContext rather than having such a highly
> >>configurable mechanism for looking up context-relevant objects (like
> >>ActionMapping and ActionForward). I think the config for setting
> >>context keys for each important object is an example of over
> >>abstraction which make these harder to understand. This TLP would
> >>also include a default chain-config which works with this set of
> >>classes in the JAR.
> >>
> >>Is there a compelling reason to put specific command implementations
> >>in the core? I kind of feel like it would be nice to feel less bound
> >>to them.
> >>
> >>If we do this repackaging, perhaps it would make sense to change the
> >>Java package for these classes. I don't have a strong opinion.
> >>
> >>Joe
> >>
> >>--
> >>Joe Germuska
> >>Joe@Germuska.com
> >>http://blog.germuska.com
> >>"Narrow minds are weapons made for mass destruction" -The Ex
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org