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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to