Developer/extension options in the publication process

As the publication process is a very central part of the system it has some special extension possibilities. The publication process allows for some extensions both on the publication (cms) side and on the deliver side.

CMS side


You can use a few interception points to trigger your own logic in the cms-part. Read the basics about Interception points here and the basics about Interceptors here. By attaching your interceptor to the "Content.SubmitToPublish" and "SiteNode.SubmitToPublish" you can perform logic when the publication process is initiated. 

Pass through/Proxy publications

When you develop modules in Infoglue which shows information from other systems you often run into the problem that you want to minimize the load on the backend system by only calling it for new data when new items is available and let Infoglue show a cached result otherwise. Since Infoglue 2.10 we have implemented a new feature which makes this possible. How it's done is that you in your Infoglue component add a cache depends key.


DeliveryContext can be reached by the page:deliveryContext-tag. Once your components have registered this data during rendering of a page it can be used to defeat the page cache. How - by using the REST-interface in the CMS to initiate a publication-like operation from your own backend system. So you could for example call Infoglue:s cms when a customer data is changed in your CRM-system if you can extend it. If you send the correct data it will be registered as a pass through publication with all the normal distribution to live instances etc. The publication process will then clear all the pages in the page cache which has the key signature you send.   

To send a pass through publication you call the action "infoglueCMS/UpdateCache!passThroughPublication.action" with the following parameters:

Name Example Description


Mattias Bogeblad

The name which will be noted as the publisher. Not used for any functionality but informative.



A descriptive name of the origin of the publication.


A change was made in the calendar system

A more descriptive text 



The repository id in which the publication should be registered. If not given the first repo is choosen.


A new event was added to the calendar system.

The text that should be shown in the publication details



Not really a class-name but rather a cache-key. In this case it instructs the deliver instance to notify the pageCache about chnages in a specific portlet. The part after the pageCache: could be any key you use in your components.



Not really used for page cache clearing 


New event

A short title for the publication detail.


A complete URL taken from the calendar system would be: 


OBS: You must make sure your external applications IP is allowed to call the action. The same mechanism all for all other update actions. Control this in the "Allowed IP addresses"-settings.

Deliver side

Publishing class

When a publication is made Infoglue deliver receives this and delegates the handling of the update to a class. This class can be overloaded if you feel you can handle the updates better than the default class. This is only possible in live instances. To override just state the class in the field "Live publication thread class" under application settings --> protection settings.

Cache notification listeners

Since Infoglue 2.10 and 3.0 you can register your own listeners to get information when a notificiation is sent to a deliver instance. The new service is implemented in and you use it like this:

.registerListener("org.infoglue.cms.entities.publishing.impl.simple.PublicationImpl", myListener);
.registerListener("org.infoglue.cms.entities.content.impl.simple.ContentVersionImpl", myListener);

In the example above we want to listen to publications but also on ContentVersions. In the live environment the only valid thing to listen to is probably the PublicationImpl-class as most normal content and page publications comes in that form but in a working-environment where the deliver get's each entity notification all the time it could be of interest to listen to more entities. The class/object you want to register must implement the and when registered that object will get a CacheEvictionBean when a corresponding change was made. It should contain all the information you need to do your operations. Make sure you don't do any long running tasks without threading them however.

When you grasp this concept yo just need to find a good way to initiate your listener registration. In Infoglue 3.0 there is a extension mechanism built in which allows you to do this from an extension class. In Infoglue 2.x you may want to register the service from a custom JSP-tag or if you look at the ServiceProvider concept in Java 6.