Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quietly ignore interfaces in IndexHtmlDispatcher, avoiding NPE. #110

Merged
merged 2 commits into from
May 3, 2017

Conversation

varyvol
Copy link
Contributor

@varyvol varyvol commented Apr 20, 2017

Issue #109

Interfaces do not have a superclass and thus a NPE exception was happening.

@reviewbybees @jglick @oleg-nenashev

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐛 I I understand the issue correctly, it used to work. And since there is no documentation about this case AFAIK, there may be regressions in other Jenkins plugins.

If there is no plan about restoring support of Resources from interfaces, there should be at least explicit log message for it and maybe a notice in https://github.com/stapler/stapler/blob/master/CHANGELOG.md.

@@ -36,7 +36,7 @@ public String toString() {
* Returns a {@link IndexHtmlDispatcher} if and only if the said class has {@code index.html} as a side-file
*/
static Dispatcher make(ServletContext context, Class c) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest documenting the null case in Javadoc/Annotations here and in Calling methods just to make sure nobody misuses the API.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean this method returning null? That should be a valid scenario in case no index.html is found.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, I just mean the documentation.

E.g.

     /**
       * Returns a {@link IndexHtmlDispatcher} if and only if the said class has {@code index.html} as a side-file
       * @param c Class to be used. For {@code null} (e.g. interface) the returned value will be {@code null} as well
       * @return Index dispatcher or {@code null} if it cannot be found
       */
      @CheckForNull
      static Dispatcher make(ServletContext context, @CheckForNull Class c) {

@varyvol
Copy link
Contributor Author

varyvol commented Apr 20, 2017

@oleg-nenashev I might be wrong, but this does not ignore the interface per se but avoids the inspection of the class hierarchy, so my understanding is this should restore the previous behaviour.

@ghost
Copy link

ghost commented Apr 20, 2017

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

@oleg-nenashev
Copy link
Member

@varyvol It is great if it fixes the issue :) Just misunderstood the PR then. Added the Javadoc enhancement proposal above. If you write a direct unit test for the case, it will be perfect

Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use case was not valid but this is an appropriate way to restore compatibility.

ServletContext context = mock(ServletContext.class);
when(context.getResource(any(String.class))).thenReturn(null);

IndexHtmlDispatcher.make(context, TestInterface.class);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assertNull the result too.

@varyvol
Copy link
Contributor Author

varyvol commented Apr 20, 2017

@oleg-nenashev @jglick comments addressed.

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to have annotations as well, but 🐝

@oleg-nenashev
Copy link
Member

@reviewbybees done

@varyvol
Copy link
Contributor Author

varyvol commented May 3, 2017

@oleg-nenashev @jglick do you know who might merge this?

@oleg-nenashev
Copy link
Member

@varyvol The merge can be done by several people, @vivek and @kohsuke are the maintainers AFAIK. I pinged them both on Friday regarding the release. We may want to also backport the fix to 2.46.3, but it will require a custom branch of Stapler (to be also decided by the maintainers). The release can be done by @kohsuke only.

@jglick jglick merged commit 3435d0e into jenkinsci:master May 3, 2017
@jglick
Copy link
Member

jglick commented May 3, 2017

I am able to cut releases. Anyway this PR needs no immediate release, much less backport, since it is merely a robustness fix and the plugin bug was already corrected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants