Hmmm, should what be skipped? Any interceptor? Java request-scope attribute or HTTP request parameter?
In Struts 1, we had a boolean HTTP request parameter (generated by a tag) that allowed validation to be skipped, which we later designated a security issue, since anyone who learned the magic word could pass it from the command line, and ultimately we removed the capability. -Ted. On 8/8/07, Nils-Helge Garli <[EMAIL PROTECTED]> wrote: > Yikes....Sounds like there's more than a simple fix needed... Maybe > it's safer (for now, I'm pretty sure that I will bump into this > problem later) to just modify the workflow interceptors? What I need > is a simple check for a Boolean request attribute indicating if it > should be skipped or not. It's a specific need for the portlet plugin, > but it can be made general. > > Nils-H > > On 8/8/07, Don Brown <[EMAIL PROTECTED]> wrote: > > Ok, here is the wierdness - yes, you can override interceptor stacks, > > kinda, only it doesn't work how you might expect. If you define an > > override in a subpackage, it not only overrides it for that subpackage > > (and its children), but overrides it in the parent as well. This is > > kinda a pain in Confluence, where a plugin might want to customize > > things like the default interceptor stack, but if they do so, the > > wreck the confluence packages they extend. > > > > Don > > > > On 8/8/07, Nils-Helge Garli <[EMAIL PROTECTED]> wrote: > > > I might have, if it's still hosted at opensymphony? If implemented, > > > what do you feel would be the best way to do it? Override by default > > > if there's an interceptor with the same name in a sub-package, or add > > > an attribute to the xml configuration syntax (which I assume would > > > require a new schema/DTD)? > > > > > > Nils-H > > > > > > On 8/7/07, James Holmes <[EMAIL PROTECTED]> wrote: > > > > Having the ability to override makes sense to me. I haven't looked into > > > > how > > > > complicated this would be to implement though. It will probably have to > > > > occur at > > > > the XWork level. Do you have committer access there? > > > > > > > > James > > > > > > > > > > > > On Tue Aug 7 10:07 , 'Nils-Helge Garli' <[EMAIL PROTECTED]> sent: > > > > > > > > >Hm...that was not the answer I wanted ;) That's unecessary duplication > > > > >of xml, and it requires manual synchronization of the interceptor > > > > >stacks... It might be that the portlet plugin is the only plugin with > > > > >this need, but to me it seems like a good feature to be able to > > > > >override interceptors, maybe with an extra attribute in the > > > > >interceptor configuration syntax or something? > > > > > > > > > >Nils-H > > > > > > > > > >On 8/7/07, Don Brown [EMAIL PROTECTED]> wrote: > > > > >> Yes, I'd say you will need to redefine the stacks users of the > > > > >> portlet > > > > >> plugin can use. > > > > >> > > > > >> Don > > > > >> > > > > >> On 8/7/07, Nils-Helge Garli [EMAIL PROTECTED]> wrote: > > > > >> > Hi! > > > > >> > > > > > >> > In the portlet plugin, I need to customize the workflow > > > > >> > interceptors. > > > > >> > So I have extended them, and added them to the struts-plugin file > > > > >> > with > > > > >> > the same names they have in struts-default. Unfortunately, this has > > > > >> > not the desired effect. The interceptors from the struts-default > > > > >> > package are still the ones that are used. Do I have to re-define > > > > >> > all > > > > >> > the stacks that uses these interceptors, or is there an easy way to > > > > >> > have these override the definitions in the parent package? > > > > >> > > > > > >> > Nils-H > > > > >> > > > > > >> > --------------------------------------------------------------------- > > > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > >> > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >> > > > > > >> > > > > > >> > > > > >> --------------------------------------------------------------------- > > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > >> > > > > >> > > > > > > > > > >--------------------------------------------------------------------- > > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted <http://www.husted.com/ted/blog/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
