This issue can be caused by the PageTypes plugin by Scandio. de.scandio.confluence.plugins.pagetypes

Ben,

in the version of the plugin that works in 3.0.1 do you still use pageManager.getById() or did you switch to PageManager.getBlogPost() or PageManager.getAbstractPage() methods?

Aha. Just realised that I seem to have misreported my version of
confluence - should have been 3.0. And I have just upgraded to 3.0.1.
And I can no longer reproduce the defect.

Tried it. set JAVA_OPTS=%JAVA_OPTS% -Xms256m -Xmx1024m -XX:MaxPermSize=256m

No difference.

Hi Anatoli. Sufficient code to reproduce the problem is attached. I'll try zhanghan's fix. If that doesn't work, I can create a plugin containing just the demo code, if necessary? Regards, Ben

fixed problem：
enlarge jvm cache size like below:

Applying Memory Settings

Users of the EAR/WAR distribution set their memory in their application server. For Confluence Standalone, the heap space is set in the Confluence install directory.

• Windows users edit TOMCAT_HOME/bin/setenv.bat
• Other OS users edit TOMCAT_HOME/bin/setenv.sh

If you are running Tomcat as a Windows service, you may need to run a regedt32 to increase memory as in the article on increasing JIRA memory. Although the article discusses JIRA, it should also be applicable to Confluence.

The relevant parameter is

JAVA_OPTS="-Xms256m -Xmx1024m"

Where -Xms is the minimum and -Xmx is the maximum memory available to Apache Tomcat. In this sample the maximum memory has been set to 1024 megabytes, but you will have to figure out the best setting based on your particular environment.
Note: In newer Tomcat distributions the file may not exist. Feel free to create it in the ./bin directory.

Seems I also meet the same poblem :

click the news Items then confluence throw :

java.lang.RuntimeException: Error rendering template for decorator root
at com.atlassian.confluence.setup.velocity.ApplyDecoratorDirective.render(ApplyDecoratorDirective.java:232)

caused by: java.lang.RuntimeException: Error rendering template for decorator space
at com.atlassian.confluence.setup.velocity.ApplyDecoratorDirective.render(ApplyDecoratorDirective.java:232)

caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getDatePath' in class com.atlassian.confluence.pages.BlogPost$$EnhancerByCGLIB$$bad4e9e7 threw exception java.lang.ClassCastException: com.atlassian.confluence.pages.Page cannot be cast to com.atlassian.confluence.pages.BlogPost @ /decorators/space.vmd[40,81]
at org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:205)

caused by: java.lang.ClassCastException: com.atlassian.confluence.pages.Page cannot be cast to com.atlassian.confluence.pages.BlogPost
at com.atlassian.confluence.pages.BlogPost$$FastClassByCGLIB$$a5eaa355.invoke(<generated>)

How can I resolve it ??

Hi Ben,

Renaming blogpost would probably load the blogpost object into hibernate cache as a page. Flushing caches should help in such case, but it contradicts the experience you describe. Is it possible for you to attach your plugin so that I could reproduce and debug problem locally?

Anatoli.

Hi Anatoli,

I think you are on the right track with your diagnosis of the problem,
but a cure is elusive....

After a page rename, calling an action gives the following:

Using getAbstractPage returns a Page, which gives the wrong url

Using getBlogPost throws an error.

demo>pageManager.getBlogPost(pageId)...
demo>failed:java.lang.ClassCastException:
com.atlassian.confluence.pages.Page cannot be cast to
com.atlassian.confluence.pages.BlogPost
demo>pageManager.getAbstractPage(pageId)...
demo>url of Page 'page: demo page - renamed again v.3
(13598761)'=/display/test/demo+page+-+renamed+again
demo>get page 13598761
demo>pageManager:com.atlassian.confluence.pages.DefaultPageManager@1a6e4c3

Flushing the cache then calling the action again without refreshing the
page gives the same results as above.

Flushing the cache, then refreshing the page (well, BlogPost), then
calling the action again works - it now returns a BlogPost, as it used
to before the the blogpost was renamed.

demo>pageManager.getBlogPost(pageId)...
demo>url of BlogPost 'blogpost: demo page - renamed again v.3
(13598761)'=/display/test/2009/08/23/demo+page+-+renamed+again
demo>pageManager.getAbstractPage(pageId)...
demo>url of BlogPost 'blogpost: demo page - renamed again v.3
(13598761)'=/display/test/2009/08/23/demo+page+-+renamed+again

It seems that the renaming of the page causes something to get confused
about what is/is not/should be in the cache?

Regards, Ben

Hi Ben,

I suspect the problem is within hibernate caching. When pageManager.getById() is called and hibernate does not have this object in a session or in its second level cache then it tries to load it from the db. PageManager is configured(wired) in a way that getById eventually delegates to getByClassId method of an object of type HibernatePageDao. This methods loads a Page object into hibernate's session and the second level cache. All subsequent calls to getById methods would get the Page object from the session/cache.

It explains why sometimes it works - when BlogPost is in the session or the second level cache and does not need to be retrieved from db.

Please use PageManager.getBlogPost() or PageManager.getAbstractPage methods to fix the problem.

Anatoli.