cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò (JIRA) <j...@apache.org>
Subject [jira] [Assigned] (COCOON-2320) CachingServletServiceSerializer
Date Tue, 29 May 2012 13:11:24 GMT

     [ 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

       

Mime
View raw message