CacheKeyFactory (com.adobe.acs.commons.httpcache.keys.CacheKeyFactory) is tied to HttpCacheConfig (com.adobe.acs.commons.httpcache.config.impl.HttpCacheConfigImpl) via cache config’s OSGi property cacheKeyFactory.target. CacheKeyFactory builds CacheKeys (com.adobe.acs.commons.httpcache.keys.CacheKey). Custom implementation of CacheKeyFactory should provide its own CacheKey. Often these implementations factor in the custom implementation of Cache config extension (com.adobe.acs.commons.httpcache.config.HttpCacheConfigExtension). The OOTB extensions mentioned above also implement the CacheKeyFactory interface, with the exception of the CombinedCacheConfigExtension. The factory variant is:
com.adobe.acs.commons.httpcache.config.impl.CombinedCacheKeyFactory allows you to combine multiple factories into 1 to promote reuse
If you want your CacheKey to work in the JCR store, you need to provide an implementation of writeObject / readObject for serialization.
writeObjectreadObject
The abstract class com.adobe.acs.commons.httpcache.keys.AbstractCacheKey contains parentReadObject and parentWriteObject as protected methods to provide serialization logic for it’s fields.
You will need to serialize your fields accordingly so they may be persisted in the JCR.
Deserialization Firewall
JCR store stores the keys in JCR repository and hence depends on serialization/deserialization of these keys.
If you have created your custom key factory, it may fail to deserialize by the JCR store as AEM has deserialization firewall preventing the deserialization from non whitelisted classes.
To prevent this, Go to configMgr and add your package name in