it cannot really be done right now as cached content is stored in the HTTP session of the user (which makes sense since it has the same lifecycle than the user).
The code is located in org.jboss.portal.portlet.aspect.cache.ConsumerCacheInterceptor. Here the content of the cache is retrieved/stored in the PRINCIPAL_SCOPE context.
This context is the (http session + the principal id) : the http session for the lifecycle management and the principal id for security reasons (so a user does not see the cached content from another user which can happens on logout operations when the session cookie stays the same).
So basically you can modify this interceptor to store instead the content in a shared cache and have that shared cache expose operation through JMX. This interceptor is declared in jboss-portal.sar/META-INF/jboss-service.xml and at this place you can replace the default implementation by your.
For the cache you could use JBoss Cache has a field of your interceptor and expose invalidation methods on the interceptor itself as it is already an MBean.
I have done it without using the jboss cache.
I use only a "signal", that is a parameter in the underlying HttpServletRequest.
I wonder if it is a proper way. (clean, surely not, but working ok ?).
If anyone can confirm it is ok ?
if so, I'll write a wiki about this, with the helper class and test portlets I made for this feature.
In the process action of the portlet that want to invalidate the cache of all portlet, I set a render parameter.
In the ConsumerCacheInterceptor :
- I get the invocation.getContext() and try to cast this context to an AbstractInvocationContext
- if this cast is ok, I get the HttpServletRequest client request from it
HttpServletRequest httpServletRequest = abstractInvCtxt.getClientRequest();
- from this HttpServletRequest, I get the parameter
If the value of the parameter says to invalidate the cache, I do so.
The parameter is seen in the ConsumerCacheInterceptor for all the windows/portlet of the page... which is great for this feature, but seems strange.
The parameter was set for only one portlet, in its processAction method...
I have made some detailed tests, and it works fine.
anybody can confirm this is ok ? Julien ?