Hi Francesco 2012/3/5 Francesco Chicchiriccò <ilgro...@apache.org>
> Hi Javier, > from a very first look your approach seems very interesting: could you > please file an issue on JIRA and attach your patch there? Thanks. > Done. You can found the patch and description here: https://issues.apache.org/jira/browse/COCOON-2320 > > I might b wrong, but it seems to me that Cocoon 3.0 could also benefit > entirely from your patch. > Yeah, I think so because I think that C3 is using the same base code for SSF. But unfortunately I don't have time atm to work with C3, only some quick looks. > > Regards. > Salu2. > > On 05/03/2012 14:50, Javier Puerto wrote: > > 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. > > > > Salu2. > -- > Francesco Chicchiriccò > > Apache Cocoon PMC and Apache Syncope PPMC Member > http://people.apache.org/~ilgrosso/ > >
