Wrong adding actions to attribute of class hudson.model.Actionable

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Wrong adding actions to attribute of class hudson.model.Actionable

lvotypko
This post was updated on .
Class hudson.model.Actionable has attribute actions, for adding action is used method addAction(action), and method getActions() return the attribute actions.
Problem is that there are classes in Jenkins core (and I think a lot of classes in plugins too) that add action by calling build.getActions().add(action) instead of build.addAction(action).

I wanted add new extension point for adding actions to left-side-menu in build page - similar to TransientProjectActionFactory.
But problem is that I can not override method getActions() in class hudson.model.AbstractBuild. If I do that I must return new ArrayList with actions, which contains all actions in attribute actions of class hudson.model.Actionable, and actions returned by TransientBuildActionFactory.all() (if I do not return new ArrayList but add them to the attribute actions, actions added by TransientBuildActionFactory will be created multiplies (always when the method getActions() is called). This approach will broke all classes (for example instances of BuildStep) which add actions by build.getActions().add(action), because they wan't add actions to attribute actions of class hudson.model.Actionable.

There is two solutions of this situation:
1. method getActions() (which serves for this purposes )won't be overriden and I will add action by another way (for example in sidepanel.jelly). It will broke nothing, but I won't use the methods which is created for this purposes and the using has not be clear at first sight (because the actions will be added into build page in totaly diferent way in compare to actions added into job page or computer page.

2. I will override method getActions() and rewrite all classes, which add actions to a build in Jenkins core, so they add action by calling build.addAction(action). But there is a big risk that it will broke a lot of plugins.

What do you mean? Is better to do first solution (use another way) or override getActions(), correct wrong using in Jenkins core and risks that it will broke plugins - so they must be rewriten too?
Reply | Threaded
Open this post in threaded view
|

Re: Wrong adding actions to attribute of class hudson.model.Actionable

Richard Lavoie
one fix is to create a pseudo List implementation that will delegate the add method to addAction.

Afaik, the backward compatibility is only ensured in core and in officially supported plugins. Happens a lot that plugins need to be modified to work on latest version of jenkins even if we try to limit that.

Richard

On 2012-04-02, at 06:46, lvotypko <[hidden email]> wrote:

> Class hudson.model.Actionable has attribute actions, for adding action is
> used method addAction(action), and method getActions() return the attribute
> actions.
> Problem is that there are classes in Jenkins core (and I think a lot of
> classes in plugins too) that add action by calling
> build.getActions().add(action) instead of build.addAction(action).
>
> I wanted add new extension point for adding actions to left-side-menu in
> build page - similar to TransientProjectActionFactory.
> But problem is that I can not override method getActions() in class
> hudson.model.AbstractBuild. If I do that I must return new ArrayList with
> actions, which contains all actions in attribute actions of class
> hudson.model.Actionable, and actions returned by
> TransientBuildActionFactory.all() (if I do not return new ArrayList but add
> them to the attribute actions, actions added by TransientBuildActionFactory
> will be created multiplies (always when the method getActions() is called).
> This approach will broke all classes (for example instances of BuildStep)
> which add actions by build.getActions().add(action), because they wan't add
> actions to attribute actions of class hudson.model.Actionable.
>
> There is two solutions of this situation:
> 1. method getActions() (which serves for this purposes )won't be overriden
> and I will add action by another way (for example in sidepanel.jelly). It
> will broke nothing, but I won't use the methods which is created for this
> purposes and the using has not be clear at first sight (because the actions
> will be added into build page in totaly diferent way in compare to actions
> added into job page or computer page.
>
> 2. I will override method getActions() and rewrite all classes, which add
> actions to a build in Jenkins core, so they add action by calling
> build.addAction(action). But there is a big risk that it will broke a lot of
> plugins.
>
> --
> View this message in context: http://jenkins.361315.n4.nabble.com/Wrong-adding-actions-to-attribute-of-class-hudson-model-Actionable-tp4525705p4525705.html
> Sent from the Jenkins dev mailing list archive at Nabble.com.