Ok, yeah, that makes sense that it would only apply for that package. I'm leaning towards Dave's answer and that is to create your own stack and encourage users to use it.
Don On 10/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Alright, the plug-n-play ain't working! The plug-in functionality works > fine if I coerce it into my application's struts.xml, but after many > attempts at overriding the existing defaultStack, it appears *not* > possible. According to the docs, > > Since a plugin can contain the struts-plugin.xml file, it has the ability > to: > > - Define new packages with results, interceptors, and/or actions > - Override framework constants > - Introduce new extension point implementation classes > > Anyone know of a framework constant that can set a package/interceptor-ref > name as default. It appears the default-interceptor-ref tag does not extend > beyond the package that contains it. Funny thing is, the framework knows > when you are trying to use a name that already exists in *another* package! > > Scott > > > > > 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] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Scott > [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
