[MAGNOLIA-2498] NPE in <cms:out> (Out.java) Created: 08/Dec/08 Updated: 12/May/14 Resolved: 12/May/14 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | taglibs |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Martin Algesten | Assignee: | Unassigned |
| Resolution: | Outdated | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
I've mapped up cms bypasses so that struts pages (*.do) are not handled by Magnolia. Note that my bypass is in "cms" in the filter chain, I do want all of the Magnolia chain, but not the actual content (since I'm generating navigation elements that depends on the Magnolia context being in place). So the below error occurs since we're currently looking at a URL and using <cms:out> on a jsp page that is not generated by Magnolia. The tag that fails is: 2008-12-08 09:19:14.078::WARN: /pbWebapp/common/welcome.do Since there is no current Magnolia page, Resource.getActivePage() returns null which means getHandle() is causing the NPE. I have implemented the obvious quick fix but I wonder if it's correct. It just bypasses the UUID resolving if Resource.getActivePage() is null. However I suspect one would really want the resolving to happen also when there is no current active page - thoughts? |
| Comments |
| Comment by Martin Algesten [ 08/Dec/08 ] |
|
The Resource.getActivePage().getHandle() is to get the current URL to be able to make relative links. Would perhaps the "correct" solution be to fall back on getServletPath() if getActivePage() is null? |
| Comment by Magnolia International [ 19/Jan/09 ] |
|
Martin, if you provide a patch that makes sense, we'll probably apply it quickly. But I'd like to understand why/how you're using the cms tags on pages which are not supposed to be handled by Magnolia ? |
| Comment by Martin Algesten [ 19/Jan/09 ] |
|
In my case I have a home page that is not maintained inside Magnolia, but I do include fragments of the page from Magnolia. Hence the filter chain is applied to it to get the context going, but not the actual "cms" part of the chain. |
| Comment by Arjan van Bentem [ 15/Sep/10 ] |
|
For what it's worth: a quick and dirty way to avoid the above error, and similar errors in <cms:setNode>, in Magnolia 4.3.5: Content content = ContentUtil.getContent(ContentRepository.WEBSITE, handle); MgnlContext.getAggregationState().setCurrentContent(content); MgnlContext.getAggregationState().setMainContent(content); Our use case is the same as Martin's: we're using some JSP fragments that fetch generic content from Magnolia, like to render a menu or a sitemap, or content based on JCR queries. These fragments are neither paragraphs nor pages. They are included in our own page templates, but also in non-Magnolia websites (served by a Spring controller). I could imagine that a "Latest headlines" component, that serves a HTML fragment to whatever website likes to include it, might be a similar use case. (When (ab)using BlossomDispatcherServlet for plain Spring controllers as well, one also needs to invoke RenderContext.push(), to avoid an IllegalStateException.) |