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 06:47:53 UTC
Struts chain integration
Who is working on bringing Struts chain into Struts core? If no one, I
wouldn't mind doing the integration.
I'm thinking about using the ComposableRequestProcessor to keep as much
backwards compatibility as possible. The changes I'm proposing by layer:
web.xml
- A "chainConfig" parameter to override default catalog. If none
specified, a default chain config will be loaded from the Struts jar.
- A "chainCommand" parameter to specify the command to execute if none
specified in modules (optional)
struts-config.xml
- The default request processor class would now be
ComposableRequestProcessor, but the legacy ones would still be available
(deprecated)
- The controller would have additional optional attributes:
- "chainConfig" - path of chain config to override default chain
catalog. Cannot be used if "catalog" is specified.
- "catalog" - name of servlet context attribute to locate catalog
for this module. Cannot be used of "chainConfig" is used.
- "command" - name of command to execute. Overrides default chain
command name.
- Remove the need for the chain plugin
Of course, if someone is already doing the integration, ignore this.
Otherwise, comments appreciated. I'll target the integration Sunday or
Monday if I don't hear different.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts chain integration
Posted by Joe Germuska <Jo...@Germuska.com>.
>1) Toss the plugin and rely on ChainListener to load everything. I
>know this goes back to adding entries in web.xml, at least for 1.2.x.
>But then ...
>
>2) We can add config for chains in struts-config.xml in the 1.3 code.
>This doesn't have to be tied to the process of adding <extends>
>support - we could do that at some later time.
>
>I suppose (2) doesn't really make the plugin go away. It just causes
>the code to be morphed a bit and embedded into the Struts config
>reading process. ;-)
Do you envision Struts 1.2.x releases including chain code? I hadn't
thought of it that way, but I suppose there's no fundamental reason
not to. But it probably makes sense to keep the plugin for that
scenario anyway, since at least in theory Struts 1.2.x should work
with Servlet 2.2, and thus couldn't use ChainListener.
>I think, though, that it's going to be easier to get to where we want
>to be if we don't have to mess around with two separate subprojects.
>With moving and deleting things in SVN being as easy as it is, I think
>it would be fine to bring in what's there now. If we do think many of
>those will go away, then perhaps they should live in a 'legacy'
>package until we know what we really want.
>
>Then again, if Don is going to do the work of bringing struts-chain
>into the mainstream, perhaps we should let him make the call. ;-)
I think I'm just fascinated with the idea of self-contained JARs that
you can just drop in. I still like the idea, but if others feel
we'll make better progress without it, I won't make a fuss. One
person on the user list liked the idea of a separate jar, for what
it's worth. I don't remember any specific comments regarding the
idea of just merging it into core. I can make time if there's
interest in this just waiting for someone to do the work. But if
others feel it's not worth it, I am ready to drop it.
> > Also, if the default chain-config is (or may be) read from the
>> classpath, then having that in the core struts requires you to
>> override it. Including it instead in a separate JAR means you could
>> remove one and add in another and still get the auto-config feature.
>> Does it help to compare it to taglibs, which we are also talking
>> about removing from the core and including as a separate JAR? You
>> could even draw an analogy between the chain-config.xml and a TLD
>> file.
>
>I would expect that the most common reason for overriding the default
>chain config would be adding some extra commands into the chain, in
>which case you'd want all of the original struts-chain except for the
>chain config file (or at least you'd want a way to override the
>default). So I'm not sure this is a reason to keep them separate.
>
>How the default chain is overridden is a good question, though. If we
>set things up so that the default is loaded automagically, then
>overriding it would have to be done with explicit config somewhere -
>plugin or web.xml. But I'm not sure what happens when two config files
>with the same catalog name are loaded. Would a second "struts" catalog
>overwrite the first, or augment it?
CatalogFactoryBase overrides:
http://jakarta.apache.org/commons/chain/xref/org/apache/commons/chain/impl/CatalogFactoryBase.html#90
(OT, line-linkable source code is one of my favorite for-free
features of Maven)
The Catalog interface is rich enough to support an alternate
CatalogFactory implementation which augmented instead, if we wanted
that kind of behavior.
You're right that in most cases people would want to augment instead
of replace the default chain. Regarding loading a default, my
thought was that it would only be loaded if NO other chain configs
were specified. As soon as one were specified, the base one would be
ignored. It's just as well, because there's really no way (as far as
I can see) to augment the chain without making at least some changes
to the config file. You'd at least have to be able to get in there
to specify an alternate catalog in which to look up a command, unless
we figured out some way to parameterize it.
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
Re: Struts chain integration
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 17 Dec 2004 13:32:16 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> >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 can go along with hesitance to use Servlet init params -- perhaps
> because we're trying to limit dependencies on the Servlet API? But
> there is nothing more global than the ActionServlet right now, and no
> way to configure anything at that level (at least, that I can think
> of off the top of my head.)
>
> We could certainly leave the plugin in place as a way to bootstrap
> chain configs without needing to extend the struts-config syntax. We
> haven't deprecated the Tiles or Validator plugins, even though we
> consider them part of the Struts core.
>
> I like the idea of a global "Struts" object, which would be a natural
> place to configure a list of one or more chains.
>
> Ultimately, I don't have a strong opinion about how this happens,
> although I thought it would be nice to leave out the Plugin. I guess
> at least making it optional would be about as good.
We could do the following:
1) Toss the plugin and rely on ChainListener to load everything. I
know this goes back to adding entries in web.xml, at least for 1.2.x.
But then ...
2) We can add config for chains in struts-config.xml in the 1.3 code.
This doesn't have to be tied to the process of adding <extends>
support - we could do that at some later time.
I suppose (2) doesn't really make the plugin go away. It just causes
the code to be morphed a bit and embedded into the Struts config
reading process. ;-)
> I'm ok with all the ideas about inheritance too, although I'd hate to
> see those bog down acceptable-if-not-perfect forward progress on
> getting the Chain in front of more people.
Agreed.
> > > >>>- 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.
>
> Yeah; I was just trying to articulate, especially because I thought
> Don was headed in a different direction.
>
>
> > > 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.
>
> My main rationale for this is a sense that the commands as they are
> are unfinished business. As noted, I'd like to see us move towards
> using a StrutsContext/ActionContext in them, and I think we could
> merge the abstract classes with the concrete implementations without
> anyone feeling much pain and simplifying things a lot for new users
> who come along and want to understand and extend the chain. It seems
> a shame to import 30 classes if half of them will be going away as
> soon as we can get around to it. (Anyone who was involved in that
> original design is encouraged to step up and defend it! Maybe I'm
> just short-sighted, or plain thick?)
Yes, it would be nice to understand the rationale for the way things
are now. ;-)
I think, though, that it's going to be easier to get to where we want
to be if we don't have to mess around with two separate subprojects.
With moving and deleting things in SVN being as easy as it is, I think
it would be fine to bring in what's there now. If we do think many of
those will go away, then perhaps they should live in a 'legacy'
package until we know what we really want.
Then again, if Don is going to do the work of bringing struts-chain
into the mainstream, perhaps we should let him make the call. ;-)
> Also, if the default chain-config is (or may be) read from the
> classpath, then having that in the core struts requires you to
> override it. Including it instead in a separate JAR means you could
> remove one and add in another and still get the auto-config feature.
> Does it help to compare it to taglibs, which we are also talking
> about removing from the core and including as a separate JAR? You
> could even draw an analogy between the chain-config.xml and a TLD
> file.
I would expect that the most common reason for overriding the default
chain config would be adding some extra commands into the chain, in
which case you'd want all of the original struts-chain except for the
chain config file (or at least you'd want a way to override the
default). So I'm not sure this is a reason to keep them separate.
How the default chain is overridden is a good question, though. If we
set things up so that the default is loaded automagically, then
overriding it would have to be done with explicit config somewhere -
plugin or web.xml. But I'm not sure what happens when two config files
with the same catalog name are loaded. Would a second "struts" catalog
overwrite the first, or augment it?
--
Martin Cooper
> 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
Re: Struts chain integration
Posted by Joe Germuska <Jo...@Germuska.com>.
>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 can go along with hesitance to use Servlet init params -- perhaps
because we're trying to limit dependencies on the Servlet API? But
there is nothing more global than the ActionServlet right now, and no
way to configure anything at that level (at least, that I can think
of off the top of my head.)
We could certainly leave the plugin in place as a way to bootstrap
chain configs without needing to extend the struts-config syntax. We
haven't deprecated the Tiles or Validator plugins, even though we
consider them part of the Struts core.
I like the idea of a global "Struts" object, which would be a natural
place to configure a list of one or more chains.
Ultimately, I don't have a strong opinion about how this happens,
although I thought it would be nice to leave out the Plugin. I guess
at least making it optional would be about as good.
I'm ok with all the ideas about inheritance too, although I'd hate to
see those bog down acceptable-if-not-perfect forward progress on
getting the Chain in front of more people.
> > >>>- 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.
Yeah; I was just trying to articulate, especially because I thought
Don was headed in a different direction.
> > 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.
My main rationale for this is a sense that the commands as they are
are unfinished business. As noted, I'd like to see us move towards
using a StrutsContext/ActionContext in them, and I think we could
merge the abstract classes with the concrete implementations without
anyone feeling much pain and simplifying things a lot for new users
who come along and want to understand and extend the chain. It seems
a shame to import 30 classes if half of them will be going away as
soon as we can get around to it. (Anyone who was involved in that
original design is encouraged to step up and defend it! Maybe I'm
just short-sighted, or plain thick?)
Also, if the default chain-config is (or may be) read from the
classpath, then having that in the core struts requires you to
override it. Including it instead in a separate JAR means you could
remove one and add in another and still get the auto-config feature.
Does it help to compare it to taglibs, which we are also talking
about removing from the core and including as a separate JAR? You
could even draw an analogy between the chain-config.xml and a TLD
file.
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
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
"extends" (was Struts chain integration)
Posted by Don Brown <mr...@twdata.org>.
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: Struts chain integration
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 17 Dec 2004 09:09:16 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 10:29 PM -0800 12/16/04, Don Brown wrote:
> >Martin Cooper wrote:
> >>On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown <mr...@twdata.org> wrote:
> >>
> >>>Who is working on bringing Struts chain into Struts core? If no one, I
> >>>wouldn't mind doing the integration.
>
> I haven't made the time to do anything. I was hoping to have some
> this weekend, but if you're ready to plunge ahead, I don't want to
> hold things up. If you think there's a good way to split tasks up,
> let me know. Below I've interspersed what I was thinking about doing.
>
> >>>I'm thinking about using the ComposableRequestProcessor to keep as much
> >>>backwards compatibility as possible. The changes I'm proposing by layer:
> >>>
> >>>web.xml
> >>>- A "chainConfig" parameter to override default catalog. If none
> >>>specified, a default chain config will be loaded from the Struts jar.
> >>>- A "chainCommand" parameter to specify the command to execute if none
> >>>specified in modules (optional)
> >>
> >>
> >>I'm probably misunderstanding something, but
> >>ComposableRequestProcessor uses two context initialisation params for
> >>these already. Those names and default values seem fine to me.
> >
> >The idea of these in web.xml is the ability to specify a custom
> >chainConfig that would be used as the default for all modules; same
> >with the command name. My goal would be to make it possible to use
> >an existing Struts 1.1/1.2 app without any changes. To meet this
> >goal, all these configuration options are optional and defaults will
> >be used if necessary.
>
> Earlier, we had discussed using one init parameter in web.xml as a
> list of chain-config files, each of which would be sought first in
> the servlet context and then on the classpath, each of which would be
> processed using the default chain digester that adds catalogs to the
> pool.
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
Re: Struts chain integration
Posted by Joe Germuska <Jo...@Germuska.com>.
At 10:29 PM -0800 12/16/04, Don Brown wrote:
>Martin Cooper wrote:
>>On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown <mr...@twdata.org> wrote:
>>
>>>Who is working on bringing Struts chain into Struts core? If no one, I
>>>wouldn't mind doing the integration.
I haven't made the time to do anything. I was hoping to have some
this weekend, but if you're ready to plunge ahead, I don't want to
hold things up. If you think there's a good way to split tasks up,
let me know. Below I've interspersed what I was thinking about doing.
>>>I'm thinking about using the ComposableRequestProcessor to keep as much
>>>backwards compatibility as possible. The changes I'm proposing by layer:
>>>
>>>web.xml
>>>- A "chainConfig" parameter to override default catalog. If none
>>>specified, a default chain config will be loaded from the Struts jar.
>>>- A "chainCommand" parameter to specify the command to execute if none
>>>specified in modules (optional)
>>
>>
>>I'm probably misunderstanding something, but
>>ComposableRequestProcessor uses two context initialisation params for
>>these already. Those names and default values seem fine to me.
>
>The idea of these in web.xml is the ability to specify a custom
>chainConfig that would be used as the default for all modules; same
>with the command name. My goal would be to make it possible to use
>an existing Struts 1.1/1.2 app without any changes. To meet this
>goal, all these configuration options are optional and defaults will
>be used if necessary.
Earlier, we had discussed using one init parameter in web.xml as a
list of chain-config files, each of which would be sought first in
the servlet context and then on the classpath, each of which would be
processed using the default chain digester that adds catalogs to the
pool.
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.
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.
>>>- 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
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. 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
Re: Struts chain integration
Posted by Don Brown <mr...@twdata.org>.
Martin Cooper wrote:
> On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown <mr...@twdata.org> wrote:
>
>>Who is working on bringing Struts chain into Struts core? If no one, I
>>wouldn't mind doing the integration.
>
>
> I've been wondering the same thing. I have not done anything myself
> yet, so I'd be happy for you to take this on. ;-)
>
>
>>I'm thinking about using the ComposableRequestProcessor to keep as much
>>backwards compatibility as possible. The changes I'm proposing by layer:
>>
>>web.xml
>>- A "chainConfig" parameter to override default catalog. If none
>>specified, a default chain config will be loaded from the Struts jar.
>>- A "chainCommand" parameter to specify the command to execute if none
>>specified in modules (optional)
>
>
> I'm probably misunderstanding something, but
> ComposableRequestProcessor uses two context initialisation params for
> these already. Those names and default values seem fine to me.
The idea of these in web.xml is the ability to specify a custom
chainConfig that would be used as the default for all modules; same with
the command name. My goal would be to make it possible to use an
existing Struts 1.1/1.2 app without any changes. To meet this goal, all
these configuration options are optional and defaults will be used if
necessary.
>
>
>>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?
>
>
>>- The controller would have additional optional attributes:
>> - "chainConfig" - path of chain config to override default chain
>>catalog. Cannot be used if "catalog" is specified.
>
>
> Why would we need this, in addition to the catalog (below)?
>
>
>> - "catalog" - name of servlet context attribute to locate catalog
>>for this module. Cannot be used of "chainConfig" is used.
>
>
> Shouldn't this just be the catalog name, now that Chain has named catalogs?
You could be right, I haven't looked into named catalogs so perhaps that
would be the catalog name. The "chainConfig" optional would be to let
the user specify a custom chain-config.xml file for that module
(overriding the default chain catalog).
>
>
>> - "command" - name of command to execute. Overrides default chain
>>command name.
>
>
> Do the above controller config attributes override the web.xml ones,
> or, if not, how do they inter-relate?
As mentioned above, these module-level configurations are all optional,
and if specified, would override defaults possibly specified in web.xml.
Don
>
>
>>- Remove the need for the chain plugin
>
>
> Yup.
>
> If any of the above are stupid questions, my excuse is that I'm really
> tired, and probably shouldn't be replying tonight at all... ;-)
>
>
>>Of course, if someone is already doing the integration, ignore this.
>>Otherwise, comments appreciated. I'll target the integration Sunday or
>>Monday if I don't hear different.
>
>
> Sounds great!
>
> --
> Martin Cooper
>
>
>
>>Don
>>
>>---------------------------------------------------------------------
>>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: Struts chain integration
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown <mr...@twdata.org> wrote:
> Who is working on bringing Struts chain into Struts core? If no one, I
> wouldn't mind doing the integration.
I've been wondering the same thing. I have not done anything myself
yet, so I'd be happy for you to take this on. ;-)
> I'm thinking about using the ComposableRequestProcessor to keep as much
> backwards compatibility as possible. The changes I'm proposing by layer:
>
> web.xml
> - A "chainConfig" parameter to override default catalog. If none
> specified, a default chain config will be loaded from the Struts jar.
> - A "chainCommand" parameter to specify the command to execute if none
> specified in modules (optional)
I'm probably misunderstanding something, but
ComposableRequestProcessor uses two context initialisation params for
these already. Those names and default values seem fine to me.
> 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?
> - The controller would have additional optional attributes:
> - "chainConfig" - path of chain config to override default chain
> catalog. Cannot be used if "catalog" is specified.
Why would we need this, in addition to the catalog (below)?
> - "catalog" - name of servlet context attribute to locate catalog
> for this module. Cannot be used of "chainConfig" is used.
Shouldn't this just be the catalog name, now that Chain has named catalogs?
> - "command" - name of command to execute. Overrides default chain
> command name.
Do the above controller config attributes override the web.xml ones,
or, if not, how do they inter-relate?
> - Remove the need for the chain plugin
Yup.
If any of the above are stupid questions, my excuse is that I'm really
tired, and probably shouldn't be replying tonight at all... ;-)
> Of course, if someone is already doing the integration, ignore this.
> Otherwise, comments appreciated. I'll target the integration Sunday or
> Monday if I don't hear different.
Sounds great!
--
Martin Cooper
>
> Don
>
> ---------------------------------------------------------------------
> 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: Struts chain integration
Posted by Ted Husted <hu...@apache.org>.
At some point, it would also be nice to extract the taglibs into a separate subproject, since in 1.3.x we agreed that they would not be part of the "core".
Ditto for the struts-examples. These are suppose to go into an "apps" subproject.
I'd also be in favor of an "extras" subproject, to distribute what we now have under "actions" and "plugins".
Each subproject (including core) could start out with a 1.0.0 release.
We could then bundle the latest GA releases for each subproject into a "Struts 1.3.0 distribution" (a la Linux).
-Ted.
On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown wrote:
> Who is working on bringing Struts chain into Struts core? If no
> one, I wouldn't mind doing the integration.
>
> I'm thinking about using the ComposableRequestProcessor to keep as
> much backwards compatibility as possible. The changes I'm
> proposing by layer:
>
> web.xml
> - A "chainConfig" parameter to override default catalog. If none
> specified, a default chain config will be loaded from the Struts
> jar. - A "chainCommand" parameter to specify the command to execute
> if none specified in modules (optional)
>
> struts-config.xml
> - The default request processor class would now be
> ComposableRequestProcessor, but the legacy ones would still be
> available (deprecated)
> - The controller would have additional optional attributes: -
> "chainConfig" - path of chain config to override default chain
> catalog. Cannot be used if "catalog" is specified.
> - "catalog" - name of servlet context attribute to locate catalog
> for this module. Cannot be used of "chainConfig" is used. -
> "command" - name of command to execute. Overrides default chain
> command name. - Remove the need for the chain plugin
>
> Of course, if someone is already doing the integration, ignore
> this. Otherwise, comments appreciated. I'll target the integration
> Sunday or Monday if I don't hear different.
>
> Don
>
>
> --------------------------------------------------------------------
> - 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