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
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 t
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
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 red
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 Cod
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:
