If something overrides struts-default then it's no longer struts-default. I'd rather that it was always explicit when something other than struts-core is involved in normal request processing; I'm not sure that adding a plugin JAR to a project in itself is enough to make it obvious that something "interesting" may happen.
d. --- Don Brown <[EMAIL PROTECTED]> wrote: > On 10/11/07, Wes Wannemacher <[EMAIL PROTECTED]> > wrote: > > 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. > > Good points. While one approach may be "cleaner", > the other is > certainly more practical, as long, as you said, you > are careful not to > break things. > > However, thinking about it more, I don't think you'd > be able to > override the default-stack without effort on the > user, cause they > would still need to extend your package that > overrides the stack. > Otherwise, you'd have the problem of two plugins > that both override - > who wins? > > Anyways, it does need to have some more thought put > to the problem, so > please do share any findings. > > Don > > > > 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] > > > > > > > > > > > --------------------------------------------------------------------- > === message truncated === --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]