Details
-
Bug
-
Resolution: Fixed
-
Highest
-
2.6.0
-
None
Description
According to the API for the V2 Macro object's 'getBodyRenderMode()' method:
If this method returns null, it causes the macro processor to treat the macro as one that returns wiki-text rather than HTML. The body of the macro will be passed in un-rendered, and the macro's output will be inserted back into the page for further normal processing by the wiki-engine.
Unfortunately, there seems to be a bug in the com.atlassian.confluence.links.LinkParserHelper object, where it assumes that the 'getBodyRenderMode()' method will always return an object (line 41):
if (macro != null && macro.hasBody() && macro.getBodyRenderMode().renderLinks())
This causes the following exception to be thrown when saving a page containing said macro:
2007-10-26 10:13:38,539 ERROR [http-8080-Processor2] [com.opensymphony.xwork.ActionSupport] doSaveEditPageBean An error occured while storing the requested page!
-- url: /pages/doeditpage.action | userName: admin | action: doeditpage | page: 2031618
java.lang.NullPointerException
at com.atlassian.confluence.links.LinkParserHelper.handleMacro(LinkParserHelper.java:41)
at com.atlassian.renderer.v2.WikiMarkupParser.makeMacro(WikiMarkupParser.java:126)
at com.atlassian.renderer.v2.WikiMarkupParser.makeMacro(WikiMarkupParser.java:121)
at com.atlassian.renderer.v2.WikiMarkupParser.handlePotentialMacro(WikiMarkupParser.java:94)
at com.atlassian.renderer.v2.WikiMarkupParser.parse(WikiMarkupParser.java:60)
at com.atlassian.confluence.links.LinkParserHelper.extractLinks(LinkParserHelper.java:67)
at com.atlassian.confluence.links.LinkParserHelper.extractLinks(LinkParserHelper.java:60)
at com.atlassian.confluence.links.ConfluenceLinkResolver.extractLinkTextList(ConfluenceLinkResolver.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
...
...which in turn, spits this out to the browser:
Cause: org.springframework.transaction.UnexpectedRollbackException: Transaction has been rolled back because it has been marked as rollback-only at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:469) Stack Trace: [hide] org.springframework.transaction.UnexpectedRollbackException: Transaction has been rolled back because it has been marked as rollback-only at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:469) at org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:266) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176) at $Proxy5.findUserByUsername(Unknown Source) at com.opensymphony.user.provider.hibernate.HibernateProfileProvider.handles(HibernateProfileProvider.java:79) at bucket.user.providers.ChainedUserProvider.handles(ChainedUserProvider.java:125) at bucket.user.providers.CachingProfileProvider.handles(CachingProfileProvider.java:71) at com.atlassian.user.impl.osuser.properties.OSUPropertySetFactory.getPropertySet(OSUPropertySetFactory.java:30) at com.atlassian.user.impl.delegation.properties.DelegatingPropertySetFactory.getPropertySet(DelegatingPropertySetFactory.java:34) at bucket.user.DefaultUserAccessor.getPropertySet(DefaultUserAccessor.java:561) at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:287) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:181) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:148) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176) at $Proxy19.getPropertySet(Unknown Source) at com.atlassian.confluence.languages.DefaultLocaleManager.getLocale(DefaultLocaleManager.java:27) at com.atlassian.confluence.core.ConfluenceActionSupport.getLocale(ConfluenceActionSupport.java:546) at com.atlassian.confluence.core.ConfluenceActionSupport.getI18n(ConfluenceActionSupport.java:600) at com.atlassian.confluence.core.ConfluenceActionSupport.getText(ConfluenceActionSupport.java:128) at com.atlassian.confluence.pages.actions.AbstractEditPageAction.doSaveEditPageBean(AbstractEditPageAction.java:185) at com.atlassian.confluence.pages.actions.EditPageAction.doSaveEditPageBean(EditPageAction.java:172) at com.atlassian.confluence.pages.actions.EditPageAction.doEdit(EditPageAction.java:244) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Not pretty. A workaround it to return a RenderMode from the 'getBodyRenderMode()' method, however there is no way to have Confluence behave in the same way as returning 'null' is supposed to, which effects how the macros render in the final page.
Attachments
Issue Links
- duplicates
-
-
- Closed
-