On 25 February 2010 13:46, Geert van der Ploeg <[email protected]>wrote:
> 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. > Good point, the use cases I mentioned are only for the 4xx series. The 5xx series should probably not be cached. i created an issue for this https://issues.onehippo.com/browse/WCL-64 >> 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. > I don't see a better option for your situation at the moment. Regards, Jasha ******************************************** 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
