You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When testing to sign a macro on a blog post, a 500 xml error for a NullPointerException is displayed.
The macro did receive the signing, though.
Regular confluence pages do not exhibit this problem.
The instance contains additional plugins related to blog posts:
Linchpin Enterprise News
(maybe) News Teaser for Confluence
The blog post in question was regular and fully published, though.
URL's like /rest/signature/1.0/sign?key=signature.a8ac9c5ed978910021be7258321a26cc5d929985cb44553b4ee202fd92ff2c50
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<status>
<status-code>500</status-code>
<stack-trace>java.lang.NullPointerException
at com.baloise.confluence.digitalsignature.rest.DigitalSigatureService.sign(DigitalSigatureService.java:109)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at com.atlassian.plugins.rest.common.interceptor.impl.DispatchProviderHelper$ResponseOutInvoker.lambda$_dispatch$0(DispatchProviderHelper.java:181)
at com.atlassian.plugins.rest.common.interceptor.impl.DispatchProviderHelper.lambda$invokeMethodWithInterceptors$0(DispatchProviderHelper.java:81)
at com.atlassian.plugins.rest.common.interceptor.impl.DefaultMethodInvocation.invoke(DefaultMethodInvocation.java:53)
at com.atlassian.plugins.rest.common.expand.interceptor.ExpandInterceptor.intercept(ExpandInterceptor.java:42)
at com.atlassian.plugins.rest.common.interceptor.impl.DefaultMethodInvocation.invoke(DefaultMethodInvocation.java:53)
at com.atlassian.plugins.rest.common.interceptor.impl.DispatchProviderHelper.invokeMethodWithInterceptors(DispatchProviderHelper.java:106)
at com.atlassian.plugins.rest.common.interceptor.impl.DispatchProviderHelper$ResponseOutInvoker._dispatch(DispatchProviderHelper.java:180)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75) at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
...
Nothing shows up in the server log files, apart from the stacktrace also shown to the user.
Following the last comment on #65 a clearing of the plugin cache did not help with the error being shown.
(Also note that the exception is different from #65 & #68.)
The text was updated successfully, but these errors were encountered:
The error also occures if the macro is used in a page comment. (both on regular pages & blog posts)
And even when used in inline comments. (Use copy-paste from e.g. a comment)
Though the last one is so exotic, that it's probably not a valid use case.
Still, not throwing stack traces at users is always nice. :)
Testing with the live system, at least the error shown when used in a page comment also exists in Confluence Server 7.3.5 with 7.0.2.
... so ... at least no regression! 😢
tosts
changed the title
NPE on Blogposts
NPE on Blogposts and (Inline) Comments
Nov 12, 2021
tosts
changed the title
NPE on Blogposts and (Inline) Comments
NPE on Blogposts and (Inline) Comments displayed to user
Nov 12, 2021
Upgraded Confluence Server 7.3.5 -> 7.13.2
& digital-signatures 7.0.2 -> 7.0.3
When testing to sign a macro on a blog post, a 500 xml error for a NullPointerException is displayed.
The macro did receive the signing, though.
Regular confluence pages do not exhibit this problem.
The instance contains additional plugins related to blog posts:
The blog post in question was regular and fully published, though.
URL's like /rest/signature/1.0/sign?key=signature.a8ac9c5ed978910021be7258321a26cc5d929985cb44553b4ee202fd92ff2c50
Nothing shows up in the server log files, apart from the stacktrace also shown to the user.
Following the last comment on #65 a clearing of the plugin cache did not help with the error being shown.
(Also note that the exception is different from #65 & #68.)
The text was updated successfully, but these errors were encountered: