I have stack traces from two different scenarios. I tend to be able to recreate this types of exception more easily when I have multiple users logged into our product, which means there are other threads which are refreshing our navigation area which has a list of folders and pages.
The 1st is a different scenario than I described in my initial post. Our product creates new folders from a template, so when we do this we call deepCopyFolder using the template directory as our source. Caused by: java.lang.NullPointerException at org.apache.jetspeed.om.folder.psml.FolderImpl.getPageSecurity(FolderImpl.java:435) at org.apache.jetspeed.om.folder.psml.FolderImpl.getEffectivePageSecurity(FolderImpl.java:673) at org.apache.jetspeed.page.document.psml.AbstractNode.checkConstraints(AbstractNode.java:406) at org.apache.jetspeed.page.document.psml.AbstractNode.checkConstraints(AbstractNode.java:410) at org.apache.jetspeed.om.page.psml.AbstractBaseElement.checkConstraints(AbstractBaseElement.java:316) at org.apache.jetspeed.om.page.psml.AbstractBaseElement.checkAccess(AbstractBaseElement.java:505) at org.apache.jetspeed.page.psml.CastorXmlPageManager.updatePage(CastorXmlPageManager.java:230) at org.apache.jetspeed.page.PageManagerUtils.deepCopyFolder(PageManagerUtils.java:255) at org.apache.jetspeed.page.AbstractPageManager.deepCopyFolder(AbstractPageManager.java:1225) The second stack trace is from the scenario I described in the initial post. I have just removed some folders using the PageManager API, and called reset(), I then look up the owner for some folders. java.lang.SecurityException: SecurityConstraintsImpl.checkConstraints(): Access for view not permitted. at org.apache.jetspeed.om.page.psml.SecurityConstraintsImpl.checkConstraints(SecurityConstraintsImpl.java:227) at org.apache.jetspeed.page.document.psml.AbstractNode.checkConstraints(AbstractNode.java:422) at org.apache.jetspeed.om.page.psml.AbstractBaseElement.checkConstraints(AbstractBaseElement.java:312) at org.apache.jetspeed.om.page.psml.AbstractBaseElement.checkAccess(AbstractBaseElement.java:505) at org.apache.jetspeed.page.psml.CastorXmlPageManager.getFolder(CastorXmlPageManager.java:623) On Fri, Jul 6, 2012 at 6:06 PM, Randy Watler <wat...@wispertel.net> wrote: > Daniel: > > PageManager.reset() is indeed intended to be safe and operate as you > expected. > > Do you have a stack trace of the exception that is thrown? > > Randy > > > On 7/6/2012 2:33 PM, robotdan wrote: > >> I'm running Jetspeed 2.2.0, and I have a question regarding the use of >> PageManager.reset(). >> >> Our product utilizes folders to allow users to create new product >> instances >> that can be managed. When utilize the PageManager API to manage the >> lifecycle of these folders. >> In general we've always called the reset method after making changes, such >> as after a call to removeFolder. >> >> The impl that we're using is CastoreXmlPageManager, it's reset >> implementation calls FileCache.evictAll(). >> >> Can anyone comment on the correct usage of the reset method? Is it >> necessary to call it after making changes like adding a folder, or >> removing >> a folder? >> If memory serves me, it seems we ended up calling the reset to ensure the >> new folder was available upon a subsequent page refresh in our >> application. >> >> The reason I ask, is because recently we've encountered a few scenarios >> where it seems resetting the cache, and then immediately looking up >> something in metadata in a folder causes a Jetspeed exception. >> For example, >> >> 1. Remove a folder (pageManager.removeFolder(**Folder)) >> 2. Reset the cache (pageManager.reset()) >> 3. Immediately look up existing folders to find the owner in the folder >> metadata. >> - Think this is failing in CastorXmlPageManager.**getFolder(String >> folderPath) >> probably on folder.checkAccess(**JetspeedActions.VIEW) >> >> We've seen step 3 fail with a Jetspeed security exception >> (org.apache.jetspeed.security.**SecurityException). But a subsequent >> call >> will succeed. >> It seems that the cache should be rebuilt upon next touch/request, but is >> Jetspeed expecting the cache to always be built? If so, it seems we are >> hitting a timing issue. >> >> My assumption was that it was safe to call reset, and you'd just pay a >> penalty for performance as the cache was rebuilt. Is it not always safe >> to >> call this? >> >> Daniel >> >> > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > jetspeed-user-unsubscribe@**portals.apache.org<jetspeed-user-unsubscr...@portals.apache.org> > For additional commands, e-mail: > jetspeed-user-help@portals.**apache.org<jetspeed-user-h...@portals.apache.org> > >
