struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musachy Barroso" <musa...@gmail.com>
Subject Re: [PROPOSAL] S2: Subclassing plugins
Date Mon, 21 Jul 2008 15:28:37 GMT
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 <pbenedict@apache.org> 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 <ian@fdar.com> 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 <musachy@gmail.com>
>>> 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 <pbenedict@apache.org>
>>>> 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: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>



-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message