[jira] Created: (COCOON-2235) Write integration tests for springified JCR block
Write integration tests for springified JCR block - Key: COCOON-2235 URL: https://issues.apache.org/jira/browse/COCOON-2235 Project: Cocoon Issue Type: Task Components: Blocks: JCR Affects Versions: 2.2-dev (Current SVN) Reporter: Lukas Lang Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposal - JS Reader
This might be a little too late, but there is a similar project. It's not a Cocoon plugin, but a servlet, which is somewhat close to a Reader, from what I understand...? The project is called JAWR https://jawr.dev.java.net/ It's a servlet that compresses all your javascript and css on server startup. It can bundle serveral javascript to one package, as well as compress every single js file. Supports minification with YUI Compressor and some others, as well as gzipping requests. I've tested it for a project I'm working on, but think I'll go for the YUI Compressor Maven plugin instead. Mostly because we create a javascript api that is needed by external partner sites, and JAWR doesn't have a good solutions for serving javascript to external sites. It's possible with a js include, but not an optimal solution imho. Regards, Gregers -- View this message in context: http://www.nabble.com/Proposal---JS-Reader-tp18415990p18959110.html Sent from the Cocoon - Dev mailing list archive at Nabble.com.
[jira] Updated: (COCOON-2235) Write integration tests for springified JCR block
[ https://issues.apache.org/jira/browse/COCOON-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Lang updated COCOON-2235: --- Attachment: patch.c2235.20080813.txt Added integration tests for JCR block. Write integration tests for springified JCR block - Key: COCOON-2235 URL: https://issues.apache.org/jira/browse/COCOON-2235 Project: Cocoon Issue Type: Task Components: Blocks: JCR Affects Versions: 2.2-dev (Current SVN) Reporter: Lukas Lang Priority: Minor Attachments: patch.c2235.20080813.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Default handlers of errors in 2.2?
Hi, In 2.1 every sitemap was mounted by root sitemap and thus mounted sitemap inherited various settings like components configuration or map:handle-errors declarations. By contrast, in 2.2 every sitemap is independent and self-contained so it does not inherit any kind of default declaration of error handlers. This is somehow problematic, because now if pipeline throws SourceNotFound exception there is no handler for this exception and Cocoon always returns 500 (Internal Server Error) response status code. This is obviously wrong and the only way to fix it is to declare map:handle-errors section in every sitemap which is rather inconvenient. I started to think about some kind of default minimalistic handler for basic exceptions that would be hard-coded into SitemapServlet. What do you think about such idea? Do you have any better one? -- Best regards, Grzegorz Kossakowski
[jira] Updated: (COCOON-2234) Migrate JCR block to Spring
[ https://issues.apache.org/jira/browse/COCOON-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Lang updated COCOON-2234: --- Attachment: patch.c2234.20080813.txt Added changes.xml entry. Removed last Avalon xconf. Javadoc corrected. Migrate JCR block to Spring --- Key: COCOON-2234 URL: https://issues.apache.org/jira/browse/COCOON-2234 Project: Cocoon Issue Type: Task Components: Blocks: JCR Affects Versions: 2.2-dev (Current SVN) Reporter: Lukas Lang Priority: Minor Attachments: patch.c2234.20080812.txt, patch.c2234.20080813.txt Task consists of removing Avalon components, adding Jackrabbit as repository and fixing unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2236) Servlet Service Framework 1.1.0 is incompatible with Cocoon Core 2.2
Servlet Service Framework 1.1.0 is incompatible with Cocoon Core 2.2 Key: COCOON-2236 URL: https://issues.apache.org/jira/browse/COCOON-2236 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2 Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2 Servlet Service Framework was refactored because there was hidden dependency on CocoonSourceResolver (in a fact, there was a hidden cyclic dependency) which was of course a bad situation because SSF is meant to be completely independent from Cocoon. However, these refactorings introduced some back-incompatibility (which is just a bug). In order to handle different protocols in context-path property of servlet bean, SSF installs JNet handlers using AOP from Spring. The problematic part is that this interceptor is disabled for init() method of every bean, including servlet beans. SitemapServlet does some serious work in its init() method and requires protocols (like block-context:) to be working properly so JNet handler must be installed. The solution for this problem will be to manually install JNet handler in ServletFactoryBean where init method is called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2237) Buffering of response does not work correctly in SSF
Buffering of response does not work correctly in SSF Key: COCOON-2237 URL: https://issues.apache.org/jira/browse/COCOON-2237 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2 Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2 Class HttpServletResponseBufferingWrapper contains subtle bug when it comes to buffering of response. It relies its behaviour on HTTP status code and buffers only if it was set to 404. However, in following scenario current implementation won't work: 1. stream = response.getOutputStream() //non buffering output stream is returned because by default status code is set to 200 2. response.setStatusCode(404) 3. stream.write() //write details about error, this is going to be written to response because non-buffering output stream is in use 4. response.resetBufferedResponse() //this fails with IllegalStateException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Default handlers of errors in 2.2?
On Wed, 2008-08-13 at 12:12 +0200, Grzegorz Kossakowski wrote: Hi, In 2.1 every sitemap was mounted by root sitemap and thus mounted sitemap inherited various settings like components configuration or map:handle-errors declarations. By contrast, in 2.2 every sitemap is independent and self-contained so it does not inherit any kind of default declaration of error handlers. This is somehow problematic, because now if pipeline throws SourceNotFound exception there is no handler for this exception and Cocoon always returns 500 (Internal Server Error) response status code. This is obviously wrong and the only way to fix it is to declare map:handle-errors section in every sitemap which is rather inconvenient. I started to think about some kind of default minimalistic handler for basic exceptions that would be hard-coded into SitemapServlet. Hmm, hard-coded does not sounds swell. Couldn't we set up an error-handler sitemap and then import it to the sitemap that need to use the handlers. This way it is still possible to implement your own. Just thought. salu2 What do you think about such idea? Do you have any better one? -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Objects inherited in subrequests
imran wrote: Grzegorz Kossakowski wrote: Grzegorz Kossakowski pisze: It's not thread-specific but request-specific but here request means the one coming from browser and handled by servlet container and not those internal requests that Cocoon is doing when cocoon: or servlet: protocols are being used. in the setup method of the generator class we replace the objectmodel injected by spring with the one passed with that method ... after doing this the errors are not that frequent .. but they are still there :( .. its still being modified by some other threads ... Could you please let us know how do u intend to implement ur proposed solution The idea is to introduce a new implementation of a Spring scope that will work in a following way: 1. if requested object (like OM) exists in current context then just return it 2. if requested object does not yet exist in current context then find out if this context is derived from root one: a) if the context is derived then ask the root for the object, clone it and store cloned version in current context b) if the context is not derived one so itself is a root then just ask Spring to create a new instance of requested object and again store it in current context The introduction of new contexts should happen only in two cases: 1. new thread is being invoked (for multi-thread scenarios) 2. new internal request is being invoked (in case of using servlet/cocoon protocols) Even if this may sound scary, the implementation of this idea should be very simple. It's only a few lines of code are needed to handle everything. Of course, the problem is where to inject this code. Actually, today I was so busy with other work that I hadn't enough time to look into Cocoon itself but tomorrow I'll do so and give you more detailed instructions how to implement this. Hopefully, proposed solution should fix this problem once and for ever (at least I fail to imagine any situation when this wouldn't work) Imran, after taking a closer look at our code I can see that there are little bit more issues that need to be fixed before I can fix this one. I guess it's going to be much easier if I take care of a whole work because it's really non-trivial stuff and you really need to know all the internals of Cocoon in order to properly fix the problem you have. Therefore I suggest that you provide me a simple application that exhibits this problem so I can test my fixes and track the whole bug. I suggest creation of two different scenarios where one will use cocoon: protocol and another will use servlet: protocol. The most preferred way of providing me this test-cases would be to prepare two ITs as it's done in http://svn.eu.apache.org/viewvc/cocoon/trunk/blocks/cocoon-it/ http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-webapp/src/test/java/org/apache/cocoon/it/ In the first location you add sitemap entries and other resources that you usually at to your block, and in the webapp you create a test-case that tests expected behavior. As soon as you provide me such test-cases (as a patch in JIRA) I'll start working on this problem. Grzegorz, i have attached the testcase to the issue https://issues.apache.org/jira/browse/COCOON-2216 i have attached three files .. test-block is the main block .. webapp is for running that block .. before that u will have to apply the patch cocoon-trunk.patch to cocoon other wise it wont work at all ... for both the block perform mvn install .. and then from webapp block mvn jetty:run so the page http://localhost:/test-block/index.html is generated using the parallel generator .. if ur lucky and dont get the error the first time then just refresh and am sure the error will be there .. there are five components included in that page ... out of which 4 are normal jx components and the fifth one is cforms component ... all the jx component have been assigned different instance of the same object but still the properties displayed on the page shows the same value(they should be different) .. if u execute query for these components individually then they appear without any error .. links for querying them individually [jx components .. shows xml output .. forgot to add the pipeline to serialize it to html.. u can add one] http://localhost:/test-block/showjx http://localhost:/test-block/showjx1 http://localhost:/test-block/showjx2 http://localhost:/test-block/showjx3 [cforms component] http://localhost:/test-block/form2bean.flow most of the time we get the error Caused by: org.apache.commons.jxpath.JXPathException: No value for xpath: $cocoon/continuation/id its because the objectmodel is being changed by all the components simultaneously the error is there on the logs not on the page .. on the page it will just ignore that component u can change the line 427 in the class TestContentAggregator in the main block ...
[continuum] BUILD FAILURE: Cocoon - Apache Cocoon [build root] - Build Def:
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=108483projectId=51 Build statistics: State: Failed Previous State: Ok Started at: Wed 13 Aug 2008 06:45:25 -0700 Finished at: Wed 13 Aug 2008 06:51:11 -0700 Total time: 5m 45s Build Trigger: Schedule Build Number: 326 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.9 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 Family: unix SCM Changes: Changed: gkossakowski @ Wed 13 Aug 2008 03:56:48 -0700 Comment: Implemented exists() method so it tries to return more meaningful value. Also, use exists() method in getInputStream, if it does not exist then SourceNotFound exception should be thrown. Files changed: /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/src/main/java/org/apache/cocoon/servletservice/components/ServletSource.java ( 685509 ) Changed: gkossakowski @ Wed 13 Aug 2008 06:27:36 -0700 Comment: AbstractSession must implement org.apache.cocoon.environment.Session not javax.servlet.http.HttpSession interface in order to get getCocoonSession() method working properly. Added some more deprecation statements. Files changed: /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/environment/http/HttpSession.java ( 685540 ) /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/environment/impl/AbstractSession.java ( 685540 ) Changed: gkossakowski @ Wed 13 Aug 2008 06:28:45 -0700 Comment: cocoon-session-fw-impl sticks to old Cocoon-specific abstraction of Session so getCocoonSession must be used instead of getSession which returns just HttpSession. Files changed: /cocoon/trunk/blocks/cocoon-session-fw/cocoon-session-fw-impl/src/main/java/org/apache/cocoon/webapps/session/components/DefaultSessionManager.java ( 685543 ) Changed: gkossakowski @ Wed 13 Aug 2008 06:29:46 -0700 Comment: Reworked HttpServletResponeBufferingWrapper a little bit. The main idea behind all my changes is to move decision about buffering or not directly to our own implementation of ServletOutputStream. ForwardingOrLimitingServletOutputStream acts in two modes depending on setting if it should buffer or just forward. This change was needed because there might be following execution of methods for which previous implementation would fail: 1. stream = response.getOutputStream() //non buffering output stream is returned because by default status code is set to 200 2. response.setStatusCode(404) 3. stream.write() //write details about error, this is going to be written to response because non-buffering output stream is in use 4. response.resetBufferedResponse() //this fails with IllegalStateException This problem was recorded in COCOON-2337 and now is fixed. Also, test-case covering this problem was added and implementation of existing ones has been changed a little bit to more carefully check if buffering really works as expected. Files changed: /cocoon/trunk/subprojects/cocoon-servlet-service/cocoon-servlet-service-impl/src/changes/changes.xml ( 685544 ) /cocoon/trunk/subprojects/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/HttpServletResponseBufferingWrapper.java ( 685544 ) /cocoon/trunk/subprojects/cocoon-servlet-service/cocoon-servlet-service-impl/src/test/java/org/apache/cocoon/servletservice/HttpServletResponseBufferingWrapperTestCase.java ( 685544 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Maven 2.0.9, Java 5 Description: Test Summary: Tests: 359 Failures: 0 Total time: 99.628
Re: Default handlers of errors in 2.2?
Thorsten Scherler pisze: Hmm, hard-coded does not sounds swell. Couldn't we set up an error-handler sitemap and then import it to the sitemap that need to use the handlers. This way it is still possible to implement your own. Actually, I've discovered that we do have already such default handling of exceptions hard-coded into code. Look at class org.apache.cocoon.servlet.RequestProcessor, and method service(). There a many calls to RequestUtil.manageException() which manages some most common exceptions. The only problematic part is when SourceNotFoundException is being thrown by sitemap component (like reader) and not ResourceNotFound. Then pipeline logic will wrap it into ProcessingException and RequestProcessor won't handle such wrapped exception correctly. I've decided to tweak pipeline implementations to handle SourceNotFoundException correctly. I hope nobody minds. -- Grzegorz Kossakowski
Re: Proposal - JS Reader
I guess a JS reader could be helpful for applications where all resources are served directly by raw Cocoon, i.e. if any compression is to be done then Cocoon has to do it. But don't most applications in a Web setting run Cocoon behind an Apache front-end? Then you can just have Apache gzip whatever you want, all outside of Cocoon, right? And wouldn't that take care of whatever one might want to gain from using a special compressing/minifying component for a specific resource type? I could be totally wrong about this, but that's just how it seemed to me... anyway, is the use case for this specifically the scenario where un-Apache-front-ended Cocoon is being used to serve resources directly? cheers, —ml—
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (109 issues) Subscriber: cocoon Key Summary COCOON-2233 Update archetypes to current trunk artifact versions https://issues.apache.org/jira/browse/COCOON-2233 COCOON-2228 StripNameSpacesTransformer does not strip namespace prefix of attributes https://issues.apache.org/jira/browse/COCOON-2228 COCOON- Add SaxParser configuration properties https://issues.apache.org/jira/browse/COCOON- COCOON-2217 HttpServletResponseBufferingWrapper throws NPE when response body is empty https://issues.apache.org/jira/browse/COCOON-2217 COCOON-2216 IncludeCacheManager can not perfom parallel includes https://issues.apache.org/jira/browse/COCOON-2216 COCOON-2212 jx:attribute does not check name is correct before proceeding https://issues.apache.org/jira/browse/COCOON-2212 COCOON-2211 Support for jx:element https://issues.apache.org/jira/browse/COCOON-2211 COCOON-2210 The field 'type' in GenerateNode in corona-sitemap should not be final https://issues.apache.org/jira/browse/COCOON-2210 COCOON-2197 Making the cocoon-auth-block acegi-security-sample work https://issues.apache.org/jira/browse/COCOON-2197 COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each other https://issues.apache.org/jira/browse/COCOON-2173 COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination page https://issues.apache.org/jira/browse/COCOON-2162 COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2108 xmodule:flow-attr Does not accept document objects https://issues.apache.org/jira/browse/COCOON-2108 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 COCOON-2071 Option to turn off pooling for components (probably faster on new JVMs and simpler debugging) https://issues.apache.org/jira/browse/COCOON-2071 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the servlet protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem:
