Why doesn't this jelly page show the configuration

[Nigel Magnay]

I must be having a bad day, but I can't figure out why this isn't working.

HPI plugin reduced to *only* 1 class and the jelly file (both below).

Config is being correctly set. Config is being correctly saved to the plugin config.xml. Config is not being loaded/displayed in the UI, however. Why?

---

public class HelloWorldPlugin extends Plugin implements Describable<HelloWorldPlugin>{
  private String fish;

  public String getFish() {
    return fish;
  }

  @DataBoundSetter public void setFish(String fish) {
    this.fish = fish;
  }


  /**
   * Returns this singleton instance.
   *
   * @return the singleton.
   */
  public static HelloWorldPlugin get() {
    return Jenkins.getInstance().getPlugin(HelloWorldPlugin.class);
  }

  @Override
  public void start() throws Exception {
    load();
  }

  @Override
  public void configure(StaplerRequest req, JSONObject formData) throws IOException,
                                                                        ServletException, Descriptor.FormException {
    req.bindJSON(this, formData);
    save();
  }

  @Override
  public Descriptor<HelloWorldPlugin> getDescriptor() {
    return Jenkins.getInstance().getDescriptorOrDie(HelloWorldPlugin.class);
  }

  @Extension
  public static class DescriptorImpl extends Descriptor<HelloWorldPlugin> {

    @Override
    public String getDisplayName() {
      return "HelloWorldPlugin Plugin";
    }
  }
}

<?jelly escape-by-default='true'?>
<j:jelly xmlns:j="jelly:core" xmlns:st="jelly:stapler" xmlns:d="jelly:define" xmlns:l="/lib/layout" xmlns:t="/lib/hudson" xmlns:f="/lib/form">
    <f:entry title="Fish" field="fish">
        <f:textbox/>
    </f:entry>
</j:jelly>

[Kanstantsin Shautsou]

From fast lookup because Plugin itself Descriptor that uses `configure` for databinding and you are making it Describable.

Try rename jelly to config.jelly and remove Describables.

[Jesse Glick]

On Wed, Nov 18, 2015 at 9:56 AM, Nigel Magnay <nigel....@gmail.com> wrote:
> public class HelloWorldPlugin extends Plugin implements Describable<HelloWorldPlugin>

Oof. Just do not use `Plugin`; consider it deprecated. Try
`GlobalConfiguration` instead.

[Kanstantsin Shautsou]

> --
> You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/V394esGVs88/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3ahBU0nQsrsjZ8rNavmPhQYbRri8WKZmsJ-rW%3DXi7q1A%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
You was faster :) Just typed the same.
Somebody should add to Plugin javadoc link to GlobalConfig as usually people trying store configs in Plugin or in Descriptor.

[Nigel Magnay]

​Cool - thanks, that works. I spent a long time in stapler-debug to try to figure out why plugin ui wasn't working (And there are several plugins doing this, I may raise tickets in them as it's possible they will spin their wheels like I did).​

[Jesse Glick]

On Wed, Nov 18, 2015 at 11:53 AM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
> Somebody should add to Plugin javadoc link to GlobalConfig

I am tempted to simply deprecate `Plugin` (or perhaps just its
constructor, which subclasses would be forced to call) in favor of the
modern replacements:

· `GlobalConfiguration` rather than `MyPlugin/config.jelly` +
`configure` + `load` + `save`
· `Jenkins.servletContext` for `setServletContext` (anyway can only
find an override in `monitoring` plugin)
· `PluginManager` methods rather than `getWrapper`
· `Initializer` and `Terminator` (or `ItemListener.onLoaded`) rather
than `start`, `postInitialize`, or `stop`

WDYT?

[Kanstantsin Shautsou]

I thought it is right entry Point if somebody wants to use some plugin specific actions as it obvious entry point for plugin (i.e. not to use GlobalConfiguration and not use Descriptors).
I also thought that start/postInitialize is used to get earlier actions for magic actions (i.e. alias XStream entries).

>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/V394esGVs88/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2cy%2B%2B8pixpzMkvVx-nYeycPSgAx9miDCoxZ7Z11Lkf-g%40mail.gmail.com.

[Jesse Glick]

On Wed, Nov 18, 2015 at 1:21 PM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
> I thought it is right entry Point if somebody wants to use some plugin specific actions as it obvious entry point for plugin

Maybe I am not understanding what you wrote, but why do you need to
extend `Plugin` at all if you just want a class where you can put some
general-purpose code used throughout the plugin?

> I also thought that start/postInitialize is used to get earlier actions for magic actions (i.e. alias XStream entries).

You can do such things in `@Initializer`. (Sometimes people use
`static` blocks in `Descriptor`s, in the particular case of XStream
aliases pertaining to the corresponding `Describable`, though that
idiom might break if we implement JENKINS-22050.)

[Kanstantsin Shautsou]

I mean not shared code, but exactly code related to plugin lifecycle in 'Plugin' class as it obvious place. With annotations in different parts of code you can't handle sequence of actions during start/stop. Spreading many start/stop/post-init hooks with annotations in different classes makes not obvious lifecycle, that's why using such Plugin class looks ok for me. 

If people don't know right extension points, then javadoc should only reference imho. 

[Jesse Glick]

On Fri, Nov 20, 2015 at 7:58 AM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
> With annotations in different parts of
> code you can't handle sequence of actions during start/stop. Spreading many
> start/stop/post-init hooks with annotations in different classes makes not
> obvious lifecycle

Nothing is stopping you from adding multiple `@Initializer`s (and/or
`@Terminator`s) in a single class if you find that clearest, though in
my experience each `@Initializer` is usually best placed in a class
related to its actual function, which is likely unrelated to any
others that happen to be present in the same plugin. So I do not buy
this as an argument for retaining `Plugin`.

[Kanstantsin Shautsou]

Ok. Fill PR with reference to this thread?