|
[
Permlink
| « Hide
]
Jeff Turner added a comment - 17/Jul/08 09:11 PM
The relevant code is AbstractTOCMacro.java
 , line 567. Basically the org.randombits.confluence.support.MacroInfo object's getRequestAttributes() method is returning null. Without source or javadocs it's hard to tell what the contract is. Hi there,
The relevant class is in the 'confluence-support' library, in SVN here; I'm not certain which version TOC is using - it may be somewhat out of date now - but current versions of the library look for the current HttpServletRequest using the ServletAssistant (also in that library). The ServletAssistant lets you register 'providers' which will look for the current Request, by default in two places - XWork's ServletActionContext and DWR's WebContextFactory. You can register other providers with it, so if the activity stream is rendering outside of one of those two locations, I would suggest implementing a 'Provider' and registering it with the ServletAssistant prior to rendering the activity stream. Thanks for the source pointer. I see in RequestInfo.java
that the javadoc for getRequestAttributes() states "This may be <code>null</code> if the HTTP request is not available inthe current context.". So if AbstractTOCMacro is not handling the null case, isn't that a bug? The toc macro does actually render (eg. see the screenshot) despite the NPE.
I assume that the activity stream shouldn't have macro-specific code in it, eg. to implement a custom ServletAssistant provider Yes, that's definitely true. TOC should handle the null case. I'm not sure how functional it will be if it doesn't have access to the request attributes, but that's probably a different issue.
This bug also prevents PDF export with the TOC macro in Confluence 2.8 and later. Please review the priority of this issue accordingly.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
{toc} macro breaks when rendered in PDF export, activity stream plugin
