I have always hoped there was a way to conditionally disable bean registration, like a beans.property file where you could say:
black.bean=false and this file would be loaded before processing all the xml files, ignoring beans that were set to false. I wanted this for something else, but it would fit here, although it really, really feels hackish. musachy On Mon, Jul 21, 2008 at 11:12 AM, Paul Benedict <[EMAIL PROTECTED]> wrote: > 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] >> >> > -- "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]
