[jira] [Created] (COCOON3-98) RegexpLinkRewriterTransformer doesn't guarantees rules order
RegexpLinkRewriterTransformer doesn't guarantees rules order Key: COCOON3-98 URL: https://issues.apache.org/jira/browse/COCOON3-98 Project: Cocoon 3 Issue Type: Bug Components: cocoon-sax Affects Versions: 3.0.0-beta-1 Reporter: Javier Puerto RegexpLinkRewriterTransformer apply all the defined rules iterating over a Set. I think that makes sense to implement some kind of priority because you may have rules that depends on other rules. -- 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
[jira] [Created] (COCOON3-97) Wrong status response code for sitemap errors
Wrong status response code for sitemap errors - Key: COCOON3-97 URL: https://issues.apache.org/jira/browse/COCOON3-97 Project: Cocoon 3 Issue Type: Bug Components: cocoon-servlet Affects Versions: 3.0.0-beta-1 Reporter: Javier Puerto As described in COCOON3-95 issue, Cocoon 3 is not handling the status response code properly when a RuntimeException is thrown. It's returning a 200 and should be a 500. The block to reproduce the error is in previous issue. -- 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
[jira] [Created] (COCOON3-95) Sitemap file not validated against schema
Sitemap file not validated against schema - Key: COCOON3-95 URL: https://issues.apache.org/jira/browse/COCOON3-95 Project: Cocoon 3 Issue Type: Bug Components: cocoon-general Affects Versions: 3.0.0-beta-1 Reporter: Javier Puerto http://cocoon.markmail.org/thread/cq6nrzy5xladcuys Summary: Lars Huttar found that his sitemap declaration was not working as expected. Some matchers worked an others not. Finally the problem was a matcher tag not inside a pipeline tag. Attached is a block to reproduce the problem, I just review the SitemapBuilder class and there's not validation at all against a schema. So if the sitemap.xmap file is a XML well formed, C3 will not throw any error about. The ugly issue is that C3 is returning a HTTP status code of 200 instead of a code 500 and also the exception in the log is not very helpful, NullPointerException. I think that we should validate the sitemap file or at least response with the right HTTP status code and better error information in this case. We can do something like we have already for the SchemaProcessorTransformer, using the caching to avoid unnecessary processing. The schema file path is trunk/cocoon-sitemap/src/main/resources/cocoon-sitemap-1.0.xsd. -- 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
[jira] [Created] (COCOON-2320) CachingServletServiceSerializer
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 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
