[jira] [Assigned] (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned COCOON-1574: --- Assignee: (was: Ralph Goers) Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: https://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2 Environment: Operating System: Windows XP Platform: PC Reporter: Ronald Blaschke Fix For: 2.1.11 I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (COCOON-1329) [PATCH] Fix for cocoon.jar bundled in ear common for portal.war and portlet.war
[ https://issues.apache.org/jira/browse/COCOON-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned COCOON-1329: --- Assignee: (was: Ralph Goers) [PATCH] Fix for cocoon.jar bundled in ear common for portal.war and portlet.war --- Key: COCOON-1329 URL: https://issues.apache.org/jira/browse/COCOON-1329 Project: Cocoon Issue Type: Bug Components: Blocks: Portal Affects Versions: 2.1.5 Environment: Operating System: All Platform: Other Reporter: Michal Durdina Attachments: ASF.LICENSE.NOT.GRANTED--RELEASE_2_1_5_1.patch_2.txt, ASF.LICENSE.NOT.GRANTED--RELEASE_2_1_6.patch_2.diff Removal of checkEnvironment() in Cocoon.process() method. Needed for cocoon portal-to-portlet communication via RequestDispatcher.include() when portal.war and portlet.war are bundled into ear. Cocoon.jar is pulled from wars'/WEB- INF/lib to top ear level - as a result common ear classloader is used for its classes. Static class fields in cocoon.jar are influenced. Critical: static field 'environmentStack'. Two use cases: A.) WORKING: portal.war and portlet.war use TWO classloaders for cocoon.jar - every war has its own cocoon.jar in WEB-INF/lib - static class fields are instantiated in each classloader - every war sees its own instance of static field B.) NOT WORKING: portal.war and portlet.war use ONE classloader for cocoon.jar - every war uses cocoon.jar from ear - static class fields are instantiated only ONCE in ear classloader - all war sees same instance of static field This patch fixes getting/setting PortalServiceInfo from/to session. When portlet constructs its url's, it calls portal service DefaultLinkService. DefaultLinkService tries to get PortalServiceInfo from session and session is retrieved from Environment object that is currently at the top of environmentStack. Case A: Calling sequence of portal processing: portal.war#Cocoon.process() - portletInfo - portal.session // cl1, cl2 stands for classloader1, classloader2 cl1.envStack.top:=portal.session portlet.war#Cocoon.process() - cl2.envStack.top:=portlet.session portal.war#DefaultLinkService.getInfo() - session := cl1.envStack.top portletInfo - session(portal.session) // portletInfo != NULL portal.war#DefaultLinkService.getInfo() - portlet.war#Cocoon.process() - portal.war#Cocoon.process() - Case B: Calling sequence of portal processing: portal.war#Cocoon.process() - portletInfo - portal.session // cl1 stands for common classloader cl1.envStack.top:=portal.session portlet.war#Cocoon.process() - cl1.envStack.top:=portlet.session portal.war#DefaultLinkService.getInfo() - session := cl1.envStack.top portletInfo - session(portlet.session) // NPE: portletInfo == NULL portal.war#DefaultLinkService.getInfo() - portlet.war#Cocoon.process() - portal.war#Cocoon.process() - -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] Commented: (COCOON-2288) Allow usage of SLF4J for traces
[ https://issues.apache.org/jira/browse/COCOON-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12853992#action_12853992 ] Ralph Goers commented on COCOON-2288: - Not that there is anything wrong with your code, but it does seem a bit strange to have a logging facade - the Avalon Logger interface - call another facade - SLF4J. However, if you want to use Logback as your implementation that is the only way that is supported. SLF4J really isn't need to allow the Avalon Logger to bridge to Log4j, or java.util.logging. Allow usage of SLF4J for traces --- Key: COCOON-2288 URL: https://issues.apache.org/jira/browse/COCOON-2288 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Attachments: SLF4JLogger.java, SLF4JLoggerManager.java Attached are two classes allowing to use SLF4J as logging facade inside Cocoon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed COCOON-1574. --- Resolution: Fixed Fix Version/s: 2.1.11 Affects version (Component): Parent values: Components: Sitemap(10152). Fix version (Component): Parent values: Components: Sitemap(10229). XPathXMLFileModule is now also available in trunk. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: https://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers Fix For: 2.1.11 I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2064) PropertySettings does not support run-mode (but documents that it does)
[ https://issues.apache.org/jira/browse/COCOON-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed COCOON-2064. --- Resolution: Fixed The javadoc has been updated. PropertySettings does not support run-mode (but documents that it does) --- Key: COCOON-2064 URL: https://issues.apache.org/jira/browse/COCOON-2064 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10, 2.1.11 Reporter: Ellis Pritchard Assignee: Ralph Goers org.apache.cocoon.util.PropertySettings documents the following: * 2) context://WEB-INF/properties/[RUNNING_MODE]/*.properties *Default values for the running mode - the order in which the files are read is not guaranteed. The running mode support doesn't seem to actually be implemented. In addition, the properties facilities of Cocoon 2.1.10+ are not documented anywhere outside of the source, so many users may be unaware of this facility (I was). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554656 ] Ralph Goers commented on COCOON-1574: - I have checked in XPathXMLFileModule which can be used as a replacement for XMLFileModule. It differs from XMLFileModule by 1. It caches a DocumentInfo instead of a DocumentHelper. DocumentInfo contains the Document, its Validity, the url, the resolver and the expression cache. The expression cache is a ReferenceMap containing soft references. 2. DocumentInfo objects are cached in an externally configurable cache. The default implementation uses ehcache. 3. The soruce url can contain variables which will be resolved each time the input module is used. The cache key used is the url after resolving variables. 4. Both the cacheable and reloadable parameters can be specified as variables which will be resolved each time the module is called. 5. The amount of code run in a synchronized block is much smaller. XPathXMLFileModule performs about the same as XMLFileModule under light load. Under heavy load it experiences much more consistent behavior than XMLFileModule. In testing XMLFileModule showed a very large standard deviation in response time with a very large maximum response compared to the minimum. XPathXMLFileModule has a much smaller standard deviation and a smaller maximum response time. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: https://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-2108) xmodule:flow-attr Does not accept document objects
[ https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reopened COCOON-2108: - This patch causes XMLFileModule and anything based on AbstractJXPathModule or JXPathMetaModule to fail as they no longer receive the value of the element. xmodule:flow-attr Does not accept document objects -- Key: COCOON-2108 URL: https://issues.apache.org/jira/browse/COCOON-2108 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Hugh Sparks Assignee: Grzegorz Kossakowski Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: Cocoon-2.2-truck-JXPathHelper.java.patch, Cocoon-BRANCH-2.1.X-JXPathHelper.java.patch, xmodulePuzzle.txt Sending document objects from flowscript back to the pipeline using xmodule:flow-attr produces unexpected results. Also, the examples from the documentation do not work as described: http://cocoon.apache.org/2.1/861.daisy.html The most common error reported is: 'The object type: class java.lang.String could not be serialized to XML This issue was discussed recently on the cocoon-users mailing list. The thread was introduced by Kazo Csaba with the subject Sending DOM from flowscript to pipeline. (July 17, 2007) He has attempted to trace this behavior in the source code and believes that a possibly-inappropriate conversion to string occurs in some cases. Jason Johnston suggested moving the issue to JIRA. I've created a demonstration of this apparent bug and some related problems in this very brief example: http://www.csparks.com/xmodulePuzzle.txt I hope someone can fix or explain the correct usage of xmodule:flow-attr. Thanks to all, -Hugh Sparks, [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2145) Input module to return absolute file location of a block
[
https://issues.apache.org/jira/browse/COCOON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545239
]
Ralph Goers commented on COCOON-2145:
-
Could you possibly also provide a unit test for this? I realize that the
servlet-service-components block doesn't have any tests yet but it should.
Input module to return absolute file location of a block
Key: COCOON-2145
URL: https://issues.apache.org/jira/browse/COCOON-2145
Project: Cocoon
Issue Type: New Feature
Components: - Servlet service framework
Reporter: Thorsten Scherler
Attachments: COCOON-2145.patch, COCOON-2145.patch
I needed an input module which returns me the full file path location of the
base dir/resource of a block.
The implementation makes use of the blockcontext: protocol.
You can use it as
{block-filepath:BLOCK/}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524447 ] Ralph Goers commented on COCOON-1765: - Daniel, all you did was repeat back what I said. It hasn't answered my concern. In Cocoon 2.1 we use the Avalon logger API. We provide a couple of implementation but anyone can write an implementation of this API to plug in their own logging framework (as I have done). As I understand the pages referenced above PAX will bind the client using a particular API with the implementation of that API in a separate bundle. So it looks to me that if Cocoon used the log4j api that it would be tied to the log4j pax bundle, which is unacceptable. If this is correct then it is a requirement that Cocoon 2.2 continue to use an abstract logging api such as the Avalon logger. Is this clear or do I misunderstand what PAX does? Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - OSGi integration Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524400 ] Ralph Goers commented on COCOON-1765: - I don't care what is used as long as it is an interface that can have any implementation (including a proprietary logging framework) plugged in. Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - OSGi integration Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524405 ] Ralph Goers commented on COCOON-1765: - I looked at the link posted by Reinhard. While the doc clealy states that it supports several different logging frameworks the examples still have the client code using a particular implementation. In other words, it looks to me like I could create my own PAX implementation but if the client has coded to log4j's api then my implementation wouldn't work. Please correct me if I misunderstand how it works, but if that is the case then it doesn't meet the requirements. Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - OSGi integration Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2064) PropertySettings does not support run-mode (but documents that it does)
[ https://issues.apache.org/jira/browse/COCOON-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495057 ] Ralph Goers commented on COCOON-2064: - I apologize. You are correct that running mode is not implemented. The error was in leaving the documentation in the class. It was borrowed from trunk and retrofitted back to 2.1 as I had a need to externalize the properties. I will remove those comments from the class. Running mode is supported in trunk. I'm leaving this open and assigning to me so that I can clean this up and document this. PropertySettings does not support run-mode (but documents that it does) --- Key: COCOON-2064 URL: https://issues.apache.org/jira/browse/COCOON-2064 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10, 2.1.11-dev (Current SVN) Reporter: Ellis Pritchard org.apache.cocoon.util.PropertySettings documents the following: * 2) context://WEB-INF/properties/[RUNNING_MODE]/*.properties *Default values for the running mode - the order in which the files are read is not guaranteed. The running mode support doesn't seem to actually be implemented. In addition, the properties facilities of Cocoon 2.1.10+ are not documented anywhere outside of the source, so many users may be unaware of this facility (I was). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2064) PropertySettings does not support run-mode (but documents that it does)
[ https://issues.apache.org/jira/browse/COCOON-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned COCOON-2064: --- Assignee: Ralph Goers PropertySettings does not support run-mode (but documents that it does) --- Key: COCOON-2064 URL: https://issues.apache.org/jira/browse/COCOON-2064 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10, 2.1.11-dev (Current SVN) Reporter: Ellis Pritchard Assigned To: Ralph Goers org.apache.cocoon.util.PropertySettings documents the following: * 2) context://WEB-INF/properties/[RUNNING_MODE]/*.properties *Default values for the running mode - the order in which the files are read is not guaranteed. The running mode support doesn't seem to actually be implemented. In addition, the properties facilities of Cocoon 2.1.10+ are not documented anywhere outside of the source, so many users may be unaware of this facility (I was). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1890) Provide a tool to update artifact versions within multiple POMs
[ http://issues.apache.org/jira/browse/COCOON-1890?page=comments#action_12428143 ] Ralph Goers commented on COCOON-1890: - Well, I do have the right. However, in this case I'll change my veto to a -0 (with caveats). I certainly understand the predicament Cocoon is in - it is holding up my organization from switching from Maven 1 to Maven 2 altogether. My caveat is that I'd simply like agreement that when this fix is done that Cocoon take advantage of it (frankly, I think that is a no-brainer so I'm not really worried). As far as the root problem goes, since my manager will let me work on the Maven issue on company time I should be able to work on it within the next couple of weeks. Provide a tool to update artifact versions within multiple POMs --- Key: COCOON-1890 URL: http://issues.apache.org/jira/browse/COCOON-1890 Project: Cocoon Issue Type: Task Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Hochsteger Attachments: update-artifact-version.zip When doing releases with Maven you have to modify many POMs to reflect the correct artifact versions. The problem is, that the whole repository should always use the consistent artifact versions. Reinhard talked to me about this problem and I tried to put togeather a quick script combined with an XSL which could do this task. Attached is a first version (docs and comments within the files) which does the job. It would be great, if somebody could give it a try and provide some feedback. -- 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-1890) Provide a tool to update artifact versions within multiple POMs
[ http://issues.apache.org/jira/browse/COCOON-1890?page=comments#action_12428152 ] Ralph Goers commented on COCOON-1890: - I guess in general I agree with you. However, if we go with the Maven fix when it is available it will have an impact on end users. We will need to make our master pom available to them to use to get all the versions Cocoon is using. But you are right that the current tool will be fairly invisible. Provide a tool to update artifact versions within multiple POMs --- Key: COCOON-1890 URL: http://issues.apache.org/jira/browse/COCOON-1890 Project: Cocoon Issue Type: Task Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Hochsteger Attachments: update-artifact-version.zip When doing releases with Maven you have to modify many POMs to reflect the correct artifact versions. The problem is, that the whole repository should always use the consistent artifact versions. Reinhard talked to me about this problem and I tried to put togeather a quick script combined with an XSL which could do this task. Attached is a first version (docs and comments within the files) which does the job. It would be great, if somebody could give it a try and provide some feedback. -- 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-1890) Provide a tool to update artifact versions within multiple POMs
[ http://issues.apache.org/jira/browse/COCOON-1890?page=comments#action_12427771 ] Ralph Goers commented on COCOON-1890: - I'd vote -1 on such a tool. The correct approach is to fix http://jira.codehaus.org/browse/MNG-1577. Provide a tool to update artifact versions within multiple POMs --- Key: COCOON-1890 URL: http://issues.apache.org/jira/browse/COCOON-1890 Project: Cocoon Issue Type: Task Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Hochsteger Attachments: update-artifact-version.zip When doing releases with Maven you have to modify many POMs to reflect the correct artifact versions. The problem is, that the whole repository should always use the consistent artifact versions. Reinhard talked to me about this problem and I tried to put togeather a quick script combined with an XSL which could do this task. Attached is a first version (docs and comments within the files) which does the job. It would be great, if somebody could give it a try and provide some feedback. -- 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-1890) Provide a tool to update artifact versions within multiple POMs
[ http://issues.apache.org/jira/browse/COCOON-1890?page=comments#action_12427779 ] Ralph Goers commented on COCOON-1890: - Jorg, What do you thing MNG-1577 is about? In Maven 1 you could create a build.properties file and put the version of every jar you wanted to use. You could share that property file across multiple projects so they would all be in synch. Maven 2 provides a similar concept in that it allows you to specify the version of a dependency in the root pom's dependencyManagement section. The problem with the implementation in Maven 2 is that, unlike Maven 1, it is not an override - so if a transitive dependency (or any dependency for that matter) specifies a version the version specified in the dependencyManagement section is not used. Fixing MNG-1577 would mean that to keep all 20 poms in synch would mean updating the dependencyManagement section in the root pom. versions in child poms would be meaningless. That is why I am -1 on the fix proposed here as it is simply a hack to get around a real problem in Maven. Please go to MNG-1577 and add your vote to that issue instead of looking for workarounds here. Unless you can convince me that this problem has problem has nothing to do with keeping dependency versions in synch across blocks, I will continue to express my -1 on this fix. Provide a tool to update artifact versions within multiple POMs --- Key: COCOON-1890 URL: http://issues.apache.org/jira/browse/COCOON-1890 Project: Cocoon Issue Type: Task Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Hochsteger Attachments: update-artifact-version.zip When doing releases with Maven you have to modify many POMs to reflect the correct artifact versions. The problem is, that the whole repository should always use the consistent artifact versions. Reinhard talked to me about this problem and I tried to put togeather a quick script combined with an XSL which could do this task. Attached is a first version (docs and comments within the files) which does the job. It would be great, if somebody could give it a try and provide some feedback. -- 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-1890) Provide a tool to update artifact versions within multiple POMs
[ http://issues.apache.org/jira/browse/COCOON-1890?page=comments#action_12427784 ] Ralph Goers commented on COCOON-1890: - I should think that would be obvious. I value a vote for MNG-1577 higher because I want a real fix to this problem. I've been looking into what it will take to fix this and might be able to get some time to do it myself. But the real issue is that the Maven developers don't seem to think this is a real problem, so the more people who complain the better. I don't like the tool because it proposes to solve the problem in exactly the wrong way - by updating every pom it can find. With the correct approach none of these poms would have a version in them at all. Now, you could go right now to all these poms and remove the versions and then create a master pom with all the correct versions in it. That would be a much better approach. But it won't work unless you disable transitive dependencies. Provide a tool to update artifact versions within multiple POMs --- Key: COCOON-1890 URL: http://issues.apache.org/jira/browse/COCOON-1890 Project: Cocoon Issue Type: Task Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Andreas Hochsteger Attachments: update-artifact-version.zip When doing releases with Maven you have to modify many POMs to reflect the correct artifact versions. The problem is, that the whole repository should always use the consistent artifact versions. Reinhard talked to me about this problem and I tried to put togeather a quick script combined with an XSL which could do this task. Attached is a first version (docs and comments within the files) which does the job. It would be great, if somebody could give it a try and provide some feedback. -- 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-398) ConcurrentModificationException in Cocoon.debug()
[ http://issues.apache.org/jira/browse/COCOON-398?page=all ] Ralph Goers updated COCOON-398: --- Bugzilla Id: (was: 12139) I checked in a workaround to this. Basically, it catches the exception and retries. If the retry fails then it just doesn't include the session attributes. ConcurrentModificationException in Cocoon.debug() - Key: COCOON-398 URL: http://issues.apache.org/jira/browse/COCOON-398 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.3, 2.1.9 Environment: Operating System: other Platform: Sun Reporter: Artur Bialecki Assignee: Cocoon Developers Team I get ConcurrentModificationException when loading a page with multiple frames and debug truned on. java.util.ConcurrentModificationExeption at java.util.HashMap$HashIterator.next(HashMap.java:731) at java.util.AbstractMap.toString(AbstractMap.java:561) at java.lang.String.valueOf(String.java:1942) at java.lang.StringBuffer.append(StringBuffer.java:365) at org.apache.cocoon.Cocoon.debug(Cocoon.java:545) at org.apache.cocoon.Cocoon.process(Cocoon.java:571) at org.apache.cocoon.CocoonServlet.service(CocoonServlet.java:1013) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) ... -- 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-1742) EncodeURLTransformer can get a StackOverflow in jakarta regexp
[ http://issues.apache.org/jira/browse/COCOON-1742?page=all ] Ralph Goers closed COCOON-1742: --- Fix Version: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed EncodeURLTransformer has been modified to use JDK 1.4 regular expressions. The modification was released in 2.1.9 but that fix was in error (the error can be circumvented by manually configuring the transformer with expressions that end with wildcards to match the end of the string). The final fix is in 2.1.10 and in trunk. The fix is only available in 2.1.10 when compiling with JDK 1.4. JDK 1.3 will still use the old version of the EncodeURLTransformer. EncodeURLTransformer can get a StackOverflow in jakarta regexp -- Key: COCOON-1742 URL: http://issues.apache.org/jira/browse/COCOON-1742 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8, 2.2-dev (Current SVN) Reporter: Ralph Goers Assignee: Ralph Goers Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) EncodeURLTransformer uses jakarta regexp and calls RE.match(). This method ends up calling matchNode() which recursively calls itself. This is slow and has the potential of causing a StackOverFlowException .Numerous issues have been opened on jakarta regexp regarding this but there are no plans to address this. I have run tests that show that regexp is much slower than the JDK regular expressions and also slower than ORO. The fix for this will be to modify the EncodeURLTransformer in 2.2-dev to use the JDK regular expressions. Since the JDK regular expressions are only available in JDK 1.4 they cannot directly be used in the 2.1 branch. Most likely Oro will be used instead. -- 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-1574) Memory Leak with XMLFileModule
[ http://issues.apache.org/jira/browse/COCOON-1574?page=comments#action_12378190 ] Ralph Goers commented on COCOON-1574: - Actually, I don't care much what is done to XMLFileModule. I've basically decided that there are so many issues that I need fixed that I can't modify it in a backwards compatible way, so I'm writing a whole new module. My plan is to use the store instead of a map (although it might be a new instance of the store - not sure yet). Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: http://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- 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-1574) Memory Leak with XMLFileModule
[ http://issues.apache.org/jira/browse/COCOON-1574?page=comments#action_12378194 ] Ralph Goers commented on COCOON-1574: - Possibly, but the caching is only one of the problems that needs to be addressed. Other issues include that document retrieval is done via a synchronized method (I'm still unclear as to why) and that the configured file needs to resolved using the PreparedVariableResolver. Basically, I plan on dumping the whole DocumentHelper object as it is tied to a fixed document, which is not at all useful for what I need. Furthermore, the code currently caches the DocumentHelper object. I plan on putting the document itself in the store, which seems much more appropriate. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: http://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- 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-398) ConcurrentModificationException in Cocoon.debug()
[ http://issues.apache.org/jira/browse/COCOON-398?page=all ] Ralph Goers updated COCOON-398: --- Bugzilla Id: (was: 12139) Version: 2.1.9 I just encountered this error in 2.1.9. Looking at the fix I don't see how it can work. There is no guarantee that whatever is modifying the session attributes is also synchronizing on the session. The only thing that can be done is to wrap this code in a try catch and just deal with the ConcurrentModificationException when it occurs. ConcurrentModificationException in Cocoon.debug() - Key: COCOON-398 URL: http://issues.apache.org/jira/browse/COCOON-398 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.3, 2.1.9 Environment: Operating System: other Platform: Sun Reporter: Artur Bialecki Assignee: Cocoon Developers Team I get ConcurrentModificationException when loading a page with multiple frames and debug truned on. java.util.ConcurrentModificationExeption at java.util.HashMap$HashIterator.next(HashMap.java:731) at java.util.AbstractMap.toString(AbstractMap.java:561) at java.lang.String.valueOf(String.java:1942) at java.lang.StringBuffer.append(StringBuffer.java:365) at org.apache.cocoon.Cocoon.debug(Cocoon.java:545) at org.apache.cocoon.Cocoon.process(Cocoon.java:571) at org.apache.cocoon.CocoonServlet.service(CocoonServlet.java:1013) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) ... -- 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] Reopened: (COCOON-398) ConcurrentModificationException in Cocoon.debug()
[ http://issues.apache.org/jira/browse/COCOON-398?page=all ] Ralph Goers reopened COCOON-398: Reopening as the fix doesn't work. ConcurrentModificationException in Cocoon.debug() - Key: COCOON-398 URL: http://issues.apache.org/jira/browse/COCOON-398 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.3, 2.1.9 Environment: Operating System: other Platform: Sun Reporter: Artur Bialecki Assignee: Cocoon Developers Team I get ConcurrentModificationException when loading a page with multiple frames and debug truned on. java.util.ConcurrentModificationExeption at java.util.HashMap$HashIterator.next(HashMap.java:731) at java.util.AbstractMap.toString(AbstractMap.java:561) at java.lang.String.valueOf(String.java:1942) at java.lang.StringBuffer.append(StringBuffer.java:365) at org.apache.cocoon.Cocoon.debug(Cocoon.java:545) at org.apache.cocoon.Cocoon.process(Cocoon.java:571) at org.apache.cocoon.CocoonServlet.service(CocoonServlet.java:1013) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) ... -- 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-398) ConcurrentModificationException in Cocoon.debug()
[ http://issues.apache.org/jira/browse/COCOON-398?page=all ] Ralph Goers updated COCOON-398: --- Bugzilla Id: (was: 12139) I don't see how that can help. The HttpSession only provides a call to get an Enumerator over all the attributes. We are forced to use that. ConcurrentModificationException in Cocoon.debug() - Key: COCOON-398 URL: http://issues.apache.org/jira/browse/COCOON-398 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.3, 2.1.9 Environment: Operating System: other Platform: Sun Reporter: Artur Bialecki Assignee: Cocoon Developers Team I get ConcurrentModificationException when loading a page with multiple frames and debug truned on. java.util.ConcurrentModificationExeption at java.util.HashMap$HashIterator.next(HashMap.java:731) at java.util.AbstractMap.toString(AbstractMap.java:561) at java.lang.String.valueOf(String.java:1942) at java.lang.StringBuffer.append(StringBuffer.java:365) at org.apache.cocoon.Cocoon.debug(Cocoon.java:545) at org.apache.cocoon.Cocoon.process(Cocoon.java:571) at org.apache.cocoon.CocoonServlet.service(CocoonServlet.java:1013) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) ... -- 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-1574) Memory Leak with XMLFileModule
[ http://issues.apache.org/jira/browse/COCOON-1574?page=comments#action_12371833 ] Ralph Goers commented on COCOON-1574: - Not yet. I hope to get to this in the next couple of days. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: http://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- 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-1742) EncodeURLTransformer can get a StackOverflow in jakarta regexp
EncodeURLTransformer can get a StackOverflow in jakarta regexp -- Key: COCOON-1742 URL: http://issues.apache.org/jira/browse/COCOON-1742 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8, 2.2-dev (Current SVN) Reporter: Ralph Goers Assigned to: Ralph Goers EncodeURLTransformer uses jakarta regexp and calls RE.match(). This method ends up calling matchNode() which recursively calls itself. This is slow and has the potential of causing a StackOverFlowException .Numerous issues have been opened on jakarta regexp regarding this but there are no plans to address this. I have run tests that show that regexp is much slower than the JDK regular expressions and also slower than ORO. The fix for this will be to modify the EncodeURLTransformer in 2.2-dev to use the JDK regular expressions. Since the JDK regular expressions are only available in JDK 1.4 they cannot directly be used in the 2.1 branch. Most likely Oro will be used instead. -- 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-1574) Memory Leak with XMLFileModule
[ http://issues.apache.org/jira/browse/COCOON-1574?page=all ] Ralph Goers updated COCOON-1574: Bugzilla Id: (was: 36162) Assign To: Ralph Goers (was: Jean-Baptiste Quenot) I'm assigning this to me as I need to make changes to it for my users. We are currently running with caching disabled because it returns the wrong content if we don't - the way caching is currently implemented you can't have an input module in the input source so you can only use fixed names. In my case they reference a pipeline that generates dynamic content - which doesn't work well since the cache key never changes. And with caching disabled it is a horrible bottleneck since it synchronizes while it is reading from disk - which happens on every request. Basically, XMLFileModule just doesn't work the way it should. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: http://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- 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] Reopened: (COCOON-1683) Allow configuration of expiry in EHDefaultStore
[ http://issues.apache.org/jira/browse/COCOON-1683?page=all ] Ralph Goers reopened COCOON-1683: - Allow configuration of expiry in EHDefaultStore --- Key: COCOON-1683 URL: http://issues.apache.org/jira/browse/COCOON-1683 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.7 Reporter: Johan Stuyts Attachments: cocoon-ehdefaultstore-configurable-expiry.patch EHDefaultStore initializes the cache to never expire entries. This means that the cache will grow indefinitely (on disk). This patch allows you to set the expiry of entries in the configuration so that stale entries will be removed. It simply adds three parameters to the component which are passed to EHCache. -- 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-1683) Allow configuration of expiry in EHDefaultStore
[ http://issues.apache.org/jira/browse/COCOON-1683?page=all ] Ralph Goers updated COCOON-1683: The patch has been applied to the 2.1 branch. Please cross check and close Allow configuration of expiry in EHDefaultStore --- Key: COCOON-1683 URL: http://issues.apache.org/jira/browse/COCOON-1683 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.7 Reporter: Johan Stuyts Attachments: cocoon-ehdefaultstore-configurable-expiry.patch EHDefaultStore initializes the cache to never expire entries. This means that the cache will grow indefinitely (on disk). This patch allows you to set the expiry of entries in the configuration so that stale entries will be removed. It simply adds three parameters to the component which are passed to EHCache. -- 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-1666) Saving of JSR-168 preferences does not appear to be working.
[ http://issues.apache.org/jira/browse/COCOON-1666?page=all ] Ralph Goers updated COCOON-1666: Assign To: Ralph Goers The test was with page labels and marshalling enabled. I missed one configuration item - uncommenting the parameter-name for the request-parameter aspect. I verified that it does indeed work. I will close this. Saving of JSR-168 preferences does not appear to be working. Key: COCOON-1666 URL: http://issues.apache.org/jira/browse/COCOON-1666 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Ralph Goers Assignee: Ralph Goers Fix For: 2.1.8-dev (Current SVN) Saving of JSR-168 preferences does not appear to be working. -- 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-1666) Saving of JSR-168 preferences does not appear to be working.
[ http://issues.apache.org/jira/browse/COCOON-1666?page=all ] Ralph Goers closed COCOON-1666: --- Resolution: Invalid Saving of JSR-168 preferences does not appear to be working. Key: COCOON-1666 URL: http://issues.apache.org/jira/browse/COCOON-1666 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Ralph Goers Assignee: Ralph Goers Fix For: 2.1.8-dev (Current SVN) Saving of JSR-168 preferences does not appear to be working. -- 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-1474) i18n transformer does not work when i18n:text tags are added via XSL
[ http://issues.apache.org/jira/browse/COCOON-1474?page=all ] Ralph Goers updated COCOON-1474: Bugzilla Id: (was: 34025) Component: * Cocoon Core (was: Blocks: (Undefined)) Description: I have reproduced this in both Cocoon 2.1.5 and 2.2.0-dev. If i18n:text tags are included in the initial file of a pipeline, the i18n transformer works great. But if they are added via an XSL transformation, the i18n transfomer no longer works. In this case, when the i18n:text tags are added via an XSL transform, the logs are recording unbalanced SAX events, and the end output is not well formed XML. I can reproduce this behavior with i18n:text and i18n:translate tags. Passing i18n attributes works fine. An example of the unbalanced SAX events are that when the i18nTransformer is processing the i18n:text elements, the SAX events look like this in the log: [startElement] uri=,local=i18n:text,raw=i18n:text [characters] MPT [endElement] uri=http://apache.org/cocoon/i18n/2.1,local=text,raw=i18n:text I'm not a SAX expert, but all the other SAX events in my log have the same thing for startElement and endElement. Further, when it outputs, it looks like this: divi18n:textMPT/div This is not well-formed XML. The i18nTransformer has removed the second i18n:text tag, but not the first, and of course it hasn't translated anything either. Here is a test case, so you can reproduce this: The pipelines: !-- this one works fine -- map:pipeline map:match pattern=simple.html map:generate src=bugtest/simple.xml label=record / map:transform type=i18n map:parameter name=locale value=en/ /map:transform map:serialize type=html/ /map:match /map:pipeline !-- This also works fine -- map:pipeline map:match pattern=simple_with_xsl.html map:generate src=bugtest/simple.xml label=record / map:transform type=xslt src=bugtest/bugtest.xsl label=basiccontent/ map:transform type=i18n map:parameter name=locale value=en/ /map:transform map:serialize type=html/ /map:match /map:pipeline !-- This one works for the titletext, but not for the i18n text in the body. The i18n:text tags were included in simple2.xml for the titletext, but they were included in bugtest2.xsl for the body text -- map:pipeline map:match pattern=simple_xsl_adds_i18n.html map:generate src=bugtest/simple2.xml label=record / map:transform type=xslt src=bugtest/bugtest2.xsl label=basiccontent/ map:transform type=i18n map:parameter name=locale value=en/ /map:transform map:serialize type=html/ /map:match /map:pipeline Files: simple.xml: ?xml version=1.0 encoding=UTF-8? html xmlns:i18n=http://apache.org/cocoon/i18n/2.1; head title i18n:texttitletext/i18n:text /title /head body div class=test i18n:textMPT/i18n:text /div /body /html simple2.xml ?xml version=1.0 encoding=UTF-8? html xmlns:i18n=http://apache.org/cocoon/i18n/2.1; head title i18n:texttitletext/i18n:text /title /head body div class=test MPT /div /body /html bugtest.xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:i18n=http://apache.org/cocoon/i18n/2.1; xmlns:dir=http://apache.org/cocoon/directory/2.0; exclude-result-prefixes=dir xsl:output method='html' indent='yes'/ !-- Match the root element -- xsl:template match=/ html xsl:copy-of select=//head/ body xsl:copy-of select=/html/body/div/ /body /html /xsl:template xsl:template match=node()|@* /xsl:template xsl:template match=/html/body/div div xsl:value-of select=./ /div /xsl:template /xsl:stylesheet bugtest2.xsl: ?xml version=1.0?xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:i18n=http://apache.org/cocoon/i18n/2.1; xmlns:dir=http://apache.org/cocoon/directory/2.0; exclude-result-prefixes=dir xsl:output method='html' indent='yes'/ !-- Match the root element -- xsl:template match=/ html xsl:copy-of select=//head/ body xsl:apply-templates select=/html/body/div/ /body /html /xsl:template xsl:template match=node()|@* /xsl:template xsl:template match=/html/body/div div i18n:text xsl:value-of select=./ /i18n:text /div /xsl:template /xsl:stylesheet Am I missing something? I can reproduce this in many places, but I've tried to boil it down to the simplest case I can. Thanks in advance for any advice! was: I have reproduced this in both Cocoon 2.1.5 and 2.2.0-dev. If i18n:text tags are included in the initial file of a pipeline, the i18n transformer works great. But if they are added via an XSL transformation, the i18n transfomer no longer works. In this case, when the i18n:text tags are added via an XSL transform, the logs are recording unbalanced SAX events, and the end output is not well formed XML. I can reproduce this behavior with i18n:text and i18n:translate tags. Passing i18n attributes works fine. An example of the unbalanced SAX events are that when the i18nTransformer is processing the i18n:text
[jira] Updated: (COCOON-1523) [PATCH] XSP expressions (attribute value/text interpolation)
[ http://issues.apache.org/jira/browse/COCOON-1523?page=all ]
Ralph Goers updated COCOON-1523:
Bugzilla Id: (was: 35228)
Component: Blocks: XSP
(was: Blocks: (Undefined))
Description:
In [1] in we discussed an XSP expression syntax for attribute value and text
expressions. This patch makes expressions available.
In XSP, you now can write:
elem attrib={#expression} which will be expanded to:
elemxsp:attribute
name=attribxsp:exprexpression/xsp:exprxsp:attribute/elem
or
elemHello #user.getFullName/elem, which will be expanded to elemHello
xsp:expruser.getFullName/xsp:expr/elem
Writing {##text} will prevent expansion and will be replaced by the text
{#text}. Inside expressions, write ## to get # and #} to get }.
This works in XSPs as well as logicsheets. The '#' was chosen out of the
discussed characters because it is IMO least likely to occur in an expression in
the used languages.
This feature is turned on by default and can be turned off by setting
attribute-value-interpolation or text-interpolation to false in
cocon.xconf:
markup-languages
xsp-language ... attribute-value-interpolation=false
text-interpolation=false
...
/xsp-language
/markup-language
It can be turned on or off on a per-XSP-/logicsheet-basis by setting attributes
attribute-value-interpolation or text-interpolation of the top level element
to true or false. Note that these attributes must belong to the
http://apache.org/xsp; namespace.
How it works:
New class XSPExpressionParser is a parser for the expressions. New class
XSPExpressionFilter is a filter that gets SAX events with embedded expressions
and generates SAX events for expanded expressions. This is used in LogicSheet to
filter read logicsheers and in XSPMarkupLanguage to filter the XSP.
Changes to existing code.
LogicSheets need to know the namespace and uri of the markup language in order
to replace expressions. Therefor AbstractMarkupLanguage needs to know this when
reading logicsheets. This meant that I had to move this configuration
information from parametrize to configure. It is unclear to me anyway, why
AbstractMarkupLanguage used both methods at the same time (which are described
as incompatible in the Avalon documentation).
The old PreProcessFilter wraps text() nodes in xsp:text elements inside some
tags (See [2]). It is unclear to me why this was done, and all XSPs I've tested
worked without this. I got no reponse on the list, so I left this feature out of
the new PreProcessFilter.
If any of the above changes need further discussion, clarification or change,
please tell me and I'll update the patch.
This patch also should be applied to 2.2. If it does not work, again please tell
me and I'll make a 2.2 patch available.
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111693513631888w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111778627925208w=2
was:
In [1] in we discussed an XSP expression syntax for attribute value and text
expressions. This patch makes expressions available.
In XSP, you now can write:
elem attrib={#expression} which will be expanded to:
elemxsp:attribute
name=attribxsp:exprexpression/xsp:exprxsp:attribute/elem
or
elemHello #user.getFullName/elem, which will be expanded to elemHello
xsp:expruser.getFullName/xsp:expr/elem
Writing {##text} will prevent expansion and will be replaced by the text
{#text}. Inside expressions, write ## to get # and #} to get }.
This works in XSPs as well as logicsheets. The '#' was chosen out of the
discussed characters because it is IMO least likely to occur in an expression in
the used languages.
This feature is turned on by default and can be turned off by setting
attribute-value-interpolation or text-interpolation to false in
cocon.xconf:
markup-languages
xsp-language ... attribute-value-interpolation=false
text-interpolation=false
...
/xsp-language
/markup-language
It can be turned on or off on a per-XSP-/logicsheet-basis by setting attributes
attribute-value-interpolation or text-interpolation of the top level element
to true or false. Note that these attributes must belong to the
http://apache.org/xsp; namespace.
How it works:
New class XSPExpressionParser is a parser for the expressions. New class
XSPExpressionFilter is a filter that gets SAX events with embedded expressions
and generates SAX events for expanded expressions. This is used in LogicSheet to
filter read logicsheers and in XSPMarkupLanguage to filter the XSP.
Changes to existing code.
LogicSheets need to know the namespace and uri of the markup language in order
to replace expressions. Therefor AbstractMarkupLanguage needs to know this when
reading logicsheets. This meant that I had to move this configuration
information from parametrize to configure. It is unclear to me anyway, why
AbstractMarkupLanguage used both methods at the same time (which are described
as incompatible in the Avalon documentation).
[jira] Updated: (COCOON-1557) [PATCH] Change access to AbstractContinuable.getContext to protected
[ http://issues.apache.org/jira/browse/COCOON-1557?page=all ] Ralph Goers updated COCOON-1557: Bugzilla Id: (was: 35672) Component: Blocks: Java Flow (was: Blocks: (Undefined)) Description: The attached patch changes the access of AbstractContinuable.getContext from private to protected so subclasses can access the context. was: The attached patch changes the access of AbstractContinuable.getContext from private to protected so subclasses can access the context. [PATCH] Change access to AbstractContinuable.getContext to protected Key: COCOON-1557 URL: http://issues.apache.org/jira/browse/COCOON-1557 Project: Cocoon Type: Bug Components: Blocks: Java Flow Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jochen Kuhnle Assignee: Cocoon Developers Team Attachments: patch-continuablecontext.txt The attached patch changes the access of AbstractContinuable.getContext from private to protected so subclasses can access the 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
[jira] Updated: (COCOON-1391) [PATCH] Popular website with XSP homepage won't come up
[ http://issues.apache.org/jira/browse/COCOON-1391?page=all ]
Ralph Goers updated COCOON-1391:
Bugzilla Id: (was: 32935)
Component: Blocks: XSP
(was: Blocks: (Undefined))
Description:
Whilst the cache of compiled XSPs is empty, each thread entering
a.o.c.components.language.generator.ProgramGeneratorImpl.load queues for the
lock on self and before compiling the XSP.
If during startup requests for an XSP arrive faster than the time it takes to
compile the XSP, the server will be on its knees recompiling the same XSP over
and over again. Therefore a popular website with an XSP homepage will have a
hard time to come up.
PATCH
=
After acquiring the lock, check again the cache:
--- ProgramGeneratorImpl.java 7 Jul 2003 14:32:15 - 1.1.1.3
+++ ProgramGeneratorImpl.java 4 Jan 2005 11:27:14 -
@@ -290,21 +290,31 @@
}
if (programInstance == null) {
-// no instance found
-if (getLogger().isDebugEnabled()) {
-getLogger().debug(Creating new serverpage for [ + id
+ ]);
-}
synchronized (this) {
-generateSourcecode(source,
- normalizedName,
- markupLanguage,
- programmingLanguage);
-
-programInstance = loadProgram(newManager,
- normalizedName,
- markupLanguage,
- programmingLanguage);
-}
+ // Attempt again to load program object from cache.
+ // This avoids that simultaneous requests recompile
+ // the same XSP over and over again.
+ try {
+ programInstance = (CompiledComponent) this.cache.select
(normalizedName);
+ if (getLogger().isDebugEnabled()) {
+ getLogger().debug(The serverpage [ + id + ] was
now in the cache);
+ }
+ } catch (ComponentException e) {
+ // no instance found
+ if (getLogger().isDebugEnabled()) {
+ getLogger().debug(Creating new serverpage for [ +
id + ]);
+ }
+ generateSourcecode(source,
+ normalizedName,
+ markupLanguage,
+ programmingLanguage);
+
+ programInstance = loadProgram(newManager,
+ normalizedName,
+ markupLanguage,
+ programmingLanguage);
+ }
+ }
} else {
// found an instance
if (this.autoReload) {
was:
Whilst the cache of compiled XSPs is empty, each thread entering
a.o.c.components.language.generator.ProgramGeneratorImpl.load queues for the
lock on self and before compiling the XSP.
If during startup requests for an XSP arrive faster than the time it takes to
compile the XSP, the server will be on its knees recompiling the same XSP over
and over again. Therefore a popular website with an XSP homepage will have a
hard time to come up.
PATCH
=
After acquiring the lock, check again the cache:
--- ProgramGeneratorImpl.java 7 Jul 2003 14:32:15 - 1.1.1.3
+++ ProgramGeneratorImpl.java 4 Jan 2005 11:27:14 -
@@ -290,21 +290,31 @@
}
if (programInstance == null) {
-// no instance found
-if (getLogger().isDebugEnabled()) {
-getLogger().debug(Creating new serverpage for [ + id
+ ]);
-}
synchronized (this) {
-generateSourcecode(source,
- normalizedName,
- markupLanguage,
- programmingLanguage);
-
-programInstance = loadProgram(newManager,
- normalizedName,
- markupLanguage,
- programmingLanguage);
-}
+ // Attempt again to load program object from cache.
+ // This avoids that simultaneous requests recompile
+ // the same XSP over and over again.
+ try {
+ programInstance = (CompiledComponent) this.cache.select
(normalizedName);
+ if
[jira] Updated: (COCOON-1286) [PATCH] XSP - JXPath logicsheet jxpath:for-each using relative contexts
[ http://issues.apache.org/jira/browse/COCOON-1286?page=all ] Ralph Goers updated COCOON-1286: Bugzilla Id: (was: 31564) Component: Blocks: XSP (was: Blocks: (Undefined)) Description: Are you using the jpath logicsheet and have been annoyed that you can't access parents or siblings elements in a for-each loop? like jpath:for-each select=myarray lijpath:value-of select=/title - jpath:value-of select=./li /jpath:for-each won't work because the logicsheet changed the context and /title is not available. There is a simple way to fix that, simply iterating over pointers instead of values. This way one can build contexts that are relative to the current one. So . and non-absolute paths will still point to the iterated element, but absolute paths point to the root and siblings etc should work, too. I wrote that patch a while ago so it is tested and works fine. --- This patch also adds a new tag to switch the lenient setting of jxpath. By default it is set to false. If set to true, xpaths that don't point to an object or a set of them will return null (Instead of that annoying exception). Saves all the checking if you can accept nulls and are sure there are no typos. jpath:set-lenient lenient=true|false If the tag contains child elements it will scope the setting for the enclosed elements, otherwise it is a global setting. You can't nest jpath:set-lenient tags. gunnar ps: the diff file does not have the correct path for the filenames as I had to use the webinterface to get the current 2.1 branch jpath.xsl. was: Are you using the jpath logicsheet and have been annoyed that you can't access parents or siblings elements in a for-each loop? like jpath:for-each select=myarray lijpath:value-of select=/title - jpath:value-of select=./li /jpath:for-each won't work because the logicsheet changed the context and /title is not available. There is a simple way to fix that, simply iterating over pointers instead of values. This way one can build contexts that are relative to the current one. So . and non-absolute paths will still point to the iterated element, but absolute paths point to the root and siblings etc should work, too. I wrote that patch a while ago so it is tested and works fine. --- This patch also adds a new tag to switch the lenient setting of jxpath. By default it is set to false. If set to true, xpaths that don't point to an object or a set of them will return null (Instead of that annoying exception). Saves all the checking if you can accept nulls and are sure there are no typos. jpath:set-lenient lenient=true|false If the tag contains child elements it will scope the setting for the enclosed elements, otherwise it is a global setting. You can't nest jpath:set-lenient tags. gunnar ps: the diff file does not have the correct path for the filenames as I had to use the webinterface to get the current 2.1 branch jpath.xsl. [PATCH] XSP - JXPath logicsheet jxpath:for-each using relative contexts - Key: COCOON-1286 URL: http://issues.apache.org/jira/browse/COCOON-1286 Project: Cocoon Type: Improvement Components: Blocks: XSP Versions: 2.1.8-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Gunnar Brand Assignee: Antonio Gallardo Priority: Minor Attachments: jpath.xsl.diff, jpath.xsl.diff Are you using the jpath logicsheet and have been annoyed that you can't access parents or siblings elements in a for-each loop? like jpath:for-each select=myarray lijpath:value-of select=/title - jpath:value-of select=./li /jpath:for-each won't work because the logicsheet changed the context and /title is not available. There is a simple way to fix that, simply iterating over pointers instead of values. This way one can build contexts that are relative to the current one. So . and non-absolute paths will still point to the iterated element, but absolute paths point to the root and siblings etc should work, too. I wrote that patch a while ago so it is tested and works fine. --- This patch also adds a new tag to switch the lenient setting of jxpath. By default it is set to false. If set to true, xpaths that don't point to an object or a set of them will return null (Instead of that annoying exception). Saves all the checking if you can accept nulls and are sure there are no typos. jpath:set-lenient lenient=true|false If the tag contains child elements it will scope the setting for the enclosed elements, otherwise it is a global setting. You can't nest jpath:set-lenient tags. gunnar ps: the diff file does not have the correct path for the filenames as I had to use the webinterface to get the current 2.1 branch jpath.xsl. -- This message is automatically generated by JIRA. - If you think it was sent
[jira] Updated: (COCOON-1280) XSP logicsheet jpath.xsl: incorrect call to JXPathContext.compile
[ http://issues.apache.org/jira/browse/COCOON-1280?page=all ] Ralph Goers updated COCOON-1280: Bugzilla Id: (was: 31493) Component: Blocks: XSP (was: Blocks: (Undefined)) Description: The xsp logix sheet jpath.xsl incorrectly calls the JXPathContext.compile method from an instance. This leads to a compilation error for the generated java source. compile should be called as a static method i.e JXPathContext.compile i.s.o. jxpathContext.compile. was: The xsp logix sheet jpath.xsl incorrectly calls the JXPathContext.compile method from an instance. This leads to a compilation error for the generated java source. compile should be called as a static method i.e JXPathContext.compile i.s.o. jxpathContext.compile. XSP logicsheet jpath.xsl: incorrect call to JXPathContext.compile - Key: COCOON-1280 URL: http://issues.apache.org/jira/browse/COCOON-1280 Project: Cocoon Type: Bug Components: Blocks: XSP Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Rob Berens Assignee: Cocoon Developers Team Attachments: patch.txt The xsp logix sheet jpath.xsl incorrectly calls the JXPathContext.compile method from an instance. This leads to a compilation error for the generated java source. compile should be called as a static method i.e JXPathContext.compile i.s.o. jxpathContext.compile. -- 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-1251) XSP compile failure when using Java 1.5 features
[ http://issues.apache.org/jira/browse/COCOON-1251?page=all ]
Ralph Goers updated COCOON-1251:
Bugzilla Id: (was: 30971)
Component: Blocks: XSP
(was: Blocks: (Undefined))
Description:
I am trying to use the new JDK1.5 foreach loop in XSP, basically:
List entries = new ArrayList();
for (Map entry: entries) {
...
}
which causes the following error with the default EclipseJavaCompiler:
// start error (lines 1003-1003) Syntax error on token :, ;
expected
for (Map entry: entries)
{
// end error
or even with the Javac compiler:
/home/tomcat/work/Default/beta.hostmaster.org/_/cocoon-
files/org/apache/cocoon/www/Dictionary_xsp.java:1003: ';' expected.
for (Map entry: entries)
{
Cocoon is running under Tomcat 5.0.28 on j2sdk-1.5.0-beta2-b51.
was:
I am trying to use the new JDK1.5 foreach loop in XSP, basically:
List entries = new ArrayList();
for (Map entry: entries) {
...
}
which causes the following error with the default EclipseJavaCompiler:
// start error (lines 1003-1003) Syntax error on token :, ;
expected
for (Map entry: entries)
{
// end error
or even with the Javac compiler:
/home/tomcat/work/Default/beta.hostmaster.org/_/cocoon-
files/org/apache/cocoon/www/Dictionary_xsp.java:1003: ';' expected.
for (Map entry: entries)
{
Cocoon is running under Tomcat 5.0.28 on j2sdk-1.5.0-beta2-b51.
XSP compile failure when using Java 1.5 features
Key: COCOON-1251
URL: http://issues.apache.org/jira/browse/COCOON-1251
Project: Cocoon
Type: Bug
Components: Blocks: XSP
Versions: 2.1.5
Environment: Operating System: Linux
Platform: PC
Reporter: Thomas Zehetbauer
Assignee: Antonio Gallardo
I am trying to use the new JDK1.5 foreach loop in XSP, basically:
List entries = new ArrayList();
for (Map entry: entries) {
...
}
which causes the following error with the default EclipseJavaCompiler:
// start error (lines 1003-1003) Syntax error on token :, ;
expected
for (Map entry: entries)
{
// end error
or even with the Javac compiler:
/home/tomcat/work/Default/beta.hostmaster.org/_/cocoon-
files/org/apache/cocoon/www/Dictionary_xsp.java:1003: ';' expected.
for (Map entry: entries)
{
Cocoon is running under Tomcat 5.0.28 on j2sdk-1.5.0-beta2-b51.
--
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-1196) [XSP] logicsheet-util.xsl failes with duplicate namespace declarations
[ http://issues.apache.org/jira/browse/COCOON-1196?page=all ] Ralph Goers updated COCOON-1196: Bugzilla Id: (was: 29864) Component: Blocks: XSP (was: Blocks: (Undefined)) Description: If an input module namespace is declared twice, e.g. xmlns:xsp-input=http://apache.org/cocoon/xsp/input/1.0; xmlns:input=http://apache.org/cocoon/xsp/input/1.0; and input:param is used for a required parameter: input:get-attribute input:param name=namefoo/input:param input:param name=modulelist/input:param /input:get-attribute a ProcessingException is thrown, because the template get-namespace-prefix in logicsheet-util.xsl is matching the first namespace declaration and does not find any parameter tags for this namespace prefix. I think it is not a good practise to rely on namespace prefixes. Wouldn't it be possible to use just the namespace URIs to resolve the parameter? was: If an input module namespace is declared twice, e.g. xmlns:xsp-input=http://apache.org/cocoon/xsp/input/1.0; xmlns:input=http://apache.org/cocoon/xsp/input/1.0; and input:param is used for a required parameter: input:get-attribute input:param name=namefoo/input:param input:param name=modulelist/input:param /input:get-attribute a ProcessingException is thrown, because the template get-namespace-prefix in logicsheet-util.xsl is matching the first namespace declaration and does not find any parameter tags for this namespace prefix. I think it is not a good practise to rely on namespace prefixes. Wouldn't it be possible to use just the namespace URIs to resolve the parameter? [XSP] logicsheet-util.xsl failes with duplicate namespace declarations -- Key: COCOON-1196 URL: http://issues.apache.org/jira/browse/COCOON-1196 Project: Cocoon Type: Bug Components: Blocks: XSP Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Andreas Hartmann Assignee: Cocoon Developers Team Priority: Minor If an input module namespace is declared twice, e.g. xmlns:xsp-input=http://apache.org/cocoon/xsp/input/1.0; xmlns:input=http://apache.org/cocoon/xsp/input/1.0; and input:param is used for a required parameter: input:get-attribute input:param name=namefoo/input:param input:param name=modulelist/input:param /input:get-attribute a ProcessingException is thrown, because the template get-namespace-prefix in logicsheet-util.xsl is matching the first namespace declaration and does not find any parameter tags for this namespace prefix. I think it is not a good practise to rely on namespace prefixes. Wouldn't it be possible to use just the namespace URIs to resolve the parameter? -- 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-1450) i18n messages don't work for required fields
[ http://issues.apache.org/jira/browse/COCOON-1450?page=all ] Ralph Goers updated COCOON-1450: Bugzilla Id: (was: 33637) Component: * Cocoon Core (was: Blocks: (Undefined)) Description: I've tried using i18n tags in the XSL for required fields to no avail. The other validation messages work when i18n tags used in form definitions but localized messages for required fields no joy under any conditions. Ideally I'd be submitting a patch with this but haven't nail exactly where the problem is. The problem is also in the samples.. You can get localised messages working when you define them with i18n tags in the form def, but a simple test using Packages.ValidationError(mykey.inmessages,true) fails. I've got as far as System.outs in I18nMessage.toSax() but haven't worked out a means of debuging a contentHandler as yet. was: I've tried using i18n tags in the XSL for required fields to no avail. The other validation messages work when i18n tags used in form definitions but localized messages for required fields no joy under any conditions. Ideally I'd be submitting a patch with this but haven't nail exactly where the problem is. The problem is also in the samples.. You can get localised messages working when you define them with i18n tags in the form def, but a simple test using Packages.ValidationError(mykey.inmessages,true) fails. I've got as far as System.outs in I18nMessage.toSax() but haven't worked out a means of debuging a contentHandler as yet. i18n messages don't work for required fields Key: COCOON-1450 URL: http://issues.apache.org/jira/browse/COCOON-1450 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: Windows XP Platform: All Reporter: Mark Assignee: Cocoon Developers Team I've tried using i18n tags in the XSL for required fields to no avail. The other validation messages work when i18n tags used in form definitions but localized messages for required fields no joy under any conditions. Ideally I'd be submitting a patch with this but haven't nail exactly where the problem is. The problem is also in the samples.. You can get localised messages working when you define them with i18n tags in the form def, but a simple test using Packages.ValidationError(mykey.inmessages,true) fails. I've got as far as System.outs in I18nMessage.toSax() but haven't worked out a means of debuging a contentHandler as yet. -- 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-1639) [patch] NekoHTMLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1639?page=all ] Ralph Goers updated COCOON-1639: Bugzilla Id: (was: 37023) Component: Blocks: HTML (was: Blocks: (Undefined)) Description: The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator and... hey, where's the NekoHTMLTransformer? So, just to complete the set, here's one I prepared earlier :-) I've also included an (empty) neko.properties configuration file, and updated the neko generator's setup bits to allow for setting parser features as well as properties. was: The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator and... hey, where's the NekoHTMLTransformer? So, just to complete the set, here's one I prepared earlier :-) I've also included an (empty) neko.properties configuration file, and updated the neko generator's setup bits to allow for setting parser features as well as properties. [patch] NekoHTMLTransformer --- Key: COCOON-1639 URL: http://issues.apache.org/jira/browse/COCOON-1639 Project: Cocoon Type: Improvement Components: Blocks: HTML Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Andrew Stevens Assignee: Cocoon Developers Team Priority: Minor Attachments: NekoHTMLTransformer.java, htmlblock.diff, neko.properties The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator and... hey, where's the NekoHTMLTransformer? So, just to complete the set, here's one I prepared earlier :-) I've also included an (empty) neko.properties configuration file, and updated the neko generator's setup bits to allow for setting parser features as well as properties. -- 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-1608) Missing Dependency in Webdav block
[ http://issues.apache.org/jira/browse/COCOON-1608?page=all ] Ralph Goers updated COCOON-1608: Bugzilla Id: (was: 36736) Component: Blocks: WebDAV (was: Blocks: (Undefined)) Description: Trace Back: [exec] java.lang.NoClassDefFoundError: org/jdom/input/DOMBuilder [exec] at org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) [exec] at org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) [exec] [exec] java.lang.NoClassDefFoundError: org/jdom/input/DOMBuilder [exec] at org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) [exec] at org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) [exec] at org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066) [exec] at org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) [exec] at org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912) [exec] at org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) [exec] at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) [exec] at org.apache.webdav.lib.WebdavResource.init(WebdavResource.java:223) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.exists(WebDAVSource.java:410) at org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066) [exec] at org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) [exec] at org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912) [exec] at org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) [exec] at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) [exec] at org.apache.webdav.lib.WebdavResource.init(WebdavResource.java:223) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.exists(WebDAVSource.java:410) Patch to gump.xml === --- gump.xml(revision 290444) +++ gump.xml(working copy) @@ -1157,6 +1157,7 @@ library name=commons-httpclient/ library name=jakarta-slide-webdavlib/ +library name=jdom/ work nested=build/cocoon-@@DATE@@/blocks/webdav/dest/ work nested=build/cocoon-@@DATE@@/blocks/webdav/test/ was: Trace Back: [exec] java.lang.NoClassDefFoundError: org/jdom/input/DOMBuilder [exec] at org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) [exec] at org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) [exec] [exec] java.lang.NoClassDefFoundError: org/jdom/input/DOMBuilder [exec] at org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) [exec] at org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) [exec] at org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066) [exec] at org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) [exec] at org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912) [exec] at org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) [exec] at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) [exec] at org.apache.webdav.lib.WebdavResource.init(WebdavResource.java:223) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.exists(WebDAVSource.java:410) at org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066) [exec] at org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) [exec] at org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912) [exec] at org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) [exec] at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) [exec] at org.apache.webdav.lib.WebdavResource.init(WebdavResource.java:223) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212) [exec] at
[jira] Updated: (COCOON-1600) [PATCH] Add method makeCollection() in XMLDBSource
[ http://issues.apache.org/jira/browse/COCOON-1600?page=all ] Ralph Goers updated COCOON-1600: Bugzilla Id: (was: 36686) Component: Blocks: XML-DB (was: Blocks: (Undefined)) Description: There is currently no way to create a collection in an XML database using the Source API. was: There is currently no way to create a collection in an XML database using the Source API. [PATCH] Add method makeCollection() in XMLDBSource -- Key: COCOON-1600 URL: http://issues.apache.org/jira/browse/COCOON-1600 Project: Cocoon Type: Bug Components: Blocks: XML-DB Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Cocoon Developers Team Attachments: 20050916-XMLDBSource There is currently no way to create a collection in an XML database using the Source API. -- 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-1584) [PATCH] Improve WebDAVSource error messages
[ http://issues.apache.org/jira/browse/COCOON-1584?page=all ] Ralph Goers updated COCOON-1584: Bugzilla Id: (was: 36371) Component: Blocks: WebDAV (was: Blocks: (Undefined)) Description: When WebDAVSource fails to connect to a WebDAV server, the error message should advertise the server address, else it is impossible to diagnose the problem. was: When WebDAVSource fails to connect to a WebDAV server, the error message should advertise the server address, else it is impossible to diagnose the problem. [PATCH] Improve WebDAVSource error messages --- Key: COCOON-1584 URL: http://issues.apache.org/jira/browse/COCOON-1584 Project: Cocoon Type: Bug Components: Blocks: WebDAV Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Jörg Heinicke Priority: Minor Attachments: WebDAVSource.patch When WebDAVSource fails to connect to a WebDAV server, the error message should advertise the server address, else it is impossible to diagnose the problem. -- 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-1578) WebServiceProxyGenerator sample block error
[ http://issues.apache.org/jira/browse/COCOON-1578?page=all ] Ralph Goers updated COCOON-1578: Bugzilla Id: (was: 36299) Component: Blocks: Proxy (was: Blocks: (Undefined)) Description: http://localhost:/samples/blocks/proxy/wsproxy/ doesn't work in 2.1.7 build. I get this error message: Impossible de résoudre le préfixe de l'espace de noms : xalan (wich means in english: unable to resolve xalan namespace I've seen that this block has bugs (14916, 21339, 21340, 21399) open in the main SVN trunk... but they don't seem to deal with this problem. I tried to remove: exclude-result-prefixes=xalan from newWizard2html.xsl (just to see...) I get an other error message: C:\...\cocoon-2.1.7\build\webapp\stylesheets\system\xmlform2html.xslt (Le fichier spécifié est introuvable) (in english: unable to find .../xmlform2html.xslt) Is it solve in the main trunk ? -- Full stacktrace of unable to resolve xalan namespace: org.apache.cocoon.ProcessingException: Unable to get transformer handler for file:/C:/developpement/apache/cocoon- 2.1.7/build/webapp/samples/blocks/proxy/stylesheets/newWizard2html.xsl: org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating Transform Handler at org.apache.cocoon.transformation.TraxTransformer.setup (TraxTransformer.java:318) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline (AbstractProcessingPipeline.java:398) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.se tupPipeline(AbstractCachingProcessingPipeline.java:620) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipelin e(AbstractProcessingPipeline.java:503) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process (AbstractProcessingPipeline.java:455) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke (SerializeNode.java:120) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke (PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:243) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke (PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:243) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
[jira] Updated: (COCOON-1574) Memory Leak with XMLFileModule
[ http://issues.apache.org/jira/browse/COCOON-1574?page=all ] Ralph Goers updated COCOON-1574: Bugzilla Id: (was: 36162) Component: * Cocoon Core (was: Blocks: (Undefined)) Description: I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron was: I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: http://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Cocoon Developers Team I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- 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-1547) [PATCH] XMLDBSource cannot find SerializerSelector
[ http://issues.apache.org/jira/browse/COCOON-1547?page=all ] Ralph Goers updated COCOON-1547: Bugzilla Id: (was: 35575) Component: Blocks: XML-DB (was: Blocks: (Undefined)) Description: In some rare circumstances, XMLDBSource.getInputStream() cannot manage to find the component SerializerSelector. The comment for getInputStream() suggests that it has been copy/pasted from SitemapSource, which has seen evolved, so the code may have to be rewritten. was: In some rare circumstances, XMLDBSource.getInputStream() cannot manage to find the component SerializerSelector. The comment for getInputStream() suggests that it has been copy/pasted from SitemapSource, which has seen evolved, so the code may have to be rewritten. [PATCH] XMLDBSource cannot find SerializerSelector -- Key: COCOON-1547 URL: http://issues.apache.org/jira/browse/COCOON-1547 Project: Cocoon Type: Bug Components: Blocks: XML-DB Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Cocoon Developers Team Attachments: patch-xmldb In some rare circumstances, XMLDBSource.getInputStream() cannot manage to find the component SerializerSelector. The comment for getInputStream() suggests that it has been copy/pasted from SitemapSource, which has seen evolved, so the code may have to be rewritten. -- 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-1549) [PATCH] Batik Rhino support incompatible with Cocoon's
[ http://issues.apache.org/jira/browse/COCOON-1549?page=all ] Ralph Goers updated COCOON-1549: Bugzilla Id: (was: 35578) Component: Blocks: Batik (was: Blocks: (Undefined)) Description: A bug has been filed at Batik, but nobody has replied yet: http://issues.apache.org/bugzilla/show_bug.cgi?id=35233 The need is to use Batik's Rhino support for adding JavaScript to SVG. The problem is that Batik's RhinoInterpreter sets a custom security domain incompatible with Rhino context from Cocoon's FlowScript which doesn't set one. The idea is to remove Batik's Rhino security controller to ensure proper interoperability between Cocoon and Batik. was: A bug has been filed at Batik, but nobody has replied yet: http://issues.apache.org/bugzilla/show_bug.cgi?id=35233 The need is to use Batik's Rhino support for adding JavaScript to SVG. The problem is that Batik's RhinoInterpreter sets a custom security domain incompatible with Rhino context from Cocoon's FlowScript which doesn't set one. The idea is to remove Batik's Rhino security controller to ensure proper interoperability between Cocoon and Batik. [PATCH] Batik Rhino support incompatible with Cocoon's -- Key: COCOON-1549 URL: http://issues.apache.org/jira/browse/COCOON-1549 Project: Cocoon Type: Bug Components: Blocks: Batik Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Cocoon Developers Team Attachments: patch-rhinointerpreter A bug has been filed at Batik, but nobody has replied yet: http://issues.apache.org/bugzilla/show_bug.cgi?id=35233 The need is to use Batik's Rhino support for adding JavaScript to SVG. The problem is that Batik's RhinoInterpreter sets a custom security domain incompatible with Rhino context from Cocoon's FlowScript which doesn't set one. The idea is to remove Batik's Rhino security controller to ensure proper interoperability between Cocoon and Batik. -- 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-1536) STX concurrency problem
[ http://issues.apache.org/jira/browse/COCOON-1536?page=all ] Ralph Goers updated COCOON-1536: Bugzilla Id: (was: 35444) Component: Blocks: STX (was: Blocks: (Undefined)) Description: Cocoon ships with an old version of Joost (20040330), and this seems to have a concurrency problem. After upgrading Joost to 20050521, the problem disappeared. was: Cocoon ships with an old version of Joost (20040330), and this seems to have a concurrency problem. After upgrading Joost to 20050521, the problem disappeared. STX concurrency problem --- Key: COCOON-1536 URL: http://issues.apache.org/jira/browse/COCOON-1536 Project: Cocoon Type: Bug Components: Blocks: STX Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Askild Aaberg Olsen Assignee: Cocoon Developers Team Cocoon ships with an old version of Joost (20040330), and this seems to have a concurrency problem. After upgrading Joost to 20050521, the problem disappeared. -- 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-1351) Batik FragmentExtractorTransformer fragment id clash
[ http://issues.apache.org/jira/browse/COCOON-1351?page=all ] Ralph Goers updated COCOON-1351: Bugzilla Id: (was: 32289) Component: * Cocoon Core (was: Blocks: (Undefined)) Description: The fragment id generated by the FragmentExtractorTransformer is not unique for each fragment extracted. The fragment id is generated by the following code: this.requestURI = ObjectModelHelper.getRequest(objectModel).getSitemapURI(); String id = Long.toHexString((hashCode()^HashUtil.hash(requestURI)) + fragmentID); where fragmentId is an integer that starts at 0 and is incremented by one for each fragment extracted in the current response. I have an application where a jpeg image is embedded in xml as base64 data. I use FragmentExtractorTransformer to extract the base64 data and replace it with a url based on the fragment id. Another pipeline handles the image request from the browser by connecting a fragmentExtractorGenerator with a base64 serializer. The problem is that the same image (usually the first one requested) is returned for all requests. The problem occurs because the request for the page containing the image displays a different image depending on the request parameters passed. As fragmentExtractorTransformer only uses the SitemapURI as the basis of the hash key, it produces the same hash key for every image. This causes different images to be stored under the same id. Its anyone's guess which image is returned by the following request for the image. The solution is that the fragment id hash should include the request parameters as well as the uri to generate unique ids. was: The fragment id generated by the FragmentExtractorTransformer is not unique for each fragment extracted. The fragment id is generated by the following code: this.requestURI = ObjectModelHelper.getRequest(objectModel).getSitemapURI(); String id = Long.toHexString((hashCode()^HashUtil.hash(requestURI)) + fragmentID); where fragmentId is an integer that starts at 0 and is incremented by one for each fragment extracted in the current response. I have an application where a jpeg image is embedded in xml as base64 data. I use FragmentExtractorTransformer to extract the base64 data and replace it with a url based on the fragment id. Another pipeline handles the image request from the browser by connecting a fragmentExtractorGenerator with a base64 serializer. The problem is that the same image (usually the first one requested) is returned for all requests. The problem occurs because the request for the page containing the image displays a different image depending on the request parameters passed. As fragmentExtractorTransformer only uses the SitemapURI as the basis of the hash key, it produces the same hash key for every image. This causes different images to be stored under the same id. Its anyone's guess which image is returned by the following request for the image. The solution is that the fragment id hash should include the request parameters as well as the uri to generate unique ids. Batik FragmentExtractorTransformer fragment id clash Key: COCOON-1351 URL: http://issues.apache.org/jira/browse/COCOON-1351 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: Windows XP Platform: PC Reporter: Dean Cording Assignee: Cocoon Developers Team The fragment id generated by the FragmentExtractorTransformer is not unique for each fragment extracted. The fragment id is generated by the following code: this.requestURI = ObjectModelHelper.getRequest(objectModel).getSitemapURI(); String id = Long.toHexString((hashCode()^HashUtil.hash(requestURI)) + fragmentID); where fragmentId is an integer that starts at 0 and is incremented by one for each fragment extracted in the current response. I have an application where a jpeg image is embedded in xml as base64 data. I use FragmentExtractorTransformer to extract the base64 data and replace it with a url based on the fragment id. Another pipeline handles the image request from the browser by connecting a fragmentExtractorGenerator with a base64 serializer. The problem is that the same image (usually the first one requested) is returned for all requests. The problem occurs because the request for the page containing the image displays a different image depending on the request parameters passed. As fragmentExtractorTransformer only uses the SitemapURI as the basis of the hash key, it produces the same hash key for every image. This causes different images to be stored under the same id. Its anyone's guess which image is returned by the following request for the image. The solution is that the fragment id hash should include the request parameters as well as the uri to
[jira] Updated: (COCOON-1339) Error-uri double instatiations in the new portal.
[ http://issues.apache.org/jira/browse/COCOON-1339?page=all ]
Ralph Goers updated COCOON-1339:
Bugzilla Id: (was: 32199)
Component: Blocks: Portal
(was: Blocks: (Undefined))
Description:
Hi!
I've found a bug in the new portal.
If a coplet has an error, the error should be handled by the pipeline defined
in the attribute tag 'error-uri', that was set in the copletdata/portal.xml
file.
Actually this happens, but the problem is that this happens twice. if the
coplet has an error, the content ('error-uri' pipeline), is instantiated two
times.
Thanks in advance.
Hugo.
was:
Hi!
I've found a bug in the new portal.
If a coplet has an error, the error should be handled by the pipeline defined
in the attribute tag 'error-uri', that was set in the copletdata/portal.xml
file.
Actually this happens, but the problem is that this happens twice. if the
coplet has an error, the content ('error-uri' pipeline), is instantiated two
times.
Thanks in advance.
Hugo.
Error-uri double instatiations in the new portal.
-
Key: COCOON-1339
URL: http://issues.apache.org/jira/browse/COCOON-1339
Project: Cocoon
Type: Bug
Components: Blocks: Portal
Versions: 2.1.5
Environment: Operating System: Linux
Platform: PC
Reporter: Hugo Marcelino
Assignee: Cocoon Developers Team
Priority: Critical
Hi!
I've found a bug in the new portal.
If a coplet has an error, the error should be handled by the pipeline defined
in the attribute tag 'error-uri', that was set in the copletdata/portal.xml
file.
Actually this happens, but the problem is that this happens twice. if the
coplet has an error, the content ('error-uri' pipeline), is instantiated two
times.
Thanks in advance.
Hugo.
--
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-1148) FragmentExtractor always returns same fragment
[ http://issues.apache.org/jira/browse/COCOON-1148?page=all ] Ralph Goers updated COCOON-1148: Bugzilla Id: (was: 28724) Component: * Cocoon Core (was: Blocks: (Undefined)) Description: From the code it is not a caching issue. Did not investigate/test further. http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=107461016305358w=4 http://marc.theaimsgroup.com/?t=10818801311r=1w=4 http://marc.theaimsgroup.com/?t=10820962381r=1w=4 was: From the code it is not a caching issue. Did not investigate/test further. http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=107461016305358w=4 http://marc.theaimsgroup.com/?t=10818801311r=1w=4 http://marc.theaimsgroup.com/?t=10820962381r=1w=4 FragmentExtractor always returns same fragment -- Key: COCOON-1148 URL: http://issues.apache.org/jira/browse/COCOON-1148 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jörg Heinicke Assignee: Jörg Heinicke From the code it is not a caching issue. Did not investigate/test further. http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=107461016305358w=4 http://marc.theaimsgroup.com/?t=10818801311r=1w=4 http://marc.theaimsgroup.com/?t=10820962381r=1w=4 -- 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-1320) [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list
[ http://issues.apache.org/jira/browse/COCOON-1320?page=all ]
Ralph Goers updated COCOON-1320:
Bugzilla Id: (was: 32011)
Component: Blocks: Databases
(was: Blocks: (Undefined))
Description:
The buildList method in AbstractDatabaseAction does not put commas between
parameter names, leading to incorrect SQL queries.
A fix is the following (diff of AbstractDatabaseAction.java):
730a731,733
if (i length - 1) {
buffer.append(, );
}
was:
The buildList method in AbstractDatabaseAction does not put commas between
parameter names, leading to incorrect SQL queries.
A fix is the following (diff of AbstractDatabaseAction.java):
730a731,733
if (i length - 1) {
buffer.append(, );
}
[PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list
--
Key: COCOON-1320
URL: http://issues.apache.org/jira/browse/COCOON-1320
Project: Cocoon
Type: Bug
Components: Blocks: Databases
Versions: 2.1.5
Environment: Operating System: Linux
Platform: PC
Reporter: wchao
Assignee: Cocoon Developers Team
Attachments: abc.tgz
The buildList method in AbstractDatabaseAction does not put commas between
parameter names, leading to incorrect SQL queries.
A fix is the following (diff of AbstractDatabaseAction.java):
730a731,733
if (i length - 1) {
buffer.append(, );
}
--
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-1316) I18NTransformer Cannot format ISO8601 dateTime format
[ http://issues.apache.org/jira/browse/COCOON-1316?page=all ] Ralph Goers updated COCOON-1316: Bugzilla Id: (was: 31889) Component: * Cocoon Core (was: Blocks: (Undefined)) Description: The i18nTransformer cannot format datesTime elements using the ISO8601 format of CCYY-MM_DDThh:mm:ss as the source (Note the 'T' is the letter T and not a field). An example date time is: 2002-04-02T12:30:00.00+10:00 A src-pattern could be used but the transformer barfs on the 'T' with java.lang.IllegalArgumentException: Illegal pattern character 'T'. ISO8601 is the date/time format specified for dateTime elements in the XML Schema definition and is the dateTime format returned by many XML databases. For more information see: http://www.w3.org/TR/xmlschema-2/#dateTime was: The i18nTransformer cannot format datesTime elements using the ISO8601 format of CCYY-MM_DDThh:mm:ss as the source (Note the 'T' is the letter T and not a field). An example date time is: 2002-04-02T12:30:00.00+10:00 A src-pattern could be used but the transformer barfs on the 'T' with java.lang.IllegalArgumentException: Illegal pattern character 'T'. ISO8601 is the date/time format specified for dateTime elements in the XML Schema definition and is the dateTime format returned by many XML databases. For more information see: http://www.w3.org/TR/xmlschema-2/#dateTime I18NTransformer Cannot format ISO8601 dateTime format - Key: COCOON-1316 URL: http://issues.apache.org/jira/browse/COCOON-1316 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: Dean Cording Assignee: Cocoon Developers Team The i18nTransformer cannot format datesTime elements using the ISO8601 format of CCYY-MM_DDThh:mm:ss as the source (Note the 'T' is the letter T and not a field). An example date time is: 2002-04-02T12:30:00.00+10:00 A src-pattern could be used but the transformer barfs on the 'T' with java.lang.IllegalArgumentException: Illegal pattern character 'T'. ISO8601 is the date/time format specified for dateTime elements in the XML Schema definition and is the dateTime format returned by many XML databases. For more information see: http://www.w3.org/TR/xmlschema-2/#dateTime -- 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-1259) [PATCH] XMLDBTransformer can use username/password to access XMLDB
[ http://issues.apache.org/jira/browse/COCOON-1259?page=all ] Ralph Goers updated COCOON-1259: Bugzilla Id: (was: 31064) Component: Blocks: XML-DB (was: Blocks: (Undefined)) Description: This patch allows a user to configure the XMLDBTransformer to use a username and password to access the underlying collection(s) for update. The new tags are sitemap parameters named username and password. was: This patch allows a user to configure the XMLDBTransformer to use a username and password to access the underlying collection(s) for update. The new tags are sitemap parameters named username and password. [PATCH] XMLDBTransformer can use username/password to access XMLDB -- Key: COCOON-1259 URL: http://issues.apache.org/jira/browse/COCOON-1259 Project: Cocoon Type: Improvement Components: Blocks: XML-DB Versions: 2.1.5 Environment: Operating System: other Platform: Other Reporter: lpb+apache Assignee: Cocoon Developers Team Priority: Minor Attachments: 20050916-XMLDBTransformer, username.txt This patch allows a user to configure the XMLDBTransformer to use a username and password to access the underlying collection(s) for update. The new tags are sitemap parameters named username and password. -- 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-1256) [PATCH] login and pseudo protocol xmldb
[ http://issues.apache.org/jira/browse/COCOON-1256?page=all ]
Ralph Goers updated COCOON-1256:
Bugzilla Id: (was: 31011)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
this patch allow to set user and password in the sitemap for the pseudo protocol
xmldb.
ex:
map:match pattern=test.xml
map:generate
src=xmldb:xdepo://{session-attr:login}:{session-attr:pwd}@/db/repository//
!-- map:parameter name=user value={session-attr:login}/
map:parameter name=password value={session-attr:pwd}/
/map:generate --
map:serialize type=xml/
/map:match
was:
this patch allow to set user and password in the sitemap for the pseudo protocol
xmldb.
ex:
map:match pattern=test.xml
map:generate
src=xmldb:xdepo://{session-attr:login}:{session-attr:pwd}@/db/repository//
!-- map:parameter name=user value={session-attr:login}/
map:parameter name=password value={session-attr:pwd}/
/map:generate --
map:serialize type=xml/
/map:match
[PATCH] login and pseudo protocol xmldb
---
Key: COCOON-1256
URL: http://issues.apache.org/jira/browse/COCOON-1256
Project: Cocoon
Type: Bug
Components: Blocks: XML-DB
Versions: 2.1.8-dev (Current SVN)
Environment: Operating System: All
Platform: All
Reporter: vincent jaulin
Assignee: Cocoon Developers Team
Attachments: XMLDBSourceFactory.java.diff
this patch allow to set user and password in the sitemap for the pseudo
protocol
xmldb.
ex:
map:match pattern=test.xml
map:generate
src=xmldb:xdepo://{session-attr:login}:{session-attr:pwd}@/db/repository//
!-- map:parameter name=user value={session-attr:login}/
map:parameter name=password value={session-attr:pwd}/
/map:generate --
map:serialize type=xml/
/map:match
--
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-1249) [Patch] XMLDBSource should accept scheme://user:[EMAIL PROTECTED]:port/path URIs
[ http://issues.apache.org/jira/browse/COCOON-1249?page=all ]
Ralph Goers updated COCOON-1249:
Bugzilla Id: (was: 30928)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
It should be possible to have the following in the sitemap:
map:generate
src=xmldb:db://{session-attr:user}:{session-attr:[EMAIL
PROTECTED]:port/db/etc.xml /
so each user can have their own authentication to the XMLDB as necessary. This
corresponds to the missing application managed security paradigm; currently
XMLDBSource only implements container managed security.
The attached patch accomplishes this goal. UserInfo in the URI overrides
container managed credential information if it exists. This seems consistent
with J2EE.
was:
It should be possible to have the following in the sitemap:
map:generate
src=xmldb:db://{session-attr:user}:{session-attr:[EMAIL
PROTECTED]:port/db/etc.xml /
so each user can have their own authentication to the XMLDB as necessary. This
corresponds to the missing application managed security paradigm; currently
XMLDBSource only implements container managed security.
The attached patch accomplishes this goal. UserInfo in the URI overrides
container managed credential information if it exists. This seems consistent
with J2EE.
[Patch] XMLDBSource should accept scheme://user:[EMAIL PROTECTED]:port/path
URIs
Key: COCOON-1249
URL: http://issues.apache.org/jira/browse/COCOON-1249
Project: Cocoon
Type: Improvement
Components: Blocks: XML-DB
Versions: 2.1.5
Environment: Operating System: other
Platform: Other
Reporter: lpb+apache
Assignee: Cocoon Developers Team
Priority: Minor
Attachments: local-login.patch
It should be possible to have the following in the sitemap:
map:generate
src=xmldb:db://{session-attr:user}:{session-attr:[EMAIL
PROTECTED]:port/db/etc.xml /
so each user can have their own authentication to the XMLDB as necessary. This
corresponds to the missing application managed security paradigm; currently
XMLDBSource only implements container managed security.
The attached patch accomplishes this goal. UserInfo in the URI overrides
container managed credential information if it exists. This seems consistent
with J2EE.
--
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-1248) [Patch] XMLDBSource cannot handle BinaryResources
[ http://issues.apache.org/jira/browse/COCOON-1248?page=all ] Ralph Goers updated COCOON-1248: Bugzilla Id: (was: 30924) Component: Blocks: XML-DB (was: Blocks: (Undefined)) Description: The method getInputStream() does not correctly handle BinaryResources stored in the XMLDB store; therefore, you cannot do map:resource src=xmldb:xxx://... / Patch will be attached. was: The method getInputStream() does not correctly handle BinaryResources stored in the XMLDB store; therefore, you cannot do map:resource src=xmldb:xxx://... / Patch will be attached. [Patch] XMLDBSource cannot handle BinaryResources - Key: COCOON-1248 URL: http://issues.apache.org/jira/browse/COCOON-1248 Project: Cocoon Type: Bug Components: Blocks: XML-DB Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: lpb+apache Assignee: Cocoon Developers Team Attachments: binary-resource.patch The method getInputStream() does not correctly handle BinaryResources stored in the XMLDB store; therefore, you cannot do map:resource src=xmldb:xxx://... / Patch will be attached. -- 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-1243) [PATCH] null pointer exception in XMLDB transformer
[ http://issues.apache.org/jira/browse/COCOON-1243?page=all ] Ralph Goers updated COCOON-1243: Bugzilla Id: (was: 30849) Component: Blocks: XML-DB (was: Blocks: (Undefined)) Description: The code assumes that DatabaseManager.getCollection raises an XMLDBException for errors, but in fact in at least some cases (non-existent collection), it returns null. The patch reworks the error checking to explicitly raise an exception for this case. was: The code assumes that DatabaseManager.getCollection raises an XMLDBException for errors, but in fact in at least some cases (non-existent collection), it returns null. The patch reworks the error checking to explicitly raise an exception for this case. [PATCH] null pointer exception in XMLDB transformer --- Key: COCOON-1243 URL: http://issues.apache.org/jira/browse/COCOON-1243 Project: Cocoon Type: Bug Components: Blocks: XML-DB Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Tim Goodwin Assignee: Cocoon Developers Team Attachments: patch The code assumes that DatabaseManager.getCollection raises an XMLDBException for errors, but in fact in at least some cases (non-existent collection), it returns null. The patch reworks the error checking to explicitly raise an exception for this case. -- 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-1165) XMLDBSource: default character encoding
[ http://issues.apache.org/jira/browse/COCOON-1165?page=all ] Ralph Goers updated COCOON-1165: Bugzilla Id: (was: 29061) Component: Blocks: XML-DB (was: Blocks: (Undefined)) Description: The org.apache.cocoon.components.source.impl.XMLDBSource.XMLDBOutputStream.close () method uses the java.io.ByteArrayOutputStream.toString() method to translate bytes into characters. IMO, it should use the java.io.ByteArrayOutputStream.toString(String encoding) method to prevent corruption of non-us data. At the same time, there should be an XMLDBSource class property that would set the encoding. If it is not set the java.io.ByteArrayOutputStream.toString() method should still be used. Please,see http://archives.real-time.com/pipermail/cocoon-users/2004-May/051561.html for more info. Good luck! was: The org.apache.cocoon.components.source.impl.XMLDBSource.XMLDBOutputStream.close () method uses the java.io.ByteArrayOutputStream.toString() method to translate bytes into characters. IMO, it should use the java.io.ByteArrayOutputStream.toString(String encoding) method to prevent corruption of non-us data. At the same time, there should be an XMLDBSource class property that would set the encoding. If it is not set the java.io.ByteArrayOutputStream.toString() method should still be used. Please,see http://archives.real-time.com/pipermail/cocoon-users/2004-May/051561.html for more info. Good luck! XMLDBSource: default character encoding --- Key: COCOON-1165 URL: http://issues.apache.org/jira/browse/COCOON-1165 Project: Cocoon Type: Bug Components: Blocks: XML-DB Versions: 2.1.4 Environment: Operating System: All Platform: PC Reporter: Timur Izhbulatov Assignee: Cocoon Developers Team Priority: Minor Attachments: XMLDBSource.java.diff, XMLDBSource.java.patch, test.txt The org.apache.cocoon.components.source.impl.XMLDBSource.XMLDBOutputStream.close () method uses the java.io.ByteArrayOutputStream.toString() method to translate bytes into characters. IMO, it should use the java.io.ByteArrayOutputStream.toString(String encoding) method to prevent corruption of non-us data. At the same time, there should be an XMLDBSource class property that would set the encoding. If it is not set the java.io.ByteArrayOutputStream.toString() method should still be used. Please,see http://archives.real-time.com/pipermail/cocoon-users/2004-May/051561.html for more info. Good luck! -- 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-1182) [PATCH] Writing an XMLDBSource through the SourceWritingTransformer does not use user and password.
[ http://issues.apache.org/jira/browse/COCOON-1182?page=all ] Ralph Goers updated COCOON-1182: Bugzilla Id: (was: 29524) Component: Blocks: XML-DB (was: Blocks: (Undefined)) Description: Hi, I was trying to write an document to an eXist database using the WritingSourceTransformer when I figure out that the user and password defined in cocoon.xconf at: component-instance class=org.apache.cocoon.components.source.impl.XMLDBSourceFactory name=xmldb driver class=org.exist.xmldb.DatabaseImpl type=exist user=user password=password/ /component-instance were not used. the XML used to store the document is like : source:write create=true source:sourcexmldb:exist://localhost:8080/exist/xmlrpc/db/test.xml/source:source source:fragment mydocpim pam pom/mydoc /source:fragment /source:write The XMLDBSourceFactory get user and password from cocoon.xconf and use them to create an XMLDBSource but two methods of this class doesn't handle credentials when accessing database : writeOutputStream() and delete(). the call to : DatabaseManager.getCollection(base); is used instead of : DatabaseManager.getCollection(base, user, password) ; was: Hi, I was trying to write an document to an eXist database using the WritingSourceTransformer when I figure out that the user and password defined in cocoon.xconf at: component-instance class=org.apache.cocoon.components.source.impl.XMLDBSourceFactory name=xmldb driver class=org.exist.xmldb.DatabaseImpl type=exist user=user password=password/ /component-instance were not used. the XML used to store the document is like : source:write create=true source:sourcexmldb:exist://localhost:8080/exist/xmlrpc/db/test.xml/source:source source:fragment mydocpim pam pom/mydoc /source:fragment /source:write The XMLDBSourceFactory get user and password from cocoon.xconf and use them to create an XMLDBSource but two methods of this class doesn't handle credentials when accessing database : writeOutputStream() and delete(). the call to : DatabaseManager.getCollection(base); is used instead of : DatabaseManager.getCollection(base, user, password) ; [PATCH] Writing an XMLDBSource through the SourceWritingTransformer does not use user and password. --- Key: COCOON-1182 URL: http://issues.apache.org/jira/browse/COCOON-1182 Project: Cocoon Type: Bug Components: Blocks: XML-DB Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Gildas Guillemot Assignee: Cocoon Developers Team Attachments: XMLDBSource.diff Hi, I was trying to write an document to an eXist database using the WritingSourceTransformer when I figure out that the user and password defined in cocoon.xconf at: component-instance class=org.apache.cocoon.components.source.impl.XMLDBSourceFactory name=xmldb driver class=org.exist.xmldb.DatabaseImpl type=exist user=user password=password/ /component-instance were not used. the XML used to store the document is like : source:write create=true source:sourcexmldb:exist://localhost:8080/exist/xmlrpc/db/test.xml/source:source source:fragment mydocpim pam pom/mydoc /source:fragment /source:write The XMLDBSourceFactory get user and password from cocoon.xconf and use them to create an XMLDBSource but two methods of this class doesn't handle credentials when accessing database : writeOutputStream() and delete(). the call to : DatabaseManager.getCollection(base); is used instead of : DatabaseManager.getCollection(base, user, password) ; -- 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-1116) Fix for WebDAVRepository*
[ http://issues.apache.org/jira/browse/COCOON-1116?page=all ] Ralph Goers updated COCOON-1116: Bugzilla Id: (was: 28189) Component: Blocks: WebDAV (was: Blocks: (Undefined)) Description: Fixes an obvious copy n paste error in createResource(String, String). Would it be ok to commit those changes direct to cvs? was: Fixes an obvious copy n paste error in createResource(String, String). Would it be ok to commit those changes direct to cvs? Fix for WebDAVRepository* - Key: COCOON-1116 URL: http://issues.apache.org/jira/browse/COCOON-1116 Project: Cocoon Type: Bug Components: Blocks: WebDAV Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Rolf Kulemann Assignee: Cocoon Developers Team Attachments: WebDAVRepositoryVersioningHelper_patch.txt, WebDAVRepository_patch.txt, WebDAVRepository_patch.txt, WebDAVUtil_patch.txt Fixes an obvious copy n paste error in createResource(String, String). Would it be ok to commit those changes direct to cvs? -- 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-1123) Patch for WebDAV block concerning locking and state.
[ http://issues.apache.org/jira/browse/COCOON-1123?page=all ] Ralph Goers updated COCOON-1123: Bugzilla Id: (was: 28311) Component: Blocks: WebDAV (was: Blocks: (Undefined)) Description: This patch integrates a new feature of apaches webdavclient from Slide2RC2. See http://marc.theaimsgroup.com/?l=slide-devm=108057214410350w=2 . Now it is possible to loack files/collections and still operate on them independant of the session. was: This patch integrates a new feature of apaches webdavclient from Slide2RC2. See http://marc.theaimsgroup.com/?l=slide-devm=108057214410350w=2 . Now it is possible to loack files/collections and still operate on them independant of the session. Patch for WebDAV block concerning locking and state. Key: COCOON-1123 URL: http://issues.apache.org/jira/browse/COCOON-1123 Project: Cocoon Type: Bug Components: Blocks: WebDAV Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Rolf Kulemann Assignee: Cocoon Developers Team Attachments: WebDAVUtil_locking.patch This patch integrates a new feature of apaches webdavclient from Slide2RC2. See http://marc.theaimsgroup.com/?l=slide-devm=108057214410350w=2 . Now it is possible to loack files/collections and still operate on them independant of the session. -- 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-806) [PATCH]: HSSF Serializer does not process gmr:PrintInformation
[ http://issues.apache.org/jira/browse/COCOON-806?page=all ] Ralph Goers updated COCOON-806: --- Bugzilla Id: (was: 23002) Component: Blocks: POI (was: Blocks: (Undefined)) Description: The gmr:PrintInformation element is where we configure all the info related to print configuration of the stylesheet generated. For example: landscape orientation, papelsize, margins, etc. Currenlty the HSSF Serializer is ignoring all the info the user send. Here is a example of the element: gmr:PrintInformation gmr:Margins gmr:top PrefUnit=cm Points=28.3/ gmr:bottom PrefUnit=cm Points=28.3/ gmr:left PrefUnit=cm Points=28.3/ gmr:right PrefUnit=cm Points=28.3/ gmr:header PrefUnit=cm Points=14.2/ gmr:footer PrefUnit=cm Points=14.2/ /gmr:Margins gmr:Scale percentage=100 type=percentage/ gmr:vcenter value=0/ gmr:hcenter value=0/ gmr:grid value=0/ gmr:even_if_only_styles value=0/ gmr:monochrome value=0/ gmr:draft value=0/ gmr:titles value=0/ gmr:repeat_top value=/ gmr:repeat_left value=/ gmr:orderr_then_d/gmr:order gmr:orientationlandscape/gmr:orientation gmr:Header Right= Middle=amp;[TAB] Left=/ gmr:Footer Right= Middle=Page amp;[PAGE] Left=/ gmr:paperA4/gmr:paper /gmr:PrintInformation was: The gmr:PrintInformation element is where we configure all the info related to print configuration of the stylesheet generated. For example: landscape orientation, papelsize, margins, etc. Currenlty the HSSF Serializer is ignoring all the info the user send. Here is a example of the element: gmr:PrintInformation gmr:Margins gmr:top PrefUnit=cm Points=28.3/ gmr:bottom PrefUnit=cm Points=28.3/ gmr:left PrefUnit=cm Points=28.3/ gmr:right PrefUnit=cm Points=28.3/ gmr:header PrefUnit=cm Points=14.2/ gmr:footer PrefUnit=cm Points=14.2/ /gmr:Margins gmr:Scale percentage=100 type=percentage/ gmr:vcenter value=0/ gmr:hcenter value=0/ gmr:grid value=0/ gmr:even_if_only_styles value=0/ gmr:monochrome value=0/ gmr:draft value=0/ gmr:titles value=0/ gmr:repeat_top value=/ gmr:repeat_left value=/ gmr:orderr_then_d/gmr:order gmr:orientationlandscape/gmr:orientation gmr:Header Right= Middle=amp;[TAB] Left=/ gmr:Footer Right= Middle=Page amp;[PAGE] Left=/ gmr:paperA4/gmr:paper /gmr:PrintInformation [PATCH]: HSSF Serializer does not process gmr:PrintInformation Key: COCOON-806 URL: http://issues.apache.org/jira/browse/COCOON-806 Project: Cocoon Type: Bug Components: Blocks: POI Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Antonio Gallardo Assignee: Cocoon Developers Team Attachments: EP_Grid.java.diff, EP_Orientation.java.diff, EP_Paper.java.diff, Sheet.java.diff The gmr:PrintInformation element is where we configure all the info related to print configuration of the stylesheet generated. For example: landscape orientation, papelsize, margins, etc. Currenlty the HSSF Serializer is ignoring all the info the user send. Here is a example of the element: gmr:PrintInformation gmr:Margins gmr:top PrefUnit=cm Points=28.3/ gmr:bottom PrefUnit=cm Points=28.3/ gmr:left PrefUnit=cm Points=28.3/ gmr:right PrefUnit=cm Points=28.3/ gmr:header PrefUnit=cm Points=14.2/ gmr:footer PrefUnit=cm Points=14.2/ /gmr:Margins gmr:Scale percentage=100 type=percentage/ gmr:vcenter value=0/ gmr:hcenter value=0/ gmr:grid value=0/ gmr:even_if_only_styles value=0/ gmr:monochrome value=0/ gmr:draft value=0/ gmr:titles value=0/ gmr:repeat_top value=/ gmr:repeat_left value=/ gmr:orderr_then_d/gmr:order gmr:orientationlandscape/gmr:orientation gmr:Header Right= Middle=amp;[TAB] Left=/ gmr:Footer Right= Middle=Page amp;[PAGE] Left=/ gmr:paperA4/gmr:paper /gmr:PrintInformation -- 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-1066) [PATCH] LDAPTransformer enhancements
[ http://issues.apache.org/jira/browse/COCOON-1066?page=all ] Ralph Goers updated COCOON-1066: Bugzilla Id: (was: 27279) Component: Blocks: Naming (was: Blocks: (Undefined)) Description: This patch addresses 2 issues through the addition of 2 elements in the LDAPTransformer (LDAPTransformer.java): dn-element: Provide element containing the DN for each entry returned in 'execute-query'. This is accomplished via 'dn-element' element that defaults to 'dn'. This element is only valid in 'execute-query'. securityprotocol: Provide a mechanism for those using JDK prior to 1.4.2 to access LDAP via SSL. This is accomplished via an optional 'securityprotocol' element that is empty (unused) by default. Please see http://java.sun.com/products/jndi/tutorial/ldap/security/ssl.html for more information on the JDK differences WRT LDAP via SSL. was: This patch addresses 2 issues through the addition of 2 elements in the LDAPTransformer (LDAPTransformer.java): dn-element: Provide element containing the DN for each entry returned in 'execute-query'. This is accomplished via 'dn-element' element that defaults to 'dn'. This element is only valid in 'execute-query'. securityprotocol: Provide a mechanism for those using JDK prior to 1.4.2 to access LDAP via SSL. This is accomplished via an optional 'securityprotocol' element that is empty (unused) by default. Please see http://java.sun.com/products/jndi/tutorial/ldap/security/ssl.html for more information on the JDK differences WRT LDAP via SSL. [PATCH] LDAPTransformer enhancements Key: COCOON-1066 URL: http://issues.apache.org/jira/browse/COCOON-1066 Project: Cocoon Type: Improvement Components: Blocks: Naming Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: David L. Day Assignee: Cocoon Developers Team Priority: Minor Attachments: LDAPTransformer.java.diff This patch addresses 2 issues through the addition of 2 elements in the LDAPTransformer (LDAPTransformer.java): dn-element: Provide element containing the DN for each entry returned in 'execute-query'. This is accomplished via 'dn-element' element that defaults to 'dn'. This element is only valid in 'execute-query'. securityprotocol: Provide a mechanism for those using JDK prior to 1.4.2 to access LDAP via SSL. This is accomplished via an optional 'securityprotocol' element that is empty (unused) by default. Please see http://java.sun.com/products/jndi/tutorial/ldap/security/ssl.html for more information on the JDK differences WRT LDAP via SSL. -- 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
