You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Paul Benedict <pb...@apache.org> on 2008/07/21 02:45:06 UTC
[PROPOSAL] S2: Subclassing plugins
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
Re: [PROPOSAL] S2: Subclassing plugins
Posted by Musachy Barroso <mu...@gmail.com>.
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 <pb...@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 <ia...@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 <mu...@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 <pb...@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
Re: [PROPOSAL] S2: Subclassing plugins
Posted by Paul Benedict <pb...@apache.org>.
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 <ia...@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 <mu...@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 <pb...@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
>
>
Re: [PROPOSAL] S2: Subclassing plugins
Posted by Ian Roughley <ia...@fdar.com>.
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 <mu...@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 <pb...@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
Re: [PROPOSAL] S2: Subclassing plugins
Posted by Paul Benedict <pb...@apache.org>.
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 <mu...@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 <pb...@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
>
>
Re: [PROPOSAL] S2: Subclassing plugins
Posted by Musachy Barroso <mu...@gmail.com>.
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 <pb...@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