Re: Using PageManager.reset()

Randy Watler <[email protected]> Fri, 06 Jul 2012 17:06:19 -0600
Newsgroups gmane.comp.jakarta.jetspeed.user
Message-ID <[email protected]>
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
>