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]

Reply via email to