Cocoon GT Speakers: Upload your Slides at slideshare.net
Dear Cocoon GT Speakers, I would like to invite you to upload your presentation slides at slideshare.net and share it in the slideshare Cocoon group: http:// www.slideshare.net/group/cocoon The nice thing about slideshare is that it provides you with space (up to 30 MB) for your slides and has a nice flash-based slide viewer that can be embedded in your blog (or even better in cocoon.apache.org) easily. (Example: http://weblogs.goshaky.com/ weblogs/lars/entry/dax_presentation_from_cocoongt) regards, Lars
[jira] Closed: (COCOON-1941) Upgrade DOJO to 0.4
[ https://issues.apache.org/jira/browse/COCOON-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff closed COCOON-1941. - Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Upgrade DOJO to 0.4 --- Key: COCOON-1941 URL: https://issues.apache.org/jira/browse/COCOON-1941 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) The Dojo Foundation has released version 0.4 of the Dojo toolkit yesterday. Cocoon should use this version of Dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: More problems with implementing servlet services
Hi Grzegorz, do we need all information from the environment? If not, we could add custom X-Cocoon-* Headers that can also be exchanged in more decoupled scenarios where servlet services are actual remote websites. Lars Am 08.05.2007 um 18:29 schrieb Grzegorz Kossakowski: Another problem is that if we want servlet services really usable we need to forward Environment to the called service. An obvious example is service that takes effort of styling Forms and handling Ajax requests. It needs to access all environment data to get run Forms machinery properly. I was thinking about it for a while and I have no appealing idea how to solve it. I guess that this task is far beyond HTTP capabilities and in this area we need to break conformity with HTTP specification. I mean that we just attach Environment object to the BlockCallHttpServletRequest instance and we'll modify cocoon's core a little bit to detect that request is service call so it will be able to make us of forwarded Environment. -- Lars Trieloff visit http://www.mindquarry.com/
[jira] Closed: (COCOON-2048) ImageOp: overlay a transparent image on another one
[ https://issues.apache.org/jira/browse/COCOON-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff closed COCOON-2048. - Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Assignee: Lars Trieloff Fixed last week. Thank you. ImageOp: overlay a transparent image on another one --- Key: COCOON-2048 URL: https://issues.apache.org/jira/browse/COCOON-2048 Project: Cocoon Issue Type: New Feature Components: Blocks: ImageOp Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assigned To: Lars Trieloff Fix For: 2.2-dev (Current SVN) Attachments: delete.png, imageop-overlay-operation-sample.patch, imageop-overlay-operation.patch New OverlayOperation that puts another image on top of the image used by the ImageOpReader. Useful to overcome problems with browsers like IE that cannot put a transparent img on top of a background image. Example usage: map:read type=image-op-overlay src=background-image.jpg map:parameter name=overlay-offset-x value=10 / map:parameter name=overlay-offset-y value=20 / map:parameter name=overlay-source value=overlay-image.png/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2048) ImageOp: overlay a transparent image on another one
[ https://issues.apache.org/jira/browse/COCOON-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490015 ] Lars Trieloff commented on COCOON-2048: --- Thanks Alex, I'm looking into this right now. I will do some further refactoring to keep the old interface. ImageOp: overlay a transparent image on another one --- Key: COCOON-2048 URL: https://issues.apache.org/jira/browse/COCOON-2048 Project: Cocoon Issue Type: New Feature Components: Blocks: (Undefined) Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: delete.png, imageop-overlay-operation-sample.patch, imageop-overlay-operation.patch New OverlayOperation that puts another image on top of the image used by the ImageOpReader. Useful to overcome problems with browsers like IE that cannot put a transparent img on top of a background image. Example usage: map:read type=image-op-overlay src=background-image.jpg map:parameter name=overlay-offset-x value=10 / map:parameter name=overlay-offset-y value=20 / map:parameter name=overlay-source value=overlay-image.png/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GT2007] [VOTE] Conference location + time
Hi Arje, B) Italy, Rome / Milano +1 B) Beginning of October (between the holidays season and ApacheCon) +1 Apart from all that, you should come over and visit Amsterdam anyway from May 1-4 at the ApacheCon Europe! www.apachecon.com +1 See you there. -- Lars Trieloff visit http://www.mindquarry.com/
Re: SVN Source for Cocoon
I just had a look, Maven uses the SVN command line executable. Lars Am 06.03.2007 um 02:34 schrieb Niclas Hedhman: On Monday 05 March 2007 17:49, Lars Trieloff wrote: Hi Reinhard, - SVN source: a source that reads a local subversion repository and provides the content, supports revisions etc. (read-only) http://www.mindquarry.org/repos/mindquarry-workspace/trunk/ mindquarry-dma-source/ how to you access SVN? Are you using a ASL-compatible base library? (http://people.apache.org/~cliffs/3party.html) We access SVN through the means of a Spring Bean. This Bean acts either as a wrapper to Subversion's native JavaHL API, which unfortunately requires native code or to SVNKit, which is not ASL- compatible. So while I see not much chances of integrating this into Cocoon, it sill might be interesting for projects using coocoon. How does Maven2 access SVN remote repositories?? Doesn't whatever they use be able to help out in this case? Cheers Niclas -- Lars Trieloff visit http://www.mindquarry.com/
Re: SVN Source for Cocoon
Hi Reinhard, - SVN source: a source that reads a local subversion repository and provides the content, supports revisions etc. (read-only) http://www.mindquarry.org/repos/mindquarry-workspace/trunk/ mindquarry-dma-source/ how to you access SVN? Are you using a ASL-compatible base library? (http://people.apache.org/~cliffs/3party.html) We access SVN through the means of a Spring Bean. This Bean acts either as a wrapper to Subversion's native JavaHL API, which unfortunately requires native code or to SVNKit, which is not ASL- compatible. So while I see not much chances of integrating this into Cocoon, it sill might be interesting for projects using coocoon. -- Lars Trieloff visit http://www.mindquarry.com/
Re: [RT] Accessing environment information in 2.2
Hi Daniel, Carsten, Carsten Ziegeler skrev: During development you sometimes face the problem that you need access to specific information, like the current request object (or its parameters), the Spring application context, the servlet context etc. In an ideal world where everything is a component, this is no issue as the container provides a way for this. But as we all know, the world is not ideal and this means, you sometimes need access to those objects when you don't have anything else to use. Can you give some specific examples where you need this? We have similar needs. For using REST-style POST and PUT request with blocks it is neccessary to copy the original request input stream to a new block request, so it would be helpful to be able to access the original request at this point of time. Another use case is copying request parameters when using blocks. I'm sure Alexander can give you some more details. I think we need a way to access the servlet context, the original http request/response object and the current application context. (If you have access to the current request object, you can get the application context from the request). Spring has some kind of request scope for beans together with a servlet filter for setting up the scope it has also mechanisms for keeping dependencies on request scoped beans up to date. This is a fairly structured and controlled way to handle request scoped information. And it keeps DI and testability. Would it be enough for your needs? If there is a solution for this problem that does not uses global variables, we should go for it. Lars -- Lars Trieloff visit http://www.mindquarry.com/
Re: svn commit: r475471 - /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml
Thank you. The Eclipse-Maven plugin removes comments and xml schema references when adding dependencies using the GUI. Am 16.11.2006 um 15:51 schrieb Vadim Gritsenko: [EMAIL PROTECTED] wrote: Author: ltrieloff Date: Wed Nov 15 14:36:29 2006 New Revision: 475471 URL: http://svn.apache.org/viewvc?view=revrev=475471 Log: update to correct excalibur-sourceresolve dependency Modified: cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml Modified: cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml URL: http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/ cocoon-forms-impl/pom.xml?view=diffrev=475471r1=475470r2=475471 = = --- cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml (original) +++ cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml Wed Nov 15 14:36:29 2006 @@ -1,37 +1,13 @@ -?xml version=1.0 encoding=UTF-8? -!-- - Licensed to the Apache Software Foundation (ASF) under one - or more contributor license agreements. See the NOTICE file I think you lost license. Vadim -- Lars Trieloff visit http://www.mindquarry.com/
Re: svn commit: r472413 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
${pom.artifactId} in the Manifest is verified to work.
Lars
Am 08.11.2006 um 09:57 schrieb Leszek Gawron:
[EMAIL PROTECTED] wrote:
Author: giacomo
Date: Tue Nov 7 23:50:28 2006
New Revision: 472413
URL: http://svn.apache.org/viewvc?view=revrev=472413
Log:
added MANIFEST entry for Cocoon Blocks
Modified:
cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/
main/resources/archetype-resources/pom.xml
Modified: cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/
src/main/resources/archetype-resources/pom.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/tools/archetypes/
cocoon-22-archetype-block/src/main/resources/archetype-resources/
pom.xml?view=diffrev=472413r1=472412r2=472413
=
=
--- cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/
main/resources/archetype-resources/pom.xml (original)
+++ cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/
main/resources/archetype-resources/pom.xml Tue Nov 7 23:50:28 2006
@@ -62,6 +62,18 @@
contextPath//contextPath
/configuration
/plugin
+ plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-jar-plugin/artifactId
+version2.1/version
+configuration
+ archive
+manifestEntries
+ Cocoon-Block-Name${pom.artifactId}/Cocoon-Block-
Name
+/manifestEntries
+ /archive
+/configuration
+ /plugin
Will that work? I know this does not:
webAppSourceDirectorytarget/${artifactId}-${version}/
webAppSourceDirectory
${artifactId}, ${version} are processed during archetype creation and
all you get are static strings.
--
Leszek GawronCTO at MobileBox Ltd.
--
Lars Trieloff
visit http://www.mindquarry.com/
Re: Solution found [Re: Performance with blocks protocol]
Alex, please submit a patch to JIRA, I will review and test it with the same setting as yesterday evening (JMeter+Yourkit) post the figures and commit it if Daniel has no objections. Lars Am 08.11.2006 um 11:28 schrieb Alexander Klimetschek: Alexander Klimetschek schrieb: Looking in the RequestProcessor that is called by the standard SitemapServlet, it calls ProcessingUtil.cleanup(), while leaving the processing of a request. I don't call that in the corresponding code in the o.a.c.sitemap.SitemapServlet, that might be a problem. I have copied that, because I tried to figure out what is different between the sitemap.SitemapServlet and the RequestProcessor, but it did not change anything with the memory leak. My fault, didn't built the core module after changing that. It is indeed the missing ProcessingUtil.cleanup() method. You probably did not put it into the sitemap.SitemapServlet because it cleans everything, including the current request data, so when called in a block that is called by another block, upon return no further processing is possible because you get NPEs when accessing the original HttpRequest... So I put that call into the DispatcherServlet, right at the end of the service() method and it seems to work. We will now do some testing with the blocks-fw-samples and then commit it. Alex -- Alexander Klimetschek http://www.mindquarry.com -- Lars Trieloff visit http://www.mindquarry.com/
Re: Performance with blocks protocol
These are the Results after applying Alexander's patch. I've modified the test case to use 32 threads for drilling, as with 10 threads only 10 ResourceReaders will be created. - 2731 BlockCallHttpServletRequest none - 2731 ResourceReader 32 - 5463 HttpEnvironment none - 5463 HttpRequest none - 5463 HttpResponse none - 5463 NonCachingProcessingPipeline 32 Looks very good! I will commit the patch. -- Lars Trieloff visit http://www.mindquarry.com/
[jira] Closed: (COCOON-1948) [Patch] Memory leak in Blocks Framework - ProcessingUtil.cleanup() does not get called
[ http://issues.apache.org/jira/browse/COCOON-1948?page=all ] Lars Trieloff closed COCOON-1948. - Resolution: Fixed fixed in revision 472455 [Patch] Memory leak in Blocks Framework - ProcessingUtil.cleanup() does not get called -- Key: COCOON-1948 URL: http://issues.apache.org/jira/browse/COCOON-1948 Project: Cocoon Issue Type: Bug Components: - Blocks Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Priority: Critical Attachments: cocoon-blocks-fw-fix-memory-leak.patch, cocoon-blocks-fw-fix-memory-leak.patch ProcessingUtil.cleanup() does not get called when using the blocks framework. Thus all components stay in memory, including references to OutputStreams (mostly via the ResourceReader, depending on the actual sitemaps), so the heap quickly grows to its maximum. The ProcessingUtil.cleanup() call cannot be put into the sitemap.SitemapServlet because it cleans everything, including the current request data, so when called in a block that is called by another block, upon return no further processing is possible because you get NPEs when accessing the original HttpRequest... So I put that call into the DispatcherServlet, right at the end of the service() method and it seems to work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1937) AccessorTestCase fails due to incomplete context initialization
[ http://issues.apache.org/jira/browse/COCOON-1937?page=all ] Lars Trieloff closed COCOON-1937. - Resolution: Fixed AccessorTestCase fails due to incomplete context initialization --- Key: COCOON-1937 URL: http://issues.apache.org/jira/browse/COCOON-1937 Project: Cocoon Issue Type: Bug Components: Blocks: Templating Reporter: Lars Trieloff The test cases in cocoon-template-impl fail in AccessorTestCase: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.components.accessor.ObjectModelAccessor.getObjectModel(ObjectModelAccessor.java:42) at org.apache.cocoon.components.accessor.RequestAccessor.getObject(RequestAccessor.java:30) at org.apache.cocoon.components.accessor.AccessorTestCase.testRequestAccessor(AccessorTestCase.java:43) The reason seems to be that at initialization of the AccessorSelector there is some incomplete initialization of the DefaultContext, such that no valid object model is handed to the DefaultContext. What is the best way to populate the DefaultContext in the test case with an object model that contains request, session and context? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Performance with blocks protocol
Hi, we should check that there are really no more than 32 instances of ResourceReader on the heap. If this is the case, all we need to do is to raise the -Xmx limit and add a note to the docs that blocks might need some more memory. Meanwhile I will try to reproduce this problem in the cocoon-blocks- fw-demo so that it can be tested using JMeter and YourKit Java Profiler. Lars Am 07.11.2006 um 10:25 schrieb Daniel Fagerstrom: Alexander Klimetschek skrev: This seems to be the real problem. There are new ResourceReader instances for each request (along with the BlockSource, BlockConnection etc. connected with it), but they are never reused. Instead they keep in memory, referenced by some ThreadLocal storage. Something in the special handling o.a.c.sitemap.SitemapServlet might be buggy, but we cannot see what. Do you have time to further look at that this week? When using forms, the amount of data that is collected this way increases so fast, that we sometimes get an OutOfMemory after 3-4 reloads... Looking at the ResourceReader it is Recyclable and has a default max-pool-size of 32. I don't know enough about the Avalon life style implementation to know exactly what happens. As long as there are no more than 32 instances of ResourceReaders they are, AFAIU supposed to be kept in a pool in the memory. But we would get a problem if the recycle method of the ResourceReader is called to late or not at all in that case the other object would be kept in memory when they should have been garbage collected. -- Lars Trieloff visit http://www.mindquarry.com/
Re: svn commit: r472224 - /cocoon/trunk/core/cocoon-webapp/pom.xml
Am 07.11.2006 um 23:08 schrieb Leszek Gawron: [EMAIL PROTECTED] wrote: Author: ltrieloff Date: Tue Nov 7 11:48:15 2006 New Revision: 472224 URL: http://svn.apache.org/viewvc?view=revrev=472224 Log: use newest jetty plugin. From now on mvn cocoon:deploy jetty:run Modified: cocoon/trunk/core/cocoon-webapp/pom.xml Modified: cocoon/trunk/core/cocoon-webapp/pom.xml URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-webapp/ pom.xml?view=diffrev=472224r1=472223r2=472224 = = --- cocoon/trunk/core/cocoon-webapp/pom.xml (original) +++ cocoon/trunk/core/cocoon-webapp/pom.xml Tue Nov 7 11:48:15 2006 @@ -58,8 +58,8 @@ /plugin plugin groupIdorg.mortbay.jetty/groupId -artifactIdmaven-jetty6-plugin/artifactId -version6.0.0beta10/version +artifactIdmaven-jetty-plugin/artifactId +version6.0.0rc4/version That probably won't work. I have done it once and reverted the change. New jetty plugin has some classloader issues (i.e. puts all webapp jar on classpath so shielding does not work as it is supposed). Maybe something changed though... I see. We are using the newer Jetty plugins exclusively as they fix a bug with reloading jar files from the local repository. Is there a Jetty bug for the problem you experienced? Lars -- Lars Trieloff visit http://www.mindquarry.com/
Re: Performance with blocks protocol
Results from a JMeter-drilling test: accessing http://localhost:8080/ cocoon/cocoon-blocks-fw-sample3/sub/test in 10 parallel threads using the cocoon-blocks-fw-sample. - 1 DispatcherServlet - 4 BlockServlet - 4 SitemapServlet - 6 TreeProcessor - 6 EnvironmentHelper - 2731 BlockCallHttpServletRequest - 1 ReadNode - 2731 ResourceReader - 5463 HttpEnvironment - 5463 HttpRequest - 5463 HttpResponse - 5463 NonCachingProcessingPipeline Meanwhile I will try to reproduce this problem in the cocoon-blocks- fw-demo so that it can be tested using JMeter and YourKit Java Profiler. -- Lars Trieloff visit http://www.mindquarry.com/
Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
+1 Before we start changing directory structures, I think it makes sense to vote. The proposal is to use the following directory structure inside a block jar: COB-INF - resources META-INF/cocoon/xconf/** META-INF/cocoon/spring/** META-INF/cocoon/properties/** Please cast your votes. -- Lars Trieloff visit http://www.mindquarry.com/
Re: Uploads not working with blocks, proposal for fix
Checking for a class doesn't seem to be a good idea I think we should check for an interface instead. Implemented. Maybe we instead could make the DispatcherServlet less intrusive on the request object by modifying the getServletPath() and getPathInfo () on the incomming request object by a dynamic proxy instead of wrapping it with a request wrapper. Implemented as well. Thank you for the suggestion. Uploads are now working again. Lars -- Lars Trieloff visit http://www.mindquarry.com/
Uploads not working with blocks, proposal for fix
Hi Daniel, I've just noted that uploads with CForms are not working with the Blocks Framework. The reason is a bug in org.apache.cocoon.environment.http.HttpRequest.get() that checks for a wrapped MultipartHttpServletRequest. With the Blocks framework the actual MultipartHttpServletRequest is wrapped into an anonymous HttpServletRequestWrapper in DispatcherServlet. My proposal to fix the bug without including cyclic dependencies is to create a new abstract class org.apache.cocoon.AbstractValueHttpServletRequestWrapper that includes a get-method, extends HttpRequestWraper and will be extended by MultipartHttpServletRequestWrapper as well as by the anonymous class in DispatcherServlet. The HttpRequest would check for this class and uploads are working again. What do you think? Lars -- Lars Trieloff visit http://www.mindquarry.com/
Re: svn commit: r467749 - /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Hi Jörg, Am 25.10.2006 um 23:10 schrieb Joerg Heinicke: On 25.10.2006 22:07, [EMAIL PROTECTED] wrote: + xsl:template match=* mode=copy-parent-id +xsl:copy + !-- do not override id if already specified, else use parent id -- + xsl:if test=not(@id) +xsl:attribute name=idxsl:value-of select=../@id// xsl:attribute + /xsl:if + xsl:copy-of select=@*/ This check is not necessary, the orignal version works. The reason is, that the potential attribute on the currently processed element overwrites the other one, as xsl:copy-of select=@*/ is applied after xsl:attribute name=id. Thanks for the hint, I did not notice this, but reverted it to the original state now. But something more general: This patch looks very specific for a maybe much more generic problem. This is just a feeling ... have not been working with CForms since 2 years and never with its Ajax functionality. What's the actual root cause? The main problem is that Cocoon-Ajax sends an update-command to the browser after deactivating or activating a fi:group programatically. This update-command works on a single HTML element that needs an ID to be identified. Forms that use ft:group with AJAX need to wrap everything contained in the group into a single HTML element to be able to recieve updates. If this element does not include an ID attribute, updating does not work either, because the target of the operation cannot be determined, so this stylesheet fix just copies the ID of the enclosing fi:group. Lars -- Lars Trieloff visit http://www.mindquarry.com/
Re: CForms: Upload Repeater
Hi Jeremy, I have now got AJAX-type submission via IframeIO in Dojo working for forms that have file-upload controls in them. Great. But meanwhile, I am trying to get some sort of Upload Repeater working and I have several problems .. The usecase is that a user may add a number of file-upload controls to a repeater, select files for them, then submit them all in one go. One problem is, that if you have file-upload controls on a form, that have a file selected, they get submitted when you click on the repeater's add button, as these action-events submit the whole form. This applies only to non-AJAX forms, I suppose. I would like to change this behaviour but do not know if this will break some other usecases. Why do you want to change the behaviour? I think it is the common behaviour in all non-ajax-enabled upload forms, so I don't see the need. In your case you would, prior to uploading get the file names from all upload fields in the repeater that already have a value, store it in a hidden field, clear the original upload field, send it to the server and when the server responds, you will copy the file names from the hidden fields to the upload fields, right? What happens if JS is deactivated? Lars -- Lars Trieloff visit http://www.mindquarry.com/
Re: CForms: Upload Repeater
The usecase is that a user may add a number of file-upload controls to a repeater, select files for them, then submit them all in one go. One problem is, that if you have file-upload controls on a form, that have a file selected, they get submitted when you click on the repeater's add button, as these action-events submit the whole form. This applies only to non-AJAX forms, I suppose. No, this happens with Ajax-enabled forms But in this case the repeater's add-button should only do an ajax- request and add the new contents behind the already existing repeater- rows. So I think the main problem is making the repeater AJAX-aware. I would like to change this behaviour but do not know if this will break some other usecases. Why do you want to change the behaviour? I think it is the common behaviour in all non-ajax-enabled upload forms, so I don't see the need. In your case you would, prior to uploading get the file names from all upload fields in the repeater that already have a value, store it in a hidden field, clear the original upload field, send it to the server and when the server responds, you will copy the file names from the hidden fields to the upload fields, right? What happens if JS is deactivated? Tricks like this are not possible (if I understood you right) there is no API for setting the value of file-upload controls via javascript. It is locked down as a security issue. Ok. I didn't know this, -- Lars Trieloff visit http://www.mindquarry.com/
Re: CForms: Upload Repeater
But in this case the repeater's add-button should only do an ajax- request and add the new contents behind the already existing repeater-rows. So I think the main problem is making the repeater AJAX-aware. Repeaters are already Ajax-aware. When you click to add a new row, the whole form is submitted, with the repeater's action button id in the hidden 'forms_submit_id' field. AFAICS, currently all form data is sent, but is not validated on the server. Turning on Ajax in the form results in the whole form being submitted via Ajax techniques, a new hidden field 'cocoon- ajax=true' is created, this is detected by the response pipeline to filter and wrap any changes in the BrowserUpdate schema, which is used to inject those changes into the form. This is how it already works. The trouble for my usecase though is that all the form fields are submitted, when not all of it is 'needed' for the event to work properly on the server. I am trying to work out if it is safe to somehow filter out a bunch of fields from this type of submit. Only sending enough data for the action to work. I see no problem with excluding some fields from the submit e.g. for actions or on-value-changed submits, the server just needs to know there are some fields that are not sending data, not sending empty data. Lars -- Lars Trieloff visit http://www.mindquarry.com/
[jira] Created: (COCOON-1941) Upgrade DOJO to 0.4
Upgrade DOJO to 0.4 --- Key: COCOON-1941 URL: http://issues.apache.org/jira/browse/COCOON-1941 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff The Dojo Foundation has released version 0.4 of the Dojo toolkit yesterday. Cocoon should use this version of Dojo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1942) Parameters in BlockConnection are read before initialized, leading to NPE
Parameters in BlockConnection are read before initialized, leading to NPE - Key: COCOON-1942 URL: http://issues.apache.org/jira/browse/COCOON-1942 Project: Cocoon Issue Type: Bug Components: - Blocks Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff The constructor of o.a.c.b.BlockConnection is called before the parameters are available (which are initialized by the parametrize method). This leads to a NullPointerException when creating a BlockConnection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1942) Parameters in BlockConnection are read before initialized, leading to NPE
[ http://issues.apache.org/jira/browse/COCOON-1942?page=all ] Lars Trieloff closed COCOON-1942. - Resolution: Invalid Parameters in BlockConnection are read before initialized, leading to NPE - Key: COCOON-1942 URL: http://issues.apache.org/jira/browse/COCOON-1942 Project: Cocoon Issue Type: Bug Components: - Blocks Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff The constructor of o.a.c.b.BlockConnection is called before the parameters are available (which are initialized by the parametrize method). This leads to a NullPointerException when creating a BlockConnection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1938) [Patch] Allow blocks mounted at / to handle more than just the / URL
[ http://issues.apache.org/jira/browse/COCOON-1938?page=all ] Lars Trieloff closed COCOON-1938. - Resolution: Won't Fix I've just tried it with mounting the block at , not / and it works as expected. But it should be documented, that the root mount path is , not /. Additionally, making / an alias for should be thought of. [Patch] Allow blocks mounted at / to handle more than just the / URL Key: COCOON-1938 URL: http://issues.apache.org/jira/browse/COCOON-1938 Project: Cocoon Issue Type: Improvement Components: - Blocks Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Priority: Minor Attachments: cocoon-blocks-fw-improve-root-mounting.patch The current DispatcherServlet allows for blocks mounted at / only the simple / URL to be handled because all other cases (eg. /style.css or /index.html) will be interpreted as blocks - and because these don't exist, the matching will fail. For this case, I added a short piece of code that will allow to handle such cases for the root block. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Postable block protocol
Hi Daniel, I was already starting to create a parametrizable BlockSource and BlockConnection, when Alexander got the idea of creating an InputSource that would be less invasive to the blocks-fw code. How do you think should a postable source work? Don't you think something like a transformer world be a better fit? This way you could create XML from your request using the request generator, hand it to a proxy-transformer which will create the Http-Request or the Block-Request and return the results? The only problem would be accessing non-xml resources. Lars Am 25.10.2006 um 13:39 schrieb Daniel Fagerstrom: While your input module can be usable in its own right I think that we should make the block protocol postable. Besides that it simplify reusing form handling as you describe above. I think that it is generally useful to make it possible to let blocks contain web services that can be called through the block protocol and be used as some webapp internal web services. To achieve this the o.a.c.blocks.util.BlockCallHttpServletRequest needs to be extended with input handling and o.a.c.blocks.components.BlockSource need to implement ModifiableSource and o.a.c.blocks.BlockProtocol needs to take care of the input. I extended the HttpClientSource to be postable long time ago (http://issues.apache.org/jira/browse/COCOON-871) as part of some code for handling web service calls within pipelines. I never applied the patch as we had some disagreement about if it was a good idea to use web services from Cocoon in this way. The critique was mainly about my extension of the SourceWritingTransformer, I still think it would be a good idea to have postable sources and especially to make the block protocol postable. /Daniel -- Lars Trieloff visit http://www.mindquarry.com/
Re: Postable block protocol
Hi Daniel, A drawback with using the some extension of the VPCs for inter block communication is that it ties the communications to the specific sitemap component APIs, so they are not usable for communication with non sitemap blocks. What I would propose is to create some new pipeline components that calls postable sources, and make the block protocol postable. Then we have four cases for the different combinations of XML or non XML input and output respectably: non XML - non XML map:read type=service src=block:b:/foo1/ non XML - XML map:generate type=service src=input.txt map:parameter name=service value=block:b:/foo2/ /map:generate XML - XML map:transform type=service src=block:b:/foo3/ XML - non XML map:serialize type=service src=block:b:/foo4/ I think this is the way we should do it. Using the source interface it is possible to communicate with simple servlets, with the sitemap components, it is easy to use from the sitemap. A tricky thing is of course to get rid of buffering and serializing followed by parsing steps for calls to services that have XML input and/or output. But I think that 1) the problem is solvable and 2) we don't have to solve it in the first implementation. What is the exact interface that the BlockSource has to implement? Then I could start looking into implementing the interface. Anyway: Is it possible to apply Alexander's original patch, as we need it in our application and it does not seem to invasive from my point of view? Lars -- Lars Trieloff visit http://www.mindquarry.com/
[jira] Closed: (COCOON-1944) [PATCH] Group widget id gets removed when group widget is just to group some sub widgets. AJAX won't work in that case
[ http://issues.apache.org/jira/browse/COCOON-1944?page=all ] Lars Trieloff closed COCOON-1944. - Resolution: Fixed Thank you. It is applied in r467749. I changed the template to add the attribute only to elements and to add only an id attribute if there is not already an id attribute in the container element. This removes the neccessity to include duplicate ids in a form template if you would like to keep your templates consistent. [PATCH] Group widget id gets removed when group widget is just to group some sub widgets. AJAX won't work in that case -- Key: COCOON-1944 URL: http://issues.apache.org/jira/browse/COCOON-1944 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Reporter: Rob Berens Attachments: patch-1944-1.txt When you use a group widget just to group some widgets in order to apply some common functionality such as setting the state of all widgets by setting the state of the group then the id of the fi:group is not copied to its enclosed child element. Therefore using ajax will fail as the widget id is not present in the html output. This is solved in the forms-field-styling.xsl. See patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: imageop-block in 2.2
Hi Nicolas, I've migrated the block by saturday, with all the pending issues. We should add these issues to JIRA. Lars Since it was I who contributed it somehmmm... 2(?) years ago, I should actually do it myself now that I am a worthy committer ;o) Well... Just want you to know that there are outstanding issues with it. IIRC; 1. Rotation of images will not produce the expected result. I never managed to figure out how to make it work, and probably need to dig deeper into the Java2D stuff (not my ball game). 2. Certain types of TIFF encodings will result in incorrect colors when converted. It is not all TIFFs, and I have not even managed to figure out which does and which doesn't work. 3. Installation of Java Advanced Imaging must be done. Never bothered to figure out if it can be used ad-hoc, or must be installed into the JRE as we did in the project (easiest approach). But besides that, scaling and conversions of images are lightening fast, and we deployed a couple of 'thumb nail' style photo library sites (NO, not porn) and a product catalog for both web and print. I got feedback from Stefan Pietschmann, and it might be that he has additional info/changes available... Cheers Niclas -- Lars Trieloff visit http://www.mindquarry.com/
[jira] Created: (COCOON-1937) AccessorTestCase fails due to incomplete context initialization
AccessorTestCase fails due to incomplete context initialization --- Key: COCOON-1937 URL: http://issues.apache.org/jira/browse/COCOON-1937 Project: Cocoon Issue Type: Bug Components: Blocks: Templating Reporter: Lars Trieloff The test cases in cocoon-template-impl fail in AccessorTestCase: org.apache.cocoon.components.ContextResourceNotFoundException: Unable to get the object model from the context. at org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) at org.apache.cocoon.components.accessor.ObjectModelAccessor.getObjectModel(ObjectModelAccessor.java:42) at org.apache.cocoon.components.accessor.RequestAccessor.getObject(RequestAccessor.java:30) at org.apache.cocoon.components.accessor.AccessorTestCase.testRequestAccessor(AccessorTestCase.java:43) The reason seems to be that at initialization of the AccessorSelector there is some incomplete initialization of the DefaultContext, such that no valid object model is handed to the DefaultContext. What is the best way to populate the DefaultContext in the test case with an object model that contains request, session and context? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
imageop-block in 2.2
Hi, In cocoon 2.1 there is an imageop-block that allows more powerful image transformations then the standard image reader. It is based on a contribution https://issues.apache.org/jira/browse/COCOON-1301 but not yet ported to Cocoon 2.2. I see Jean-Baptiste started porting, but was unable to finish it, so if there are no obections, I will start porting it to cocoon 2.2. Lars Lars Trieloff visit http://www.mindquarry.com/
[jira] Updated: (COCOON-1301) [Patch] Image Operation Reader
[ http://issues.apache.org/jira/browse/COCOON-1301?page=all ] Lars Trieloff updated COCOON-1301: -- Attachment: cocoon-imageop-2.2.tar.gz Complete port of the imageop block to Cocoon 2.2. To be extracted in trunk/blocks. [Patch] Image Operation Reader -- Key: COCOON-1301 URL: http://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, imageop-block.zip I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1301) [Patch] Image Operation Reader
[ http://issues.apache.org/jira/browse/COCOON-1301?page=all ] Lars Trieloff updated COCOON-1301: -- Attachment: cocoon-imageop-2.2.tar.gz Same file, without compiled classes. [Patch] Image Operation Reader -- Key: COCOON-1301 URL: http://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, cocoon-imageop-2.2.tar.gz, imageop-block.zip I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1301) [Patch] Image Operation Reader
[ http://issues.apache.org/jira/browse/COCOON-1301?page=all ] Lars Trieloff closed COCOON-1301. - Resolution: Fixed Resolved with r466242. [Patch] Image Operation Reader -- Key: COCOON-1301 URL: http://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, cocoon-imageop-2.2.tar.gz, imageop-block.zip, pom.xml I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: AW: RFC: CForms + Dojo: the way forward
Hi Christopher, as the individual JS files are rather small, the most costly part is requesting them from the web server, not downloading them. With an aggregated file, there is only one single request. I agree that it does not make sense to create a JS file per form because that would result in redundant downloads, so the only possibility is to have it configured at build time. What about creating a src/main/js directory where all contained *.js files will be aggregated into a single $projectname.js file? Lars Am 09.10.2006 um 09:26 schrieb [EMAIL PROTECTED]: Hi, I am following this discussion since the beginning. There is one thing I don't quite understand. I had a lot of problems with dojo, because it does a lot of caching on its own. If we package and compress the scripts on a per-form-basis we get tons of different compressed js-files with lots of redundant code fragments. Each one has to be transferred individually. Wouldn't it be better to compress each fragment individually so the current loading mechanism is still used but the resources being loaded are compressed? Chris -Ursprüngliche Nachricht- Von: Lars Trieloff [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 6. Oktober 2006 20:01 An: dev@cocoon.apache.org Betreff: Re: RFC: CForms + Dojo: the way forward Hi Jeremy, I see the following ways to solve this: - create a DojoReader that will dynamically compress and aggregate Javascript on the fly. - create a Maven Mojo that does the same job as Dojo's ant task, but this needs to be configured at build time. The first option needs no build time configuration and it allows to generate a minimal javascript library file on the fly that needs to be loaded only once for every configuration of dojo.require statements. The most important question here is: How do we find out, what dojo packages are actually required. Lars Am 06.10.2006 um 16:42 schrieb Jeremy Quinn: 6. Dojo has an ant build script which uses Rhino to compile and compress all needed dojo code into a single file. This speeds up the client *significantly*. How can we use this better from within Cocoon? Conclusion: It would be of great advantage to have this dojo compressor build, better integrated into Cocoon, so that an optimised production environment can be used. The compressor does 2 things: aggregate and compress all of the required dojo packages, aggregate all of the html template and css snippets required by the widgets you actually need. This functionality is already in place (src/blocks/ajax/dojo/), it is just not obvious or automatable. Currently you would create a listing of the required dojo libs by hand, then run the build script. Can and should we find a way to automate this? Lars Trieloff visit http://www.mindquarry.com/
Re: [VOTE] Lars Trieloff as a new Cocoon committer
Hi everyone, Now that the voting is over, I think it is time to introduce myself to the list: My first encounter with Cocoon was in 2001, when I was looking for a standards conforming way to generate XHTML out of web- applications. In the meantime I have started and finished my studies at the Hasso-Plattner-Institute in Potsdam, wrote a book on DocBook XML, and developed an extension to Subversion that allows it to deal with XML documents in terms of the XML Infoset, not as text files. This leads me to my current engagement with Cocoon. As co-founder of Mindquarry I am developing with my team a software for better teamwork that combines the best aspects of version control systems, wikis, issue tracking systems and mailing list systems. We are using Cocoon 2.2 for the web application layer, so my main aspects of work within the Cocoon project will be fixing bugs in trunk, integrating Cocoon with JCR and version control systems, the build system and CForms. It is a great honor for me to be invited to take part in the Cocoon project and meeting you at the Cocoon GT and hacking together at the Hackathon was more than a joy. I am looking forward to further development of Cocoon and increasing the percentage of pages in the world wide web served by Cocoon ;-) Lars Am 06.10.2006 um 22:32 schrieb Jean-Baptiste Quenot: Congratulations Lars, you are elected with 21 +1s. Welcome on board! It was very nice to meet you at the Cocoon GetTogether. We all enjoyed hacking with you ;-) -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/ Lars Trieloff visit http://www.mindquarry.com/
Re: RFC: CForms + Dojo: the way forward
Hi Jeremy, I see the following ways to solve this: - create a DojoReader that will dynamically compress and aggregate Javascript on the fly. - create a Maven Mojo that does the same job as Dojo's ant task, but this needs to be configured at build time. The first option needs no build time configuration and it allows to generate a minimal javascript library file on the fly that needs to be loaded only once for every configuration of dojo.require statements. The most important question here is: How do we find out, what dojo packages are actually required. Lars Am 06.10.2006 um 16:42 schrieb Jeremy Quinn: 6. Dojo has an ant build script which uses Rhino to compile and compress all needed dojo code into a single file. This speeds up the client *significantly*. How can we use this better from within Cocoon? Conclusion: It would be of great advantage to have this dojo compressor build, better integrated into Cocoon, so that an optimised production environment can be used. The compressor does 2 things: aggregate and compress all of the required dojo packages, aggregate all of the html template and css snippets required by the widgets you actually need. This functionality is already in place (src/blocks/ajax/dojo/), it is just not obvious or automatable. Currently you would create a listing of the required dojo libs by hand, then run the build script. Can and should we find a way to automate this?
[jira] Closed: (COCOON-1908) Add query support to JCR source factory
[ http://issues.apache.org/jira/browse/COCOON-1908?page=all ] Lars Trieloff closed COCOON-1908. - Resolution: Later This will be included in the reworked JCR sourcefactory that Mindquarry is currently working on. Add query support to JCR source factory --- Key: COCOON-1908 URL: http://issues.apache.org/jira/browse/COCOON-1908 Project: Cocoon Issue Type: New Feature Components: Blocks: JCR Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: cocoon-jcr-add-query-support.patch The current implementation of the JCRSourceFactory is missing the support for JCR queries (XPath and SQL) and only allows direct paths (like jcr://root/folder/file). I have implemented a simple query handling (see patch). It supports both XPath (required for JCR Level 1 compliance, thus any JCR implementation) and SQL (optional JCR feature). The query strings given as Source-URIs must look like this: XPath: jcr://xpath!//root/* (which maps to the xpath query //root/* which is passed on to the JCR Query) jcr://!//root/* (which is just a shorthand notation for the above, using Xpath) SQL: jcr://sql!select * from nt:base where jcr:path = '/root/myfile' (well, which maps to the sql query select * from nt:base where jcr:path = '/root/myfile') There is a restriction for the queries: the result to be returned must be a content-node with no children and some streamable content. The JCRNodeSource class does not allow collections to be returned. I am working on subclasses that will target this issue (using the XMLizable interface) but this is not yet finished. I tried to make the patch complete, including updated javadocs for the JCRSourceFactory class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1905) [PATCH] Support non-file resources for jaas.config in JCR block
[ http://issues.apache.org/jira/browse/COCOON-1905?page=all ] Lars Trieloff closed COCOON-1905. - Resolution: Later This will be included in the reworked JCR sourcefactory that Mindquarry is currently working on. [PATCH] Support non-file resources for jaas.config in JCR block --- Key: COCOON-1905 URL: http://issues.apache.org/jira/browse/COCOON-1905 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-jcr-jaas-uri-source.patch The current implementation of the JCR-block requires the user to define a physical file as source for the jaas.config. While is behaviour matches the requirements of the Java JAAS implementation it is inconvenient for development and prevents the creation of a generic out-of-the-box cocoon-JCR-example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1926) CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException
CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException - Key: COCOON-1926 URL: http://issues.apache.org/jira/browse/COCOON-1926 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Following stack trace: java.lang.NullPointerException at org.apache.cocoon.environment.ObjectModelHelper.getRequest(ObjectModelHelper.java:65) at org.apache.cocoon.environment.internal.EnvironmentHelper.getSitemapServiceManager(EnvironmentHelper.java:400) at org.apache.cocoon.ProcessingUtil.getSitemapServiceManager(ProcessingUtil.java:110) at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:154) at org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:550) at org.apache.cocoon.transformation.CIncludeTransformer.startTransformingElement(CIncludeTransformer.java:258) at org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(AbstractSAXTransformer.java:460) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349) at $Proxy1.startElement(Unknown Source) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.startNode(DOMStreamer.java:435) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.stream(DOMStreamer.java:217) at org.apache.cocoon.xml.dom.DOMStreamer.stream(DOMStreamer.java:141) at org.apache.cocoon.SitemapComponentTestCase.transform(SitemapComponentTestCase.java:404) at org.apache.cocoon.transformation.CIncludeTransformerTestCase.testCInclude1(CIncludeTransformerTestCase.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1926) CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException
[ http://issues.apache.org/jira/browse/COCOON-1926?page=all ] Lars Trieloff updated COCOON-1926: -- Attachment: cocoon-core-testcases.patch This patch changes the sitemaptestcase class to be able to resolve beans as if it were running in a servlet container. The result is that all test cases in cocoon-core are working again. CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException - Key: COCOON-1926 URL: http://issues.apache.org/jira/browse/COCOON-1926 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-core-testcases.patch Following stack trace: java.lang.NullPointerException at org.apache.cocoon.environment.ObjectModelHelper.getRequest(ObjectModelHelper.java:65) at org.apache.cocoon.environment.internal.EnvironmentHelper.getSitemapServiceManager(EnvironmentHelper.java:400) at org.apache.cocoon.ProcessingUtil.getSitemapServiceManager(ProcessingUtil.java:110) at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:154) at org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:550) at org.apache.cocoon.transformation.CIncludeTransformer.startTransformingElement(CIncludeTransformer.java:258) at org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(AbstractSAXTransformer.java:460) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349) at $Proxy1.startElement(Unknown Source) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.startNode(DOMStreamer.java:435) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.stream(DOMStreamer.java:217) at org.apache.cocoon.xml.dom.DOMStreamer.stream(DOMStreamer.java:141) at org.apache.cocoon.SitemapComponentTestCase.transform(SitemapComponentTestCase.java:404) at org.apache.cocoon.transformation.CIncludeTransformerTestCase.testCInclude1(CIncludeTransformerTestCase.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1922) [PATCH] cocoon-core-sample should be part of the default build, because it is required by the default example webapp
[PATCH] cocoon-core-sample should be part of the default build, because it is required by the default example webapp Key: COCOON-1922 URL: http://issues.apache.org/jira/browse/COCOON-1922 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-core-samples-in-default-build.patch The cocoon-webapp depends on cocoon-core-sample, but this is not part of the default build, causing a mvn install in trunk to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1922) [PATCH] cocoon-core-sample should be part of the default build, because it is required by the default example webapp
[ http://issues.apache.org/jira/browse/COCOON-1922?page=all ] Lars Trieloff updated COCOON-1922: -- Attachment: cocoon-core-samples-in-default-build.patch This patch adds cocoon-core-sample to the default build profile. [PATCH] cocoon-core-sample should be part of the default build, because it is required by the default example webapp Key: COCOON-1922 URL: http://issues.apache.org/jira/browse/COCOON-1922 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-core-samples-in-default-build.patch The cocoon-webapp depends on cocoon-core-sample, but this is not part of the default build, causing a mvn install in trunk to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1924) [PATCH] cocoon-fop-ng-block introduces support for FOP 0.92beta and later
[PATCH] cocoon-fop-ng-block introduces support for FOP 0.92beta and later - Key: COCOON-1924 URL: http://issues.apache.org/jira/browse/COCOON-1924 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff This patch was written by Jeremias Märki (FOP Developer) and Lars Trieloff. It uses the new FOP API which simplifies the Serializer code greatly and allows for relative addressing of resources using the URIResolver framework. This patch should close COCOON-1797, COCOON-1795 and COCOON-531 It depends on the addition of the FOP pom to the central repository which is in the works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1924) [PATCH] cocoon-fop-ng-block introduces support for FOP 0.92beta and later
[ http://issues.apache.org/jira/browse/COCOON-1924?page=all ] Lars Trieloff updated COCOON-1924: -- Attachment: cocoon-fop-ng-block.patch In order to keep history of the files, cocoon-fop-impl has to be copied to cocoon-fop-ng-impl and cocoon-fop-sample to cocoon-fop-ng-sample, only afterwards the patch can be applied. Following files are affected by the patch: A + blocks/cocoon-fop/cocoon-fop-ng-impl D + blocks/cocoon-fop/cocoon-fop-ng-impl/src/main/java/org/apache/cocoon/components A blocks/cocoon-fop/cocoon-fop-ng-impl/src/main/java/org/apache/cocoon/serialization/FOPNGSerializer.java D + blocks/cocoon-fop/cocoon-fop-ng-impl/src/main/java/org/apache/cocoon/serialization/FOPSerializer.java M + blocks/cocoon-fop/cocoon-fop-ng-impl/src/main/resources/META-INF/legacy/sitemap-additions/cocoon-fop.xmap M + blocks/cocoon-fop/cocoon-fop-ng-impl/pom.xml A + blocks/cocoon-fop/cocoon-fop-ng-sample M + blocks/cocoon-fop/cocoon-fop-ng-sample/src/main/resources/COB-INF/fop.xsamples M + blocks/cocoon-fop/cocoon-fop-ng-sample/pom.xml M blocks/cocoon-fop/pom.xml [PATCH] cocoon-fop-ng-block introduces support for FOP 0.92beta and later - Key: COCOON-1924 URL: http://issues.apache.org/jira/browse/COCOON-1924 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-fop-ng-block.patch This patch was written by Jeremias Märki (FOP Developer) and Lars Trieloff. It uses the new FOP API which simplifies the Serializer code greatly and allows for relative addressing of resources using the URIResolver framework. This patch should close COCOON-1797, COCOON-1795 and COCOON-531 It depends on the addition of the FOP pom to the central repository which is in the works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1924) [PATCH] cocoon-fop-ng-block introduces support for FOP 0.92beta and later
[ http://issues.apache.org/jira/browse/COCOON-1924?page=all ] Lars Trieloff updated COCOON-1924: -- Attachment: xmlgraphics-maven-repo.tar.gz These files, put into a local maven repository make it possible to build the new fop-ng-block. [PATCH] cocoon-fop-ng-block introduces support for FOP 0.92beta and later - Key: COCOON-1924 URL: http://issues.apache.org/jira/browse/COCOON-1924 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Assigned To: Jean-Baptiste Quenot Attachments: cocoon-fop-ng-block.patch, xmlgraphics-maven-repo.tar.gz This patch was written by Jeremias Märki (FOP Developer) and Lars Trieloff. It uses the new FOP API which simplifies the Serializer code greatly and allows for relative addressing of resources using the URIResolver framework. This patch should close COCOON-1797, COCOON-1795 and COCOON-531 It depends on the addition of the FOP pom to the central repository which is in the works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources
[ http://issues.apache.org/jira/browse/COCOON-1906?page=comments#action_12437870 ] Lars Trieloff commented on COCOON-1906: --- Jean Baptiste, the main problem is that there is no casting in Javascript and for any class that implements both XMLlizable and Source, the Rhino interpreter cannot decide because the distance is equal. So I see following solutions: - adding a method for every xmllizable source (the approach of my patch) - making xmlizable extend source (impossible, as it is in excalibur) - adding an interface xmlizablesource and changing every cocoon source that implements xmlizable (inconvenient) - adding methods with different names sourceToSAX() and xmlizableToSAX() (this is not the best Java style, but would be the choice for Javascript development) As the goal is to make it easier to use this class from Javascript, I would prefer the last option. It does not break the api, requires no changes to existing code and is easy to implement? What do you think? [PATCH] simple-xml binding does not work with non file sources -- Key: COCOON-1906 URL: http://issues.apache.org/jira/browse/COCOON-1906 Project: Cocoon Issue Type: Bug Components: Blocks: Forms, * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-formsbinding-sample.patch, cocoon-formsbinding-sourceutil.patch The cocoon forms flowscript API comes with a helper method form.loadXML, that retrieves data from an xml document. The current implementation however does not work with documents that are referenced not as files, but as SitemapSources, e.g. via the cocoon:/ or xmldb:// pseudo-protocol. In this case the Rhino engine is unable to resolve the ambiguity between two method signatures: org.mozilla.javascript.EvaluatorException: resource://org/apache/cocoon/forms/flow/javascript/Form.js, line 287: The choice of Java constructor toSAX matching JavaScript argument types (org.apache.cocoon.components.source.impl.SitemapSource,org.apache.cocoon.forms.util.XMLAdapter) is ambiguous; candidate constructors are: void toSAX(org.apache.excalibur.xml.sax.XMLizable,org.xml.sax.ContentHandler) void toSAX(org.apache.excalibur.source.Source,org.xml.sax.ContentHandler) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources
[ http://issues.apache.org/jira/browse/COCOON-1906?page=comments#action_12437883 ] Lars Trieloff commented on COCOON-1906: --- org.apache.cocoon.components.source.SitemapSource implements Poolable, Recyclable, LogEnabled, ModifiableSource, *Source*, XMLConsumer, *XMLizable*, ContentHandler, LexicalHandler org.apache.cocoon.components.source.impl.XMLDBSource implements LogEnabled, ModifiableSource, ModifiableTraversableSource, *Source*, TraversableSource, *XMLizable* and some other sources we are using internally. [PATCH] simple-xml binding does not work with non file sources -- Key: COCOON-1906 URL: http://issues.apache.org/jira/browse/COCOON-1906 Project: Cocoon Issue Type: Bug Components: Blocks: Forms, * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-formsbinding-sample.patch, cocoon-formsbinding-sourceutil.patch The cocoon forms flowscript API comes with a helper method form.loadXML, that retrieves data from an xml document. The current implementation however does not work with documents that are referenced not as files, but as SitemapSources, e.g. via the cocoon:/ or xmldb:// pseudo-protocol. In this case the Rhino engine is unable to resolve the ambiguity between two method signatures: org.mozilla.javascript.EvaluatorException: resource://org/apache/cocoon/forms/flow/javascript/Form.js, line 287: The choice of Java constructor toSAX matching JavaScript argument types (org.apache.cocoon.components.source.impl.SitemapSource,org.apache.cocoon.forms.util.XMLAdapter) is ambiguous; candidate constructors are: void toSAX(org.apache.excalibur.xml.sax.XMLizable,org.xml.sax.ContentHandler) void toSAX(org.apache.excalibur.source.Source,org.xml.sax.ContentHandler) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources
[ http://issues.apache.org/jira/browse/COCOON-1906?page=all ] Lars Trieloff updated COCOON-1906: -- Attachment: cocoon-forms-javascript-disambiguation.patch Hi Vadim, thank you for the hint. Using the attached patch, which will disambigue the method using the methodology described at http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html I am able to run the modified samples in the way intended. So the other patches are obsolete. [PATCH] simple-xml binding does not work with non file sources -- Key: COCOON-1906 URL: http://issues.apache.org/jira/browse/COCOON-1906 Project: Cocoon Issue Type: Bug Components: Blocks: Forms, * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-forms-javascript-disambiguation.patch, cocoon-formsbinding-sample.patch, cocoon-formsbinding-sourceutil.patch The cocoon forms flowscript API comes with a helper method form.loadXML, that retrieves data from an xml document. The current implementation however does not work with documents that are referenced not as files, but as SitemapSources, e.g. via the cocoon:/ or xmldb:// pseudo-protocol. In this case the Rhino engine is unable to resolve the ambiguity between two method signatures: org.mozilla.javascript.EvaluatorException: resource://org/apache/cocoon/forms/flow/javascript/Form.js, line 287: The choice of Java constructor toSAX matching JavaScript argument types (org.apache.cocoon.components.source.impl.SitemapSource,org.apache.cocoon.forms.util.XMLAdapter) is ambiguous; candidate constructors are: void toSAX(org.apache.excalibur.xml.sax.XMLizable,org.xml.sax.ContentHandler) void toSAX(org.apache.excalibur.source.Source,org.xml.sax.ContentHandler) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1912) [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope
[ http://issues.apache.org/jira/browse/COCOON-1912?page=comments#action_12433584 ] Lars Trieloff commented on COCOON-1912: --- You are right, the test works without logkit as well. [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope --- Key: COCOON-1912 URL: http://issues.apache.org/jira/browse/COCOON-1912 Project: Cocoon Issue Type: Bug Components: Blocks: WebDAV Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-webdav-impl-test-dependencies.patch Running mvn:test in cocoon-webdav-impl fails due to unresolved dependencies of the ContainerTestCase class in cocoon-core. This patch adds the needed dependencies in the test scope, making the test cases work again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1912) [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope
[ http://issues.apache.org/jira/browse/COCOON-1912?page=comments#action_12433628 ] Lars Trieloff commented on COCOON-1912: --- If it works, it is ok. I originally tried to fix the dependencies of cocoon-jcr-impl's tests and came up with this configuration, which failed for other reasons. When I noticed there are similar problems in cocoon-webdav-impl's tests, I added these dependencies to make it work again. [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope --- Key: COCOON-1912 URL: http://issues.apache.org/jira/browse/COCOON-1912 Project: Cocoon Issue Type: Bug Components: Blocks: WebDAV Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-webdav-impl-test-dependencies.patch Running mvn:test in cocoon-webdav-impl fails due to unresolved dependencies of the ContainerTestCase class in cocoon-core. This patch adds the needed dependencies in the test scope, making the test cases work again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1912) [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope
[PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope --- Key: COCOON-1912 URL: http://issues.apache.org/jira/browse/COCOON-1912 Project: Cocoon Issue Type: Bug Components: Blocks: WebDAV Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Running mvn:test in cocoon-webdav-impl fails due to unresolved dependencies of the ContainerTestCase class in cocoon-core. This patch adds the needed dependencies in the test scope, making the test cases work again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1912) [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope
[ http://issues.apache.org/jira/browse/COCOON-1912?page=all ] Lars Trieloff updated COCOON-1912: -- Attachment: cocoon-webdav-impl-test-dependencies.patch To be applied in cocoon/trunk [PATCH] cocoon-webdav-impl test run fails due to missing dependencies in test scope --- Key: COCOON-1912 URL: http://issues.apache.org/jira/browse/COCOON-1912 Project: Cocoon Issue Type: Bug Components: Blocks: WebDAV Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-webdav-impl-test-dependencies.patch Running mvn:test in cocoon-webdav-impl fails due to unresolved dependencies of the ContainerTestCase class in cocoon-core. This patch adds the needed dependencies in the test scope, making the test cases work again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Excalibur and Factory-Methods
Hi, we are currently writing a SourceFactory for Cocoon that should be configured via the XConf XML format. The only problem is that a dependency of this SourceFactory cannot be instantiated via a Constructor as Excalibur does by default, so I am looking for the equivalent of Spring's factory-method attribute. Lars
[jira] Created: (COCOON-1913) [PATCH] ContainerTestCase in cocoon-core should be abstract
[PATCH] ContainerTestCase in cocoon-core should be abstract --- Key: COCOON-1913 URL: http://issues.apache.org/jira/browse/COCOON-1913 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff ContainerTestCase is a TestCase class in cocoon-core that helps setting up an environment for container-dependent test cases. The class itself does not provide any test methods and could be made abstract. When running tests with Eclipse's built-in JUnit testrunner, empty test cases (even superclasses of actual test cases) are regarded as failure, while abstract super classes of test cases are ignored. Making ContainerTestCase abstract would help users of the Eclipse IDE that are writing container-dependent test cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1913) [PATCH] ContainerTestCase in cocoon-core should be abstract
[ http://issues.apache.org/jira/browse/COCOON-1913?page=all ] Lars Trieloff updated COCOON-1913: -- Attachment: cocoon-core-abstract-containertestcase.patch To apply in cocoon/trunk [PATCH] ContainerTestCase in cocoon-core should be abstract --- Key: COCOON-1913 URL: http://issues.apache.org/jira/browse/COCOON-1913 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-core-abstract-containertestcase.patch ContainerTestCase is a TestCase class in cocoon-core that helps setting up an environment for container-dependent test cases. The class itself does not provide any test methods and could be made abstract. When running tests with Eclipse's built-in JUnit testrunner, empty test cases (even superclasses of actual test cases) are regarded as failure, while abstract super classes of test cases are ignored. Making ContainerTestCase abstract would help users of the Eclipse IDE that are writing container-dependent test cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1911) [PATCH] cocoon-jcr-impl does not declare dependency to cocoon-core's test classes
[PATCH] cocoon-jcr-impl does not declare dependency to cocoon-core's test classes - Key: COCOON-1911 URL: http://issues.apache.org/jira/browse/COCOON-1911 Project: Cocoon Issue Type: Improvement Components: Blocks: JCR Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-jcr-test-dependency.patch The Cocoon JRC block impl uses in its test cases the ContainerTestCase which is part of the test classes of cocoon-core. The attached patch adds a depdendency to the test-jar of cocoon-core for the test scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1911) [PATCH] cocoon-jcr-impl does not declare dependency to cocoon-core's test classes
[ http://issues.apache.org/jira/browse/COCOON-1911?page=all ] Lars Trieloff updated COCOON-1911: -- Attachment: cocoon-jcr-test-dependency.patch To apply in cocoon/trunk [PATCH] cocoon-jcr-impl does not declare dependency to cocoon-core's test classes - Key: COCOON-1911 URL: http://issues.apache.org/jira/browse/COCOON-1911 Project: Cocoon Issue Type: Improvement Components: Blocks: JCR Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-jcr-test-dependency.patch The Cocoon JRC block impl uses in its test cases the ContainerTestCase which is part of the test classes of cocoon-core. The attached patch adds a depdendency to the test-jar of cocoon-core for the test scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1910) cocoon deployer fails when deploying cocoon-core
cocoon deployer fails when deploying cocoon-core Key: COCOON-1910 URL: http://issues.apache.org/jira/browse/COCOON-1910 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Running mvn cocoon:deploy on my application's blocks or the cocoon-webapp leads to following results: The deployer fails to deploy cocoon-core, because WEB-INF/cocoon/properties/core.properties is already deployed. [INFO] Deploying cocoon-core [INFO] [ERROR] FATAL ERROR [INFO] [INFO] File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! [INFO] [INFO] Trace org.apache.cocoon.maven.deployer.monolithic.FileAlreadyDeployedException: File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! at org.apache.cocoon.maven.deployer.monolithic.SingleFileDeployer.writeResource(SingleFileDeployer.java:99) at org.apache.cocoon.maven.deployer.monolithic.MonolithicServer22.extract(MonolithicServer22.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:57) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:180) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1910) cocoon deployer fails when deploying cocoon-core
[ http://issues.apache.org/jira/browse/COCOON-1910?page=comments#action_12432813 ] Lars Trieloff commented on COCOON-1910: --- This is correct. I've just stepped through the deployment process and the problem is that core.properties and dev/core.properties map to the same path. Are you already working on fixing the ZipExtractor or might I look into creating a patch? cocoon deployer fails when deploying cocoon-core Key: COCOON-1910 URL: http://issues.apache.org/jira/browse/COCOON-1910 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Assigned To: Leszek Gawron Running mvn cocoon:deploy on my application's blocks or the cocoon-webapp leads to following results: The deployer fails to deploy cocoon-core, because WEB-INF/cocoon/properties/core.properties is already deployed. [INFO] Deploying cocoon-core [INFO] [ERROR] FATAL ERROR [INFO] [INFO] File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! [INFO] [INFO] Trace org.apache.cocoon.maven.deployer.monolithic.FileAlreadyDeployedException: File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! at org.apache.cocoon.maven.deployer.monolithic.SingleFileDeployer.writeResource(SingleFileDeployer.java:99) at org.apache.cocoon.maven.deployer.monolithic.MonolithicServer22.extract(MonolithicServer22.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:57) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:180) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1910) cocoon deployer fails when deploying cocoon-core
[ http://issues.apache.org/jira/browse/COCOON-1910?page=comments#action_12432826 ] Lars Trieloff commented on COCOON-1910: --- Thank you. It works now. cocoon deployer fails when deploying cocoon-core Key: COCOON-1910 URL: http://issues.apache.org/jira/browse/COCOON-1910 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Assigned To: Leszek Gawron Running mvn cocoon:deploy on my application's blocks or the cocoon-webapp leads to following results: The deployer fails to deploy cocoon-core, because WEB-INF/cocoon/properties/core.properties is already deployed. [INFO] Deploying cocoon-core [INFO] [ERROR] FATAL ERROR [INFO] [INFO] File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! [INFO] [INFO] Trace org.apache.cocoon.maven.deployer.monolithic.FileAlreadyDeployedException: File '/Users/lars/Documents/coccon/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/cocoon/properties/core.properties' already exists! at org.apache.cocoon.maven.deployer.monolithic.SingleFileDeployer.writeResource(SingleFileDeployer.java:99) at org.apache.cocoon.maven.deployer.monolithic.MonolithicServer22.extract(MonolithicServer22.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:84) at org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.deploy(MonolithicCocoonDeployer.java:57) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:180) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432499 ] Lars Trieloff commented on COCOON-1898: --- Leszek, there are some weak points in the XUpdate language, for example the if-semantics are not yet defined. Putting the patches below src/main/xpath is no problem when you add this path to the list of paths that are considered by the jar plugin (or whatever does the packaging) I understand your motivation for multiple patches targeting one file. For the long command line: could not the cocoon-deployer call cocoon:xupdate before finishing the deployment? The deployer scans the required jar files for patches, extracts them to a target/xpatch directory, calls cocoon:xupdate which then uses patches in target/xpatch and /src/main/xpatch to patch the extracted files. [PATCH] XPatch support for maven-cocoon-deployer-plugin --- Key: COCOON-1898 URL: http://issues.apache.org/jira/browse/COCOON-1898 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch The cocoon-deployer-plugin has currently no support for XPatch, which makes it difficult to modify the web.xml when developing cocoon blocks. For example the cocoon-xmldb-impl block should add, when deployed, a servlet for xindice and a servlet mapping for the xindice servlet. This was possible in 2.1 using the XConfToolTask, but is no longer possible with the current state of the deployer-plugin. My patch adds support for patching the web.xml file using *.xweb files in the /conf directory of a block by filtering the block's jar file during deployment for conf/*.xweb files, caching the patch document temporarily and applying them (using code from the orgiginal XConfToolTask in 2.1) to the web.xml. The patch has currently no support for other files than conf/*.xweb files and does not support any property expansion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432367 ] Lars Trieloff commented on COCOON-1898: --- I like the idea of being able to patch any XML file in cocoon, but I would not place them in src/main/resources, but to src/main/xpatch/, just to reduce the cluttering of the src/main/resources directory. Having multiple patch files targeting one file sounds like no good idea when you can have multiple patch targets in one patch file. This should also be the place where profile conditions should be enabled (ideally through property replacement as done in the original ant tasks.) The most important argument for chosing XPatch over any other format (e.g. the more widely distributed standard XUpdate) is that it is already in use in Cocoon. [PATCH] XPatch support for maven-cocoon-deployer-plugin --- Key: COCOON-1898 URL: http://issues.apache.org/jira/browse/COCOON-1898 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch The cocoon-deployer-plugin has currently no support for XPatch, which makes it difficult to modify the web.xml when developing cocoon blocks. For example the cocoon-xmldb-impl block should add, when deployed, a servlet for xindice and a servlet mapping for the xindice servlet. This was possible in 2.1 using the XConfToolTask, but is no longer possible with the current state of the deployer-plugin. My patch adds support for patching the web.xml file using *.xweb files in the /conf directory of a block by filtering the block's jar file during deployment for conf/*.xweb files, caching the patch document temporarily and applying them (using code from the orgiginal XConfToolTask in 2.1) to the web.xml. The patch has currently no support for other files than conf/*.xweb files and does not support any property expansion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources
[PATCH] simple-xml binding does not work with non file sources -- Key: COCOON-1906 URL: http://issues.apache.org/jira/browse/COCOON-1906 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff The cocoon forms flowscript API comes with a helper method form.loadXML, that retrieves data from an xml document. The current implementation however does not work with documents that are referenced not as files, but as SitemapSources, e.g. via the cocoon:/ or xmldb:// pseudo-protocol. In this case the Rhino engine is unable to resolve the ambiguity between two method signatures: org.mozilla.javascript.EvaluatorException: resource://org/apache/cocoon/forms/flow/javascript/Form.js, line 287: The choice of Java constructor toSAX matching JavaScript argument types (org.apache.cocoon.components.source.impl.SitemapSource,org.apache.cocoon.forms.util.XMLAdapter) is ambiguous; candidate constructors are: void toSAX(org.apache.excalibur.xml.sax.XMLizable,org.xml.sax.ContentHandler) void toSAX(org.apache.excalibur.source.Source,org.xml.sax.ContentHandler) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources
[ http://issues.apache.org/jira/browse/COCOON-1906?page=all ] Lars Trieloff updated COCOON-1906: -- Attachment: cocoon-formsbinding-sample.patch This is a small test case that modifies the form2simpleXML sample in the cocoon-forms-sample block to use a cocoon:/ resource instead of an XML file. Running the example leads to the problems described above. [PATCH] simple-xml binding does not work with non file sources -- Key: COCOON-1906 URL: http://issues.apache.org/jira/browse/COCOON-1906 Project: Cocoon Issue Type: Bug Components: Blocks: Forms, * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-formsbinding-sample.patch The cocoon forms flowscript API comes with a helper method form.loadXML, that retrieves data from an xml document. The current implementation however does not work with documents that are referenced not as files, but as SitemapSources, e.g. via the cocoon:/ or xmldb:// pseudo-protocol. In this case the Rhino engine is unable to resolve the ambiguity between two method signatures: org.mozilla.javascript.EvaluatorException: resource://org/apache/cocoon/forms/flow/javascript/Form.js, line 287: The choice of Java constructor toSAX matching JavaScript argument types (org.apache.cocoon.components.source.impl.SitemapSource,org.apache.cocoon.forms.util.XMLAdapter) is ambiguous; candidate constructors are: void toSAX(org.apache.excalibur.xml.sax.XMLizable,org.xml.sax.ContentHandler) void toSAX(org.apache.excalibur.source.Source,org.xml.sax.ContentHandler) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources
[ http://issues.apache.org/jira/browse/COCOON-1906?page=all ] Lars Trieloff updated COCOON-1906: -- Attachment: cocoon-formsbinding-sourceutil.patch This patch adds another method to the SourceUtil class that helps Rhino in resolving the ambiguity between toSAX(Source,ContentHandler) and toSAX(XMLizable,ContentHandler) when dealing with a SitemapSource. The example above runs perfectly when this patch is applied. [PATCH] simple-xml binding does not work with non file sources -- Key: COCOON-1906 URL: http://issues.apache.org/jira/browse/COCOON-1906 Project: Cocoon Issue Type: Bug Components: Blocks: Forms, * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-formsbinding-sample.patch, cocoon-formsbinding-sourceutil.patch The cocoon forms flowscript API comes with a helper method form.loadXML, that retrieves data from an xml document. The current implementation however does not work with documents that are referenced not as files, but as SitemapSources, e.g. via the cocoon:/ or xmldb:// pseudo-protocol. In this case the Rhino engine is unable to resolve the ambiguity between two method signatures: org.mozilla.javascript.EvaluatorException: resource://org/apache/cocoon/forms/flow/javascript/Form.js, line 287: The choice of Java constructor toSAX matching JavaScript argument types (org.apache.cocoon.components.source.impl.SitemapSource,org.apache.cocoon.forms.util.XMLAdapter) is ambiguous; candidate constructors are: void toSAX(org.apache.excalibur.xml.sax.XMLizable,org.xml.sax.ContentHandler) void toSAX(org.apache.excalibur.source.Source,org.xml.sax.ContentHandler) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1903) [PATCH] cocoon-block-deployer does not reflect latest spring configuration changes
[ http://issues.apache.org/jira/browse/COCOON-1903?page=all ] Lars Trieloff closed COCOON-1903. - Resolution: Fixed [PATCH] cocoon-block-deployer does not reflect latest spring configuration changes -- Key: COCOON-1903 URL: http://issues.apache.org/jira/browse/COCOON-1903 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-block-deployer-spring-support.patch In revision 436902 cziegeler changed the way a cocoon web application is loaded in order to provide better spring support. This change had been applied to the cocoon-webapp example web application, but not to the mininmal web application configuration provided by the cocoon-block-deployer maven plugin resulting in breaking the mvn cocoon:deploy jetty6:run target used for developing custom blocks in trunk. (In effect class org.apache.cocoon.servlet.CocoonServletListener could not found) The attached patch updates the web.xml provided by the cocoon-block-deployer to use org.springframework.web.context.ContextLoaderListener instead of org.apache.cocoon.servlet.CocoonServletListener, adds an applicationContext.xml to the cocoon-block-deployer and makes cocoon-block-deployer deploy this applicationContext.xml additionally to web.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1904) [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions
[PATCH] pom.xml generated for cocoon-block-archetype does not regard versions - Key: COCOON-1904 URL: http://issues.apache.org/jira/browse/COCOON-1904 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-archetype-pom-version.patch The pom.xml generated by the cocoon-22-block archtepye uses a variable for the version for configuring the maven-jetty-plugin, but uses a fixed version for the project itself. This leads to problem when the version specified at the command line is not identical to 1.0.0-SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1904) [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions
[ http://issues.apache.org/jira/browse/COCOON-1904?page=all ] Lars Trieloff updated COCOON-1904: -- Attachment: cocoon-archetype-pom-version.patch This patch makes the version for the generated pom.xml variable. [PATCH] pom.xml generated for cocoon-block-archetype does not regard versions - Key: COCOON-1904 URL: http://issues.apache.org/jira/browse/COCOON-1904 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-archetype-pom-version.patch The pom.xml generated by the cocoon-22-block archtepye uses a variable for the version for configuring the maven-jetty-plugin, but uses a fixed version for the project itself. This leads to problem when the version specified at the command line is not identical to 1.0.0-SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1905) [PATCH] Support non-file resources for jaas.config in JCR block
[PATCH] Support non-file resources for jaas.config in JCR block --- Key: COCOON-1905 URL: http://issues.apache.org/jira/browse/COCOON-1905 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor The current implementation of the JCR-block requires the user to define a physical file as source for the jaas.config. While is behaviour matches the requirements of the Java JAAS implementation it is inconvenient for development and prevents the creation of a generic out-of-the-box cocoon-JCR-example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1905) [PATCH] Support non-file resources for jaas.config in JCR block
[ http://issues.apache.org/jira/browse/COCOON-1905?page=all ] Lars Trieloff updated COCOON-1905: -- Attachment: cocoon-jcr-jaas-uri-source.patch This patch allows the JAAS configuration to be stored in non physical files, e.g. in context resources, which is often the case with blocks under development that are deployed using the mvn cocoon:deploy goal. The patch adds a special case for those non-physical files: A temporary file is created, the contents of the specified resource are copied into the temporary file and this temporary file is used for configuring JAAS. This is very convenient behaviour in development environments because the block can be used out-of-the-box, but does not affect the security properties of a production system because in this case the location of the jaas.config file will be specified using Java system properties. [PATCH] Support non-file resources for jaas.config in JCR block --- Key: COCOON-1905 URL: http://issues.apache.org/jira/browse/COCOON-1905 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-jcr-jaas-uri-source.patch The current implementation of the JCR-block requires the user to define a physical file as source for the jaas.config. While is behaviour matches the requirements of the Java JAAS implementation it is inconvenient for development and prevents the creation of a generic out-of-the-box cocoon-JCR-example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1903) [PATCH] cocoon-block-deployer does not reflect latest spring configuration changes
[PATCH] cocoon-block-deployer does not reflect latest spring configuration changes -- Key: COCOON-1903 URL: http://issues.apache.org/jira/browse/COCOON-1903 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff In revision 436902 cziegeler changed the way a cocoon web application is loaded in order to provide better spring support. This change had been applied to the cocoon-webapp example web application, but not to the mininmal web application configuration provided by the cocoon-block-deployer maven plugin resulting in breaking the mvn cocoon:deploy jetty6:run target used for developing custom blocks in trunk. (In effect class org.apache.cocoon.servlet.CocoonServletListener could not found) The attached patch updates the web.xml provided by the cocoon-block-deployer to use org.springframework.web.context.ContextLoaderListener instead of org.apache.cocoon.servlet.CocoonServletListener, adds an applicationContext.xml to the cocoon-block-deployer and makes cocoon-block-deployer deploy this applicationContext.xml additionally to web.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1903) [PATCH] cocoon-block-deployer does not reflect latest spring configuration changes
[ http://issues.apache.org/jira/browse/COCOON-1903?page=all ] Lars Trieloff updated COCOON-1903: -- Attachment: cocoon-block-deployer-spring-support.patch The described patch. [PATCH] cocoon-block-deployer does not reflect latest spring configuration changes -- Key: COCOON-1903 URL: http://issues.apache.org/jira/browse/COCOON-1903 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-block-deployer-spring-support.patch In revision 436902 cziegeler changed the way a cocoon web application is loaded in order to provide better spring support. This change had been applied to the cocoon-webapp example web application, but not to the mininmal web application configuration provided by the cocoon-block-deployer maven plugin resulting in breaking the mvn cocoon:deploy jetty6:run target used for developing custom blocks in trunk. (In effect class org.apache.cocoon.servlet.CocoonServletListener could not found) The attached patch updates the web.xml provided by the cocoon-block-deployer to use org.springframework.web.context.ContextLoaderListener instead of org.apache.cocoon.servlet.CocoonServletListener, adds an applicationContext.xml to the cocoon-block-deployer and makes cocoon-block-deployer deploy this applicationContext.xml additionally to web.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
Hi. I am the author of this patch. I can confirm the patching language is the same (as I copied most of it's implementation from the actual ant task). Sorry for the remaining System.out, it is not necessary from my point of view, I added it simply for debugging purposes. regards, Lars Trieloff Am Dienstag, den 29.08.2006, 08:36 +0200 schrieb Reinhard Poetz: The patch looks good to me. If you apply the patch, please check if the patching language is the same as in 2.1 and use the Maven logger instead of printing to System.out.
Re: [2.2] jcr jar missing?
JCR-1.0 is not available in the public repository, JCR-1.0.1 is. As Jackrabbit's dependencies have not been updated yet, you still have to download it and install it manually. Am Dienstag, den 29.08.2006, 18:19 +0200 schrieb Carsten Ziegeler: When building latest jcr block, I get: Missing: -- 1) jsr170:jcr:jar:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=jsr170 -DartifactId=jcr \ -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.cocoon:cocoon-jcr-impl:jar:1.0.0-SNAPSHOT 2) org.apache.jackrabbit:jackrabbit-core:jar:1.0.1 3) jsr170:jcr:jar:1.0 -- 1 required artifact is missing. for artifact: org.apache.cocoon:cocoon-jcr-impl:jar:1.0.0-SNAPSHOT from the specified remote repositories: central (http://ibiblio.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache.snapshot (http://svn.apache.org/maven-snapshot-repository), apache-cvs (http://svn.apache.org/repository)
[jira] Created: (COCOON-1899) [PATCH] Cocoon XML:DB Implementation should not depend on Xindice
[PATCH] Cocoon XML:DB Implementation should not depend on Xindice - Key: COCOON-1899 URL: http://issues.apache.org/jira/browse/COCOON-1899 Project: Cocoon Issue Type: Improvement Components: Blocks: XML-DB Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Currently the cocoon-xmldb-impl block depends on Xindice as an XML database. This leads to a number of problems when the user decides to use a different XML database, e.g. Exist: - the configuration files injected by the build system still refer to Xindice - Xindice is deployed as a JAR file in the application, regardless of not being in use by the application - It is not easy to add a different XML database by adding a new cocoon block that contains cocoon-specific configuration files. A better configuration would be the removal of all references to Xindice in cocoon-xmldb-impl (dependencies as well as configuration files) and the creation of a new block cocoon-xmldb-xindice that depends on Xindice and brings all configuration files neccessary to use Cocoon with Xindice. Accordingly cocoon-xmldb-examples should depend on cocoon-xmldb-xindice as well. This configuration makes it easy to create a new block for other XML-databases, e.g. Exist. Switching to a new XML-database would be as easy as changing the dependency in the pom and updating all connection-uris in the sitemap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1899) [PATCH] Cocoon XML:DB Implementation should not depend on Xindice
[ http://issues.apache.org/jira/browse/COCOON-1899?page=all ] Lars Trieloff updated COCOON-1899: -- Attachment: cocoon-xindice-as-own-block-rev437218.patch The patch - removes xindice from the list of dependencies in cocoon-xmldb-impl - creates a new block cocoon-xmldb-xindice - moves xindice-specific configurations from cocoon-xmldb-impl to cocoon-xmldb-xindice - adds a dependency to cocoon-xmldb-xindice to cocoon-xmldb-sample [PATCH] Cocoon XML:DB Implementation should not depend on Xindice - Key: COCOON-1899 URL: http://issues.apache.org/jira/browse/COCOON-1899 Project: Cocoon Issue Type: Improvement Components: Blocks: XML-DB Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-xindice-as-own-block-rev437218.patch Currently the cocoon-xmldb-impl block depends on Xindice as an XML database. This leads to a number of problems when the user decides to use a different XML database, e.g. Exist: - the configuration files injected by the build system still refer to Xindice - Xindice is deployed as a JAR file in the application, regardless of not being in use by the application - It is not easy to add a different XML database by adding a new cocoon block that contains cocoon-specific configuration files. A better configuration would be the removal of all references to Xindice in cocoon-xmldb-impl (dependencies as well as configuration files) and the creation of a new block cocoon-xmldb-xindice that depends on Xindice and brings all configuration files neccessary to use Cocoon with Xindice. Accordingly cocoon-xmldb-examples should depend on cocoon-xmldb-xindice as well. This configuration makes it easy to create a new block for other XML-databases, e.g. Exist. Switching to a new XML-database would be as easy as changing the dependency in the pom and updating all connection-uris in the sitemap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[PATCH] XPatch support for maven-cocoon-deployer-plugin --- Key: COCOON-1898 URL: http://issues.apache.org/jira/browse/COCOON-1898 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch The cocoon-deployer-plugin has currently no support for XPatch, which makes it difficult to modify the web.xml when developing cocoon blocks. For example the cocoon-xmldb-impl block should add, when deployed, a servlet for xindice and a servlet mapping for the xindice servlet. This was possible in 2.1 using the XConfToolTask, but is no longer possible with the current state of the deployer-plugin. My patch adds support for patching the web.xml file using *.xweb files in the /conf directory of a block by filtering the block's jar file during deployment for conf/*.xweb files, caching the patch document temporarily and applying them (using code from the orgiginal XConfToolTask in 2.1) to the web.xml. The patch has currently no support for other files than conf/*.xweb files and does not support any property expansion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=all ] Lars Trieloff updated COCOON-1898: -- Attachment: maven-cocoon-deployer-plugin-with-xpatch-support.patch This is the patch file, created from revision 432584. [PATCH] XPatch support for maven-cocoon-deployer-plugin --- Key: COCOON-1898 URL: http://issues.apache.org/jira/browse/COCOON-1898 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch The cocoon-deployer-plugin has currently no support for XPatch, which makes it difficult to modify the web.xml when developing cocoon blocks. For example the cocoon-xmldb-impl block should add, when deployed, a servlet for xindice and a servlet mapping for the xindice servlet. This was possible in 2.1 using the XConfToolTask, but is no longer possible with the current state of the deployer-plugin. My patch adds support for patching the web.xml file using *.xweb files in the /conf directory of a block by filtering the block's jar file during deployment for conf/*.xweb files, caching the patch document temporarily and applying them (using code from the orgiginal XConfToolTask in 2.1) to the web.xml. The patch has currently no support for other files than conf/*.xweb files and does not support any property expansion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
