[jira] Commented: (COCOON-2306) StripNameSpacesTransformer does not strip attribute namespaces
[ https://issues.apache.org/jira/browse/COCOON-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932886#action_12932886 ] Jasha Joachimsthal commented on COCOON-2306: I already fixed this in the 2.1 branch. See COCOON-2228 StripNameSpacesTransformer does not strip attribute namespaces -- Key: COCOON-2306 URL: https://issues.apache.org/jira/browse/COCOON-2306 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Nico Verwer Attachments: StripNameSpacesTransformer.patch The StripNameSpacesTransformer strips namespaces only from elements, but not from attributes. This leads to an inconsistent SAX stream if the input has attributes with namespaces. The patch fixes this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2306) StripNameSpacesTransformer does not strip attribute namespaces
[ https://issues.apache.org/jira/browse/COCOON-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2306. -- Resolution: Duplicate Fix Version/s: 2.1.12-dev (Current SVN) Assignee: Jasha Joachimsthal StripNameSpacesTransformer does not strip attribute namespaces -- Key: COCOON-2306 URL: https://issues.apache.org/jira/browse/COCOON-2306 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Nico Verwer Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Attachments: StripNameSpacesTransformer.patch The StripNameSpacesTransformer strips namespaces only from elements, but not from attributes. This leads to an inconsistent SAX stream if the input has attributes with namespaces. The patch fixes this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901743#action_12901743 ] Jasha Joachimsthal commented on COCOON-2295: Can't make the Batik block to work for JPEG/PNG serialization so won't apply this patch. integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12892707#action_12892707 ] Jasha Joachimsthal commented on COCOON-2295: Strange, at http://cocoon.zones.apache.org/demos/21branch/samples/blocks/batik/welcome they do work. I'll have a look at it, but not immediately. integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2295: --- Comment: was deleted (was: Strange, at http://cocoon.zones.apache.org/demos/21branch/samples/blocks/batik/welcome they do work. I'll have a look at it, but not immediately.) integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2295: -- Assignee: Jasha Joachimsthal integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12892416#action_12892416 ] Jasha Joachimsthal commented on COCOON-2295: The FOP upgrade works fine for the FOP block but it breaks the SVGSerializer in the Batik block. See the JPEG and PNG examples at http://localhost:/samples/blocks/batik/welcome (local build) integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2259) Memory leak in PoolableProxyHandler
[ https://issues.apache.org/jira/browse/COCOON-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2259: -- Assignee: Jasha Joachimsthal Memory leak in PoolableProxyHandler --- Key: COCOON-2259 URL: https://issues.apache.org/jira/browse/COCOON-2259 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Alexander Daniel Assignee: Jasha Joachimsthal Attachments: patchForIssue2259.txt I reproduced the problem with following pipeline and by adding log output to PoolableProxyHandler [1] map:pipeline id=cocoonTest type=noncaching map:match pattern=cocoonProtocol map:generate src=cocoon://sub/ map:serialize type=xhtml/ /map:match map:match pattern=sub map:generate src=welcome/welcome.xml/ map:transform src=welcome/welcome.xslt/ map:serialize type=xhtml/ /map:match /map:pipeline Changing the line this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.handler.hashCode(); to this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.hashCode(); fixes the memory leak. Why? The PoolableFactoryBean [2] handler is a singleton for every pipeline component, i.e. one instance for noncaching pipeline, one instance for xalan transformer, ... Therefore the attributeName is the same for every component of the same type but Spring requires an unique value for the destruction callback handler. In the example sitemap above two noncaching pipeline instances are needed for processing the request. Both call registerDestructionCallback with the same attributeName. Because the attributeName is the same the callback is only called once and the other component remains in ThreadLocal. [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java [2] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2259) Memory leak in PoolableProxyHandler
[ https://issues.apache.org/jira/browse/COCOON-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2259. -- Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed Applied the patch. Thanks for submitting it. Memory leak in PoolableProxyHandler --- Key: COCOON-2259 URL: https://issues.apache.org/jira/browse/COCOON-2259 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Alexander Daniel Assignee: Jasha Joachimsthal Fix For: 2.2-dev (Current SVN) Attachments: patchForIssue2259.txt I reproduced the problem with following pipeline and by adding log output to PoolableProxyHandler [1] map:pipeline id=cocoonTest type=noncaching map:match pattern=cocoonProtocol map:generate src=cocoon://sub/ map:serialize type=xhtml/ /map:match map:match pattern=sub map:generate src=welcome/welcome.xml/ map:transform src=welcome/welcome.xslt/ map:serialize type=xhtml/ /map:match /map:pipeline Changing the line this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.handler.hashCode(); to this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.hashCode(); fixes the memory leak. Why? The PoolableFactoryBean [2] handler is a singleton for every pipeline component, i.e. one instance for noncaching pipeline, one instance for xalan transformer, ... Therefore the attributeName is the same for every component of the same type but Spring requires an unique value for the destruction callback handler. In the example sitemap above two noncaching pipeline instances are needed for processing the request. Both call registerDestructionCallback with the same attributeName. Because the attributeName is the same the callback is only called once and the other component remains in ThreadLocal. [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java [2] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2289. -- Fix version (Component): Parent values: Blocks: FOP(10237). Affects version (Component): Parent values: Blocks: FOP(10166). Resolution: Fixed [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-2104) [PATCH] Add base URI fixup support to XIncludeTransformer
[ https://issues.apache.org/jira/browse/COCOON-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2104: -- Assignee: Jasha Joachimsthal (was: Jörg Heinicke) [PATCH] Add base URI fixup support to XIncludeTransformer - Key: COCOON-2104 URL: https://issues.apache.org/jira/browse/COCOON-2104 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11, 2.2 Reporter: Andrew Cave Assignee: Jasha Joachimsthal Priority: Minor Attachments: baseFixup-2.1-r561455.diff, baseFixup-2.2-r561499.diff As discussed at [1], the XIncludeTransformer fails to perform the base URI fixup specified in the W3C's XInclude spec [2]. The spec says that the base URIs of elements do not change when passed through a conformant XInclude processor. Meaning, xml:base attributes must be added to the result set. The reason being that relative URIs in the included document should not break; this provides a mechanism to resolve them properly. This patch results in the XIncludeTransformer adding xml:base attributes to top-level included elements. It does this only when the the base URI of the included element differs from the base URI of the parent element (meaning: for almost every case except where the included document is the current document). The XIncludeTransformer's JUnit test is also updated by this patch to reflect the fact that the resulting XML file (xinclude-result-1.xml) has an xml:base attribute added. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg52803.html [2] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the W3C's XInclude specification -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-2104) [PATCH] Add base URI fixup support to XIncludeTransformer
[ https://issues.apache.org/jira/browse/COCOON-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2104. -- Fix version (Component): Parent values: Components: Pipeline(10228). Affects version (Component): Parent values: Components: Pipeline(10157). Fix Version/s: 2.1.12-dev (Current SVN) 2.2-dev (Current SVN) Resolution: Fixed Thanks Andrew for the patches [PATCH] Add base URI fixup support to XIncludeTransformer - Key: COCOON-2104 URL: https://issues.apache.org/jira/browse/COCOON-2104 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11, 2.2 Reporter: Andrew Cave Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: baseFixup-2.1-r561455.diff, baseFixup-2.2-r561499.diff As discussed at [1], the XIncludeTransformer fails to perform the base URI fixup specified in the W3C's XInclude spec [2]. The spec says that the base URIs of elements do not change when passed through a conformant XInclude processor. Meaning, xml:base attributes must be added to the result set. The reason being that relative URIs in the included document should not break; this provides a mechanism to resolve them properly. This patch results in the XIncludeTransformer adding xml:base attributes to top-level included elements. It does this only when the the base URI of the included element differs from the base URI of the parent element (meaning: for almost every case except where the included document is the current document). The XIncludeTransformer's JUnit test is also updated by this patch to reflect the fact that the resulting XML file (xinclude-result-1.xml) has an xml:base attribute added. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg52803.html [2] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the W3C's XInclude specification -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2289: --- Status: On Hold (was: Open) I backported o.a.c.blocks.fop.FOPNGSerlializer from C2.2 to o.a.c.serialization.FOPSerializer in C2.1. Upgraded to FOP 0.95 and added xmlcommons-graphics. In the samples it only involved moving 1 line in the xsl-fo. If this is ok, I'll close the issue. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-2041) WebDAV Returns improper status on PUT
[
https://issues.apache.org/jira/browse/COCOON-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jasha Joachimsthal closed COCOON-2041.
--
Fix Version/s: 2.1.12-dev (Current SVN)
2.2-dev (Current SVN)
Resolution: Fixed
SourceRepositoryImpl now returns a 204 instead of 200 after a PUT on an
existing resource. Thanks for spotting the bug.
WebDAV Returns improper status on PUT
-
Key: COCOON-2041
URL: https://issues.apache.org/jira/browse/COCOON-2041
Project: Cocoon
Issue Type: Bug
Components: Blocks: WebDAV
Affects Versions: 2.1.11
Reporter: Edward Riede
Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN)
on PUT, server returns the status 200 OK, when the proper response seems to
204 No Content
int the put method in webdav.js::: this:
try {
var status = repository.save(src,dest);
sendStatus(status);
}
can be changed to this:
try {
var status = repository.save(src,dest);
if(status == 200 ) status = 204;
sendStatus(status);
}
This fixed the issue in my application. However this seems a little hackish
and I haven't tested it well.
The org.apache.cocoon.components.repository.SourceRepository object might be
changed instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-2041) WebDAV Returns improper status on PUT
[
https://issues.apache.org/jira/browse/COCOON-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jasha Joachimsthal reassigned COCOON-2041:
--
Assignee: Jasha Joachimsthal
WebDAV Returns improper status on PUT
-
Key: COCOON-2041
URL: https://issues.apache.org/jira/browse/COCOON-2041
Project: Cocoon
Issue Type: Bug
Components: Blocks: WebDAV
Affects Versions: 2.1.11
Reporter: Edward Riede
Assignee: Jasha Joachimsthal
Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN)
on PUT, server returns the status 200 OK, when the proper response seems to
204 No Content
int the put method in webdav.js::: this:
try {
var status = repository.save(src,dest);
sendStatus(status);
}
can be changed to this:
try {
var status = repository.save(src,dest);
if(status == 200 ) status = 204;
sendStatus(status);
}
This fixed the issue in my application. However this seems a little hackish
and I haven't tested it well.
The org.apache.cocoon.components.repository.SourceRepository object might be
changed instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2289: -- Assignee: Jasha Joachimsthal [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng 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-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855293#action_12855293 ] Jasha Joachimsthal commented on COCOON-2289: I'll try to move to fop 0.95 this weekend. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng 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-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854420#action_12854420 ] Jasha Joachimsthal commented on COCOON-2289: The 2.1 branch is more or less in maintenance mode. If you start a new project, use Cocoon 2.2 which does contain the new FOP block. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng 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-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854460#action_12854460 ] Jasha Joachimsthal commented on COCOON-2289: I know there are still a lot of 2.1 projects, I've been working on one the whole day. :-) IMHO, no new Cocoon 2.1 project would be happy with FOP 0.20 made me think he was starting a new Cocoon project. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng 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-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854533#action_12854533 ] Jasha Joachimsthal commented on COCOON-2289: Please do, I'm not the only one with an opinion. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng 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-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854571#action_12854571 ] Jasha Joachimsthal commented on COCOON-2289: BTW, I'm happy to see you put effort in improving Cocoon [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng 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-2288) Allow usage of SLF4J for traces
[ https://issues.apache.org/jira/browse/COCOON-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12853882#action_12853882 ] Jasha Joachimsthal commented on COCOON-2288: Cédric, which version of slf4j-api.jar did you use? 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] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854067#action_12854067 ] Jasha Joachimsthal commented on COCOON-2289: It goes a bit further than just copying the FOPNGSerializer.java. Especially the conflicting fop dependency. In 2.2 this is easier because of the modular maven setup. The bluid process of 2.1 is more complex. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng 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-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854117#action_12854117 ] Jasha Joachimsthal commented on COCOON-2289: I tried adding them both but that resulted in compilation errors. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2278) Make SOAPHelper use https, not just http
[ https://issues.apache.org/jira/browse/COCOON-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2278: -- Assignee: Jasha Joachimsthal Make SOAPHelper use https, not just http Key: COCOON-2278 URL: https://issues.apache.org/jira/browse/COCOON-2278 Project: Cocoon Issue Type: Improvement Components: Blocks: XSP Affects Versions: 2.1.11 Reporter: Nico Verwer Assignee: Jasha Joachimsthal Attachments: SOAPHelper.patch The current SOAPHelper class in the XSP block only speaks http to webservices. With a small addition, it respects the protocol specified by, e.g., a WSDL file. Many webservices use https, which works with this patch for the SOAPHelper. Other protocols work if there is a protocol factory configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2278) Make SOAPHelper use https, not just http
[ https://issues.apache.org/jira/browse/COCOON-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2278. -- Resolution: Fixed Fix Version/s: 2.1.12-dev (Current SVN) Thanks Nico for the patch. Note: in HttpClient 3 HttpConnection(proxyHost, proxyPort, host, virtualHost, port, protocol); will be deprecated, use HttpConnection(proxyHost, proxyPort, host, port, protocol); (which is unavailable in HttpClient 2). Make SOAPHelper use https, not just http Key: COCOON-2278 URL: https://issues.apache.org/jira/browse/COCOON-2278 Project: Cocoon Issue Type: Improvement Components: Blocks: XSP Affects Versions: 2.1.11 Reporter: Nico Verwer Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Attachments: SOAPHelper.patch The current SOAPHelper class in the XSP block only speaks http to webservices. With a small addition, it respects the protocol specified by, e.g., a WSDL file. Many webservices use https, which works with this patch for the SOAPHelper. Other protocols work if there is a protocol factory configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2250) Wrong error message in Element.java (jx:element)
[ https://issues.apache.org/jira/browse/COCOON-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2250. -- Resolution: Fixed Affects version (Component): Parent values: Blocks: Template(10171). Fix version (Component): Parent values: Blocks: Template(10243). Thanks for spotting the incorrect message. I've committed the fix. Wrong error message in Element.java (jx:element) Key: COCOON-2250 URL: https://issues.apache.org/jira/browse/COCOON-2250 Project: Cocoon Issue Type: Bug Components: Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Benjamin Boksa Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: Element.java.patch the error-message says prefix 'namespace' instead of prefix 'uri', a patch that fixes that is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2270) Cocoon fails to find files when deployed into a directory containing a '#' character
[
https://issues.apache.org/jira/browse/COCOON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773532#action_12773532
]
Jasha Joachimsthal commented on COCOON-2270:
Characters like # and ? are special. The sourceresolver tries to create a uri
of your path and therefore stops at the # character.
Cocoon fails to find files when deployed into a directory containing a '#'
character
Key: COCOON-2270
URL: https://issues.apache.org/jira/browse/COCOON-2270
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.1.11
Reporter: Christopher Schultz
I have been using Cocoon 2.1.10 and 2.1.11 for quite some time with a handful
of modest pipelines using XSLTs on the local disk.
Recently, I've been building a development server to be shared among several
developers on our team. In order to share HTTP ports and URL spaces, we've
chosen to use URL spaces like /[username]/[appname] rather than simply
/[appname] as we've used in the past.
We use Apache Tomcat 5.5 as our app server, and the proper way to deploy a
web application with a / in its context name is to use either a WAR file such
as [username]#[appname].war, or a directory with the same name (minus the
.war, of course).
When we do this, we find that Cocoon gets tripped-up, apparently confused by
the # symbol in the path name. It can't find our templates on the disk
(maybe?) and it's also failing to find its own exception2html.xslt file.
Cocoon has been deployed into this directory:
/home/cschultz/projects/cocoon/app/webapps/cschultz#chadis
Our top-level sitemap has the default exception handler configuration:
map:handle-errors
map:select type=exception
map:when test=not-found
map:generate type=exception/
map:transform src=stylesheets/system/exception2html.xslt
map:parameter name=contextPath value={request:contextPath}/
map:parameter name=realPath value={realpath:}/
map:parameter name=pageTitle value=Resource not found/
/map:transform
map:serialize status-code=404/
/map:when
map:when test=invalid-continuation
map:generate type=exception/
map:transform src=stylesheets/system/exception2html.xslt
map:parameter name=contextPath value={request:contextPath}/
map:parameter name=realPath value={realpath:}/
map:parameter name=pageTitle value=Invalid Continuation/
/map:transform
map:serialize status-code=404/
/map:when
map:otherwise
map:generate type=exception/
map:transform src=stylesheets/system/exception2html.xslt
map:parameter name=contextPath value={request:contextPath}/
map:parameter name=realPath value={realpath:}/
/map:transform
map:serialize status-code=500/
/map:otherwise
/map:select
/map:handle-errors
When we try to execute our transformers, we get the following error:
Message:
/home/cschultz/.webapps/cocoon/8225/webapps/stylesheets/system/exception2html.xslt
(No such file or directory)
If you notice, this path is not correct. It should be:
/home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt
Note that the path element after webapps has been removed.
I have tried changing the path to the exception stylesheet in the top-level
sitemap to:
map:transform
src=/home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt
But this results in the following error:
Message: /home/cschultz/.webapps/cocoon/8225/webapps/cschultz (No such file
or directory)
Note the path is truncated at the '#' symbol.
Finally, I tried changing the path to:
map:transform
src=/home/cschultz/.webapps/cocoon/8225/webapps/cschultz%23chadis/stylesheets/system/exception2html.xslt
Message: Did not find the stylesheet root!
Description: org.apache.cocoon.ProcessingException: Unable to get transformer
handler for
file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt
at map:serialize -
file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45
at map:transform -
file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133
at map:generate type=exception -
file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43
full exception chain stacktrace
org.apache.cocoon.ProcessingException: Unable to get transformer handler for
[jira] Reopened: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reopened COCOON-2228: Patch only worked with 1 attribute. StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2228. -- Resolution: Fixed StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON-2257) Missing modCount attribute in JCR sample content
[ https://issues.apache.org/jira/browse/COCOON-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705424#action_12705424 ] Jasha Joachimsthal edited comment on COCOON-2257 at 5/3/09 8:14 AM: Added modCount to sample content. Sample is still not working 100% but at least Cocoon is able to run. was (Author: jashajoachimsthal): Added modCount to sample content. Sample is still not working 100% Missing modCount attribute in JCR sample content Key: COCOON-2257 URL: https://issues.apache.org/jira/browse/COCOON-2257 Project: Cocoon Issue Type: Bug Components: Blocks: JCR Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) The JCR sample content was probably written before the JCR-1.0 spec was released. In the final release a modCount attribute was expected in org.apache.jackrabbit.core.state.xml.XMLPersistenceManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2257) Missing modCount attribute in JCR sample content
[ https://issues.apache.org/jira/browse/COCOON-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705424#action_12705424 ] Jasha Joachimsthal commented on COCOON-2257: Added modCount to sample content. Sample is still not working 100% Missing modCount attribute in JCR sample content Key: COCOON-2257 URL: https://issues.apache.org/jira/browse/COCOON-2257 Project: Cocoon Issue Type: Bug Components: Blocks: JCR Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) The JCR sample content was probably written before the JCR-1.0 spec was released. In the final release a modCount attribute was expected in org.apache.jackrabbit.core.state.xml.XMLPersistenceManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2257) Missing modCount attribute in JCR sample content
Missing modCount attribute in JCR sample content Key: COCOON-2257 URL: https://issues.apache.org/jira/browse/COCOON-2257 Project: Cocoon Issue Type: Bug Components: Blocks: JCR Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) The JCR sample content was probably written before the JCR-1.0 spec was released. In the final release a modCount attribute was expected in org.apache.jackrabbit.core.state.xml.XMLPersistenceManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2228: -- Assignee: Jasha Joachimsthal StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2213. -- Resolution: Fixed Affects version (Component): Parent values: Blocks: Mail(10170). Level 1 values: 1.0.0(10394). Fix version (Component): Parent values: Blocks: Mail(10242). Level 1 values: 1.1.0-SNAPSHOT(10401). Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Jasha Joachimsthal Assignee: Alfred Nathaniel Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: SendMailTransformer-plaintext.patch, SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2228. -- Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Affects version (Component): Parent values: Components: Pipeline(10157). Level 1 values: 1.0.0(10382). Fix version (Component): Parent values: Components: Pipeline(10228). Level 1 values: 1.1.0-SNAPSHOT(10403). StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2213: --- Attachment: SendMailTransformer-plaintext.patch Seems like one code changes breaks setting a charset on plain/text mails. I couldn't find your change in one of the patches for this issue or COCOON-1622. Created a patch to revert this. Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Alfred Nathaniel Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: SendMailTransformer-plaintext.patch, SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2213: --- Fix Version/s: 2.2-dev (Current SVN) Affects Version/s: 2.2-dev (Current SVN) Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Jasha Joachimsthal Assignee: Alfred Nathaniel Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: SendMailTransformer-plaintext.patch, SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: Blocks: (Undefined) Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2228: --- Component/s: (was: Blocks: (Undefined)) * Cocoon Core StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2228: --- Attachment: StripNameSpacesTransformer-Attributes.diff Added stripping of attributes StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2213: --- Attachment: SendMailTransformer_mime-type.patch Patch with changed mime-type check Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.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-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605907#action_12605907 ] Jasha Joachimsthal commented on COCOON-2213: Useful in cases like email:body mime-type=text/html;charset=UTF-8 /email:body email:body mime-type=text/plain;charset=UTF-8 /email:body Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reopened COCOON-1574: JXPathHelper.getAttribute() now always returns an Object of type String instead of any Object which breaks implementations that do not expect a String. 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: 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] Issue Comment Edited: (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599018#action_12599018 ] jashajoachimsthal edited comment on COCOON-1574 at 5/22/08 7:03 AM: - AbstractJXPathModule.getAttribute() now always returns an Object of type String instead of any Object which breaks implementations that do not expect a String. was (Author: jashajoachimsthal): JXPathHelper.getAttribute() now always returns an Object of type String instead of any Object which breaks implementations that do not expect a String. 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: 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] Commented: (COCOON-1818) SendMailTransformer misses closing tag when recipient address is malformed
[ http://issues.apache.org/jira/browse/COCOON-1818?page=comments#action_12414052 ] Jasha Joachimsthal commented on COCOON-1818: Could someone please commit the SendMailTransformer.diff so this bug is fixed? Thanks SendMailTransformer misses closing tag when recipient address is malformed -- Key: COCOON-1818 URL: http://issues.apache.org/jira/browse/COCOON-1818 Project: Cocoon Type: Bug Components: Blocks: Mail Reporter: Jasha Joachimsthal Attachments: SendMailTransformer.diff, sendmail-exceptions.diff, sendmail-exceptions2.diff When a recipient address contains an illegal character (, ; space [EMAIL PROTECTED]@com etc), an exception is being thrown by method sendMail(List newAddresses, Transport trans). The execution of the try in method sendMail() is stopped which may have created a email:result tag. No /email:result end tag is created when this occurs. -- 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-1818) SendMailTransformer misses closing tag when recipient address is malformed
[ http://issues.apache.org/jira/browse/COCOON-1818?page=all ] Jasha Joachimsthal updated COCOON-1818: --- Attachment: SendMailTransformer.diff Simone, thank you for making the changes. I moved soms other lines of code too so the SendMailTransformer won't stop if one address is invalid. The diff is not a delta from yours but a new one. SendMailTransformer misses closing tag when recipient address is malformed -- Key: COCOON-1818 URL: http://issues.apache.org/jira/browse/COCOON-1818 Project: Cocoon Type: Bug Components: Blocks: Mail Reporter: Jasha Joachimsthal Attachments: SendMailTransformer.diff, sendmail-exceptions.diff, sendmail-exceptions2.diff When a recipient address contains an illegal character (, ; space [EMAIL PROTECTED]@com etc), an exception is being thrown by method sendMail(List newAddresses, Transport trans). The execution of the try in method sendMail() is stopped which may have created a email:result tag. No /email:result end tag is created when this occurs. -- 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-1818) SendMailTransformer misses closing tag when recipient address is malformed
[ http://issues.apache.org/jira/browse/COCOON-1818?page=comments#action_12372436 ] Jasha Joachimsthal commented on COCOON-1818: This fix will cause other problems (the result tag is not always present, e.g. when the smtp host is incorrect). I am working on it, hope to post something asap. SendMailTransformer misses closing tag when recipient address is malformed -- Key: COCOON-1818 URL: http://issues.apache.org/jira/browse/COCOON-1818 Project: Cocoon Type: Bug Components: Blocks: Mail Reporter: Jasha Joachimsthal Attachments: sendmail-exceptions.diff When a recipient address contains an illegal character (, ; space [EMAIL PROTECTED]@com etc), an exception is being thrown by method sendMail(List newAddresses, Transport trans). The execution of the try in method sendMail() is stopped which may have created a email:result tag. No /email:result end tag is created when this occurs. -- 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-1818) SendMailTransformer misses closing tag when recipient address is malformed
[ http://issues.apache.org/jira/browse/COCOON-1818?page=comments#action_12372443 ] Jasha Joachimsthal commented on COCOON-1818: My solution was like #3 (not sure whether email:error should be inside email:result or outside like it is now) but the last time I did something in Java was in the 20th century so I want someone else at Hippo to have a look at it. :) Other thing. If you send it to 10 addresses and it creates an exception, at address 6, it stops and 7-10 won't get the mail. Is this behaviour correct, disirable or not? SendMailTransformer misses closing tag when recipient address is malformed -- Key: COCOON-1818 URL: http://issues.apache.org/jira/browse/COCOON-1818 Project: Cocoon Type: Bug Components: Blocks: Mail Reporter: Jasha Joachimsthal Attachments: sendmail-exceptions.diff When a recipient address contains an illegal character (, ; space [EMAIL PROTECTED]@com etc), an exception is being thrown by method sendMail(List newAddresses, Transport trans). The execution of the try in method sendMail() is stopped which may have created a email:result tag. No /email:result end tag is created when this occurs. -- 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-1818) SendMailTransformer misses closing tag when recipient address is malformed
SendMailTransformer misses closing tag when recipient address is malformed -- Key: COCOON-1818 URL: http://issues.apache.org/jira/browse/COCOON-1818 Project: Cocoon Type: Bug Components: Blocks: Mail Reporter: Jasha Joachimsthal When a recipient address contains an illegal character (, ; space [EMAIL PROTECTED]@com etc), an exception is being thrown by method sendMail(List newAddresses, Transport trans). The execution of the try in method sendMail() is stopped which may have created a email:result tag. No /email:result end tag is created when this occurs. -- 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
