Expand my Community achievements bar.

July 31st AEM Gems Webinar: Elevate your AEM development to master the integration of private GitHub repositories within AEM Cloud Manager.

Flush json file from dispatcher


Level 4


I have a requirement in my project where I have created a (registered with resourceType) servlet which returns meta data of assets/tags as json. This json consists of data of all assets/child tags as well.

This JSON is cached at parent level. For e.g if I request tags at this level - /etc/tags/we-retail/audience.tagsweretail.json(tagsweretail is my selector) it caches the json at the audience level. Now if I change any child tag and activate it and then if i send request for same url, the json returned has old data as this json is not flushed when activating child tag. Is there any any way I can flush json at parent level in case tags are activated at child level. I went through the new ACS Commons Dispatcher Flush Rules service as well but it doesn't work in my case as the level at right hand side is not fixed it keeps on varying according to the path requested. Any help would be appreciated.

Thanks in advance,


3 Replies


Level 4

Looking at these links it seems none of this serves our purpose. So, that means we will have to write a custom listener to auto flush these set of json's? I was looking for some OOTB approach to achieve this.


Employee Advisor

You shouldn't need to write code for this.

From what I understand, in your case cached .json files are not invalidated on the dispatcher; that's part of the default configuration, because even .json files are not cached. You need to explicitly configure the dispatcher to invalidate .json files as well.

The next problem could be the statfilelevel. That's a single value which applies to all invalidation requests, independent of path (which can be a problem in your case). Let me explain that with an example:

You have

* /content/brand/mysite/en/page

* /content/brand/mysite/es/homepage

* /content/brand/mysite/es/products

Then you would probably set the statfilelevel to to 4, so any change on the es site purges only the cache of the es-site and not on the en site.

That can be problematic when you have as well




Because now any change on /etc/tags/es/tag2 will not cause the all tags of es being flushed.

But please check before that you configured the invalidation of the .json files.