[jira] [Updated] (COCOON-2359) [2.2] Fix incompatibility of cocoon-captcha with JDK 1.7/1.8
[ https://issues.apache.org/jira/browse/COCOON-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel updated COCOON-2359: - Summary: [2.2] Fix incompatibility of cocoon-captcha with JDK 1.7/1.8 (was: Fix incompatibility of cocoon-captcha with JDK 1.7/1.8) > [2.2] Fix incompatibility of cocoon-captcha with JDK 1.7/1.8 > > > Key: COCOON-2359 > URL: https://issues.apache.org/jira/browse/COCOON-2359 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Captcha >Affects Versions: 2.2 >Reporter: Gabriel Gruber >Priority: Major > Fix For: 2.2.1 > > > Goal is to remove the direct usage of > - JPEGImageEncoder > - JPEGEncodeParam > inside CaptchaReader.java > And replace them with the newer 1.6 API of ImageIO > https://blog.idrsolutions.com/2012/05/replacing-the-deprecated-java-jpeg-classes-for-java-7/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COCOON-2360) [2,2] Inconsistent method names
[
https://issues.apache.org/jira/browse/COCOON-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alfred Nathaniel updated COCOON-2360:
-
Affects Version/s: 2.2
Summary: [2,2] Inconsistent method names (was: Inconsistent
method names)
> [2,2] Inconsistent method names
> ---
>
> Key: COCOON-2360
> URL: https://issues.apache.org/jira/browse/COCOON-2360
> Project: Cocoon
> Issue Type: Improvement
> Components: Blocks: (Undefined)
>Affects Versions: 2.2
>Reporter: KuiLIU
>Priority: Major
>
> The following method is named as "select".
> "select" is prone to mean that something will be selected.
> But this method actually checks whether the expression is contained or not.
> So, rename it as "contains" should be more clearly and intuitively.
> public boolean select( String expression ) {
> return this.set.contains( expression );
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (COCOON-2364) Update to fop-1.1
[ https://issues.apache.org/jira/browse/COCOON-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-2364. Resolution: Fixed Assignee: Alfred Nathaniel > Update to fop-1.1 > - > > Key: COCOON-2364 > URL: https://issues.apache.org/jira/browse/COCOON-2364 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: FOP >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel > Assignee: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 includes fop-1.0. fop-1.1 contains an impressive list of > improvements: https://xmlgraphics.apache.org/fop/1.1/changes_1.1.html > Update is straightforward except that the ExtendableRendererFactory must be > removed. The old Renderer implementations it is based are no longer > available. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COCOON-2362) Unsynchronized HashMap.put leads to infinite loop
[
https://issues.apache.org/jira/browse/COCOON-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alfred Nathaniel closed COCOON-2362.
Resolution: Fixed
Assignee: Alfred Nathaniel
> Unsynchronized HashMap.put leads to infinite loop
> -
>
> Key: COCOON-2362
> URL: https://issues.apache.org/jira/browse/COCOON-2362
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.12
>Reporter: Alfred Nathaniel
> Assignee: Alfred Nathaniel
>Priority: Major
> Fix For: 2.1.13
>
>
> Under load a Cocoon thread occasionally starts spinning at 100% in an
> infinite loop. The reason is concurrent writing to a HashMap without proper
> synchronization. The two stack traces are:
> {noformat}
> java.util.HashMap.put (HashMap.java:420)
> org.apache.cocoon.components.language.generator.GeneratorSelector.select
> (GeneratorSelector.java:125)
> {noformat}
> {noformat}
> java.util.HashMap.getEntry(HashMap.java:465)
> java.util.HashMap.get(HashMap.java:417)
> org.apache.cocoon.reading.ResourceReader.getLastModified(ResourceReader.java:242)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (COCOON-2363) Update to poi-3.14
[ https://issues.apache.org/jira/browse/COCOON-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-2363. Resolution: Fixed Assignee: Alfred Nathaniel > Update to poi-3.14 > -- > > Key: COCOON-2363 > URL: https://issues.apache.org/jira/browse/COCOON-2363 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: POI >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel > Assignee: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > The Cocoon 2.1.12 POI block uses poi-3.10-final which contains a few security > issues. > Updating to 3.14 is low-hanging fruit, except that minimum Java is 1.6. > (3.15 drops deprecated methods. 4.0 raises Java to 1.8). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COCOON-2365) Update to httpclient-3.1
[ https://issues.apache.org/jira/browse/COCOON-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-2365. Resolution: Fixed > Update to httpclient-3.1 > > > Key: COCOON-2365 > URL: https://issues.apache.org/jira/browse/COCOON-2365 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: XSP > Reporter: Alfred Nathaniel >Assignee: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 uses httpclient-2.0.2 in various blocks (XSP, Proxy, WebDAV). > The Commons HttpClient project is now end of life and has been replaced by > the Apache HttpComponents project. > An update to the latest available version httpclient-3.1 is low-hanging fruit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COCOON-2367) Update to xalan-2.7.2 and add serializer-2.7.2
[ https://issues.apache.org/jira/browse/COCOON-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-2367. Resolution: Fixed > Update to xalan-2.7.2 and add serializer-2.7.2 > -- > > Key: COCOON-2367 > URL: https://issues.apache.org/jira/browse/COCOON-2367 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel > Assignee: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 uses xalan-2.7.1 which contains a security issue. Upgrade to > xalan-2.7.2 is straightforward. Only the spawned-off serializer-2.7.2 jar > must be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COCOON-2366) XSP block doesn't compile with Java 8
[ https://issues.apache.org/jira/browse/COCOON-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-2366. Resolution: Fixed > XSP block doesn't compile with Java 8 > - > > Key: COCOON-2366 > URL: https://issues.apache.org/jira/browse/COCOON-2366 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: XSP >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel > Assignee: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 provides as option to use the JDK compiler for XSPs. The Javac > class calls internal APIs no longer available in recent Java versions. Since > Java 6 the standard API javax.tool.JavaCompiler is provided. > Source code to compile with Java 5 and Java 6 would need to do indirect class > loading calls. Better to drop Java 5 support in Cocoon and declare 1.6 to be > the minimum version, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (COCOON-2366) XSP block doesn't compile with Java 8
[ https://issues.apache.org/jira/browse/COCOON-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel reassigned COCOON-2366: Assignee: Alfred Nathaniel > XSP block doesn't compile with Java 8 > - > > Key: COCOON-2366 > URL: https://issues.apache.org/jira/browse/COCOON-2366 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: XSP >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel > Assignee: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 provides as option to use the JDK compiler for XSPs. The Javac > class calls internal APIs no longer available in recent Java versions. Since > Java 6 the standard API javax.tool.JavaCompiler is provided. > Source code to compile with Java 5 and Java 6 would need to do indirect class > loading calls. Better to drop Java 5 support in Cocoon and declare 1.6 to be > the minimum version, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (COCOON-2365) Update to httpclient-3.1
[ https://issues.apache.org/jira/browse/COCOON-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel reassigned COCOON-2365: Assignee: Alfred Nathaniel > Update to httpclient-3.1 > > > Key: COCOON-2365 > URL: https://issues.apache.org/jira/browse/COCOON-2365 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: XSP > Reporter: Alfred Nathaniel >Assignee: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 uses httpclient-2.0.2 in various blocks (XSP, Proxy, WebDAV). > The Commons HttpClient project is now end of life and has been replaced by > the Apache HttpComponents project. > An update to the latest available version httpclient-3.1 is low-hanging fruit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (COCOON-2367) Update to xalan-2.7.2 and add serializer-2.7.2
[ https://issues.apache.org/jira/browse/COCOON-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel reassigned COCOON-2367: Assignee: Alfred Nathaniel > Update to xalan-2.7.2 and add serializer-2.7.2 > -- > > Key: COCOON-2367 > URL: https://issues.apache.org/jira/browse/COCOON-2367 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel > Assignee: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 uses xalan-2.7.1 which contains a security issue. Upgrade to > xalan-2.7.2 is straightforward. Only the spawned-off serializer-2.7.2 jar > must be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COCOON-2367) Update to xalan-2.7.2 and add serializer-2.7.2
[ https://issues.apache.org/jira/browse/COCOON-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774266#comment-16774266 ] Alfred Nathaniel commented on COCOON-2367: -- Committed fix to 2.1.13-dev. http://svn.apache.org/viewvc?view=revision=1853788 > Update to xalan-2.7.2 and add serializer-2.7.2 > -- > > Key: COCOON-2367 > URL: https://issues.apache.org/jira/browse/COCOON-2367 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 uses xalan-2.7.1 which contains a security issue. Upgrade to > xalan-2.7.2 is straightforward. Only the spawned-off serializer-2.7.2 jar > must be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COCOON-2367) Update to xalan-2.7.2 and add serializer-2.7.2
Alfred Nathaniel created COCOON-2367: Summary: Update to xalan-2.7.2 and add serializer-2.7.2 Key: COCOON-2367 URL: https://issues.apache.org/jira/browse/COCOON-2367 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.1.12 Reporter: Alfred Nathaniel Fix For: 2.1.13 Cocoon 2.1.12 uses xalan-2.7.1 which contains a security issue. Upgrade to xalan-2.7.2 is straightforward. Only the spawned-off serializer-2.7.2 jar must be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COCOON-2366) XSP block doesn't compile with Java 8
Alfred Nathaniel created COCOON-2366: Summary: XSP block doesn't compile with Java 8 Key: COCOON-2366 URL: https://issues.apache.org/jira/browse/COCOON-2366 Project: Cocoon Issue Type: Improvement Components: Blocks: XSP Affects Versions: 2.1.12 Reporter: Alfred Nathaniel Fix For: 2.1.13 Cocoon 2.1.12 provides as option to use the JDK compiler for XSPs. The Javac class calls internal APIs no longer available in recent Java versions. Since Java 6 the standard API javax.tool.JavaCompiler is provided. Source code to compile with Java 5 and Java 6 would need to do indirect class loading calls. Better to drop Java 5 support in Cocoon and declare 1.6 to be the minimum version, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COCOON-2366) XSP block doesn't compile with Java 8
[ https://issues.apache.org/jira/browse/COCOON-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774256#comment-16774256 ] Alfred Nathaniel commented on COCOON-2366: -- Retaining Javac, Jikes, and Pizza compilers as options is rather nostalgic. The Eclipse JDT compiler included in the standard Cocoon distribution is quite sufficient. > XSP block doesn't compile with Java 8 > - > > Key: COCOON-2366 > URL: https://issues.apache.org/jira/browse/COCOON-2366 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: XSP >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 provides as option to use the JDK compiler for XSPs. The Javac > class calls internal APIs no longer available in recent Java versions. Since > Java 6 the standard API javax.tool.JavaCompiler is provided. > Source code to compile with Java 5 and Java 6 would need to do indirect class > loading calls. Better to drop Java 5 support in Cocoon and declare 1.6 to be > the minimum version, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COCOON-2366) XSP block doesn't compile with Java 8
[ https://issues.apache.org/jira/browse/COCOON-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774251#comment-16774251 ] Alfred Nathaniel commented on COCOON-2366: -- Committed fix to 2.1.13-dev. http://svn.apache.org/viewvc?view=revision=1853873 > XSP block doesn't compile with Java 8 > - > > Key: COCOON-2366 > URL: https://issues.apache.org/jira/browse/COCOON-2366 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: XSP >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 provides as option to use the JDK compiler for XSPs. The Javac > class calls internal APIs no longer available in recent Java versions. Since > Java 6 the standard API javax.tool.JavaCompiler is provided. > Source code to compile with Java 5 and Java 6 would need to do indirect class > loading calls. Better to drop Java 5 support in Cocoon and declare 1.6 to be > the minimum version, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COCOON-2365) Update to httpclient-3.1
[ https://issues.apache.org/jira/browse/COCOON-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774243#comment-16774243 ] Alfred Nathaniel commented on COCOON-2365: -- Committed fix to 2.1.13-dev. http://svn.apache.org/viewvc?view=revision=1853818 > Update to httpclient-3.1 > > > Key: COCOON-2365 > URL: https://issues.apache.org/jira/browse/COCOON-2365 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: XSP > Reporter: Alfred Nathaniel >Priority: Major > > Cocoon 2.1.12 uses httpclient-2.0.2 in various blocks (XSP, Proxy, WebDAV). > The Commons HttpClient project is now end of life and has been replaced by > the Apache HttpComponents project. > An update to the latest available version httpclient-3.1 is low-hanging fruit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COCOON-2365) Update to httpclient-3.1
Alfred Nathaniel created COCOON-2365: Summary: Update to httpclient-3.1 Key: COCOON-2365 URL: https://issues.apache.org/jira/browse/COCOON-2365 Project: Cocoon Issue Type: Improvement Components: Blocks: XSP Reporter: Alfred Nathaniel Cocoon 2.1.12 uses httpclient-3.0 in varies blocks (XSP, Proxy, WebDAV). The Commons HttpClient project is now end of life and has been replaced by the Apache HttpComponents project. An update to the latest available version httpclient-3.1 is low-hanging fruit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COCOON-2365) Update to httpclient-3.1
[ https://issues.apache.org/jira/browse/COCOON-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel updated COCOON-2365: - Description: Cocoon 2.1.12 uses httpclient-2.0.2 in various blocks (XSP, Proxy, WebDAV). The Commons HttpClient project is now end of life and has been replaced by the Apache HttpComponents project. An update to the latest available version httpclient-3.1 is low-hanging fruit. was: Cocoon 2.1.12 uses httpclient-3.0 in varies blocks (XSP, Proxy, WebDAV). The Commons HttpClient project is now end of life and has been replaced by the Apache HttpComponents project. An update to the latest available version httpclient-3.1 is low-hanging fruit. > Update to httpclient-3.1 > > > Key: COCOON-2365 > URL: https://issues.apache.org/jira/browse/COCOON-2365 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: XSP > Reporter: Alfred Nathaniel >Priority: Major > > Cocoon 2.1.12 uses httpclient-2.0.2 in various blocks (XSP, Proxy, WebDAV). > The Commons HttpClient project is now end of life and has been replaced by > the Apache HttpComponents project. > An update to the latest available version httpclient-3.1 is low-hanging fruit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COCOON-2364) Update to fop-1.1
[ https://issues.apache.org/jira/browse/COCOON-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774202#comment-16774202 ] Alfred Nathaniel commented on COCOON-2364: -- Committed fix to 2.1.13-dev. http://svn.apache.org/viewvc?view=revision=1853820 > Update to fop-1.1 > - > > Key: COCOON-2364 > URL: https://issues.apache.org/jira/browse/COCOON-2364 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: FOP >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > Cocoon 2.1.12 includes fop-1.0. fop-1.1 contains an impressive list of > improvements: https://xmlgraphics.apache.org/fop/1.1/changes_1.1.html > Update is straightforward except that the ExtendableRendererFactory must be > removed. The old Renderer implementations it is based are no longer > available. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COCOON-2364) Update to fop-1.1
Alfred Nathaniel created COCOON-2364: Summary: Update to fop-1.1 Key: COCOON-2364 URL: https://issues.apache.org/jira/browse/COCOON-2364 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12 Reporter: Alfred Nathaniel Fix For: 2.1.13 Cocoon 2.1.12 includes fop-1.0. fop-1.1 contains an impressive list of improvements: https://xmlgraphics.apache.org/fop/1.1/changes_1.1.html Update is straightforward except that the ExtendableRendererFactory must be removed. The old Renderer implementations it is based are no longer available. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COCOON-2363) Update to poi-3.14
[ https://issues.apache.org/jira/browse/COCOON-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel updated COCOON-2363: - Description: The Cocoon 2.1.12 POI block uses poi-3.10-final which contains a few security issues. Updating to 3.14 is low-hanging fruit, except that minimum Java is 1.6. (3.15 drops deprecated methods. 4.0 raises Java to 1.8). was: The Cocoon 2.1.12 POI block uses poi-3.10-final which contains a few security issues. Updating to 3.14 is low-hanging fruit, except that minimum Java is 1.6 since 3.11. (3.15 drops deprecated methods. 4.0 raises Java to 1.8). > Update to poi-3.14 > -- > > Key: COCOON-2363 > URL: https://issues.apache.org/jira/browse/COCOON-2363 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: POI >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > The Cocoon 2.1.12 POI block uses poi-3.10-final which contains a few security > issues. > Updating to 3.14 is low-hanging fruit, except that minimum Java is 1.6. > (3.15 drops deprecated methods. 4.0 raises Java to 1.8). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COCOON-2363) Update to poi-3.14
[ https://issues.apache.org/jira/browse/COCOON-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774179#comment-16774179 ] Alfred Nathaniel commented on COCOON-2363: -- Commited fix to 2.1.13-dev, including updates to * commons-logging-1.2 * log4j-1.2.17 * commons-codec-1.10.jar * curvesapi-1.06.jar * poi-3.14.jar * poi-ooxml-3.14.jar * poi-ooxml-schemas-3.14.jar * xmlbeans-3.0.2.jar * slf4j-log4j12-1.6.4.jar http://svn.apache.org/viewvc?view=revision=1853823 http://svn.apache.org/viewvc?view=revision=1853975 > Update to poi-3.14 > -- > > Key: COCOON-2363 > URL: https://issues.apache.org/jira/browse/COCOON-2363 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: POI >Affects Versions: 2.1.12 >Reporter: Alfred Nathaniel >Priority: Major > Fix For: 2.1.13 > > > The Cocoon 2.1.12 POI block uses poi-3.10-final which contains a few security > issues. > Updating to 3.14 is low-hanging fruit, except that minimum Java is 1.6. > (3.15 drops deprecated methods. 4.0 raises Java to 1.8). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COCOON-2363) Update to poi-3.14
Alfred Nathaniel created COCOON-2363: Summary: Update to poi-3.14 Key: COCOON-2363 URL: https://issues.apache.org/jira/browse/COCOON-2363 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.12 Reporter: Alfred Nathaniel Fix For: 2.1.13 The Cocoon 2.1.12 POI block uses poi-3.10-final which contains a few security issues. Updating to 3.14 is low-hanging fruit, except that minimum Java is 1.6 since 3.11. (3.15 drops deprecated methods. 4.0 raises Java to 1.8). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COCOON-2362) Unsynchronized HashMap.put leads to infinite loop
[
https://issues.apache.org/jira/browse/COCOON-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774123#comment-16774123
]
Alfred Nathaniel commented on COCOON-2362:
--
Fix committed to 2.1.13-dev.
http://svn.apache.org/viewvc?view=revision=1853824
> Unsynchronized HashMap.put leads to infinite loop
> -
>
> Key: COCOON-2362
> URL: https://issues.apache.org/jira/browse/COCOON-2362
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.12
>Reporter: Alfred Nathaniel
>Priority: Major
> Fix For: 2.1.13
>
>
> Under load a Cocoon thread occasionally starts spinning at 100% in an
> infinite loop. The reason is concurrent writing to a HashMap without proper
> synchronization. The two stack traces are:
> {noformat}
> java.util.HashMap.put (HashMap.java:420)
> org.apache.cocoon.components.language.generator.GeneratorSelector.select
> (GeneratorSelector.java:125)
> {noformat}
> {noformat}
> java.util.HashMap.getEntry(HashMap.java:465)
> java.util.HashMap.get(HashMap.java:417)
> org.apache.cocoon.reading.ResourceReader.getLastModified(ResourceReader.java:242)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COCOON-2362) Unsynchronized HashMap.put leads to infinite loop
Alfred Nathaniel created COCOON-2362:
Summary: Unsynchronized HashMap.put leads to infinite loop
Key: COCOON-2362
URL: https://issues.apache.org/jira/browse/COCOON-2362
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.12
Reporter: Alfred Nathaniel
Fix For: 2.1.13
Under load a Cocoon thread occasionally starts spinning at 100% in an infinite
loop. The reason is concurrent writing to a HashMap without proper
synchronization. The two stack traces are:
{noformat}
java.util.HashMap.put (HashMap.java:420)
org.apache.cocoon.components.language.generator.GeneratorSelector.select
(GeneratorSelector.java:125)
{noformat}
{noformat}
java.util.HashMap.getEntry(HashMap.java:465)
java.util.HashMap.get(HashMap.java:417)
org.apache.cocoon.reading.ResourceReader.getLastModified(ResourceReader.java:242)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
[ https://issues.apache.org/jira/browse/COCOON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-2169. Resolution: Fixed Assuming lazy consense that issue is solved. ImageOp resize effect has broken/useless default dimensions --- Key: COCOON-2169 URL: https://issues.apache.org/jira/browse/COCOON-2169 Project: Cocoon Issue Type: Bug Components: Blocks: ImageOp Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2 Reporter: Mark Lundquist Assignee: Alfred Nathaniel Priority: Minor Attachments: smime.p7s Class ResizeOperation in the ImageOp block has broken/useless default values for the height and width parameters. The only reasonable default values are zero. Zero height or width has a special meaning. I am passing these parameters in from the sitemap using the request parameter input module. If the parameter doesn't exist, I need the zero value and behavior from the Reader. Setting the dimension to e.g. 300 is broken. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON-2315) WebserviceGenerator should allow to include the request headers of the caller.
[
https://issues.apache.org/jira/browse/COCOON-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alfred Nathaniel updated COCOON-2315:
-
Summary: WebserviceGenerator should allow to include the request headers of
the caller. (was: Generator and CInclude transformer do not include the
request headers of the caller.)
That looks as if you expect Cocoon to act as forward proxy. I suggest you send
a description of the actual problem to us...@cocoon.apache.org.
WebserviceGenerator should allow to include the request headers of the caller.
--
Key: COCOON-2315
URL: https://issues.apache.org/jira/browse/COCOON-2315
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.9, 2.1.12-dev (Current SVN)
Reporter: Alec Bickerton
When using the file generator or any sub class. The request headers are not
propagated to the source.
e.g.
{code}
map:match pattern=deviceInfo
map:generate src=http://deviceMetaService.example.com/lookup.jsp/
map:serialize/
/map:match
{code}
The request received by the http://deviceMetaService.example.com/lookup.jsp
will not contain the user-agent header of the original request.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COCOON-2315) Generator and CInclude transformer do not include the request headers of the caller.
[
https://issues.apache.org/jira/browse/COCOON-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alfred Nathaniel closed COCOON-2315.
Resolution: Not A Problem
This is not a bug but a misconception what the file generator does. As the
name implies the file generator is most often used to read files, parse them as
XML documents and send the SAX events down the pipeline. The src attribute
also allows to use other source protocols as drop-in replacement for files.
In the case of http: the file generator creates a GET request to the given
webserver. Parameters or headers from the original request invoking the
current pipeline are not forwarded.
If you need to formulate customized HTTP requests you should look at
http://cocoon.apache.org/2.1/userdocs/wsproxy-generator.html.
Generator and CInclude transformer do not include the request headers of the
caller.
Key: COCOON-2315
URL: https://issues.apache.org/jira/browse/COCOON-2315
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.9, 2.1.12-dev (Current SVN)
Reporter: Alec Bickerton
When using the file generator or any sub class. The request headers are not
propagated to the source.
e.g.
{code}
map:match pattern=deviceInfo
map:generate src=http://deviceMetaService.example.com/lookup.jsp/
map:serialize/
/map:match
{code}
The request received by the http://deviceMetaService.example.com/lookup.jsp
will not contain the user-agent header of the original request.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [2.1] Is Cocoon 2.1.x officially dead ?
BTW, is there still many Cocoon-2.1 users around here ? Best regards, Cédric Damioli At my daytime job I am also still running a number of high-profile websites with Cocoon 2.1.10. So I am very much interested in continuing the 2.1.x branch. But could we agree that JDK1.5 should be the minimum for that future 2.1.12 release? Cheers, Alfred.
Re: [VOTE] Release Cocoon Serializers Charset and Block
On Fri, 2009-10-09 at 14:23 +0200, Carsten Ziegeler wrote: Please cast your votes. +1 Cheers, Alfred.
Re: FW: Cocoon versions for Java 6
Hi Laurent, we are using Cocoon 2.1.x still with Java 5. But with that comment in the bug report you should just give it a spin. If you want to be cautious, define the magic property. If you feel more adventerous, try it without and fix the source where it bombs. Cheers, Alfred. Submitted On 25-JUL-2007 Neale I tripped over this, and thought: JDK6 has broken something. Now that there is a documented workaround, I think that it could be considered fixed, as we now have two options: 1) Add -Dsun.lang.ClassLoader.allowArraySyntax=true if you want to use a library for which you don't have the source with JDK6 2) Change loader.loadClass( name ) to Class.forName( name, false, loader ) if you own the code. If Sun are not intending to fix this to be compatible without the flag, then I think it would be great if we could have a clear statement here to close off this bug On Thu, 2009-02-26 at 14:25 +0100, Laurent Medioni wrote: Hi, Trying my luck on the dev list ? Thanks, Laurent -Original Message- From: Laurent Medioni [mailto:lmedi...@odyssey-group.com] Sent: mardi, 24. février 2009 10:37 To: us...@cocoon.apache.org Subject: Cocoon versions for Java 6 Hi, Anyone knows if a Cocoon version is validated/intended for Java 6 ? Sorry Googled a lot but to no avail... We plan to move our 2.1.11 application to Java 6 and already had a nasty Reflection issue for arrays with 1.6 described in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434149 And I noticed that there are a lot of occurrences of these calls in 2.1.11... Thanks.
[jira] Commented: (COCOON-2247) Default matcher no longer works when divider character part of match
[
https://issues.apache.org/jira/browse/COCOON-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661389#action_12661389
]
Alfred Nathaniel commented on COCOON-2247:
--
Latest Cocoon 2.2 and 2.1 behave in the same way. Before 2.1.10 the
WildcardMatcherHelper was a handmade parser which had a number of subtle bugs.
Now the match pattern is translated into an RE and handed to the Apache regexp
package.
In that translation is handled as [^/]*, i.e. greedy match except slash.
Unfortunately there are only testcases for the greediness of but not for *.
Therefore the behaviour for is open for discussion.
I think should remain greedy as it is now because
a) is definitely greedy and * should not be the other way around
b) in other RE languages the default is usually greedy
If you want non-greedy matches, there is match type=regexp to use general
REs.
(Visible to all-developers group)
Default matcher no longer works when divider character part of match
Key: COCOON-2247
URL: https://issues.apache.org/jira/browse/COCOON-2247
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.11
Reporter: Kamal Bhatt
Example sitemap:
!-- Generates a CFORM selection list based on all images accessible to
publication --
map:match pattern=image_list_*_*
map:generate type=imagedirectory
src=../cmsblocks/holidayImg/{1}/{2}
map:parameter name=depth value=2/
/map:generate
map:transform src=xslt/brandimagedirectory_list.xsl
map:parameter name=list_level value=file/
/map:transform
map:serialize type=xml/
/map:match
Using the following match:
image_list_images_TE_tours
You get the following error:
../cmsblocks/holidayImg/images_TE/tours is not a directory.
The match is completely foobar. This used to work in 2.1.9
I have not had a chance to see how it works in 2.2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: DTD validation
On Fri, 2008-09-05 at 17:08 -0500, Lars Huttar wrote: I'm all for supporting XML Schema and Relax NG, but for Cocoon not to support DTD's at all just seems baffling. There is the excellent trang utility to convert between Relax NG / XML Schema / DTD (http://www.thaiopensource.com/relaxng/trang.html). HTH, Alfred.
[JOB] Web application developer in Geneva
Swiss Exchange has an opening for a fulltime staff position as web application developer in Geneva, Switzerland. We are looking for an experienced developer with a strong background in Java5 and OO design. Additional assets are prior experience with other components of our technology stack (Ant, Apache, Axis, Cocoon, C++, CSS, CVS, Dojo, Eclipse, Findbugs, FOP, HTLM, JavaScript, JDBC, make, Oracle10g, Perl5, POI, RelaxNG, Solaris10, SVG, Sybase12, Tomcat, XML, XSLT). You will be working in a small team of developers who are in charge of developing and maintaining the dynamic parts of http://www.swx.com and other related websites. The working language is English but a basic knowledge of German is a plus. If you are interested, please post your application to http://www.swx.com/careers/description/g08msc_lsg01_en.html with reference to this announcement. Best regards, Alfred Nathaniel SWX e-Services
Re: CForms and Dojo
On Thu, 2008-08-21 at 19:46 -0400, Vadim Gritsenko wrote: On Aug 21, 2008, at 10:59 AM, Jeremy Quinn wrote: But in the short term, what do people prefer? My fully expanded Dojo as a block (every file in SVN), or as a Jar (a single file in SVN)? Personally, jar file is just fine. Most or all IDEs can peek inside jar file and show any file you want to see. And it is faster to pull then 4k files (is this number for Dojo files only or Dojo and all files added by the Subversion?) +1 for the jar That avoids also the temptation to modify the Dojo sources in our SVN. Cheers, Alfred.
Re: [vote] Cocoon 3.0
On Wed, 2008-08-06 at 13:19 +0200, Reinhard Pötz wrote: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. This means that any reference on Corona in source files, package names, artifact ids, group ids or anywhere else will be dropped and the standard Cocoon namespace org.apache.cocoon will be used. This majority vote stays open for 72 hours. Please cast your votes. Here is my +1 -1 I think it is much too early to proclaim a tiny blossom like Corona to be the heir to the huge thicket called Cocoon. It gives the wrong signal to potential new users and will make them shy away. They will read it as: Oh, they are now working on C3.0. So C2.2 will be legacy by the time my project is finished. I may be forced to migrate to 3.0 with lots of incompatibilities. Better I use some other framework for now. I'll have another look when C3.1 is out. At least that was my personal reaction when in 1999 I first came across Cocoon. I never bothered with C1.7 because C2.0 was already announced as being a complete rewrite. Luckily, I passed by a second time in 2002 when C2.1 was in beta state. Evolution instead of revolution is the key to success here. C2.2 almost killed us because it was very bold and then took very long to get out due to the feature creep during the long time it took to get out. Porting stuff forward and backward between C2.1 and C2.2 did and does cost a lot of resources. I would not want to throw in there yet another branch. Before considering C3.0 we should have finished the C2.1 to C2.2 transition period. And that is not achieved by simply declaring the C2.1 branch to be closed. For that I would like to hear more success stories where people actually migrated non-trivial apps from C2.1 to C2.2. I don't want to stand in the way of progress here. Please carry on with Corona and stay within the Cocoon context but just don't call to Cocoon-x.y. Wasn't the original motivation for Corona to have a programmable pipeline container which can be used independently of Cocoon? Maybe stupid question: Why can't it be a set of experimental blocks in trunk which may lateron replace the current sitemap processor? Cheers, Alfred.
Re: [vote] Java 1.5 as minimal requirement for trunk
On Tue, 2008-08-05 at 15:40 +0200, Grzegorz Kossakowski wrote: But of course I meant: The vote will stay open until 12:00 UTC, 08.08.2008. Too late, but still +1. Cheers, Alfred.
Re: A new name for Corona (take 2)
On Mon, 2008-08-04 at 08:24 +0200, Reinhard Pötz wrote: Let's summarize the proposed names (alphabetical order): Cocoon Chasse -1: Too carnivore; makes me think first of the French term la chasse meaning deer hunting or a dish of deer meat. Cocoon Merenque +0: How would you pronounce that? meren-kee / merenk / meren-keh? Cocoon Morus -1: Too puritan; makes me think of Thomas Morus; also too close to Moron Cocoon Weedle -1: Too childish Any general comments? Any other suggestions? Carrying on the association chain from Cocoon Silk: Cocoon Satin Cocoon Cotton Cocoon Fabric Cheers, Alfred.
[jira] Assigned: (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
[ https://issues.apache.org/jira/browse/COCOON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel reassigned COCOON-2169: Assignee: Alfred Nathaniel ImageOp resize effect has broken/useless default dimensions --- Key: COCOON-2169 URL: https://issues.apache.org/jira/browse/COCOON-2169 Project: Cocoon Issue Type: Bug Components: Blocks: ImageOp Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2 Reporter: Mark Lundquist Assignee: Alfred Nathaniel Priority: Minor Attachments: smime.p7s Class ResizeOperation in the ImageOp block has broken/useless default values for the height and width parameters. The only reasonable default values are zero. Zero height or width has a special meaning. I am passing these parameters in from the sitemap using the request parameter input module. If the parameter doesn't exist, I need the zero value and behavior from the Reader. Setting the dimension to e.g. 300 is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2177) ImageOp with requested height width both zero should be a no-op, instead it throws an exception
[
https://issues.apache.org/jira/browse/COCOON-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alfred Nathaniel closed COCOON-2177.
Resolution: Duplicate
This issue is a variation of COCOON-2169.
ImageOp with requested height width both zero should be a no-op, instead it
throws an exception
-
Key: COCOON-2177
URL: https://issues.apache.org/jira/browse/COCOON-2177
Project: Cocoon
Issue Type: Bug
Components: Blocks: ImageOp
Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN),
2.2
Reporter: Mark Lundquist
Assignee: Alfred Nathaniel
Priority: Minor
When the resize height and width are both zero, the resize operation throws:
java.awt.image.ImagingOpException: Unable to invert transform
AffineTransform[[0.0, 0.0, 0.0], [0.0, 0.0, 0.0]]
Note, if COCOON-2169 is fixed, this happens when no height or width parameter
is passed from the sitemap. In this case, the resize effect should simply
pass through the unaltered image... it should be a no-op.
The patch is too small to bother attaching, here it is:
===
---
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(revision 635771)
+++
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(working copy)
@@ -57,6 +57,9 @@
if( ! enabled ) {
return image;
}
+if ( this.width == 0 this.height == 0 ) {
+return image;
+}
double height = image.getHeight();
double width = image.getWidth();
double xScale = this.width / width
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
[ https://issues.apache.org/jira/browse/COCOON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel updated COCOON-2169: - Status: Continued (was: On Hold) OK, got it now. ImageOp resize effect has broken/useless default dimensions --- Key: COCOON-2169 URL: https://issues.apache.org/jira/browse/COCOON-2169 Project: Cocoon Issue Type: Bug Components: Blocks: ImageOp Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2 Reporter: Mark Lundquist Assignee: Alfred Nathaniel Priority: Minor Attachments: smime.p7s Class ResizeOperation in the ImageOp block has broken/useless default values for the height and width parameters. The only reasonable default values are zero. Zero height or width has a special meaning. I am passing these parameters in from the sitemap using the request parameter input module. If the parameter doesn't exist, I need the zero value and behavior from the Reader. Setting the dimension to e.g. 300 is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
[ https://issues.apache.org/jira/browse/COCOON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel updated COCOON-2169: - Status: On Hold (was: Continued) Fix for 2.1: http://svn.apache.org/viewvc?rev=674973view=rev Fix for 2.2: http://svn.apache.org/viewvc?rev=674971view=rev Please check and close issue. ImageOp resize effect has broken/useless default dimensions --- Key: COCOON-2169 URL: https://issues.apache.org/jira/browse/COCOON-2169 Project: Cocoon Issue Type: Bug Components: Blocks: ImageOp Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2 Reporter: Mark Lundquist Assignee: Alfred Nathaniel Priority: Minor Attachments: smime.p7s Class ResizeOperation in the ImageOp block has broken/useless default values for the height and width parameters. The only reasonable default values are zero. Zero height or width has a special meaning. I am passing these parameters in from the sitemap using the request parameter input module. If the parameter doesn't exist, I need the zero value and behavior from the Reader. Setting the dimension to e.g. 300 is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2031) Language Exception at Runtime by the attempt to compile a random XSP
[
https://issues.apache.org/jira/browse/COCOON-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alfred Nathaniel closed COCOON-2031.
Resolution: Fixed
Fix Version/s: 2.1.10
Presumed to be fixed.
Reopen or raise a new issue in case the problem persists with release 2.1.10+.
Language Exception at Runtime by the attempt to compile a random XSP
Key: COCOON-2031
URL: https://issues.apache.org/jira/browse/COCOON-2031
Project: Cocoon
Issue Type: Bug
Components: Blocks: XSP
Affects Versions: 2.1.7
Reporter: Sebastian Wenzky
Priority: Critical
Fix For: 2.1.10
Hi there,
at my topic you have a first imagination about my current (very hard) problem.
But at fist, my enumeration of my software components:
- Cocoon 2.18
- JBoss (Version 4) - Tomcat.
Indeed, i have no explanation, for my confuse problem and i don´t know, what
kind of state occures that. Normally, when cocoon starts at first time there
are no problems. I can go, visit different pages (which will be correctly
compiled) and so on... But sometimes later the error occurs suddenly, without
any real worthwhile exception message to me.
But the tracer in cocoon said to me following text(an excerpt):
ERROR (2007-03-10) 07:44.24:308 [sitemap.handled-errors]
(/jobapp3/content/fhj/user.xsp$user-search$meta-html)
TP-Processor8/ErrorHandlerHelper: Language Exception
org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling
user_xsp:
ERROR 1 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
name,
name,
CDATA,
pst_id
// start error (lines 1044-1044) Syntax error, insert ) to complete
Expression
);
// end error
this.contentHandler.startElement(
http://apache.org/xsp/request/2.0;;,
...
ERROR 2 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
get-parameter,
xsp-request:get-parameter
);
// start error (lines 1063-1063) Syntax error on token ), delete this
token
);
// end error
if ( pstID != null )
{
...
Line 1044, column 0: Syntax error, insert ) to complete Expression
Line 1063, column 0: Syntax error on token ), delete this token
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.loadProgram(ProgramGeneratorImpl.java:409)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:280)
at
org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:385)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:620)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(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.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.SwitchSelectNode.invoke(SwitchSelectNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(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.invokeNodes(AbstractParentProcessingNode.java:46
[jira] Assigned: (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 ] Alfred Nathaniel reassigned COCOON-2213: Assignee: Alfred Nathaniel 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_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 ] Alfred Nathaniel updated COCOON-2213: - Status: On Hold (was: Open) Applied your patch and synchronized branch and trunk versions. That means that http://svn.apache.org/viewvc?view=revrevision=314933 is now backported to 2.1 and that http://issues.apache.org/jira/browse/COCOON-1622 is now also in 2.2. Please check and close issue. 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_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-1622) [PATCH] SendMailTransformer and HTML body
[ https://issues.apache.org/jira/browse/COCOON-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610653#action_12610653 ] Alfred Nathaniel commented on COCOON-1622: -- Applied the patch also to 2.2: http://svn.apache.org/viewvc?view=revrevision=674112 [PATCH] SendMailTransformer and HTML body - Key: COCOON-1622 URL: https://issues.apache.org/jira/browse/COCOON-1622 Project: Cocoon Issue Type: Bug Components: Blocks: Mail Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Philippe Gassmann Assignee: Helma van der Linden Attachments: 20051006-sendmailtr, 20051020-sendmailtr The SendMailTransformer is unable to handle XML tags directly in the SAX flow. ex : email:sendmail email:smtphostsmtp/email:smtphost email:from[EMAIL PROTECTED]/email:from email:to[EMAIL PROTECTED]/email:to email:subject Bogus sendmailtrasformer /email:subject email:body htmlbody pthis is a paragraph/p panother/p /body/html /email:body /email:sendmail It simply remove xml tags in the body ! It a a strange behaviour since DEFAULT_BODY_MIMETYPE = text/html ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2177) ImageOp with requested height width both zero should be a no-op, instead it throws an exception
[
https://issues.apache.org/jira/browse/COCOON-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alfred Nathaniel reassigned COCOON-2177:
Assignee: Alfred Nathaniel
ImageOp with requested height width both zero should be a no-op, instead it
throws an exception
-
Key: COCOON-2177
URL: https://issues.apache.org/jira/browse/COCOON-2177
Project: Cocoon
Issue Type: Bug
Components: Blocks: ImageOp
Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN),
2.2
Reporter: Mark Lundquist
Assignee: Alfred Nathaniel
Priority: Minor
When the resize height and width are both zero, the resize operation throws:
java.awt.image.ImagingOpException: Unable to invert transform
AffineTransform[[0.0, 0.0, 0.0], [0.0, 0.0, 0.0]]
Note, if COCOON-2169 is fixed, this happens when no height or width parameter
is passed from the sitemap. In this case, the resize effect should simply
pass through the unaltered image... it should be a no-op.
The patch is too small to bother attaching, here it is:
===
---
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(revision 635771)
+++
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(working copy)
@@ -57,6 +57,9 @@
if( ! enabled ) {
return image;
}
+if ( this.width == 0 this.height == 0 ) {
+return image;
+}
double height = image.getHeight();
double width = image.getWidth();
double xScale = this.width / width
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2177) ImageOp with requested height width both zero should be a no-op, instead it throws an exception
[
https://issues.apache.org/jira/browse/COCOON-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alfred Nathaniel updated COCOON-2177:
-
Status: On Hold (was: Open)
Patch applied to 2.1 and 2.2:
http://svn.apache.org/viewvc?rev=674121view=rev
http://svn.apache.org/viewvc?rev=674122view=rev
Please check and close issue.
ImageOp with requested height width both zero should be a no-op, instead it
throws an exception
-
Key: COCOON-2177
URL: https://issues.apache.org/jira/browse/COCOON-2177
Project: Cocoon
Issue Type: Bug
Components: Blocks: ImageOp
Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN),
2.2
Reporter: Mark Lundquist
Assignee: Alfred Nathaniel
Priority: Minor
When the resize height and width are both zero, the resize operation throws:
java.awt.image.ImagingOpException: Unable to invert transform
AffineTransform[[0.0, 0.0, 0.0], [0.0, 0.0, 0.0]]
Note, if COCOON-2169 is fixed, this happens when no height or width parameter
is passed from the sitemap. In this case, the resize effect should simply
pass through the unaltered image... it should be a no-op.
The patch is too small to bother attaching, here it is:
===
---
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(revision 635771)
+++
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(working copy)
@@ -57,6 +57,9 @@
if( ! enabled ) {
return image;
}
+if ( this.width == 0 this.height == 0 ) {
+return image;
+}
double height = image.getHeight();
double width = image.getWidth();
double xScale = this.width / width
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610660#action_12610660 ] Alfred Nathaniel commented on COCOON-2133: -- Backported to 2.1: http://svn.apache.org/viewvc?rev=674121view=rev Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Reporter: Robin Wyles Assignee: Grzegorz Kossakowski Priority: Minor Attachments: 4x2.jpg, cocoon-core-SitemapComponentTestCase-read-method.patch, cocoon-imageop-impl-no-effects-test.patch, cocoon-imageop-impl-resize-operation-and-test.patch , ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
[ https://issues.apache.org/jira/browse/COCOON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel updated COCOON-2169: - Status: On Hold (was: Open) I can't quite follow you. What is the special behaviour of zero values you would like to inherit by leaving out the parameters? ImageOp resize effect has broken/useless default dimensions --- Key: COCOON-2169 URL: https://issues.apache.org/jira/browse/COCOON-2169 Project: Cocoon Issue Type: Bug Components: Blocks: ImageOp Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2 Reporter: Mark Lundquist Priority: Minor Class ResizeOperation in the ImageOp block has broken/useless default values for the height and width parameters. The only reasonable default values are zero. Zero height or width has a special meaning. I am passing these parameters in from the sitemap using the request parameter input module. If the parameter doesn't exist, I need the zero value and behavior from the Reader. Setting the dimension to e.g. 300 is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r661886 - in /cocoon/trunk: ./ project/
On Fri, 2008-05-30 at 21:40 +, [EMAIL PROTECTED] wrote: Author: anathaniel Date: Fri May 30 14:40:23 2008 New Revision: 661886 URL: http://svn.apache.org/viewvc?rev=661886view=rev Log: Move all files from /trunk to /trunk/project. Otherwise these files would never show up in Eclipse. Added: cocoon/trunk/1ST_README.txt cocoon/trunk/project/ cocoon/trunk/project/.project cocoon/trunk/project/README.txt - copied, changed from r661475, cocoon/trunk/README.txt cocoon/trunk/project/build-docs.sh - copied, changed from r661475, cocoon/trunk/build-docs.sh cocoon/trunk/project/build.sh - copied unchanged from r661475, cocoon/trunk/build.sh cocoon/trunk/project/cocoon.sh - copied, changed from r661475, cocoon/trunk/cocoon.sh cocoon/trunk/project/pom.xml - copied, changed from r661475, cocoon/trunk/pom.xml cocoon/trunk/project/settings.xml - copied unchanged from r661475, cocoon/trunk/settings.xml Removed: cocoon/trunk/README.txt cocoon/trunk/build-docs.sh cocoon/trunk/build.sh cocoon/trunk/cocoon.sh cocoon/trunk/pom.xml cocoon/trunk/settings.xml I suppose this change will break the continuum build. Could somebody with enough karma please change the build to start off in /trunk/project. Cheers, Alfred.
Re: svn commit: r661886 - in /cocoon/trunk: ./ project/
On Fri, 2008-05-30 at 23:52 +0200, Grzegorz Kossakowski wrote: Are you sure that having these files listed in Eclipse is enough reason to move them? Personally speaking, I'm not so keen on this idea even if using Eclipse. I found it very annoying that part of the files, especially the root and parent pom.xml, where not visible in Eclipse. (Do other IDEs do it better?) I think you should at least inform others that you are going to do such changes so others could have a chance to comment on idea. They are really far from being cosmetic. Sure, the implications may be more drastic than imagined first. If it is a problem, the changes are easy to revert. By the way, is there any reason for telling people to use *.sh scripts instead of Maven directly? I find that easier to explain than all the MAVEN_OPTS magic required when using mvn directly. Cheers, Alfred.
Re: [VOTE] Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
On Wed, 2008-05-28 at 09:03 +0200, Jeroen Reijn wrote: Please cast your votes! +1 Cheers, Alfred.
Re: svn commit: r629374 - /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
On Wed, 2008-05-07 at 22:52 -0400, Joerg Heinicke wrote: On 30.03.2008 02:50, Joerg Heinicke wrote: Author: antonio Date: Tue Feb 19 22:42:45 2008 New Revision: 629374 URL: http://svn.apache.org/viewvc?rev=629374view=rev Log: Faster implementation. Saw this one only now ... I'm a bit concerned about the approach. First, do you really think this implementation is significantly faster? Your implementation only caches the parser instance, you replace the instantiation with ThreadLocal handling. Parsing itself should still be the slowest part. How many Strings do you convert to SAX per thread? Second, who cleans up the thread before it goes back to the thread pool? At the end is it really worth the ugly implementation? IMO it's a much better approach to make it a real Cocoon component (Serializeable) instead and look up the SAXParser. Any opinions on this one? Joerg [1] http://marc.info/?l=xml-cocoon-cvsm=120348979305179w=4 What happens if an exception leaves the parser in a messy state when it is reused? Is there any rule which would guarantee that this should never happen for the average SAXParser implementation? Cheers, Alfred.
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
On Mon, 2008-05-05 at 00:08 -0700, Ralph Goers wrote: I sure am glad we decided to go with Java 1.4 for 2.2. See the nice bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now I'm certain we won't be supporting 1.4 until 2010. No hope to get rid of 1.4 anytime soon. Java 1.3 is EOL since Dec 2006, and we are still supporting it for 2.1. http://java.sun.com/j2se/1.3/download.html Cheers, Alfred.
Re: Excessive file handles on cocoon.xconf
On Wed, 2008-04-30 at 01:04 +0100, Andy Stevens wrote: Okay, I admit this is more a user query, but since it's a bit more technical that some I thought I'd ask where more of the developers hang out. We've just migrated some 2.1.x-based sites from Websphere 5 on Solaris and Windows (where they were running quite happily) to Websphere 6 on Linux. And now, from time to time, we keep getting occassional FileNotFound exceptions stating Too many open files, leading to the pages returning 500s. This isn't even under heavy load. The sites could have been sitting there untouched for a couple of hours (they're not live yet), but subsequently opening up all the home pages you'd get a significant proportion of them producing the error. A few minutes later you refresh those pages that gave an error and they come up fine... We've worked around it by using ulimit to increase the no. of available handles (per process, if I read the docs correctly) from the default 1024 to 8000, and haven't seen it happen again. So it looks like it is simply that from time to time we hit the limit on simultaneously open files, and by the time we try again a few minutes later some of the handles have been freed up again. The interesting thing (and the reason for my mail) is that at the time we're seeing the error, doing an lsof on that particular app server's process ID reveals hundreds of open file handles on cocoon.xconf So, my question is this - can anyone suggest why this configuration file keeps getting opened so much? It's almost as if every time a configurable sitemap component is called, it's opening the file again to check the default configuration, and not releasing the handle again until some time later (possibly once the response has all been sent). But given the file never changes from request to request (and I'd expect to restart the application if it ever did change anyway) I'd be astonished if it didn't just read parse it once at startup and pass the resulting object in to all the components rather than having them all do it. Can anyone confirm the file should only be opened once? (assuming there's nothing else accessing it outside of Cocoon) And, if so, can anyone think of a reason we're getting these problems in this particular environment? I'm just wary that if we were to move a bunch more sites onto this infrastructure, we might start hitting some global limit instead. Here's hoping... Andy. That sounds like a resource leak which is exposed by the way WS6 initializes the Cocoon servlet. But first thing to do is to check in your web.xml file that the cocoon.xconf reloading is disabled: !-- Allow reinstantiating (reloading) of the cocoon instance. If this is set to yes or true, a new cocoon instance can be created using the request parameter cocoon-reload. It also enables that Cocoon is reloaded when cocoon.xconf changes. Default is no for security reasons. -- init-param param-nameallow-reload/param-name param-valueno/param-value /init-param HTH, Alfred.
[jira] Commented: (COCOON-2031) Language Exception at Runtime by the attempt to compile a random XSP
[
https://issues.apache.org/jira/browse/COCOON-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586972#action_12586972
]
Alfred Nathaniel commented on COCOON-2031:
--
Peter, what is the difference between the *,java files? That should allow to
determine which logicsheet is not applied / applied out of order. Is that
always the same one? Which logicsheets are used in the failing XSP?
NB we are heavy users of XSPs on Cocoon 2.1.10 / Tomcat 4.1.23 / Java 1.5.0_14
/ Solaris 10, and have no problems anymore since the fix mentioned above.
Language Exception at Runtime by the attempt to compile a random XSP
Key: COCOON-2031
URL: https://issues.apache.org/jira/browse/COCOON-2031
Project: Cocoon
Issue Type: Bug
Components: Blocks: XSP
Affects Versions: 2.1.7
Reporter: Sebastian Wenzky
Priority: Critical
Hi there,
at my topic you have a first imagination about my current (very hard) problem.
But at fist, my enumeration of my software components:
- Cocoon 2.18
- JBoss (Version 4) - Tomcat.
Indeed, i have no explanation, for my confuse problem and i don´t know, what
kind of state occures that. Normally, when cocoon starts at first time there
are no problems. I can go, visit different pages (which will be correctly
compiled) and so on... But sometimes later the error occurs suddenly, without
any real worthwhile exception message to me.
But the tracer in cocoon said to me following text(an excerpt):
ERROR (2007-03-10) 07:44.24:308 [sitemap.handled-errors]
(/jobapp3/content/fhj/user.xsp$user-search$meta-html)
TP-Processor8/ErrorHandlerHelper: Language Exception
org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling
user_xsp:
ERROR 1 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
name,
name,
CDATA,
pst_id
// start error (lines 1044-1044) Syntax error, insert ) to complete
Expression
);
// end error
this.contentHandler.startElement(
http://apache.org/xsp/request/2.0;;,
...
ERROR 2 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
get-parameter,
xsp-request:get-parameter
);
// start error (lines 1063-1063) Syntax error on token ), delete this
token
);
// end error
if ( pstID != null )
{
...
Line 1044, column 0: Syntax error, insert ) to complete Expression
Line 1063, column 0: Syntax error on token ), delete this token
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.loadProgram(ProgramGeneratorImpl.java:409)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:280)
at
org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:385)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:620)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(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.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.SwitchSelectNode.invoke(SwitchSelectNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(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
[jira] Updated: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel updated COCOON-2065: - Fix Version/s: 2.1.12-dev (Current SVN) I applied the patch now also to 2.1.12-dev. huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN) Reporter: Dominique De Munck Assignee: Alfred Nathaniel Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel reassigned COCOON-2065: Assignee: Alfred Nathaniel huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN) Reporter: Dominique De Munck Assignee: Alfred Nathaniel Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: XSP block dependencies
On Mon, 2007-11-26 at 08:45 +0100, Reinhard Poetz wrote: The problem is that the groupId of the Avalon framework changed and that's the root of all evil in this case. We ever never need a dependency on Avalon 4.1.3 but how to express this in the managedDependencies section? The only chance for us is configuring exclusions but first you have to figure out that you have to do it at all (here the dependency module comes into play). I have also experienced very strange behaviour of the dependency resultion mechanism e.g. I exclude avalon-framework from being pulled in by commons-logging but then, when I use commons-beanutils, which pulls in commons-logging, the avalon-framework dependency is used again. TBH, I have no idea why the dependency resolution is still buggy after such a long time after the first final Maven 2 release :-/ I now added exclusion rules to all our explicit dependencies which pick up the old avalon-framework through transitive dependencies. Although that brings us out of jar hell for the moment, it is only a stop-gap solution. Any new explicit dependencies could bring back the problem. For once, it is not a fault of m2. It is doing the right thing. The problem is in the avalon-framework poms changing groupId and artefactId between versions. Maven should, however, provide a mechanism to deal with this globally in a parent pom. Here is the pedestrian approach I used to find the places where the exclusions needed to be inserted: 1.) rm -r $M2_REPO/avalon-framework 2.) fgrep avalon-framework-4 `find trunk -name .classpath` 3.) cd to first project directory containing a matching .classpath 4.) mvn -X eclipse:clean eclipse:eclipse 5.) Identify the explicit dependency with triggers the download of avalon-framework-4.1.3.pom. 6.) Add exclusion rule to that explicit dependency, e.g.: dependency groupIdcommons-httpclient/groupId artifactIdcommons-httpclient/artifactId + exclusions +exclusion + groupIdavalon-framework/groupId + artifactIdavalon-framework/artifactId +/exclusion + /exclusions /dependency 7.) mvn eclipse:clean eclipse:eclipse 8.) Rinse and repeat. Cheers, Alfred.
[jira] Closed: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-2065. Resolution: Fixed Please check 2.1.12-dev and reopen issue in case there is a problem. Thanks again for providing the patch. huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN) Reporter: Dominique De Munck Assignee: Alfred Nathaniel Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2165) PROCESSING BUG when using COCOON-PROTOCOL for TRANSFORMATION SRC and XSL:INCLUDE
[ https://issues.apache.org/jira/browse/COCOON-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-2165. Resolution: Won't Fix The xsl:include uses the same source resolver and default protocol used for reading the parent stylesheet. Therefore href=test_inc.xhtml is interpreted as cocoon:/test_inc.xhtml which is normalized to cocoon://test/test_inc.xhtml. To make your use case work, you have to either a) use an absolute file:protocol as in href=file:/home/user/path/to/test_inc.xhtml or b) add a match to your sitemap as map:match pattern=test_inc.xhtml map:generate src=test_inc.xhtml/ map:serialize type=xml/ /map:match Option b) is heavier as it goes once again through the Cocoon machinery for all includes but it avoids having an absolute path in the parent stylesheet. IIUC you try to use dynamically generated stylesheets. I can only recommend you to look for another way to solve your actual problem. Dynamic stylesheets will be difficult to debug, and you may run into problems that the stylesheets are either reloaded too often or not at all. If I misinterpret your intentations and you are not into dynamic stylesheets, then option c) is even simpler: map:match pattern=testD.html map:generate src=test_content.xhtml/ map:transform src=test_transform.xhtml map:serialize type=html/ /map:match HTH, Alfred. PROCESSING BUG when using COCOON-PROTOCOL for TRANSFORMATION SRC and XSL:INCLUDE Key: COCOON-2165 URL: https://issues.apache.org/jira/browse/COCOON-2165 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Robert Hoffmann Priority: Critical Hi cocoon developers, I found the following problem when using the cocoon-protocol in the src of map:transform, BUT ONLY if there is an xsl:include in the transforming xsl. 1)the sitemap map:pipeline !-- testA: simple transform test: WORKS -- map:match pattern=testA.html map:generate src=test_content.xhtml/ map:transform src=test_transform.xhtml/ map:serialize type=html/ /map:match !-- testB: 'dynamic' resource for test_transform.xhtml: WORKS -- !-- IMPORTANT: the include reference in 'test_transform.xhtml' causes the error! -- !-- IMPORTANT: Remove this include reference and it works -- map:match pattern=testB.html map:generate src=test_transform.xhtml/ map:serialize type=xml/ /map:match !-- testC: transform using 'dynamic' resource as transformer: FAILS -- !-- FAILS: but ONLY if there is a xsl:include reference in the transforming xsl -- map:match pattern=testC.html map:generate src=test_content.xhtml/ map:transform src=cocoon:/testB.html/ map:serialize type=html/ /map:match /map:pipeline 2) Exception: org.apache.cocoon.ProcessingException: Unable to get transformer handler for cocoon://test/testB.html?pipelinehash=2533989387103728471 at [TransformerException] - file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/test_transform.xhtml:11:38 at map:serialize type=html - file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/fooTest.xmap:27:33 at map:transform - file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/fooTest.xmap:26:46 at map:generate - file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/fooTest.xmap:25:45 at map:mount - file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/fooRootSitemap.xmap:77:92 Complete exception stack: http://cbio.mskcc.org/~hoffmann//pub/cocoon/a/cocoon_bug_report/error.txt 3) I provide links to all the mentioned files at: a) Individual files: http://cbio.mskcc.org/~hoffmann//pub/cocoon/a/cocoon_bug_report/ b) One archive: http://cbio.mskcc.org/~hoffmann//pub/cocoon/a/cocoon_bug_report.zip I hope this detailed test case will be helpful to one of the cocoon gurus... Many thanks!!! Robert PS: Cocoon really rocks! -- Have you tried iHOP yet? http://www.ihop-net.org/UniPub/iHOP/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Preparing the 2.1.1 release
On Tue, 2007-12-18 at 19:34 +0100, Carsten Ziegeler wrote: Hi, I'm planning to release 2.1.1 in the near future. So, are the any outstanding issues? Carsten I am not aware of any- Cheers, Alfred-
[jira] Commented: (COCOON-1990) Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount
[ https://issues.apache.org/jira/browse/COCOON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549708 ] Alfred Nathaniel commented on COCOON-1990: -- Vadim, sub-sitemap and root sitemap can be in the same directory. Only, before I put my hands on the code, cocoon:/ could not be used in the sub-sitemap (it would be interpreted as cocoon://). I am not completely sure that the latest version with the explicit check for cocoon:// works, because there may be additional effects due to the MutableEnvironmentFacade case. If that turns out to be the case, I propose to revert to the original version, which has been working for years, except for the recently discovered corner case. Jörg, I agree, that the hardwired cocoon:// check is not the most appealing solution. But given the facts that 2.1 is in maintenance mode, 2.2 already has a completely different code in that area, and people are discussion a deprecation of the cocoon; protocol, I am pragmatic and don't think it is worthwhile to invest much more effort on this. I only would want to have a working solution in 2.1.11. Of course, if you feel like it, you are welcome to do it better. Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount -- Key: COCOON-1990 URL: https://issues.apache.org/jira/browse/COCOON-1990 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: Robert Hoffmann Assignee: Alfred Nathaniel Fix For: 2.1.11-dev (Current SVN) Hi cocoon developers, I found the following problem with redirects within sub-sitemaps WHEN using the uri-prefix in map:mount... Test case: 1) Sitemaps: Root sitemap ... map:pipeline map:match pattern=test/** map:mount check-reload=yes src=subsitemap.xmap uri-prefix=test / /map:match /map:pipeline ... Sub sitemap ... map:match pattern=A.html map:redirect-to uri=cocoon:/B.html/ /map:match map:match pattern=B.html map:redirect-to uri=http://www.google.com/ /map:match ... 2) NOW: When you request http://testserver/cocoon/test/A.html;... you should get redirected to B.html WITHIN the sub sitemap (that's why we use 'cocoon:/B.html' and not 'cocoon://B.html')... BUT the redirect does NOT work correctly, hence we will not get the google-site which would be the correct result. 3) The cocoon.log says: http-11080-Processor23/CocoonServlet: No pipeline matched request: test/B.html !!! [So it seems to me that the uri-prefix from the sub-sitemap mount is added in the this redirect, which might be why it does not match then within the sub-sitemap.] 3) Important: This only goes wrong when using the uri-prefix[-remove] attribute in map:mount I hope this detailed test case will be helpful to one of the cocoon gurus... I really would hate if I had to use redirects to the ROOT sitemap (that's not the idea of sub sitemaps). Many thanks!!! Robert PS: Cocoon really rocks! -- Have you tried iHOP yet? http://www.ihop-net.org/UniPub/iHOP/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COCOON-1990) Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount
On Fri, 2007-12-07 at 23:09 -0500, Vadim Gritsenko wrote: On Dec 7, 2007, at 10:37 PM, Jörg Heinicke (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel #action_12549643 ] Jörg Heinicke commented on COCOON-1990: --- Also I don't like the idea of checking for a particular protocol. In theory somebody could have implemented its own protocol doing something similar as cocoon://. You do not even need a theory :) Simply edit cocoon.xconf, and use any protocol you like. component-instance name=sitemap class=org.apache.cocoon.components.source.impl.SitemapSourceFactory/ Vadim Unfortunately, that is only a theoretical possibility. There are already 11 places where startsWith(cocoon:) is hardwired in the code. Cheers, Alfred.
[jira] Closed: (COCOON-1990) Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount
[ https://issues.apache.org/jira/browse/COCOON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-1990. Resolution: Fixed That was a weird way to find out, whether it was a redirect to the root sitemap. I now put in a direct check: ConcreteTreeProcessor processor = this; if (uri.startsWith(cocoon://)) processor = ((TreeProcessor)getRootProcessor()).concreteProcessor; Please try again if that also fixes your use case. If not, we should revert to the old code. That works except for the easy-to-avoid case of root sitemap and sub-sitemap placed in the same directory. Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount -- Key: COCOON-1990 URL: https://issues.apache.org/jira/browse/COCOON-1990 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: Robert Hoffmann Assignee: Alfred Nathaniel Fix For: 2.1.11-dev (Current SVN) Hi cocoon developers, I found the following problem with redirects within sub-sitemaps WHEN using the uri-prefix in map:mount... Test case: 1) Sitemaps: Root sitemap ... map:pipeline map:match pattern=test/** map:mount check-reload=yes src=subsitemap.xmap uri-prefix=test / /map:match /map:pipeline ... Sub sitemap ... map:match pattern=A.html map:redirect-to uri=cocoon:/B.html/ /map:match map:match pattern=B.html map:redirect-to uri=http://www.google.com/ /map:match ... 2) NOW: When you request http://testserver/cocoon/test/A.html;... you should get redirected to B.html WITHIN the sub sitemap (that's why we use 'cocoon:/B.html' and not 'cocoon://B.html')... BUT the redirect does NOT work correctly, hence we will not get the google-site which would be the correct result. 3) The cocoon.log says: http-11080-Processor23/CocoonServlet: No pipeline matched request: test/B.html !!! [So it seems to me that the uri-prefix from the sub-sitemap mount is added in the this redirect, which might be why it does not match then within the sub-sitemap.] 3) Important: This only goes wrong when using the uri-prefix[-remove] attribute in map:mount I hope this detailed test case will be helpful to one of the cocoon gurus... I really would hate if I had to use redirects to the ROOT sitemap (that's not the idea of sub sitemaps). Many thanks!!! Robert PS: Cocoon really rocks! -- Have you tried iHOP yet? http://www.ihop-net.org/UniPub/iHOP/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-1990) Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount
[ https://issues.apache.org/jira/browse/COCOON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel reassigned COCOON-1990: Assignee: Alfred Nathaniel Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount -- Key: COCOON-1990 URL: https://issues.apache.org/jira/browse/COCOON-1990 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: Robert Hoffmann Assignee: Alfred Nathaniel Hi cocoon developers, I found the following problem with redirects within sub-sitemaps WHEN using the uri-prefix in map:mount... Test case: 1) Sitemaps: Root sitemap ... map:pipeline map:match pattern=test/** map:mount check-reload=yes src=subsitemap.xmap uri-prefix=test / /map:match /map:pipeline ... Sub sitemap ... map:match pattern=A.html map:redirect-to uri=cocoon:/B.html/ /map:match map:match pattern=B.html map:redirect-to uri=http://www.google.com/ /map:match ... 2) NOW: When you request http://testserver/cocoon/test/A.html;... you should get redirected to B.html WITHIN the sub sitemap (that's why we use 'cocoon:/B.html' and not 'cocoon://B.html')... BUT the redirect does NOT work correctly, hence we will not get the google-site which would be the correct result. 3) The cocoon.log says: http-11080-Processor23/CocoonServlet: No pipeline matched request: test/B.html !!! [So it seems to me that the uri-prefix from the sub-sitemap mount is added in the this redirect, which might be why it does not match then within the sub-sitemap.] 3) Important: This only goes wrong when using the uri-prefix[-remove] attribute in map:mount I hope this detailed test case will be helpful to one of the cocoon gurus... I really would hate if I had to use redirects to the ROOT sitemap (that's not the idea of sub sitemaps). Many thanks!!! Robert PS: Cocoon really rocks! -- Have you tried iHOP yet? http://www.ihop-net.org/UniPub/iHOP/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1990) Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount
[
https://issues.apache.org/jira/browse/COCOON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546916
]
Alfred Nathaniel commented on COCOON-1990:
--
Your case does not work only because the sub-sitemap is in the same directory
as the root sitemap. If you move it to a sub-directory as in
map:mount check-reload=yes src=subdir/test_sub_sitemap.xmap
uri-prefix=test /
then it works. The problem is here in ConcreteTreeProcessor:
// Get the processor that should process this request
ConcreteTreeProcessor processor;
! if (newEnv.getRootContext().equals(newEnv.getContext())) {
processor = ((TreeProcessor)getRootProcessor()).concreteProcessor;
} else {
processor = this;
}
In 2.2 that reads (already since 2004):
// Get the processor that should process this request
ConcreteTreeProcessor processor;
! if ( newEnv.getURIPrefix().equals() ) {
processor = ((TreeProcessor)getRootProcessor()).concreteProcessor;
} else {
processor = this;
}
I don't have the time right now to backport that fix to 2.1. I'll do it later
if nobody else steps in beforehand.
Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount
--
Key: COCOON-1990
URL: https://issues.apache.org/jira/browse/COCOON-1990
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.10
Reporter: Robert Hoffmann
Assignee: Alfred Nathaniel
Hi cocoon developers,
I found the following problem with redirects within sub-sitemaps WHEN using
the uri-prefix in map:mount...
Test case:
1) Sitemaps:
Root sitemap
...
map:pipeline
map:match pattern=test/**
map:mount check-reload=yes src=subsitemap.xmap uri-prefix=test /
/map:match
/map:pipeline
...
Sub sitemap
...
map:match pattern=A.html
map:redirect-to uri=cocoon:/B.html/
/map:match
map:match pattern=B.html
map:redirect-to uri=http://www.google.com/
/map:match
...
2) NOW: When you request http://testserver/cocoon/test/A.html;...
you should get redirected to B.html WITHIN the sub sitemap (that's why we use
'cocoon:/B.html' and not 'cocoon://B.html')...
BUT the redirect does NOT work correctly, hence we will not get the
google-site which would be the correct result.
3) The cocoon.log says: http-11080-Processor23/CocoonServlet: No pipeline
matched request: test/B.html !!!
[So it seems to me that the uri-prefix from the sub-sitemap mount is added in
the this redirect, which might be why it does not match then within the
sub-sitemap.]
3) Important: This only goes wrong when using the uri-prefix[-remove]
attribute in map:mount
I hope this detailed test case will be helpful to one of the cocoon gurus...
I really would hate if I had to use redirects to the ROOT sitemap (that's not
the idea of sub sitemaps).
Many thanks!!!
Robert
PS: Cocoon really rocks!
--
Have you tried iHOP yet? http://www.ihop-net.org/UniPub/iHOP/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
On Thu, 2007-11-15 at 09:41 -0500, Carsten Ziegeler wrote: If I get enough positive feedback about the current state I'm happy to prepare a release of 2.1.11 in December. WDYT? Carsten +1 Cheers, Alfred.
Re: [VOTE] Division of Cocoon's JIRA project
On Sun, 2007-08-19 at 17:44 +0200, Reinhard Poetz wrote: What I mean is that one release cycle should have one Jira project. As soon as we have two modules that have _different_ release cycles and managed by _one_ Jira project, I don't understand what we gain compared to the status quo. Personally, I don't believe that the idea of different release cycles will fly for very long. In the end there will be the same sort of problems getting a grip on the version compatibilities which made the Eclipse people invent the Callisto approach. And with 100 open JIRA issues, I don't see the necessity of splitting into smaller parts. Splitting also assumes that the reporting user is able to pinpoint the part where his particular problems stems from. If he makes a mistake there, we can correct it by changing the project to which it refers -- but that breaks each time the URL. So here's my -0. Cheers, Alfred.
Re: Default Expression Language
On Sun, 2007-08-19 at 21:20 +0200, Daniel Fagerstrom wrote: Thanks to Grzegorz efforts, we are now close to be able to use the same exprssion language and object model both in the sitemap and in templates. The whole thing is plugable, so those who have large investments in the current syntax and models can continue using them. But while flexibillity is good for back compability it is confusing for new users. So we should try hard to decide what should be the default expression language and expression syntax. Once I preffered JXPath as my webapps where XML-centric and I used XSLT and XPath everywhere. But now my webapps is more Java based, so JEXL or JS seem more natural. Of these I prefer JEXL as JS is a little bit to powerful as an EL for my taste. But is the rest of world really using JEXL, JS or JXPath as ELs? Wouldn't it be a better idea to use the Unified Expression Language (EL) of JSP 2.1 (JSR-245) (http://en.wikipedia.org/wiki/Unified_Expression_Language). To me it seem like a rather good EL and there are several Apache licenced implementations, Tomcat has one and there is another one called JUEL http://juel.sourceforge.net/. WDYT? /Daniel Maybe there is no good default at all! How about specifying in the sitemap which expression language is used in it? And if this specification is missing, the default is the good old input module. Cheers, Alfred.
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
On Sat, 2007-08-11 at 11:22 +0200, Grzegorz Kossakowski wrote:
Speaking about myself I prefer much more language prefixes and I think we
should go for it. The
question that we need to answer is if we want to support #{} syntax in
sitemap? Since it was never
there I don't think it makes sense to do so.
I also don't see the benefit of extending the sitemap syntax. The
existing {input-module:parameter} syntax is flexible enough to support
{jexl:cocoon.request.some_param} and {jxpath:cocoon/request/some_param},
and that is not much harder to read or write than the ${} and #{}
equivalents.
Besides it avoids all problems where you would want to have a literal $
or # immediately followed by an input module expression. (Although I
cannot think just now of an example where that would occur.)
Cheers, Alfred.
[jira] Closed: (COCOON-2098) [PATCH] Argument quoting in build.sh
[ https://issues.apache.org/jira/browse/COCOON-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-2098. Resolution: Fixed Assignee: Alfred Nathaniel Patch applied, thanks. Does not apply to 2.2 trunk. [PATCH] Argument quoting in build.sh Key: COCOON-2098 URL: https://issues.apache.org/jira/browse/COCOON-2098 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven Affects Versions: 2.1.11-dev (Current SVN) Reporter: Andreas Deininger Assignee: Alfred Nathaniel Priority: Trivial Fix For: 2.1.11-dev (Current SVN) Attachments: COCOON-2098.diff If build.sh is called with something like: ./build.sh -propertyfile $PROJECT_PROPERTIES ... the build fails if PROJECT_PROPERTIES=/path/ with/spaces/to/local.build.properties The uploaded patch cures that problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vote] Let our environment abtractions extend the http servlet ones
On Tue, 2007-08-07 at 09:46 +0200, Daniel Fagerstrom wrote: Unfortunately it is more complicated than that. The non-compatible change is that Request.getSession switches return value from o.a.c.environment.Session to javax.servlet.http.HttpSession and that Request.getCookie switch return value from o.a.c.environment.Cookie to javax.servlet.http.Cookie. You, of course, cannot have a method with two different return types. So there is no point in deprecating Request.getSession and Request.getCookie in 2.2 as we not will have any replacements until 2.3 in that case. So the deprecation mechanism is AFAICS not applicable. How about this: 1.) In 2.1.11 add Request.getCocoonSession and Request.getCocoonCookie and deprecate the current methods. 2.) In 2.2 let o.a.c.e.XXX extend the standard interfaces, change return types of getXXX methods and deprecate getCocoonXXX methods. 3.) In 2.3 remove getCocoonXXX and o.a.c.e.XXX. That allows for a smoother transition path for user components because they can be made forwards compatible to work for both 2.1.11+ and 2.2 (if Session/Cookie is the only incompatibility?). In any case, I am -1 on creating a 2.3 branch in the near future. First we must get out 2.2 and let it season on trunk to reach production quality. The parallel maintenance and forward and backward porting between 2.1 and 2.2 was a terrible resource drain which we should try to avoid as far as possible. Cheers, Alfred.
Re: 2.2 does not build with JDK1.4.2
On Mon, 2007-07-16 at 14:32 -0400, Joerg Heinicke wrote: Can somebody please try out to add this dependency explicitly or exclude it if we don't need it. I added the transtive dependencies to the two POMs which needed them. Now the build runs through and also the samples work again. The endorsed problem I had before has vanished by itself. Sigh - this habit of unreproducable behaviour is a real pain with 2.2 Cheers, Alfred.
Re: 2.2 does not build with JDK1.4.2
On Wed, 2007-07-11 at 07:50 +0200, Carsten Ziegeler wrote:
Hi,
did you try maven 2.0.7 with jdk 1.4.2?
While building Cocoon with 2.0.7 and jdk1.5, I noticed that the version
for the spring-dao was resolved to 2.0.4which fortunately is
available :(
Carsten
Nope, same problem with maven 2.0.7.
Actually in Jan you filed yourself a bugreport
http://jira.codehaus.org/browse/MNG-2782 where ${project.version} was
resolved to 2.4.1. (You were then still using JDK1.4.2?)
Reading http://docs.codehaus.org/display/MAVEN/Refactoring+Interpolation
I gather the problem it is deeply rooted in maven and may be tackled
only with maven 2.1.x.
As it seems, it affects only transitive dependencies. So a possible
workaround is to spell out these dependencies in our own poms.
There are just two poms to patch:
cocoon-databases-impl:
dependency
groupIdorg.springframework/groupId
artifactIdspring-dao/artifactId
version2.0.6/version
/dependency
cocoon-javaflow-impl:
dependency
groupIdasm/groupId
artifactIdasm-util/artifactId
version2.2.1/version
/dependency
dependency
groupIdasm/groupId
artifactIdasm-attrs/artifactId
version2.2.1/version
/dependency
dependency
groupIdasm/groupId
artifactIdasm-analysis/artifactId
version2.2.1/version
/dependency
dependency
groupIdasm/groupId
artifactIdasm-tree/artifactId
version2.2.1/version
/dependency
Then the build runs through successfully (after increasing max memory to
-Xmx250m). There are still trace messages Downloading:
http://repo1.maven.org/maven2/org/springframework/spring-dao/2.4.1/spring-dao-2.4.1.pom
which seem to be harmless.
However, the server does not run properly. The homepage still loads but
http://localhost:/samples/ aborts with
java.lang.NoSuchMethodError:
javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node;
at
org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:199)
at
org.apache.xalan.transformer.TransformerIdentityImpl.setDocumentLocator(TransformerIdentityImpl.java:880)
at
org.apache.cocoon.xml.AbstractXMLPipe.setDocumentLocator(AbstractXMLPipe.java:39)
at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown
Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown
Source)
at
org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source)
at
org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:196)
at
org.apache.cocoon.core.xml.avalon.DefaultSAXParser.parse(DefaultSAXParser.java:47)
at
org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:127)
at
org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:180)
at
org.apache.cocoon.components.source.util.SourceUtil.toDOM(SourceUtil.java:309)
at
org.apache.cocoon.generation.XPathTraversableGenerator.performXPathQuery(XPathTraversableGenerator.java:220)
at
org.apache.cocoon.generation.XPathTraversableGenerator.addContent(XPathTraversableGenerator.java:196)
at
org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGenerator.java:482)
at
org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGenerator.java:464)
at
org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGenerator.java:464)
at
org.apache.cocoon.generation.TraversableGenerator.addAncestorPath(TraversableGenerator.java:383)
at
org.apache.cocoon.generation.TraversableGenerator.generate(TraversableGenerator.java:321)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy6.generate(Unknown Source)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:363)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:437)
at
Re: Can't build trunk
On Tue, 2007-07-10 at 23:03 -0700, Ralph Goers wrote: I checked out the latest and ran mvn -Dmaven.test.skip=true -P allblocks install on Windows using Maven 2.0.6 and Java 1.6.0_01. Any ideas? Missing: -- 1) org.apache.cocoon:cocoon-rcl-webapp-wrapper:jar:1.0.0-RC1-SNAPSHOT Need to build it manually: cd tools mvn install (Maybe http://svn.apache.org/viewvc?view=revrev=555201 fixes that already?) HTH, Alfred.
2.2 does not build with JDK1.4.2
There seems to be a Maven-intrinsic problem with building trunk using a
1.4.2 JVM. With maven version 2.0.6 and the command line
$ MAVEN_OPTS=-Xmx200m
$ export MAVEN_OPTS
$ mvn -Dmaven.test.skip=true -P allblocks clean install
I get consistent build failures for cocoon-databases-impl
[INFO] Failed to resolve artifact.
Missing:
--
1) org.springframework:spring-dao:jar:2.4.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.springframework
-DartifactId=spring-dao \
-Dversion=2.4.1 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1)
org.apache.cocoon:cocoon-databases-impl:jar:1.0.0-RC2-SNAPSHOT
2) org.springframework:spring-jdbc:jar:2.0.6
3) org.springframework:spring-dao:jar:2.4.1
--
1 required artifact is missing.
for artifact:
org.apache.cocoon:cocoon-databases-impl:jar:1.0.0-RC2-SNAPSHOT
The version number 2.4.1 for spring-dao is phoney, the latest version
being 2.0.6. The dependency in the spring-jdbc pom.xml is simply:
dependency
groupId${project.groupId}/groupId
artifactIdspring-dao/artifactId
version${project.version}/version
/dependency
This seems to be an incarnation of
http://jira.codehaus.org/browse/MNG-2653
I see this with Sun JDK1.4.2_13 on Linux. (Is it by chance that 2.4.1
is 1.4.2 spelled backwards?) With JDK1.5.0_09 the build runs through.
More fuel for the discussion on 1.4 vs 1.5 as minimum JVM for 2.2...
Cheers, Alfred.
Re: [vote] Grzegorz Kossakowski as a new Cocoon committer
On Thu, 2007-02-22 at 17:36 +0100, Daniel Fagerstrom wrote: Hi all! I'd like to propose Grzegorz Kossakowski (aka Grek) as a new Cocoon committer. He has been around at the user list since 2003 and has been very active at the dev list the last months. He has provided a number of high quality patches and in depth design discussions in complicated areas. Please cast your votes. /Daniel +1 Cheers, Alfred.
Re: [graphics] Masthead artwork for cocoon.apache.org
On Sat, 2007-01-20 at 10:39 +0800, Thien wrote: No worries, it actually helps a lot :D I will improve the design further once a final one has been picked. (#2 or #3 so far.) My favorite is #2. Cheers, Alfred.
[jira] Updated: (COCOON-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline
[ https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel updated COCOON-1985: - A Java thread cannot deadlock with itself. Which is the other thread which holds the lock, and what is it waiting for? AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline --- Key: COCOON-1985 URL: https://issues.apache.org/jira/browse/COCOON-1985 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.9, 2.1.10, 2.1.11-dev (Current SVN) Reporter: Ellis Pritchard Priority: Critical Attachments: includer.xsl, patch.txt, sitemap.xmap Cocoon 2.1.9 introduced the concept of a lock in AbstractCachingProcessingPipeline, an optimization to prevent two concurrent requests from generating the same cached content. The first request adds the pipeline key to the transient cache to 'lock' the cache entry for that pipeline, subsequent concurrent requests wait for the first request to cache the content (by Object.lock()ing the pipeline key entry) before proceeding, and can then use the newly cached content. However, this has introduced an incompatibility with the IncludeTransformer: if the inclusions access the same yet-to-be-cached content as the root pipeline, the whole assembly hangs, since a lock will be made on a lock already held by the same thread, and which cannot be satisfied. e.g. i) Root pipeline generates using sub-pipeline cocoon:/foo.xml ii) the cocoon:/foo.xml sub-pipeline adds it's pipeline key to the transient store as a lock. iii) subsequently in the root pipeline, the IncludeTransformer is run. iv) one of the inclusions also generates with cocoon:/foo.xml, this sub-pipeline locks in AbstractProcessingPipeline.waitForLock() because the sub-pipeline key is already present. v) deadlock. I've found a (partial, see below) solution for this: instead of a plain Object being added to the transient store as the lock object, the Thread.currentThread() is added; when waitForLock() is called, if the lock object exists, it checks that it is not the same thread before attempting to lock it; if it is the same thread, then waitForLock() returns success, which allows generation to proceed. You loose the efficiency of generating the cache only once in this case, but at least it doesn't hang! With JDK1.5 this can be made neater by using Thread#holdsLock() instead of adding the thread object itself to the transient store. See patch file. However, even with this fix, parallel includes (when enabled) may still hang, because they pass the not-the-same-thread test, but fail because the root pipeline, which holds the initial lock, cannot complete (and therefore statisfy the lock condition for the parallel threads), before the threads themselves have completed, which then results in a deadlock again. The complete solution is probably to avoid locking if the lock is held by the same top-level Request, but that requires more knowledge of Cocoon's processing than I (currently) have! IMHO unless a complete solution is found to this, then this optimization should be removed completely, or else made optional by configuration, since it renders the IncludeTransformer dangerous. -- 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-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline
[ https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alfred Nathaniel closed COCOON-1985. Resolution: Fixed Fix Version/s: 2.1.11-dev (Current SVN) Oops, deadlock in lock.wait is possible, of course. Patch applied. Thanks for the detailed analysis. AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline --- Key: COCOON-1985 URL: https://issues.apache.org/jira/browse/COCOON-1985 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.9, 2.1.10, 2.1.11-dev (Current SVN) Reporter: Ellis Pritchard Priority: Critical Fix For: 2.1.11-dev (Current SVN) Attachments: includer.xsl, patch.txt, sitemap.xmap Cocoon 2.1.9 introduced the concept of a lock in AbstractCachingProcessingPipeline, an optimization to prevent two concurrent requests from generating the same cached content. The first request adds the pipeline key to the transient cache to 'lock' the cache entry for that pipeline, subsequent concurrent requests wait for the first request to cache the content (by Object.lock()ing the pipeline key entry) before proceeding, and can then use the newly cached content. However, this has introduced an incompatibility with the IncludeTransformer: if the inclusions access the same yet-to-be-cached content as the root pipeline, the whole assembly hangs, since a lock will be made on a lock already held by the same thread, and which cannot be satisfied. e.g. i) Root pipeline generates using sub-pipeline cocoon:/foo.xml ii) the cocoon:/foo.xml sub-pipeline adds it's pipeline key to the transient store as a lock. iii) subsequently in the root pipeline, the IncludeTransformer is run. iv) one of the inclusions also generates with cocoon:/foo.xml, this sub-pipeline locks in AbstractProcessingPipeline.waitForLock() because the sub-pipeline key is already present. v) deadlock. I've found a (partial, see below) solution for this: instead of a plain Object being added to the transient store as the lock object, the Thread.currentThread() is added; when waitForLock() is called, if the lock object exists, it checks that it is not the same thread before attempting to lock it; if it is the same thread, then waitForLock() returns success, which allows generation to proceed. You loose the efficiency of generating the cache only once in this case, but at least it doesn't hang! With JDK1.5 this can be made neater by using Thread#holdsLock() instead of adding the thread object itself to the transient store. See patch file. However, even with this fix, parallel includes (when enabled) may still hang, because they pass the not-the-same-thread test, but fail because the root pipeline, which holds the initial lock, cannot complete (and therefore statisfy the lock condition for the parallel threads), before the threads themselves have completed, which then results in a deadlock again. The complete solution is probably to avoid locking if the lock is held by the same top-level Request, but that requires more knowledge of Cocoon's processing than I (currently) have! IMHO unless a complete solution is found to this, then this optimization should be removed completely, or else made optional by configuration, since it renders the IncludeTransformer dangerous. -- 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
Re: [continuum] BUILD FAILURE: Apache Cocoon
To get around this problem: cd trunk/tools/cocoon-maven-reports mvn install But how to express that to happen automatically in trunk/pom.xml ? Cheers, Alfred. On Wed, 2007-01-17 at 00:07 +, [EMAIL PROTECTED] wrote: Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1700 Build statistics: State: Failed Previous State: Ok Started at: Wed, 17 Jan 2007 00:07:06 + Finished at: Wed, 17 Jan 2007 00:07:12 + Total time: 5s Build Trigger: Schedule Exit code: 1 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes cziegeler Add support for checkstyle report generation /cocoon/trunk/pom.xml /cocoon/trunk/tools/cocoon-maven-reports /cocoon/trunk/tools/cocoon-maven-reports/pom.xml /cocoon/trunk/tools/cocoon-maven-reports/src /cocoon/trunk/tools/cocoon-maven-reports/src/main /cocoon/trunk/tools/cocoon-maven-reports/src/main/resources /cocoon/trunk/tools/cocoon-maven-reports/src/main/resources/org /cocoon/trunk/tools/cocoon-maven-reports/src/main/resources/org/apache /cocoon/trunk/tools/cocoon-maven-reports/src/main/resources/org/apache/cocoon /cocoon/trunk/tools/cocoon-maven-reports/src/main/resources/org/apache/cocoon/maven /cocoon/trunk/tools/cocoon-maven-reports/src/main/resources/org/apache/cocoon/maven/reports /cocoon/trunk/tools/cocoon-maven-reports/src/main/resources/org/apache/cocoon/maven/reports/checkstyle-header.txt /cocoon/trunk/tools/cocoon-maven-reports/src/main/resources/org/apache/cocoon/maven/reports/checkstyle.xml /cocoon/trunk/tools/pom.xml cziegeler Fix header file /cocoon/trunk/tools/cocoon-maven-reports/src/main/resources/org/apache/cocoon/maven/reports/checkstyle-header.txt cziegeler Use same header in all files! /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/BlockResourcesHolder.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/ResourceUtils.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/WebAppContextUtils.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/AbstractElementParser.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/AbstractSettingsBeanFactoryPostProcessor.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/AbstractSettingsElementParser.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/ChildSettingsBeanFactoryPostProcessor.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/ChildSettingsElementParser.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/ChildXmlWebApplicationContext.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/ConfiguratorNamespaceHandler.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/Constants.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DefaultBlockResourcesHolder.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/DeploymentUtil.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/ExtendedPropertyOverrideConfigurer.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/RunningModeHelper.java /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/ServletContextFactoryBean.java
[jira] Closed: (COCOON-1980) Build error with Java 6
[
https://issues.apache.org/jira/browse/COCOON-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alfred Nathaniel closed COCOON-1980.
Resolution: Fixed
Fix Version/s: 2.1.11-dev (Current SVN)
Added dummy implementations of JDBC4 unwrap / isWrapperFor methods.
http://svn.apache.org/viewvc?view=revrev=495744
Build error with Java 6
---
Key: COCOON-1980
URL: https://issues.apache.org/jira/browse/COCOON-1980
Project: Cocoon
Issue Type: Bug
Components: Blocks: Databases
Affects Versions: 2.1.10
Reporter: Markus Wolf
Priority: Minor
Fix For: 2.1.11-dev (Current SVN)
Building the database block with Java 6 results in the following exception:
.../cocoon-2.1.10/src/blocks/databases/java/org/apache/cocoon/databases/ibatis/ExcaliburDataSourceFactory.java:82:
org.apache.cocoon.databases.ibatis.ExcaliburDataSourceFactory.DataSourceWrapper
is not abstract and does not override abstract method
isWrapperFor(java.lang.Class?) in java.sql.Wrapper
protected static final class DataSourceWrapper implements DataSource {
^
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
BUILD FAILED
--
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] Commented: (COCOON-1624) reader caching does not consider mime-type
[ https://issues.apache.org/jira/browse/COCOON-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464049 ] Alfred Nathaniel commented on COCOON-1624: -- ... or simply flush the pipeline cache whenever the sitemap is reloaded. There can be many more sitemap changes which may affect the pipeline output but are too rare/difficult to include in the cache validity calculation. reader caching does not consider mime-type -- Key: COCOON-1624 URL: https://issues.apache.org/jira/browse/COCOON-1624 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jörg Heinicke Assigned To: Cocoon Developers Team Changing the mime type on a reader in a caching pipeline does not invalidate its former usage with another mime type. Sample: map:match pattern=form1.xul map:read src=forms/form1_template.xul mime-type=text/xml/ /map:match changed to map:match pattern=form1.xul map:read src=forms/form1_template.xul mime-type=application/vnd.mozilla.xul+xml/ /map:match still results in delivery with text/xml. Carsten already saw it at the hackathon when I played around with XUL. Jörg -- 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
Re: WildcardMatcherHelper caching issue
On Fri, 2007-01-05 at 13:45 +0100, Bruno Dumon wrote:
Hi,
I noticed the new WildcardMatcherHelper class holds an internal static
map for caching. In the older solution, it was up to the caller to cache
the compiled pattern (similar to how regexp libraries work). This had
the advantage that the caller itself can decide whether the pattern
should be cached. It also avoids a potential memory leak if this code is
used to evaluate always-changing patterns, and avoids the need to do
hashmap lookups.
So I'm wondering if anyone would mind if I change it back so that caller
caches the pattern?
Thanks for any input.
The integrated cache is a convenience for the many client who repeated
match the same pattern and gain performance without having to code their
own cache management.
If you have an application where you will be matching a lot of one-shot
patterns, you could add
public static Map match(String pat, String str, Map cache)
which can be called with a null Map to by-pass caching. The old
signature then becomes simply
public static Map match(String pat, String str) {
return match(pat, str, cache);
}
The built-in cache could also use a WeakHashMap to avoid ever-increasing
memory consumption.
Cheers, Alfred.
Re: [Vote] Release 2.1.10
+1 Cheers, Alfred.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Tue, 2006-12-19 at 02:50 -0600, Antonio Gallardo wrote: Also given the current status, I am wondering if we should reconsider java 1.4 as the minimum for cocoon 2.2. We should keep in mind java 1.6 is out, hence if we agree to have java 1.4 as minimum we will have to support it for the next 2 years or so (based on the current release time). Thinking in 2 years for now. I wonder who will still be using java 1.4 and hence we will met the same issue as today, isn't? AT may day job we recently switched to Java5, and I started to convert the code base. Generics are useful to better understand code which makes extensive use of Lists and Maps, and the new for-loop I find really neat. But it is only syntactic sugar. I don't see a killer feature to justify giving up just yet compatibility to 1.4, which is still the production JVM version for many enterprises (including the one I work for). In order to avoid the same squeeze we are in atm for 2.1/1.3 we should call *the next big thing* Cocoon 3.0. Then we can close 2.2 and start 2.3 with 1.5 as minimum JVM whenever it makes sense. Cheers, Alfred. PS congrats for you little boy.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Mon, 2006-12-18 at 16:24 +0100, Reinhard Poetz wrote: Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. I agree. I agree, too. The last thing I want is to hold up the 2.1.10. If I had known what I stirred up here, I would not have started it. I apologize for the short time for discusion and vote but the idea was to get it into 2.1.10. Otherwise it will stay forever. Personally I think trunk is still too immature and unapproachable that there must a way open for 2.1.11+ release. I have nothing against staying JDK1.3 compatible, only I doubt that is is still useful. I think it is simply a non-issue, and we are making life unnecessarily hard for ourselves. Hands up, who has still a working 1.3 JVM on his computer to support it? If we weren't nailed down with trunk == 2.2, it would be sensible to save face by calling the 2.1.1 already 2.2. But that is too late now... I am not so firm in ASF rules. Does the one who called the vote have the right to withdraw the motion? Or does somebody else want to call a vote to undo this vote? Cheers, Alfred.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
I counted 6 binding +1, 1 binding -0, and 2 non-binding +1. The proposal is accepted. I'll put a note into status.xml. Cheers, Alfred.
[VOTE] Drop JDK1.3 support after 2.1.10 release
The current mantra is that Cocoon 2.1 is JDK1.3+ compatible and only from Cocoon 2.2 onwards JDK1.4+ is required. However, nowadays all developers use 1.4, or 5.0, or soon even 6.0. That makes it tedious to guarantee 1.3 support because Java compilers allow to set source file compatibility but they do not check API versions. (For example, RuntimeException(String, Throwable) is a 1.4 addition.) This errors are usually easy to fix but always leave a bad taste of unkept promisses when they go unnoticed by committers and are pointed out by users. I therefore propose to declare 2.1.10 the last release with JDK1.3 compatibility. In case there are really any JDK1.3 locked-in users who deploy 2.1.10 and find showstopper bugs, we create a BRANCH_2_1_10_X where point patches can be applied. That may possibly lead to a consolidated 2.1.10.1 maintenance release. Please cast your votes. Here is my +1. Cheers, Alfred.
Re: Looking for help in upcoming release
On Mon, 2006-12-11 at 14:55 +0100, Carsten Ziegeler wrote: 7. Make sure you describe your test environment: Platform and JVM, including version numbers. The following blocks do not compile with Sun JDK 1.3.1_19: -- databases: import javax.sql cannot be resolved -- imageop: import javax.imageio cannot be resolved -- portal: constructor RuntimeException(String, ServiceException) is undefined (twice in StandardPortalApplication.java) NB this is only compilation in Eclipse using the 1.3 rt.jar. I failed to get the 1.3 JVM running on my Ubuntu Dapper Drake due a missing shared library. Is anyone of the committers really still using JDK1.3? If not, shouldn't promise support for something nobody is using. Shall we say that 2.1.10 is the last 1.3 compatible release? Or even that 2.1.9 is already the last one? Cheers, Alfred.
VOTE: delete WildcardHelper from 2.1.x (was [2.1.10] WildcardHelperTestCase fails)
On Fri, 2006-12-08 at 08:13 +0100, Carsten Ziegeler wrote: WildcardHelper is now no longer used in 2.1. Should we remove it together with WildcardHelperTestCase? That breaks private Cocoon components which may still use it but IMHO that is better than just giving a depracation warning. (Friends don't let friends use broken WildcardHelper.) WildcardMatcherHelper is not a drop-in replacement of WildcardHelper but easy enough to use. WDYT? Hmm, yes, this seems logical - on the other hand there might be people relying on the bugs in the code :) I think you should start a vote on this and hopefully we get the buggy code out of 2.1.10. Carsten Here we go: I propose to delete the obsolete BRANCH_2_1_X/src/java/org/apache/cocoon/matching/helpers/WildcardHelper.java and the related test case. Please cast your votes. Cheers, Alfred.
Re: [RT] Improved matching selecting
On Fri, 2006-12-08 at 14:07 -0800, Mark Lundquist wrote: ... I think we should use two different keywords because otherwise the content model depends on the presence of various attributes and not on the tagname only -- that is really confusing. To my mind, a special element to distinguish conditionals having exactly 1 alternative is no more desirable than a special element to distinguish conditionals having exactly two alternatives, or three, or any other number; that is to say, not desirable at all. In the scheme I've proposed, it's very easy (and to me, natural) to tell how many alternatives a matcher has. best regards, —ml— Could you try to write a Relax NG schema sniplet (preferable in compact notation) for validating your proposed syntax? Cheers, Alfred.
Re: [2.1.10] WildcardHelperTestCase fails
On Wed, 2006-12-06 at 08:34 +0100, Carsten Ziegeler wrote: Ok, I removed the usage of the deprecated matching code and replaced it with using the new matcher. In addition I removed the duplicate test case for the WildcardHelper class and commented out the failing test in the remaining test case. Thanks Carsten, WildcardHelper is now no longer used in 2.1. Should we remove it together with WildcardHelperTestCase? That breaks private Cocoon components which may still use it but IMHO that is better than just giving a depracation warning. (Friends don't let friends use broken WildcardHelper.) WildcardMatcherHelper is not a drop-in replacement of WildcardHelper but easy enough to use. WDYT? Cheers, Alfred.
Re: [2.1.10] WildcardHelperTestCase fails
On Tue, 2006-12-05 at 11:02 +0100, Carsten Ziegeler wrote:
Afaik, the code for the wildcard helper has been replaced after that by
someone else.
Carsten
Bertrand Delacretaz wrote:
Just tried to run the junit tests on BRANCH_2_1_X, and the second
assertion in WildcardHelperTestCase fails:
public void testEndPattern() throws Exception {
WildcardHelper is rotten and has been deprecated in favor of
WildcardMatcherHelper.
However, WildcardHelper is still used by CocoonBean and portal's
UserRightService. Anyone who knows these two classes and could clean
them out?
Also there are two distinct copies of WildcardHelperTestCase in
src/test/org/apache/cocoon/util/test and
src/test/org/apache/cocoon/matching/helpers which both should go.
Cheers, Alfred.
Re: [RT] Improved matching selecting
On Tue, 2006-12-05 at 07:58 -0800, Mark Lundquist wrote: On Dec 4, 2006, at 12:46 PM, Alfred Nathaniel wrote: Or use different tags, say in resemblance to XSLT: map:if path=... ... /map:if map:choose map:when path=... I'm not so keen on that, 'cause I'm actually trying to get away from using 2 different elements for this. Rationale: 1) The precedent of match and select would have conditioned users to interpret if and choose as referring to two different kinds of sitemap components (Iffers and Choosers? :-). I'd like the syntax to emphasize that it's all matching and there is only one component now, The Matcher. There is no need for a one-to-one relation between sitemap tags and components. (There won't be any Whener in your model either?). So I don't see the problem in using Matcher implementations for more than one tag which is not called map:match. 2) The sitemap language is not XSLT and has nothing to do with XSLT. The only relationship is that the sitemap has to do with Cocoon and Cocoon uses XSLT... big deal! :-) Trying to imitate XSLT in the sitemap in the interest of familiarity IMHO is misguided and results in confusion. Things that are different should look and feel different. For example: in XSLT if and choose, the @test clause contains a predicate. This is fundamentally different then in the sitemap, where the corresponding attribute contains a pattern, and the predicate comprises some kind of (implicit or configured) match of this pattern against a configured target value. Now the way this is expressed in the classic sitemap, the select/when version puts this value into an attribute called test — probably, again, in deference to XSLT, and IMHO confusing — while the match version puts it in an attribute called pattern. But in either case, the semantics are rather different than XSLT owing to the difference between predicate and pattern. Well, why not really use XSLT syntax? map:if test=wcmatch(uri(), '**/*.xml' where wcmatch() and uri() are Cocoon components. 3) I think XSLT got it wrong :-). They should have used something like xsl:cond for both, and treated @test like I treat @value in my proposal. An analogy between xsl:choose and a switch or case statement is flawed, the correct analogy is to if()... else if() — again, because of the distinction between predicate and pattern! Switch/case is really like today's map:select!!! if()... inaugurates a conditional using the same keyword regardless of how many alternatives there are — one, or many. That's how sitemap matching (which has only patterns) should do it, and that's how XSLT (which has only predicates) should have done it. No need for two different keywords. I think we should use two different keywords because otherwise the content model depends on the presence of various attributes and not on the tagname only -- that is really confusing. Whether the keyword pair is match/select or if/choose or cond/switch or something else I don't care too much. cheers and thx for the feedback :-), —ml— Cheers, Alfred.
Re: Releasing 2.1.10
On Mon, 2006-12-04 at 14:08 +0100, Carsten Ziegeler wrote: If there are no outstanding issues I will assemble a release next monday (11th), put it up for downloading and testing and if nothing bad happens do the release of that assembled version on monday, 18th. +1 Cheers, Alfred.
Re: [RT] Improved matching selecting
On Mon, 2006-12-04 at 08:34 -0800, Mark Lundquist wrote: On Dec 4, 2006, at 7:37 AM, Bertrand Delacretaz wrote: Restricting a single sitemap to use either of these engines (as opposed to allowing a mix in a single sitemap) might help avoid confusion. I totally agree! How about... sitemap matching=classic This would be the default setting, to preserve backward-compatibility. It would also log a message to the deprecation log! vs.: sitemap matching=engine !-- out w/ the old, in w/ the new :-) -- I'm also thinking that with matching=engine, we should get rid of the matchers section in the sitemap altogether, and set up the matching engine component in cocoon.xconf. WDYT? cheers, —ml— Or use different tags, say in resemblance to XSLT: map:if path=... ... /map:if map:choose map:when path=... ... /map:when map:otherwise /map:otherwise /map:choose map:match and map:select can the be deprecated and removed in a future version. Cheers, Alfred.
