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]
