[ https://issues.apache.org/jira/browse/COCOON-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Francesco Chicchiriccò reassigned COCOON-2320: ---------------------------------------------- Assignee: (was: Francesco Chicchiriccò) Sorry, I thought issue (and provided patch) were about cocoon-servlet-service-impl, used by either C2.2 and C3 but only now I see that instead they are related to cocoon-servlet-service-components (C2.2 only). > CachingServletServiceSerializer > ------------------------------- > > Key: COCOON-2320 > URL: https://issues.apache.org/jira/browse/COCOON-2320 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core, - Servlet service framework > Affects Versions: 2.2-dev (Current SVN) > Reporter: Javier Puerto > Priority: Minor > Attachments: CachingServletServiceSerializer.patch > > > Hello Cocoon developers, > We are using Apache Cocoon 2.2 for a project and I've found a bottleneck in > our template system. We use servlet service components to render our pages in > the same way you can see for Style Block. The current Cocoon Welcome block is > an example. > This way of rendering is very useful but as currently the servlet services > components doesn't implement CacheableServiceComponent interface, all the > request will be processed completely at the end. > For our usecase, here is an example: > <map:match pattern="x"> > <map:generate ... > <map:transform ... > <map:include ... > <map:serialize type="servletService"> > <map:parameter name="service" > value="servlet:style:/service/common/simple-page2html"/> > </map:serialize> > </map:match> > The most expensive part is the serialization process because we use i18n, > Link rewriter and some transformations. We can configure everything to be > cacheable but at the end, the serialization process must be performed > entirely. I've simply extended the current ServletServiceSerializer in > CachingServletServiceSerializer adding the cache key as requested service URL > and NOPValidity as validity object. This approach has a problem, due to the > nature of the servlet service components we need to move all the dynamically > generated content from our GUI block since if we detect that the content > hasn't changed, the CachingServletServiceSerializer will not perform any > process and will return the cached content. Also, as there's a little hack > for serializer output mime type, if you want to use the new component you > must set the serialization content type explicitly. See > http://article.gmane.org/gmane.text.xml.cocoon.devel/73261 > <map:match pattern="x"> > <map:generate ... > <map:transform ... > <map:include ... > <map:serialize type="caching-servletService" mime-type="text/html"> > <map:parameter name="service" > value="servlet:style:/service/common/simple-page2html"/> > </map:serialize> > </map:match> > For our usecase seems to fit well and will allow us to enable the powerful > cocoon caching system for a lot of pages. IMO, it's a problem when you want > to use the ServletServiceSerializer to have a clean and common output for the > template system and you can't use the caching even with static files. > Attached is the patch for cocoon-servlet-service-components block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira