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] |
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. 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] |
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] |
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] |
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] |
Free forum by Nabble | Edit this page |