It comes down to the embedding of the struts.xml in the plugins. Certain values get set which cannot be unset. For instance, if one plugin sets the UnknownActionHandler, no one else can override it. (I don't want the conversation to focus on UAH improvements but it is one good example). I imagine there are other <bean> properties which developers woulds like to replace too.
What can we make Struts do to make this easier? Paul On Mon, Jul 21, 2008 at 7:47 AM, Ian Roughley <[EMAIL PROTECTED]> wrote: > I'm a little surprised that you can't do this now. Is the problem because > of the order of loading the plugins during bootstrapping or the way the > authors write the plugins, or something else? > > /Ian > > > Paul Benedict wrote: > >> Since plugins are a collection of classes and they are available to me on >> the class path, I should be able to subclass any of them -- and replace >> them. >> >> Imagine I like the functionality of one and want to add a bit more? Why >> can't plugins have protected methods that I customize? I don't want to >> redo >> all its work, but I do want to "replace" classes with my subclass. >> >> Paul >> >> On Sun, Jul 20, 2008 at 8:33 PM, Musachy Barroso <[EMAIL PROTECTED]> >> wrote: >> >> >> >>> I don't see plugins as something that you extend, but more like >>> something that you customize. If there is something that you need to >>> modify on a plugin, then that should probably be an extension point in >>> the plugin. Take for example the case of Codebehind and REST, with >>> some small modifications Codebehind was modified so it could be >>> "customized" by REST without having to extend it. I know this doesn't >>> cover all the possible use cases. >>> >>> musachy >>> >>> On Sun, Jul 20, 2008 at 8:45 PM, Paul Benedict <[EMAIL PROTECTED]> >>> wrote: >>> >>> >>>> When I want to extend a plugin, I unfortunately have to unpack the >>>> >>>> >>> libraries >>> >>> >>>> and include them into my own web application. I use Maven's Dependency >>>> plugin for this. :-) It is the only way I know of getting a hold of the >>>> binaries without forcing them into plugin status. >>>> >>>> I see two ways out of this: >>>> 1) Refactor each plugin to be the code and a plugin jar wrapper. >>>> 2) S2 needs a way of saying which plugin NOT to load. Obviously the >>>> >>>> >>> plugin >>> >>> >>>> jar is going to be in WEB-INF/lib. That's good enough to extend, if I >>>> >>>> >>> have a >>> >>> >>>> way to stop it from registering. >>>> >>>> I wholly prefer #2. Other options welcomed. >>>> >>>> Paul >>>> >>>> >>>> >>> >>> -- >>> "Hey you! Would you help me to carry the stone?" Pink Floyd >>> >>> --------------------------------------------------------------------- >>> 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] > >
