struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nils-Helge Garli" <nil...@gmail.com>
Subject Re: Override interceptors in struts-default from plugin
Date Thu, 09 Aug 2007 12:46:00 GMT
Only the workflow interceptors. The problem is that when switching
portlet modes with portlet controls, the render state sticks between
the requests (it's a part of the JSR168 spec I've never understood
why....). So if there were a validation error on the previous request,
the workflow interceptor returns "input" even when the mode has been
switched...hope that made sense....

Anyway, I was thinking about a request attribute. No parameter that
can be set from the outside.

Nils-H

On 8/9/07, Ted Husted <husted@apache.org> wrote:
> 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 <nilsga@gmail.com> 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 <mrdon@twdata.org> 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 <nilsga@gmail.com> 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 <james@jamesholmes.com> 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' <nilsga@gmail.com>
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 mrdon@twdata.org> 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 nilsga@gmail.com> 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: 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
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> --
> HTH, Ted <http://www.husted.com/ted/blog/>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message