[ANN] Apache Cocoon 2.1 and 3.0 retired
Apache Cocoon 2.1 and 3.0 retired - After the recent release of Cocoon 2.3.0, the Apache Cocoon Community has decided to retire both 2.1 and 3.0 versions, to focus on further developments of the 2.3 branch The 2.1 branch was first released more than 20 years ago and is now considered obsolete. The 3.0 version was an attempt to rewrite Cocoon from scratch, but was never finalized. Apache Cocoon is a Spring-based framework (since version 2.2 of Cocoon) built around the concepts of separation of concerns and component-based development. Cocoon implements these concepts around the notion of component pipelines, each component on the pipeline specializing on a particular operation. 2.3.0 is the continuation of Cocoon 2.2 for contemporary Java versions. Apache Cocoon 2.3.0 may be downloaded from https://cocoon.apache.org/mirror.html For more information about Apache Cocoon, please go to https://cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Future of the Cocoon project
Dear Cocoon users and developers, Sorry for crossposting here, I wanted to be sure that all involved people were aware of the ongoing discussions. We recently pushed a new release of Cocoon, 11 years after the previous one. This release gathers all changes made in between as well as two security fixes discovered last year. The journey to roll this release out was definitively not an easy one, and it's now time to think about what should be next for the project. We currently officially maintain 3 branches, not compatible with each others and having evolved differently over the years : 2.1.x, 2.2/2.3 and 3.0, and we do not have enough active developers to be able to continue to properly and correctly maintain them. For a project as old as Cocoon (21 years!), there may be many users around here still using one branch or another, which could be interested to step up, contribute and try to revive the project, or at least some parts of it. I will soon start 3 threads on the developers list to decide what to do about each of the 3 branches (retiring or not), so I encourage volunteers to bring their voices. Best regards, Cédric, on behalf of the Apache Cocoon PMC - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: CVE-2023-49733: Apache Cocoon's StreamGenerator is vulnerable to XXE injection
Hi Warell, Yes it does ... I think however that it should be quite straight forward to use log4j2 instead if needed. Cédric Le 30/11/2023 à 12:30, warrell harries a écrit : Hi Cedric, Does this build still use the infamous Log4J v1. 2 jar I know it's actually benign due to no use of the jndi but security vulnerability scanners usually complain. Thanks for your work on this. Best regards Warrell On Thu, 30 Nov 2023, 11:16 Cédric Damioli, wrote: Severity: important Affected versions: - Apache Cocoon 2.2.0 before 2.3.0 Description: Improper Restriction of XML External Entity Reference vulnerability in Apache Cocoon.This issue affects Apache Cocoon: from 2.2.0 before 2.3.0. Users are recommended to upgrade to version 2.3.0, which fixes the issue. References: https://cocoon.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-49733 - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org -- Cédric Damioli CMS - Java - Open Source www.ametys.org
CVE-2023-49733: Apache Cocoon's StreamGenerator is vulnerable to XXE injection
Severity: important Affected versions: - Apache Cocoon 2.2.0 before 2.3.0 Description: Improper Restriction of XML External Entity Reference vulnerability in Apache Cocoon.This issue affects Apache Cocoon: from 2.2.0 before 2.3.0. Users are recommended to upgrade to version 2.3.0, which fixes the issue. References: https://cocoon.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-49733 - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
CVE-2022-45135: Apache Cocoon: SQL injection in DatabaseCookieAuthenticatorAction
Severity: moderate
Affected versions:
- Apache Cocoon 2.2.0 before 2.3.0
Description:
Improper Neutralization of Special Elements used in an SQL Command ('SQL
Injection') vulnerability in Apache Cocoon.This issue affects Apache Cocoon:
from 2.2.0 before 2.3.0.
Users are recommended to upgrade to version 2.3.0, which fixes the issue.
Credit:
QSec-Team (finder)
References:
https://cocoon.apache.org/
https://www.cve.org/CVERecord?id=CVE-2022-45135
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
[ANN] Apache Cocoon 2.3.0 Released
Apache Cocoon 2.3.0 Released - The Apache Cocoon Community is proud to announce the release of Cocoon 2.3.0. Apache Cocoon is a Spring-based framework (since version 2.2 of Cocoon) built around the concepts of separation of concerns and component-based development. Cocoon implements these concepts around the notion of component pipelines, each component on the pipeline specializing on a particular operation. This release, 11 years after 2.2.0, gathers all changes made since then, along with security fixes. The minimum Java version was also upgraded to 1.8 Apache Cocoon 2.3.0 may be downloaded from https://cocoon.apache.org/1284_1_1.html For more information about Apache Cocoon, please go to https://cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Getting UTF-16 encoding on dynamic content regardless of output content type
Hi, To help isolate the issue, could you test with a simpler pipeline with only generator/single simple XSLT/xml serializer ? Cédric Le 31/03/2022 à 17:54, Christopher Schultz a écrit : Cédric, On 3/29/22 12:52, Cédric Damioli wrote: Do you use Xalan as XSLT Processor ? If so, I remember https://issues.apache.org/jira/browse/XALANJ-2617 which could be a cause of your issue. I resolved it on my side years ago by compiling my own patched version > of Xalan. I'm using whatever Cocoon uses natively. For example, I don't throw-in Jackson or StaX or whatever other options there are. For "markers", you may use labels on your sitemap steps associated with a cocoon view. Yeah, that sound familiar. Thanks, -chris Le 29/03/2022 à 18:36, Christopher Schultz a écrit : Cédric, On 3/29/22 12:06, Cédric Damioli wrote: Could you provide more details ? How is your XML processed before outputting the wrong UTF-8 sequence ? It's somewhat straightforward: https://source/; />
Re: Getting UTF-16 encoding on dynamic content regardless of output content type
Do you use Xalan as XSLT Processor ? If so, I remember https://issues.apache.org/jira/browse/XALANJ-2617 which could be a cause of your issue. I resolved it on my side years ago by compiling my own patched version of Xalan. For "markers", you may use labels on your sitemap steps associated with a cocoon view. HTH, Cédric Le 29/03/2022 à 18:36, Christopher Schultz a écrit : Cédric, On 3/29/22 12:06, Cédric Damioli wrote: Could you provide more details ? How is your XML processed before outputting the wrong UTF-8 sequence ? It's somewhat straightforward: https://source/; />
Re: Getting UTF-16 encoding on dynamic content regardless of output content type
Hi Christopher,
Could you provide more details ?
How is your XML processed before outputting the wrong UTF-8 sequence ?
Regards,
Cédric
Le 29/03/2022 à 17:48, Christopher Schultz a écrit :
All,
I'm still struggling with this. I have upgraded to 2.1.13 which
includes the fix for https://issues.apache.org/jira/browse/COCOON-2352
but I'm still getting that American flag converted into those 4 HTML
entities:
I would expect there to be a single (multibyte) character in the
output with no HTML entities.
I've double-checked, and the source XML contains the flag as a single
multi-byte character, served as UTF-8.
Any ideas for how to get this working? I'm sure I could put together a
trivial test-case.
Thanks,
-chris
On 10/30/18 12:18, Christopher Schultz wrote:
All,
Some additional information at the end.
On 10/30/18 11:58, Christopher Schultz wrote:
All,
I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have
a servlet generating XML in UTF-8 encoding and I have a pipeline
with a few transforms in it, ultimately serializing to XHTML.
If I have a Unicode character in the XML which is outside of the
BMP, such as this one: (that's an American flag, in case your
mail reader doesn't render it correctly), then I end up getting a
series of bytes coming from Cocoon after the transform that look
like UTF-16.
Here's what's in the XML:
Test
Just like that. The bytes in the message for the flag character
are:
f0 9f 87 ba f0 9f 87 b8
When rendering that into XHTML, I'm getting this in the output:
Test
The American flag in Unicode reference can be found here:
https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%87%BA%F0%9F%87%
B8
You can see it broken down a bit better here for "Regional U":
http://www.fileformat.info/info/unicode/char/1f1fa/index.htm
and "Regional S":
http://www.fileformat.info/info/unicode/char/1f1f8/index.htm
What's happening is that some component in Cocoon has decided to
generate HTML entities instead of just emitting the character.
That's okay IMO. But what it does doesn't make sense for a UTF-8
output encodin g.
The first two entities "" are the decimal numbers
that represent the UTF-16 character for that "Regional Indicator
Symbol Letter U" and they are correct... for UTF-16. If I change
the output encoding from UTF-8 to UTF0-16, then the browser will
render these correctly. Using UTF-8, they show as four of those
ugly [?] characters on the screen.
I had originally just decided to throw up my hands and use UTF-16
encoding even though it's dumb. But it seems that MSIE cannot be
convinced to use UTF-16 no matter what, and I must continue to
support MSIE. :(
So it's back to UTF-8 for me.
How can I get Cocoon to output that character (or "those
characters") correctly?
It needs to be one of the following:
(HTML decimal entities)
(HTML hex entities) f0 9f 87 ba
f0 9f 87 b8 (raw UTF-8 bytes)
Does anyone know how/where this conversion is being performed ion
Cocoon? Probably in a XHTML serializer (I'm using
org.apache.cocoon.serialization.XMLSerializer). I'm using
mime-type "text/html" and UTF-8 in my sitemap
for that serializer (the one named "xhtml"). I believe I've mads
very few changes from the default, if any.
I haven't yet figured out how to get from what Java sees (\uE50C
for the "S" for example) to , but knowing where the code
is that is making that decision would be very helpful.
Any ideas?
-chris
I created a text file (UTF-8) containing only the flag and read it in
using Java and printed all of the code points. There should be 2
"characters" in the file. It's 4 bytes per UTF-8 character so I
assumed I'd end up with 2 'char' primitives in the file, but I ended
up with more.
Here's the loop and the output:
try(java.io.FileReader in = new java.io.FileReader("file.txt"))
{
char[] chars = new char[10];
int count = in.read(chars);
for(int i=0; i // Skip any trailing "characters" that are actually a part of this
one
if(1 < Character.charCount(cp))
i += Character.charCount(cp) - 1;
}
Using the above code is completely encoding-agnostic, because it's
describing the Unicode code point and not some set of bytes in a
particular flavor of UTF-x.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: using cocoon 2.1 in the long-term, security concerns
Hi, Not only Tomcat, but each and every dependency your particular project uses. As of today, Cocoon 2.1 works well in a Java 11+/Tomcat 9+ environment, with all dependencies upgraded. Cocoon 2.1.13 itself contained a fix for a security-related issue, but in the past years, there wasn't many security issues targeting Cocoon core. HTH, Regards, Cédric Le 19/07/2021 à 14:05, warrell harries a écrit : The Tomcat version must be updated to address these concerns. That should do it On Mon, 19 Jul 2021, 13:03 Vincent Neyt, <mailto:vincent.n...@gmail.com>> wrote: Hi Cocoon users, I'd like to ask your opinion on the long-term security risks of running Cocoon on a server. The colleague responsible for the servers at my university is inquiring if the software I'm using for my website is up to date and is concerned that I'm using outdated software that could in the future pose a security risk. I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13 without many problems. But I'm concerned about the long-term, and wondering if it would perhaps be better to reprogram the website I've been working on for 10 years into eXist DB (which would be a huge time investment). I like cocoon very much and would love to continue using it if it's possible. I'm curious to hear your thoughts about using Cocoon 2.1 for the long term: will it still work well inside future versions of servlet containers like Tomcat? What about the java dependencies? And will cocoon 2.1 continue to put out updates when security risks are identified? thanks very much, Vincent -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: Cocoon 2.1.11 problem with JDK release versions above 255
Hi Vincent, Do you have any stack trace to help finding the actual issue ? I know there's a similar issue with the ICU library. Do you use it, and if so in which version ? Regards, Cédric Le 30/06/2021 à 17:11, Francesco Chicchiriccò a écrit : On 28/06/21 09:48, Vincent Neyt wrote: Hi list, I did a stupid thing, I posted to the user list without first subscribing, so I'm sending my query again now that I am subscribed to the list. Sorry for the inconvenience! Since 2011 I've been using a build of Cocoon 2.1.11 (inside Tomcat 8) as the publishing framework for my website. I've recently found out that Cocoon fails to start up when the installed java version has an update number higher than 255. Things start up properly with Java SE Development Kit 8u255 and lower, but fail to start up with Java SE Development Kit 8u256 and higher (for instance the current Java SE Development Kit 8u291). The error I get is Initialization Problem: Scheduler with name 'Cocoon' already exists. but it has cost me blood sweat and tears to find out that the underlying cause is the Java update version number. Is there a line in a file in my Cocoon 2.1.11 build that I could change to get rid of this error? Hi Vincent, I am afraid I cannot be of much help here, not using Cocoon 2.1 since quite some time. Anyway, did you find anything more than just the line reported above? Any stacktrace? Regards. -- <http://www.ametys.org> <http://www.facebook.com/ametysCMS> <http://twitter.com/ametysCMS> <http://plus.google.com/+ametysOrg/posts> <http://www.youtube.com/user/ametysWebCMS> Cédric Damioli Directeur associé +33 (0)5 62 19 19 07 / +33 (0)6 87 03 61 63 | +33 (0)5 61 75 84 12 cedric.dami...@ametys.org <mailto:cedric.dami...@ametys.org> 40 Rue du Village d'entreprises 31670 Labège Inscrivez-vous à notre newsletter <http://anyware-services.us2.list-manage2.com/subscribe?u=1cf1cbf2891b613e90fd95eb2=01c7bdfce3>
Re: Build failed: -Djava.endorsed.dirs=lib/endorsed is not supported.
Hi, It should be ok to build with Java 8. AFAIK, this error message in only provided by a JVM 9+ Is it possible that you have both JRE 8 and JRE 9+ on your system and that you use the wrong one ? Regards, Cédric Le 13/09/2020 à 11:31, Thorsten Mauch a écrit : Hi , I try to build cocoon but i get an this error: -Djava.endorsed.dirs=lib/endorsed is not supported. Endorsed standards and standalone APIs in modular form will be supported via the concept of upgradeable modules. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Is use; java version "1.8.0_191" Java(TM) SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) I understood from read me, that java 1.8 is supported by the build system. Any ideas what i may made wrong ? Thanks Thorsten - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org -- Cédric Damioli CMS - Java - Open Source www.ametys.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: [CVE-2020-11991] Apache Cocoon security vulnerability
Hi, Entities resolution is managed by features of the SAX Parser, before any transformation. Cédric Le 11/09/2020 à 12:12, gelo1234 a écrit : Hello Cedric, Are external entities blocked also in XSLT? Greetings, Greg pt., 11 wrz 2020 o 11:39 Cédric Damioli <mailto:cdami...@apache.org>> napisał(a): [CVE-2020-11991] Apache Cocoon security vulnerability Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Cocoon up to 2.1.12 Description: When using the StreamGenerator, the code parse a user-provided XML. A specially crafted XML, including external system entities, could be used to access any file on the server system. Mitigation: The StreamGenerator now ignores external entities. 2.1.x users should upgrade to 2.1.13 Example: With the following input : ]> John an attacker got the content of /etc/shadow Credit: This issue was discovered by Nassim Asrir. Regards, -- Cédric Damioli -- Cédric Damioli CMS - Java - Open Source www.ametys.org
[CVE-2020-11991] Apache Cocoon security vulnerability
[CVE-2020-11991] Apache Cocoon security vulnerability Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Cocoon up to 2.1.12 Description: When using the StreamGenerator, the code parse a user-provided XML. A specially crafted XML, including external system entities, could be used to access any file on the server system. Mitigation: The StreamGenerator now ignores external entities. 2.1.x users should upgrade to 2.1.13 Example: With the following input : "file:///etc/shadow"> ]> John an attacker got the content of /etc/shadow Credit: This issue was discovered by Nassim Asrir. Regards, -- Cédric Damioli
Re: upgrade 2.1.11 -> 2.1.13
Hi, I wouldn't expect any major issue upgrading from 2.1.11 to 2.1.13. You may look at [1] to identify which fixes are relevant to you. Regards, Cédric [1] : https://issues.apache.org/jira/browse/COCOON-2367?jql=project%20%3D%20COCOON%20AND%20fixVersion%20in%20(2.1.12%2C%202.1.13) Le 23/08/2020 à 15:03, Thorsten Mauch a écrit : Hi all I'm happy to see some activity in the development. I also still run two applications with cocoon, but with very old 2.1.11 and java 1.6. My question, if i try to upgrade to 2.1.13 and a current java, does i have to expect major issues ? Of course nobody know my apps. But maybe someone made some experiences, that may helps. Thanks Thorsten - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org -- Cédric Damioli CMS - Java - Open Source www.ametys.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: [ANN] Apache Cocoon 2.1.13 Released
I updated the mirror page. Thanks ! Cédric Le 30/07/2020 à 12:24, warrell harries a écrit : Great news! Well done! The download is still showing version 2.12 Many thanks from a die-hard cocooner On Thu, 30 Jul 2020 at 11:12, Cédric Damioli <mailto:cdami...@apache.org>> wrote: Apache Cocoon 2.1.13 Released - The Apache Cocoon Community is proud to announce the new release of Apache Cocoon. Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD. Cocoon implements these concepts around the notion of 'component pipelines' modelled after the 'process chain' concept where each worker specializes on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions where these components can be hooked together into pipelines without requiring further programming. We like to think at Cocoon as "web glue" for your web application development needs. But most important, a glue that can keep concerns separate and allow parallel evolution of the two sides, improving development pace and reducing the chance of conflicts. For more information about Apache Cocoon 2.1.13, please go to http://cocoon.apache.org Changes with Apache Cocoon 2.1.13 *) Starting with 2.1.13 the minimum required Java version will be 1.6. [all] *) Cannot start Cocoon 2.1.12 on Windows [FC] *) Cannot build with Java 7 [FC] *) Use ImageIO instead of old com.sun.image.* package in ImageReader [FC] *) Apache license at the beginning cocoon's dojo widgets templates causes: dojo.widget.Parse: error: [FC] *) XSP not working with Java 8 [FC] *) Make XMLResourceBundle (and -Factory) more extensible [CD] *) XMLResourceBundles are not available outside a Request [CD] *) Escape accolades in i18n messages [CD] *) ContextSourceFactory calculates the path incorrectly when removing the protocol part [FC] *) XMLEncoder doesn't support Unicode surrogate pairs [FC] *) Content-Range and Range headers does not respect the HTTP spec [CD] *) Inconsistent Content-Length header for HEAD requests [CD] *) Cannot upload a file with name containing a '=' or a ';' [CD] *) Unsynchronized HashMap.put in ResourceReader and GeneratorSelector may lead to infinite loop. [AN] *) Update to poi-3.14 (requires Java 1.6) [AN] *) Update to fop-1.1 [AN] *) Update to commons-httpclient-3.1 [AN] *) XSP: Use javax.tools.JavaCompiler interface for Javac (available since Java 6). [AN] *) Core: Update to xalan-2.7.2 and add serializer-2.7.2 [AN] *) Enable 'java' to be found by the build and run shell scripts on a modern Mac OS X. [DC] - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org <mailto:users-unsubscr...@cocoon.apache.org> For additional commands, e-mail: users-h...@cocoon.apache.org <mailto:users-h...@cocoon.apache.org> -- Cédric Damioli CMS - Java - Open Source www.ametys.org
[ANN] Apache Cocoon 2.1.13 Released
Apache Cocoon 2.1.13 Released - The Apache Cocoon Community is proud to announce the new release of Apache Cocoon. Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD. Cocoon implements these concepts around the notion of 'component pipelines' modelled after the 'process chain' concept where each worker specializes on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions where these components can be hooked together into pipelines without requiring further programming. We like to think at Cocoon as "web glue" for your web application development needs. But most important, a glue that can keep concerns separate and allow parallel evolution of the two sides, improving development pace and reducing the chance of conflicts. For more information about Apache Cocoon 2.1.13, please go to http://cocoon.apache.org Changes with Apache Cocoon 2.1.13 *) Starting with 2.1.13 the minimum required Java version will be 1.6. [all] *) Cannot start Cocoon 2.1.12 on Windows [FC] *) Cannot build with Java 7 [FC] *) Use ImageIO instead of old com.sun.image.* package in ImageReader [FC] *) Apache license at the beginning cocoon's dojo widgets templates causes: dojo.widget.Parse: error: [FC] *) XSP not working with Java 8 [FC] *) Make XMLResourceBundle (and -Factory) more extensible [CD] *) XMLResourceBundles are not available outside a Request [CD] *) Escape accolades in i18n messages [CD] *) ContextSourceFactory calculates the path incorrectly when removing the protocol part [FC] *) XMLEncoder doesn't support Unicode surrogate pairs [FC] *) Content-Range and Range headers does not respect the HTTP spec [CD] *) Inconsistent Content-Length header for HEAD requests [CD] *) Cannot upload a file with name containing a '=' or a ';' [CD] *) Unsynchronized HashMap.put in ResourceReader and GeneratorSelector may lead to infinite loop. [AN] *) Update to poi-3.14 (requires Java 1.6) [AN] *) Update to fop-1.1 [AN] *) Update to commons-httpclient-3.1 [AN] *) XSP: Use javax.tools.JavaCompiler interface for Javac (available since Java 6). [AN] *) Core: Update to xalan-2.7.2 and add serializer-2.7.2 [AN] *) Enable 'java' to be found by the build and run shell scripts on a modern Mac OS X. [DC] - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Compatibility check
Hi, We use Cocoon 2.1.12 with Java 8 in production for years without any problems. Never tried Tomcat 9 yet, but any other versions worked well also, inclufind 8 and 8.5. No dependencies with OS as well. Regards, Cédric Le 11/09/2018 à 08:20, Thangavel, Senthil Kumar (LNG-CON) a écrit : HI, I am currently using Cocoon version 2.1. And I am planning to upgrade the tomcat container version to “9.0.11” and java version to 1.8. Will the Cocoon 2.1 version is compatible with the higher version of tomcat and java. Also does it have any dependency with OS? Please provide the expert advice. Regards, Senthilkumar.T -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: Trouble switching locales with i18ntransformer
Hi Christopher, Just in case, did you try to hardcode the "es" value : Regards, Cédric Le 09/01/2018 à 17:34, Christopher Schultz a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I have an I18NTranformer configured and elements in my stylesheets and everything is working for the default locale. But changing locales doesn't seem to be working for me. I think I must be missing something. I'm using Cocoon 2.1.11. Here's what I have: sitemap.xmap: ... en ... ... ... I have 3 files in /path/to/files: common.xml [xml:lang="en"] summary.xml[xml:lang="en"] summary_es.xml [xml:lang="es"] This works as expected with en is set in the global-variables section. I was expecting that changing to: es And then restarting Cocoon would end up using the text from my summary_es.xml file, but it's still showing the English text from summary.xml. Replacing summary.xml with summary_es.xml works of course (i.e. the text from summary_es.xml is now showing in my rendered pages). The client (browser) is advertising a preference for lang=en, but that shouldn't matter because I'm invoking the i18n transform specifically with locale="en", right? I even changed by browser's preferred language from English to Spanish and nothing changed. I'd prefer to be able to change the locale by setting the global variable and not doing anything else. What am I missing, here? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpU7yMdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiDLQ/6A0SqCs/ava78tK53 CSvMZqpY4xfKXu3GQqS+7DK0wxi4pOcnsNtRxhaQHmPVPvtPKv6H0+fzGIMkRpGn lJRcXzSFAa4zkWcQ2zDPh+FatROftroTRK+TljVIrmYJG4BNFbuH1PlNgpj3dPOC bpuKhTNAC8lz7Pdu9JbTiy3mCSXihv18S/wcJ52g69Uh8oa5Vo1o6nHDO1hEe1zt ejBDVQd5pytmFomWrYm2BR0/OG3mjUY+9uyI3Ys1K8uuFDFxtT6u0Ew0RtpYP9T3 UdWCvcR1ixmVNQ9Xwxtk8Cf0n0eoYdffdj+LK3h7WdCF/eJCkRkxTzrB2KmFnaiq BwHJmXs1u0V5If9POEBsP+GjhdwCtdV2up16yb6f2Mw6X0/fsQvmmVA9eQUk7/EH s94qvOkjeozTZVGd8Hovw9GXYze9MMHOp4lVz5H93e0Psjy8BBIOfSyxQEtPx9A9 xh/POW1BOKDUw1O2/x8f21yHwlOcwfIrkQKRvp9cAFQMWtAsJ7QJVqUX5jdtIsrO H/tBO0+qO7HNfxllyHeSVbx+nPkHEXceijUZfhG+Nakmi/GfgMgtangrKbfSflEU vl+qRHbHYdBphrIrWRy6huyOQojV4RAxp8WcV8+M9NrtItFIUeDuCnJumH51Fm1Y oubhYj1xaPRowGIlWmrAD3tlEIo= =NoLl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org -- Cédric Damioli CMS - Java - Open Source www.ametys.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: PDF in Cocoon 2.1.12 Tomcat
Hi Peter, Which JRE do you use on your windows box and on your debian box ? Your problem seems to be related to fonts that are not found by the JRE. If you use openjdk on debian, you may try oracle jdk. Regards, Cédric Le 02/08/2013 10:47, Peter Sparkes a écrit : Hi, I have an 2.1.12 application which produces some PDF pages. It works well on my windows machine, however, on my debian tomcat server the pdf pages produce the following error *type*Exception report *message*_Servlet execution threw an exception_ *description*_The server encountered an internal error (Servlet execution threw an exception) that prevented it from fulfilling this request._ *exception* javax.servlet.ServletException: Servlet execution threw an exception *root cause* java.lang.Error: Probable fatal error:No fonts found. sun.font.FontManager.getDefaultPhysicalFont(FontManager.java:1087) sun.font.FontManager.initialiseDeferredFont(FontManager.java:966) sun.font.CompositeFont.doDeferredInitialisation(CompositeFont.java:254) sun.font.CompositeFont.getSlotFont(CompositeFont.java:334) sun.font.CompositeGlyphMapper.initMapper(CompositeGlyphMapper.java:81) sun.font.CompositeGlyphMapper.init(CompositeGlyphMapper.java:62) sun.font.CompositeFont.getMapper(CompositeFont.java:390) sun.font.CompositeFont.canDisplay(CompositeFont.java:416) Any Ideas Please Peter -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: 2.1.12 and html5
Hi,
The XHTMLSerializer Francesco was referring to is not the
org.apache.cocoon.serialization.XMLSerializer of your sample, but the
org.apache.cocoon.components.serializers.XHTMLSerializer from the
serializers block, which is another implementation of XHTML serialization.
Regards,
Cédric
Le 05/06/2013 07:15, Peter Sparkes a écrit :
Hi Francesco ,
I can't get the XHTML serializer to produce html5, the sitemap.xmap has:
map:serializer logger=sitemap.serializer.xhtml
mime-type=text/html name=xhtml
pool-max=${xhtml-serializer.pool-max}
src=org.apache.cocoon.serialization.XMLSerializer
!--+
| You can choose from Strict, Transitional, or Frameset
XHTML.
| For Strict XHTML set doctype to:
| doctype-public-//W3C//DTD XHTML 1.0
Strict//EN/doctype-public
|
doctype-systemhttp://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd/doctype-system
| For Transitional XHTML set doctype to:
| doctype-public-//W3C//DTD XHTML 1.0
Transitional//EN/doctype-public
|
doctype-systemhttp://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd/doctype-system
| For Frameset XHTML set doctype to:
| doctype-public-//W3C//DTD XHTML 1.0
Frameset//EN/doctype-public
|
doctype-systemhttp://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd/doctype-system
|
| Default XHTML doctype in Cocoon is XHTML Strict. If
you want to use more than one
| XHTML DTD simultaneously, you can define several XHTML
serializers.
+--
doctype-public-//W3C//DTD XHTML 1.0
Strict//EN/doctype-public
doctype-systemhttp://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd/doctype-system
encodingUTF-8/encoding
/map:serializer
I have tried experimenting with various values in doctype-public and
doctype-system but can't get
!DOCTYPE html
html
head
Regards
Peter
On 04/06/2013 08:18, Francesco Chicchiriccò wrote:
On 03/06/2013 19:19, Peter Sparkes wrote:
Hi
Does 2.1.12 have a html5 serializer
Yes: XHTML serializer can handle HTML5 doctype -
https://issues.apache.org/jira/browse/COCOON-2310
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com
[ANN] Apache Cocoon 2.1.12 Released
Apache Cocoon 2.1.12 Released - The Apache Cocoon Community is proud to announce the new release of Apache Cocoon. Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD. The latest version is downloadable from http://cocoon.apache.org/mirror.cgi (Please use the mirrors to download the release - it might take a little bit more time until the latest release is available on all mirrors, so give the mirrors some time - approx. 24h to update.) This release includes many bug fixes and smaller enhancements. For more information about Apache Cocoon 2.1.12, please go to http://cocoon.apache.org. You'll find the whole list of changes at http://cocoon.apache.org/2.1/changes.html. The Apache Cocoon Project -- Cédric Damioli For more information about Apache Cocoon 2.1.12, please go to http://cocoon.apache.org Changes with Apache Cocoon 2.1.12 *) Starting with 2.1.12 the minimum required Java version will be 1.4.2. [all] *) Core: Update xml-commons-resolver to 1.2 [DC] *) Allow usage of SLF4J for traces [CD] *) I18nTranformer should consume and stop propagating start/endPrefixMapping of its namespace [CD] *) Cocoon 2.1 is not initialized when building without samples [CD] *) Serializers block: Added support of XHTML5 in the XHTMLSerializer [CD] *) Core: When interrupted, the ResourceReader may store incomplete data in the cache [CD] *) Core: Allow to override the upload parameters in CocoonServlet [CD] *) Core: Update xercesImpl to 2.11.0 and xml-apis to 1.4.01. [AG] *) Add base URI fixup support to XIncludeTransformer [JSJ] *) Repository block: WebDAV Returns improper status on PUT [JSJ] *) FOP block: Backport from FOPNGSerializer (C2.2) to FOPSerializer. Upgraded FOP dependency from 0.20.5 to 0.95. [JSJ] *) XSP block: Make SOAPHelper use https, not just http [JSJ] *) Serializer block: charset data won't load if there's a space in the path to the jar file (e.g C:\Program Files\MyApp\...) [SW] *) JCR block: Missing modCount attribute in JCR sample content. [JSJ] *) Updated ant to 1.7.1. This ant detects correctly java 1.6. [AG] *) Change HostSelector to be case-insensitive according to RFC3986 section 3.2.2. [JH] *) Handle case in ApplicationUtil.isUserInRole(..) when User is null. [JH] *) Forms: MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms. [AG] *) StripNameSpacesTransformer does not strip namespace prefix of attributes [JSJ] *) ImageOp block: If parameter width or height in resize operation is zero, use the original image size. If both are zero, then handle as no-op. Set default values to zero to allow using that feature by leaving out the parameters. [AN] *) ImageOp block: Addition of allow-enlarge parameter to resize operation. [AN] *) Mail block: Allow mime-type to explicitly set a charset as in mime-type=text/html;charset=UTF-8. [AN] *) Mail block: Make a difference between plain text mails and mails that have a multi-part body. If the mail-body has set the mime-type=text/plain, then the message body isn't send as body part but as simple content. That avoids getting a plain text-message without attachment being marked as mail with attachment. [RP] *) Core: Cocoon's pipeline buffer increases from an initial buffer size of 8192 bytes to the configurable flush buffer size rather than allocating the complete buffer beforehand. [JH] *) POI Block: formatted style regions stop creating style at 2000 rows. [AG] *) Eventcache: Events are persisted and restored and sample works [AS] *) POI Block: Update to poi-3.0.2. [AN] *) HTML: Fix encoding issue in NekoHTMLTransformer. Fix similar issue in NekoHTMLGenerator when reading a request parameter value. [VG, JH] *) Forms: Fix @id handling on fi:group/fi:struct element in conjunction with AJAX requests. [JH] *) Core: Fix CachingOutputStream not caching all content or leading to ArrayIndexOutOfBoundsException when using write(byte[], int, int). [JH] *) Core: Set the default output buffer size of the pipeline to 1,048,576 (1 MB) rather than -1 (complete buffering) to avoid potential OutOfMemoryErrors on too large output. [JH] *) Core: In Cocoon 2.2 the org.apache.cocoon.environment.Session interface is deprecated, and the return type of getSession() changes to vanilla javax.servlet.HttpRequest. For migrating from Cocoon 2.1 to 2.2, replace in your custom code all calls to getSession() by getCocoonSession(). That allows for a common codebase usable on both version. [AN] *) Core: Allow multiple file uploads of the same field name. If there are multiple file uploads Request.get(String) will return a Vector. If there is only one file upload it will return the Part as it did before. This is now the same behavior as for inline parts. [JH] *) Core: Update commons
[2.1.12] Feedback request
Dear Cocoon users, A few years after the 2.1.11 release (!), we are currently in the process of releasing a 2.1.12 There are 85 open issues in JIRA (see [1]), only 13 of which have their fix-for version set to 2.1.12 Almost all these issues have been opened more than 2 years ago, so I don't know which are still valid or not, especially for blocks I've never used myself. What we'd like to know is if there are specific issues you want to be included for this upcoming release. If so, please reply to this message or directly set the fix-for version in the corresponding issue. Best regards, Cédric [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+COCOON+AND+resolution+%3D+Unresolved+AND+affectedVersion+in+%2812312231%2C+12310931%2C+12310650%29 - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Welcome Cédric Damioli and Robby Pelssers as Cocoon committers
Hi community, I'm very proud to have been nominated for Cocoon commitership. Thanks a lot to all who voted for me. Let's introduce briefly myself: I am a 32 years old french guy, living and working near Toulouse (south west of France). I am married with Florence and have two daughters, Lisa, 3 years and Julia, 7 months and 2 teeth since last week :) My long story with Cocoon began in 2002 as an intern of Sylvain Wallez, with pre-2.0 versions, on a time where sitemap was compiled and XSP were kings ! I was immediately impressed by the elegance of SAX based pipelines. I quickly learned to write custom components and to understand Cocoon internals. During the 7 next years, I have trained 100+ people from French administration and universities to Cocoon and developped dozens of Cocoon 2.0 and 2.1 based applications. Since 2009, I am the co-founder and CTO of Anyware Services, a small company developping Ametys (http://www.ametys.org), an Open Source Web CMS written on top of Cocoon 2.1. Ametys is currently mainly used by French universities, and run almost 50 000 sites around the world. Despite that Cocoon 2.1 may be considered as obsolete by many people, I still consider it as the best existing framework for building publishing applications. It is VERY stable and reliable. I must admit that I never considered a migration to Cocoon 2.2 nor 3.0, because of the amount of work it would represent to migrate all the features I hacked directly deep in the Cocoon internals. That's why I volunteered to help maintaining and releasing Cocoon 2.1 I hope to be able to contribute back to Cocoon community as much as it brought to me and my projects the last 10 years. Best regards, Cédric Damioli Le 18/12/2011 23:53, Sylvain Wallez a écrit : Hi all, I am very happy to announce that the Cocoon PMC has voted Cédric Damioli and Robby Pelssers as new Cocoon committers, provided of course that they accept it. Also, once you have your commit rights, you are welcome to join the Cocoon PMC whose member have binding votes for releases and other project matters. Please read the instructions for committers and PMC members [1], first thing being to send a CLA if not already done, and suggest your preferred account name. Welcome on board guys! Sylvain [1] http://apache.org/dev/#committers - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Using I18NTransformer with Dynamic Locales
Hi Christopher,
The locale of the I18nTransformer may be set a sitemap parameter :
map:transform type=i18n
map:parameter name=locale value=/
/map:transform
In this cas, the actual locale value may be computed in a surrounding
action :
map:act type=proxy
map:generate/
map:transform type=i18n
map:parameter name=locale value={locale}/
/map:transform
map:serialize/
/map:act
where the proxy action actually proxy the request to your real
webapp, get the responses header you mentionned and put it in the result
map.
Regards,
Cédric
Le 01/12/2011 17:49, Christopher Schultz a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
I'd like to start using the I18NTransformer so I can localize the
output of my XSLTs. We have what I believe to be a somewhat unique
situation with regard to the actual source of the locale information.
Here goes:
We have Cocoon set up as a webapp all by itself, separate from our
real webapp. Our pipelines take incoming HTTP requests and
essentially forward them, with modifications of course, to our real
webapp that produces XML for consumption by Cocoon. The Cocoon webapp
does not maintain session state of any kind: it merely forwards
requested session ids from the incoming request through the outgoing
request to the real webapp.
The real webapp knows what the user's preferred Locale is, and can
provide that information back to Cocoon if necessary. We have lots of
options: HTTP response headers, something in the XML document
returned, etc.
Unfortunately, I'm not sure how to get any of those data when calling
the I18N transformer itself.
Can anyone offer any suggestions?
If I can't come up with anything else, I'll have to encode the locale
in each request's URL which, while doable, will likely be fragile and
a total PITA to actually accomplish.
Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7XsBIACgkQ9CaO5/Lv0PBAxwCdER3GqI5TLETkSIeRzstvFcYn
nAkAoJ+5dPRr0zymd6dMez9pm4we4JJS
=GlJl
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Désactivation de cette liste
La fin d'une époque ! Je suis néanmoins toujours persuadé que Cocoon reste un super framework pour une application de publication type CMS, et que si il y a beaucoup moins d'activité sur les ML, c'est aussi et surtout parce que le framework est stable et fonctionnel. En tout cas, ça fait maintenant presque 10 ans (le temps passe vite !) que j'en fais une utilisation intensive et on a réussi à faire des trucs très sympa avec ! Cédric Le 20/06/2011 11:56, Sylvain Wallez a écrit : Le 20/06/11 11:48, Bertrand Delacretaz a écrit : Bonjour users-fr@cocoon.apache.org , Cette liste n'étant pas utilisée, elle sera prochainement désactivée - détails ic: https://issues.apache.org/jira/browse/INFRA-3716 Ca fait du sens, comme on dit en bon franglais ! Malheureusement notre bon vieux Cocoon a perdu de sa vivacité et de son rayonnement, et j'invite tous les utilisateurs francophones à rejoindre les listes anglophones s'ils n'y sont pas déjà. Sylvain -- Cédric Damioli Solutions GED/CMS Ametys ANYWARE SERVICES http://www.anyware-services.com http://www.ametys.org - To unsubscribe, e-mail: users-fr-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-fr-h...@cocoon.apache.org
[Annonce] Ametys, CMS Open Source basé sur Cocoon
Bonjour à tous, C'est avec grand plaisir que je vous annonce la mise en Open Source du CMS d'Anyware Technologies, sous le nom Ametys. Deux sites ont été mis en ligne à cette occasion : http://www.ametys.fr qui présente l'outil et ses fonctionnalités, et http://www.ametys.org, site communautaire destiné à regrouper la documentation, les archives à télécharger, ... et à fédérer les communautés naissantes d'utilisateurs et de développeurs. Ce CMS est entre autres basé sur Cocoon et JCR (Jackrabbit) et est particulièrement mis en oeuvre dans le secteur public français (universités, ministères, ...). Dans les prochaines semaines, d'autres outils collaboratifs (calendrier partagé, porte documents en ligne, ...) basés sur la même architecture seront disponibles sur ces sites. N'hésitez donc pas à vous joindre à cette nouvelle aventure ! -- Cédric Damioli Directeur de projets Solutions GED/CMS Ametys ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 73 47 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: [Annonce] Ametys, CMS Open Source basé sur Co coon
Bertrand Delacretaz a écrit : On 6/13/07, Cédric Damioli [EMAIL PROTECTED] wrote: C'est avec grand plaisir que je vous annonce la mise en Open Source du CMS d'Anyware Technologies, sous le nom Ametys Bravo, et merci pour l'info! ...Ce CMS est entre autres basé sur Cocoon et JCR (Jackrabbit)... Je n'ai pas encore regardé le code, mais par curiosité: avez-vous utilisé le bloc JCR de Cocoon, ou vos propres interfaces? Je n'ai pas regardé ce bloc depuis longtemps, mais comme c'est nous qui l'avions écrit à l'époque, et justement pour ce CMS, ça ne doit pas être trop éloigné ;-) Ceci étant, le bloc JCR de Cocoon est surtout basé sur une implémentation de l'interface Source et ne convient pas à toutes les utilisations. Pendant que j'y pense, cette ML est plutôt dédiée aux utilisateurs, mais il peut-être intéressant de noter également que les composants Ametys (et notamment la nouvelle génération, basée sur Ametys Runtime) intègrent un gestionnaire de plugins et de points d'extension, basés sur des composants Avalon et donc bien intégrés à Cocoon. Rdv sur les ML Ametys pour plus de détails ! -- Cédric Damioli Directeur de projets Solutions GED/CMS ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 73 47 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: Log-level and logkit
Lionel Crine a écrit : Hi all, I have some trouble to figure out what's going on with the logkit. My log-level (web.xml) is set to WARN and I overload the logkit the DEBUG the messages of the sitemap. Why is it working because the the logl-level in the web.xml is set to WARN ? Lionel The log-level parameter in the web.xml is only used at servlet init time, before the WEB-INF/logkit.xconf is actually read. After that, only values that are configured in the WEB-INF/logkit.xconf are used. Best regards, Cédric -- Cédric Damioli ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bloc Chaperon
Vincent Battaglia | Vima Design a écrit : J'ai essayé d'executer le module Chaperon de Cocoon pour transformer de la syntaxe Wiki en XML (dans le but d'extraire des articles de Wikipedia dynamiquement sur mon site). Malheureusement, j'obtiens toujours une page vierge en résultat. Voici le contenu de cette page : !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=Content-Type content=text/html; charset=windows-1252/HEAD BODY/BODY/HTML J'ai essayé avec les Cocoon samples et j'obtiens le même résultat. Dois-je activer quelque chose dans les fichiers de configuration de Cocoon pour que ca fonctionne? Merci. En général quand ca fait ca, c'est qu'il y a un ClassNotFoundException. Il faut regarder dans les logs du moteur de servlets. S'il s'agit d'un nouveau bloc, il doit d'agir du JAR de chaperon ou alors le bloc cocoon-chaperon -- Cédric Damioli Chef de projets systèmes d'informations Solutions CMS ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: CVSSource
Antonio Fiol Bonnín a écrit :
2005/4/21, Cédric Damioli [EMAIL PROTECTED]:
Antonio Fiol Bonnín a écrit :
Hello,
I am trying to use the CVSSource on Cocoon 2.1.5.
What I tried is adding to cocoon.xconf:
(1 line context information)
component-instance
class=org.apache.cocoon.components.source.impl.ModuleSourceFactory
name=module/
component-instance name=cocodoco-cvs
class=com.anwrt.cocoon.cvssource.source.CVSSourceFactory
hostnamecvs.apache.org/hostname
repository/home/cvspublic/repository
modulexml-cocoon2/src/documentation/module
usernameanoncvs/username
passwordanoncvs/password
!-- optionnal hierarchy refresh period (in seconds, defaults to 600) --
refresh-period3600/refresh-period
!-- optionnal commit message expression (sitemap syntax) --
commit-message-expr{request-param:cvs-message}/commit-message-expr
/component-instance
/source-factories
I did this because I did not find a source-handlers section.
The problem: StackOverflowException.
The repeating stack:
(snip)
If I understand what is happening, cocoon is trying to initialize
everything recursively. IOW, the getVariable method of CVSSource needs
something from the component manager which is not ready until it is
fully initialized... but what?
Any hints? Thank you very much for your help.
You guessed correctly ! :-)
IIRC, the guilty component is an InputModule (in your case,
PropertiesFileModule).
There's also others InputModule (XMLMetaModule ?) trying to lookup a
SourceResolver, which itself try to initialize CVSSourceFactory, which
itself needs InputModule (via VariableResolver), etc etc...
Every time I want to use CVSSource in my project, I clean InputModule
section and all works correctly after that.
Maybe it works if you clean the InputModule section. I will test it.
However, isn't it a bug (of CVSSource or other) that you can't have
both CVSSource and InputModules together at the same time?
Shouldn't someone break the loop? Who? How?
I imagine you could create a version of CVSSource not dependent of
InputModules (without variable resolving).
But, on the other hand, you only have to remove those InputModule who
create the circular dependencies (those who need a SourceResolver): they
are only a few.
--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVSSource
everything recursively. IOW, the getVariable method of CVSSource needs something from the component manager which is not ready until it is fully initialized... but what? Any hints? Thank you very much for your help. You guessed correctly ! :-) IIRC, the guilty component is an InputModule (in your case, PropertiesFileModule). There's also others InputModule (XMLMetaModule ?) trying to lookup a SourceResolver, which itself try to initialize CVSSourceFactory, which itself needs InputModule (via VariableResolver), etc etc... Every time I want to use CVSSource in my project, I clean InputModule section and all works correctly after that. Hope that helps, Cédric -- Cédric Damioli IS Project Leader CMS solutions ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
