Jasha, others,
>> We are using the repository-adapter for retrieving documents from the
>> repository (e.g. running DASL's from within portal or just using the
>> webdav-client).
>> Responses from the repository are cached, by WebdavServiceImpl,
>> WebdavCacheHandler, CachingServiceImpl etc.
>>
>> However, the cache does not discern positive responses (with HTTP code
>> 2xx/3xx) from negative ones (4xx, 5xx).
>>
>
> Yes, this is implemented on purpose. The communication between a web
> application and the repository can be the most expensive part of the whole
> response rendering (unless you're doing something very inefficient). We
> chose not only to cache the successful responses but also the unsuccessful
> because they may be a part of your logic. E.g. when your default logo can be
> overridden by an image in the repository. If it's not in the repository
> (404) then use the static one in the web application. Or there may be some
> warning document for your homepage in case of emergency which is not present
> under normal circumstances. Or some logic is failing in the site and the
> site is requesting a non-existent resource (shouldn't happen though but it
> does).
> In these cases you don't want all the traffic between the web application
> and the repository "is this document there?" "no it's not" for every time
> the homepage is built up.
Ok, that sounds reasonable. However, would it make sense both for 4xx and 5xx
responses?
In my opinion the 4xx responses can be cached like you suggest, but 5xx should
not, as they (should) represent errors which the client cannot do anything
about.
I will change my implementation to only not cache 5xx responses.
>> I would like to add that to our environment.
>>
>> As the above mentioned classes do not provide possibilities for injection
>> of a class with does that, I had to create a subclass of CachingServiceImpl.
>> (see attached 'NoErrorResponseCachingServiceImpl')
>> I'm not fond of this solution.
>>
>> Would it be possible to either incorporate this behaviour in one of the
>> hippo classes or to provide a possibility to inject such behaviour?
>> (see attached patches)
>>
>
> I wouldn't recommend implementing this behaviour for the reasons mentioned
> above. I didn't try it but afaics it's not necessary to inject the
> cachingservice. In the web.xml you configure the RepositoryAdapter. You can
> extend the nl.hippo.client.webapp.RepositoryAdapter and add your own
> cachingservice to the setupService method.
> On line 93 it says:
> cache = new CachingServiceImpl(new JCSDefaultCache("default") ...
> which can be replaced by your own.
That seems to work only when using the 'adapter-webapp', right?
When using the 'webdav-client' or from within portal, this RepositoryAdapter
isn't used.
Unless there's a better option for injection etc., I will keep with my current
solution.
Thanks!
With kind regards,
Geert van der Ploeg********************************************
Hippocms-dev: Hippo CMS 6 development public mailinglist
Searchable archives can be found at:
MarkMail: http://hippocms-dev.markmail.org
Nabble: http://www.nabble.com/Hippo-CMS-f26633.html
