I think it could go either way, depending on the nature of the interceptor/plugin. As for Scott's question, since I had a good idea of what he was working on (like the Value Stack, it was magic baby!), I think he should override the defaultStack. I agree with Don, though that larger apps should have their own stack configured.
I was mainly thinking from a "support" perspective. An experienced struts2 developer would not have much problem configuring their interceptor stack, whereas others are probably using struts-default, with defaultStack as their interceptor stack. If Scott doesn't override defaultStack, I figured he'll field that question more than any other. Whereas, someone not using defaultStack is likely to understand any documentation (or even the plugin's code) indicating that the interceptor needs to be placed in the stack. This works, I think, if it can be assumed that the plugin can be dropped into a vanilla struts2-app (struts2-blank, struts2-showcase) and the app still operates without errors. If you drop your plugin into an app and code or configuration is required for the app to continue to operate, I would think that overriding defaultStack is a bad idea. On 10/10/07, Don Brown <[EMAIL PROTECTED]> wrote: > Let us know how overriding the default stack turns out. In other > plugins, I've been creating new stacks, then assuming a user would > just use that stack. Also, I'd make that stack the default stack in > the plugin package, something like myplugin-default, so that if a user > extended it, my stack would be the one they'd get. I generally > assume that for any sizable, production application, you should > construct your own stack with exactly the interceptors you need, but I > could be wrong. > > Anyways, I've been thinking of ways to plug interceptors from plugins > into the default stack so the user doesn't have to lift a finger, so > if you have any ideas, send them along. > > Don > > On 10/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Rock on my brother! And however did you guess that it might be a breadcrumb > > plugin? :) Karin has been patiently waiting to see code, so I finished it > > this morning at 3:00 AM around watering my lawn (with a flashlight) and > > making coffee! By noon today I was too tired to workout the > > stuts-plugin.xml details. So are you suggesting my defaultStack > > implementation *will* override the one in struts-core.xxx.jar? I saw the > > order they are applied but wondered if there was a qualifier <ns?> beyond > > the simple name. The implementation of this plugin does not require > > interfaces to use. It is parameter driven and easily configured at the > > interceptor declaration itself. I am really liking this framework. > > > > Scott > > > > On 10/10/07, Wes Wannemacher <[EMAIL PROTECTED]> wrote: > > > > > > Scott, > > > > > > I would say that you are okay overriding the defaultStack since it is > > > a plugin. For a user to actively install your plugin, then they are > > > seeking the functionality you are providing. I don't know much about > > > the plugin you are writing, but if it works similar to other > > > interceptors, meaning that the user has to implement an interface to > > > get the functionality (like, if you were building a breadcrumb plugin > > > and actions have to implement com.gmail.stanlick.Crumbable, or have to > > > annotated by @com.gmail.stanlick.Crumb), then it should have no > > > side-effects. The advantage of overriding the defaultStack is that > > > most users will have less steps to be up and running, but the caveat > > > is that users who don't use defaultStack will have to include your > > > interceptor manually. Of course, you'll have all of this documented > > > and users in the second scenario will most likely know where to look > > > to get your plugin up and running. > > > > > > -W > > > > > > On 10/10/07, stanlick <[EMAIL PROTECTED]> wrote: > > > > > > > > I am writing a plugin that consists of a new interceptor. I would like > > > its > > > > struts-plugin.xml to append to the defaultStack so the interceptor works > > > out > > > > of the box for packages leveraging the default interceptor stack. What > > > is > > > > the ethical thing to do as it relates to a plugin modifying the default > > > > interceptor stack? Overriding the stack does not pass the tummy test, > > > but > > > > in the spirit of plugin drop-n-go, I also feel odd about including a > > > list of > > > > modifications you need to make to get the plugin to play! > > > > > > > > Scott > > > > -- > > > > View this message in context: > > > http://www.nabble.com/Struts-2-Plugin-tf4603263.html#a13143714 > > > > Sent from the Struts - User mailing list archive at Nabble.com. > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Wesley Wannemacher > > > President, Head Engineer/Consultant > > > WanTii, Inc. > > > http://www.wantii.com > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Scott > > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]