Help/Hint needed: Post build action doesn't stay activated

[Daniel Lindner-2]

  Hello all,

i'm out of luck with this bug, it's probably a minor tweak that I keep
overlooking.
I'm the author of the crap4j plugin
(http://wiki.hudson-ci.org/display/HUDSON/Crap4J+Plugin) that has a
nasty bug i want to fix:
http://issues.hudson-ci.org/browse/HUDSON-5493

The problem can be described as follows:
- Enable "Report Crap" on one of your freestyle jobs
- Enter a report file pattern and some threshold (optional) and click "Save"
- The config gets saved in the job's config.xml and crap is reported.
- Enter the job configuration page again: the "Report Crap" checkbox is
disabled. If you re-enable it, the pattern field (etc.) is empty.
- You have two options now:
1. Leave the configuration page without saving - the job keeps reporting
crap
2. Save the configuration page - the job stops reporting crap, the
corresponding entry in the config.xml disappears.

The enable/disable checkbox somehow forgets to load its correct state.
As this is handled by core hudson and it works for most/all other
plugins, i'm really looking forward for a hint on what i've done wrong.

Sincerely,
Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Daniel Lindner-2]

  On 31.07.2010 14:43, Daniel Lindner wrote:

> http://issues.hudson-ci.org/browse/HUDSON-5493
>
> The problem can be described as follows:
> - Enable "Report Crap" on one of your freestyle jobs
> - Enter a report file pattern and some threshold (optional) and click
> "Save"
> - The config gets saved in the job's config.xml and crap is reported.
> - Enter the job configuration page again: the "Report Crap" checkbox
> is disabled. If you re-enable it, the pattern field (etc.) is empty.
> - You have two options now:
> 1. Leave the configuration page without saving - the job keeps
> reporting crap
> 2. Save the configuration page - the job stops reporting crap, the
> corresponding entry in the config.xml disappears.
>
> The enable/disable checkbox somehow forgets to load its correct state.

I found the solution/fix and want to share it in case somebody
encounters the same effects:
It boils down to a misplaced @Extension-Annotation. I've added this
annotation to the PluginDescriptor class, but it needs to be attached to
the static member holding the only instance of the PluginDescriptor.
Once I corrected it, the plugin worked as desired (after i ran a clean
build, that is).

Sincerely, Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Alan Harder-2]

Daniel Lindner wrote:
>  I found the solution/fix and want to share it in case somebody
> encounters the same effects:
> It boils down to a misplaced @Extension-Annotation. I've added this
> annotation to the PluginDescriptor class, but it needs to be attached
> to the static member holding the only instance of the
> PluginDescriptor. Once I corrected it, the plugin worked as desired
> (after i ran a clean build, that is).

to clarify:
- the "recommended" setup is @Extension on the class, and don't create a
singleton instance.
- if you DO have a singleton instance, then @Extension must on that and
not on the class (as you found).. otherwise Hudson uses one instance of
the descriptor and your code uses a different instance.

    - Alan


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Daniel Lindner-2]

  On 02.08.2010 16:32, Alan Harder wrote:
> to clarify:
> - the "recommended" setup is @Extension on the class, and don't create
> a singleton instance.
> - if you DO have a singleton instance, then @Extension must on that
> and not on the class (as you found).. otherwise Hudson uses one
> instance of the descriptor and your code uses a different instance.
  Hi Alan,

thank you for the clarification. It matches the observed behaviour :)
Is this information persisted in the Wiki? If not, I would search for a
place to put it in.

This was a problem of an aging code base, written before the
@Extension-Annotation, so I guess the problem will diminish over time.

Sincerely, Daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kohsuke Kawaguchi-3]

On 08/02/2010 12:16 PM, Daniel Lindner wrote:

>    On 02.08.2010 16:32, Alan Harder wrote:
>>  to clarify:
>>  - the "recommended" setup is @Extension on the class, and don't create
>>  a singleton instance.
>>  - if you DO have a singleton instance, then @Extension must on that
>>  and not on the class (as you found).. otherwise Hudson uses one
>>  instance of the descriptor and your code uses a different instance.
>    Hi Alan,
>
> thank you for the clarification. It matches the observed behaviour :)
> Is this information persisted in the Wiki? If not, I would search for a
> place to put it in.

I think there should be a page called "Implementing an extension point"
under the "Extension points" bullet item in
http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson

If you can start a page, that would be great.


> This was a problem of an aging code base, written before the
> @Extension-Annotation, so I guess the problem will diminish over time.

I commit rev.33544 in core so that it actively looks out for this error
in plugins and report it. Hopefully that'll make it easier for other
people in a similar situation to realize what's going wrong.

>
> Sincerely, Daniel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi | InfraDNA, Inc. | http://infradna.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]