[
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
