[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 55 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- lenya :  Content Management System


Full details are available at:
http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-07102005.jar
 -Dbuild=build/cocoon-07102005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/g

[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 55 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- lenya :  Content Management System


Full details are available at:
http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-07102005.jar
 -Dbuild=build/cocoon-07102005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/g

how do you get the directory where the current flow is running?

[Stefano Mazzocchi]

I'm in a flow.js and I want to know where it is located on disk.

Any idea anyone?

--
Stefano.

[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 55 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- lenya :  Content Management System


Full details are available at:
http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-07102005.jar
 -Dbuild=build/cocoon-07102005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/g

[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 55 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- lenya :  Content Management System


Full details are available at:
http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-07102005.jar
 -Dbuild=build/cocoon-07102005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/g

Malformed stream: Read timed out

[g[R]eK]

Hello!

I have very mysterious error while using forms with 
@enctype="multipart/form-data". _Some times_ while submiting the form I 
get "org.apache.cocoon.servlet.multipart.MultipartException: Malformed 
stream: Read timed" out error and have no idea what is the cause. I get 
it even with simple form without any fields with @type="file". Even 
more, this error seems to exist only if Cocoon is proxied by Apache 
httpd (configured as described in [1]).
I said the issue emerges only some times. That is true for my own forms, 
but Daisy's editor always fails on clicking on "Switch editors to 
textareas" but only if size of form data being submited to a server is 
big enough (about 2000b). On small enough chunks of data being submited 
to a server there is no error whatever I try to do. To confuse more 
everything is on my production server (let's call it A) but I can't 
reproduce it on my dev machine (call it B) with the same configuration, 
and versions of httpd, tomcat etc. They only differ in OS (details below).


To sum up there is strange error that I get on more strange and unclear 
conditions. They were so strange that I had no idea how describe them 
that is why my mail is quite tangled.


My configuration:
A: FC 1, Tomcat 5.5.9, Apache httpd 2.0.51, Java 1.5.0_02, Cocoon 2.1.7, 
Daisy 1.3
B: WinXP SP 1, Tomcat 5.5.9, Apache httpd 2.0.51, Java 1.5.0_02, Cocoon 
2.1.7, Daisy 1.3


Both tested using Firefox 1.0.7 and IE 6.0.

I would be very thankful for any hints where to search, maybe some tools 
to monitor data transmited on ports? I really don't have idea what to do 
next :/


[1] http://cocoondev.org/daisydocs-1_3/admin/99.html

This is full exception:


 Problem in creating the Request

Message: Malformed stream: Read timed out

Description: org.apache.cocoon.servlet.multipart.MultipartException: 
Malformed stream: Read timed out


Sender: org.apache.cocoon.servlet.CocoonServlet

Source: Cocoon Servlet

cause

org.apache.cocoon.servlet.multipart.MultipartException: Malformed stream: Read 
timed out

request-uri

/warsztat/daisy/warsztat/g2/g1/17/edit/4e86451f4400448e6f2a71526c443a33782e241b

full exception chain stacktrace

org.apache.cocoon.servlet.multipart.MultipartException: Malformed stream: Read 
timed out
at 
org.apache.cocoon.servlet.multipart.MultipartParser.parsePart(MultipartParser.java:175)
at 
org.apache.cocoon.servlet.multipart.MultipartParser.parseMultiPart(MultipartParser.java:128)
at 
org.apache.cocoon.servlet.multipart.MultipartParser.getParts(MultipartParser.java:101)
at 
org.apache.cocoon.servlet.multipart.MultipartParser.getParts(MultipartParser.java:107)
at 
org.apache.cocoon.servlet.multipart.RequestFactory.getServletRequest(RequestFactory.java:94)
at 
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1029)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at 
net.mmogspot.warsztat.helpers.HibernateFilter.doFilter(HibernateFilter.java:30)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at 
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

stacktrace

org.apache.cocoon.servlet.multipart.MultipartException: Malformed stream: Read 
timed out
at 
org.apache.cocoon.servlet.multipart.MultipartParser.parsePart(MultipartParser.java:175)
at 
org.apache.cocoon.servlet.multipart.MultipartParser.parseMultiPart(MultipartParser.java:128)
at 
org.apache.cocoon.servlet.multipart.MultipartParser.getParts(MultipartParser.java:101)
at 
org.apache.cocoon.servlet.mul

Re: Cocoon Fat Test

[Stefano Mazzocchi]

Leszek Gawron wrote:

Carsten Ziegeler wrote:


And I agree, not having the "jx" transformer/generator in the core
anymore is really annoying. If you forget to include the template block
it breaks your application immediately. But I hope we will fix this, as
well.


I do not get it. It's like saying "if you forget to tank your car will 
stop - how annoying" :). What I mean is that the same problem applies to 
any block (i.e. forms). It's just jx and forms tend to be most "core" ones.


I think it was a good decision to move jx from core to it's own block.

It's a stupid work to customize cocoon blocks - this is the biggest 
problem. I agree with Stefano. My local.blocks.properties should state:


exclude.all.blocks=true
include.block.forms=true
include.block.template=true

that's all. Someone said some time ago to use :s/#include/include. Try 
to merge your customized local.blocks.properties with updated main 
blocks.properties file.


Agreed. I never said it was annoying to move stuff out, I don't mind to 
have to specify what blocks to add, but I want this to be easy not a 
PITA like it is today.


My local.blocks.properties should look like Leszek wrote above. Easy and 
simple. That would make us go a long way forward.


--
Stefano.

Re: Cocoon Fat Test

[Mark Lundquist]

On Oct 7, 2005, at 1:00 PM, Leszek Gawron wrote:

I do not get it. It's like saying "if you forget to tank your car will 
stop - how annoying" :). What I mean is that the same problem applies 
to any block (i.e. forms). It's just jx and forms tend to be most 
"core" ones.


I think it was a good decision to move jx from core to it's own block.



I agree.
—ml—

Re: Cocoon Fat Test

[Leszek Gawron]

Carsten Ziegeler wrote:

And I agree, not having the "jx" transformer/generator in the core
anymore is really annoying. If you forget to include the template block
it breaks your application immediately. But I hope we will fix this, as
well.
I do not get it. It's like saying "if you forget to tank your car will 
stop - how annoying" :). What I mean is that the same problem applies to 
any block (i.e. forms). It's just jx and forms tend to be most "core" ones.


I think it was a good decision to move jx from core to it's own block.

It's a stupid work to customize cocoon blocks - this is the biggest 
problem. I agree with Stefano. My local.blocks.properties should state:


exclude.all.blocks=true
include.block.forms=true
include.block.template=true

that's all. Someone said some time ago to use :s/#include/include. Try 
to merge your customized local.blocks.properties with updated main 
blocks.properties file.


--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: [vote] Ross Gardler as a new Cocoon committer

[Tim Larson]

On Wed, Oct 05, 2005 at 10:43:59AM +0200, Daniel Fagerstrom wrote:
> Hi all!
> 
> I'd like to propose Ross Gardler as a Cocoon committer. He is one of the 
> driving forces in the Forrest project, he has been quite active in our 
> documentation efforts and in integrating Forrest, Lenya and Cocoon. 
> Becoming a Cocoon committer will simplify his work and bring our 
> communities closer.
> 
> Please cast you votes.

+1

--Tim Larson

RE: [vote] Ross Gardler as a new Cocoon committer

[Nathaniel Alfred]

> I'd like to propose Ross Gardler as a Cocoon committer. 

Sure +1.

Cheers, Alfred.
 
 
This message is for the named person's use only. It may contain confidential, 
proprietary or legally privileged information. No confidentiality or privilege 
is waived or lost by any mistransmission. If you receive this message in error, 
please notify the sender urgently and then immediately delete the message and 
any copies of it from your system. Please also immediately destroy any 
hardcopies of the message. You must not, directly or indirectly, use, disclose, 
distribute, print, or copy any part of this message if you are not the intended 
recipient. The sender's company reserves the right to monitor all e-mail 
communications through their networks. Any views expressed in this message are 
those of the individual sender, except where the message states otherwise and 
the sender is authorised to state them to be the views of the sender's company.

DO NOT REPLY [Bug 36967] New: - redundant copying between container and form encoding

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36967

   Summary: redundant copying between container and form encoding
   Product: Cocoon 2
   Version: 2.1.7
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Even if container and form encoding are the same, String is still copied. It
would be nice to avoid this performance penalty by adding a check in
HttpRequestClass.decode().

Background: e use servlet filter which sets characterEncoding of
ServletHttpRequest in front of cocoon, so form re-encoding by cocoon is not
needed. Most natural way to skip it would be to set same default encodings in
Cocoon servlet parameters.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [RT] contrib directory

[Gregor J. Rothfuss]

Bertrand Delacretaz wrote:
We talked about that this morning with Jeremy at the GT: how about 
creating a "contrib" directory in our repository, for stuff that we want 
to stay available, without being directly tied to our releases.


would that replace the sandbox?

Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)

[Berin Loritsch]

Andrew Savory wrote:

In all seriousness, the biggest lesson from the Ruby on Rails  
project that Cocoon can learn is the power of convention.  One of  
the biggest things that contributes to the high learning curve of  
Cocoon is the lack of convention.



Not just the lack of convention but also the lack of good sample apps  
(solved by Bertrand with the bricks-cms) and of a decent generator of  
templates (temporarily done by raccoon but hopefully soon by m2  
archetypes).


This morning I asked if Cocoon is too complex for convention, or if  
we simply have a logistical problem - lack of time to define suitable  
conventions. It looks like you've given us a starting point!


Its largely a lack of knowing where to start.  As to the sample apps--I 
agree to a point.  If you don't have the convention to build the sample 
app with, how is the potential user going to know what they are looking 
at?  In other words what are they going to walk away with when the look 
at a sample app?



Model
-
The Rails model is one of the most powerful aspects of the whole  
framework.  I'm not going to go into the whole ActiveModel  
architecture other than to say that the model lives in the app/ 
models/ directory and the class name is the singular form of the  
concept (i.e. LogEntry) and the backing database table is the  plural 
form (i.e. LogEntries).  Using convention to map class  methods to 
tables and records is a very powerful aspect that beats  out anything 
else in the Java world.  It would be a project in and  of itself to 
write a replacement for this piece--which is not  something I would 
recommend for CRACK.



I got a little way down this path using XSLT and the SQLTransformer  
(crude but it worked). We can go a long way using JDBI (http:// 
jdbi.codehaus.org/) and DdlUtils (http://db.apache.org/ddlutils/).  
Hopefully Sylvain will be able to commit his JDBI flowscript wrapper  
as a start.



SQLTransformer is evil (it should have been deprecated and done away 
with back in the early 2.0 days).  Again, its mixing the concerns.  A 
proper model is a separate entity that can be easily referenced, 
modified and controlled through the controller and then examined from 
the view.  It should not be mixed in with the view.



View

In the CRACK version matching the /login/index URL, we would look  
for (in this order) a .jx file, a .xml file, or a .xsp file that  
matches the name of the action "index".  More clearly, in that  
example CRACK would look for app/views/login/index.jx first, and  
then substitute the other extensions in case they are there.  The  
Rails view framework also allows fragments that can be embedded in  
other views, but this is good enough for now.



I think views are one of the areas where RoR is the weakest, and  
where we can make the most significant improvements - for example  
thinking in terms of a CRACK view being index.jx/xml coupled with an  
associated xslt by default.


Amazingly, it is good enough for many uses.  I like the simplicity of 
being able to specify the JXL as the generator portion and then 
finishing the pipeline with the layout.  "It just works" for the 80/20 rule.



Changes to Cocoon
-
In order to support something like this, we don't have to make  
fundamental changes to Cocoon.  In fact, all we have to do is  
provide an alternate Sitemap implementation that uses reflection to  
find the controller class and build the pipeline based on the view  
source, the layout location, etc.



Or a tool to one side of core Cocoon that provides these features,  
and can also generate the default layout etc?


When the base convention is defined, it is easy to add the code 
automation scripts to support that convention.  Again, reasonable 
defaults also help.  That allows the user to concentrate on one thing at 
a time.

Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)

[Sylvain Wallez]

Berin Loritsch wrote:




Where CRACK is Better
-
Ruby on Rails is highly HTML centric.  That's ok because 80% of all 
web applications are HTML centric.  However, we can leverage a 
convention that they started in a more powerful way.  In addition to 
the normal View conventions, Rails also has the concept of a layout.  
You can apply the same layout to all the views in your application.  
Now, remember that I said that Rails doesn't support extensions 
(.html, .png, etc.).  We can set up a set of layouts that are 
essentially the finishing pipeline for the application.  By specifying 
a generic page markup we can provide default layouts, but the 
convention would work like this:


* The layout has a base name such as "site" which is how the layout 
would be specified in the controller.
* The XSLT layout naming convention would be {name}2{ext}.xsl, and we 
would automatically select the serializer mapped to the {ext} name.
 - Example: login/index.html using the "site" layout would transform 
the standard markup using the "site2html.xsl" file and use the "html" 
serializer.
 - This allows us to also render a "site2pdf.xsl" using the "pdf" 
serializer for /article/show/3.pdf



Funny, I just wrote something similar for my current project (simplified 
as it's a form pipeline):



 
 
   
 
   
   
 
   
   
 


What that means is that all pages are using the common "style.xsl" 
stylesheet except if a specific "page-xxx.xsl" file exist. It then 
overrides the common styling.


Define this selector and transformers snippet as a virtual component and 
you have a transformer that uses convention over configuration and yet 
allows people to add some specific styling if ever needed.



Changes to Cocoon
-
In order to support something like this, we don't have to make 
fundamental changes to Cocoon.  In fact, all we have to do is provide 
an alternate Sitemap implementation that uses reflection to find the 
controller class and build the pipeline based on the view source, the 
layout location, etc.



We can do that right now with flowscript. Something along these lines:



function frontend() {
   var path = cocoon.request.requestPath;
   var elements = split(path);
   if (this[path[0]]) {
   this[path[0]]();
   }
   if (!cocoon.redirector.hasRedirected) {
   cocoon.sendPage("view-" + path);
   }
}

If the controller function does not exist, or if it did not explictely 
sent a page, then we call the view.


One of the things that would also help _emensely_ is to automatically 
generate a 404 return response if there is no Controller/Action 
match.  There are other things that will help in the process, but I 
believe this is a much more usable way to get baptised into 
Cocoon--and still leverage its power.  Because we would be using 
convention to wire together an application, we have the power to even 
build in some normal conventions for being browser aware by default.  
If the end client's browser is smart enough to handle client side 
styling then we can let it happen--with no more effort required by the 
developer.


Oh, and one more thing: we default to UTF-8 as the default encoding 
all the way through.  There are issues with the ESQL logicsheet 
introducing encoding errors, and a few more other locations.  Just 
because much of the commercial industry seems to be ignoring 
internationalization does not mean we should follow they poor example.


What do you think?  Rosy picture?  BTW, I only used the name CRACK as 
an eye catcher--I'm not expecting the final product to be named that.



I love it. Let's call it Crackoon :-P

Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)

[Berin Loritsch]

Andrew Savory wrote:


Hi Berin,

On 7 Oct 2005, at 15:09, Berin Loritsch wrote:

Here's the deal: Cocoon is a very powerful publishing framework  
adapted to do web applications, and Ruby on Rails is a very  
empowering web application framework that can be adapted for a  
number of purposes.  There are two very different mindsets behind  
the two frameworks--and I believe we can leverage the very potent  
lessons learned from Rails for the Cocoon framework.



I couldn't agree more. In fact, I spoke about this at the GT this  
morning :-)


The full slides with notes, videos etc will be available via the GT  
web site shortly, but until then you can see the basics at http:// 
www.luminas.co.uk/andrew/raccoon.pdf


Your SHRT goes into rather more technical detail than I managed.



Hopefully it can produce some more conversation topics at the GT.

I saw the PDF, but without the comments or extra talking points its hard 
to get much out of it.  I.e. the questions are asked, some great quotes 
(and a really nice looking presentation), but no content to walk away 
with.  Hopefully that can be added in later.


As to the technical detail, I've used Rails and I've used Cocoon--I know 
where things can happen.  Its possible and it can/should be done.

Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)

[Andrew Savory]

Hi Berin,

On 7 Oct 2005, at 15:09, Berin Loritsch wrote:

Here's the deal: Cocoon is a very powerful publishing framework  
adapted to do web applications, and Ruby on Rails is a very  
empowering web application framework that can be adapted for a  
number of purposes.  There are two very different mindsets behind  
the two frameworks--and I believe we can leverage the very potent  
lessons learned from Rails for the Cocoon framework.


I couldn't agree more. In fact, I spoke about this at the GT this  
morning :-)


The full slides with notes, videos etc will be available via the GT  
web site shortly, but until then you can see the basics at http:// 
www.luminas.co.uk/andrew/raccoon.pdf


Your SHRT goes into rather more technical detail than I managed.

In all seriousness, the biggest lesson from the Ruby on Rails  
project that Cocoon can learn is the power of convention.  One of  
the biggest things that contributes to the high learning curve of  
Cocoon is the lack of convention.


Not just the lack of convention but also the lack of good sample apps  
(solved by Bertrand with the bricks-cms) and of a decent generator of  
templates (temporarily done by raccoon but hopefully soon by m2  
archetypes).


This morning I asked if Cocoon is too complex for convention, or if  
we simply have a logistical problem - lack of time to define suitable  
conventions. It looks like you've given us a starting point!



Model
-
The Rails model is one of the most powerful aspects of the whole  
framework.  I'm not going to go into the whole ActiveModel  
architecture other than to say that the model lives in the app/ 
models/ directory and the class name is the singular form of the  
concept (i.e. LogEntry) and the backing database table is the  
plural form (i.e. LogEntries).  Using convention to map class  
methods to tables and records is a very powerful aspect that beats  
out anything else in the Java world.  It would be a project in and  
of itself to write a replacement for this piece--which is not  
something I would recommend for CRACK.


I got a little way down this path using XSLT and the SQLTransformer  
(crude but it worked). We can go a long way using JDBI (http:// 
jdbi.codehaus.org/) and DdlUtils (http://db.apache.org/ddlutils/).  
Hopefully Sylvain will be able to commit his JDBI flowscript wrapper  
as a start.



View

In the CRACK version matching the /login/index URL, we would look  
for (in this order) a .jx file, a .xml file, or a .xsp file that  
matches the name of the action "index".  More clearly, in that  
example CRACK would look for app/views/login/index.jx first, and  
then substitute the other extensions in case they are there.  The  
Rails view framework also allows fragments that can be embedded in  
other views, but this is good enough for now.


I think views are one of the areas where RoR is the weakest, and  
where we can make the most significant improvements - for example  
thinking in terms of a CRACK view being index.jx/xml coupled with an  
associated xslt by default.



Changes to Cocoon
-
In order to support something like this, we don't have to make  
fundamental changes to Cocoon.  In fact, all we have to do is  
provide an alternate Sitemap implementation that uses reflection to  
find the controller class and build the pipeline based on the view  
source, the layout location, etc.


Or a tool to one side of core Cocoon that provides these features,  
and can also generate the default layout etc?


What do you think?  Rosy picture?  BTW, I only used the name CRACK  
as an eye catcher--I'm not expecting the final product to be named  
that.


Raccoon has kind of a ring to it, no? ;-)


Andrew.

--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/

[SHRT] Cocoon on Rails Application Component Kernel (CRACK)

[Berin Loritsch]

SHRT = Semi-Humorous Random Thought

Here's the deal: Cocoon is a very powerful publishing framework adapted 
to do web applications, and Ruby on Rails is a very empowering web 
application framework that can be adapted for a number of purposes.  
There are two very different mindsets behind the two frameworks--and I 
believe we can leverage the very potent lessons learned from Rails for 
the Cocoon framework.  The only real humorous aspect of this post is the 
acronym I came up with above.  In one summary statement:


CRACK: A highly adictive web framework that is very potent.  Side 
affects include loss of weight, faster completion, and eagerness for 
more.  Best selling point: seeing the reaction of saying your a "CRACK Ho".


In all seriousness, the biggest lesson from the Ruby on Rails project 
that Cocoon can learn is the power of convention.  One of the biggest 
things that contributes to the high learning curve of Cocoon is the lack 
of convention.  Because there are so many ways of doing things, the user 
has to learn all of them to determine what is going to be best for the 
project the user is working on.  I belive that this lack of convention 
is even a bigger contributor than all the different XML standards that 
we integrate.  A long time ago Stefano gave the RT on the URL as a 
contract--and rightly so.  The Sitemap was born of that RT allowing 
Cocoon to respect the external contract and the developer to organize 
the filesystem any way they chose.  The Rails solution to the problem is 
the convention of the MVC architecture is also mapped in a logical way 
to the files and class structure.  Let me lay out the convention used:


Controller
--
Rails has a definite mapping of the URL to a controller.  The convention 
is {context}/{controller}/{action}[/{id}] where {context} is the 
location where the app is running, {controller} is the controller class 
that responds to actions, {action} is the method on the controller class 
that is called to process a request, and {id} is an optional piece that 
identifies a specific record.  The controller class is defined in the 
app/controllers/ directory and has a naming convention of 
{name}Controller.  For example a "Login" controller would be named 
"LoginController".  Rails finds the controller based on the URL.  Once 
Rails has the controller it calls the method matching the action.  One 
of the side effects is that the URL does not have any extensions defined 
(i.e. there is no .html or .pdf in the URL).  The job of the controller 
is to do any set up for the request before it allows the action to "fall 
through" to the matching view.


Model
-
The Rails model is one of the most powerful aspects of the whole 
framework.  I'm not going to go into the whole ActiveModel architecture 
other than to say that the model lives in the app/models/ directory and 
the class name is the singular form of the concept (i.e. LogEntry) and 
the backing database table is the plural form (i.e. LogEntries).  Using 
convention to map class methods to tables and records is a very powerful 
aspect that beats out anything else in the Java world.  It would be a 
project in and of itself to write a replacement for this piece--which is 
not something I would recommend for CRACK.


View

The Rails view lives in app/views/{controller}/{action}.  That's right, 
there is a mapping of a set of views directly 1:1 to the controllers.  
In the case of the LoginController there would be an app/views/login/ 
directory, and for each action ("index", "login" etc.) there would be a 
view that corresponds.  In the Ruby on Rails world these are .rhtml 
files so they are analogous to XSP or JXL files.  In fact I would argue 
that it is closer to JXL than XSP.  Once the method in the controller is 
complete, provided the controller did not explicitly send a named page, 
the view is selected from this directory.  In the CRACK version matching 
the /login/index URL, we would look for (in this order) a .jx file, a 
.xml file, or a .xsp file that matches the name of the action "index".  
More clearly, in that example CRACK would look for 
app/views/login/index.jx first, and then substitute the other extensions 
in case they are there.  The Rails view framework also allows fragments 
that can be embedded in other views, but this is good enough for now.


Now, imagine a Cocoon scenario where the user is faced with a blank 
project.  Where to begin...  Using the power of convention, they start 
writing a class named HelloController.java located in the 
app/controllers/ directory.  They add one method called index() to the 
class.  Then they open the browser to 
http://localhost:8000/cocoon/hello--at which point Cocoon compiles the 
HelloController.java class and responds by processing the index() method 
(oh yeah, forgot to mention the convention of the index method being the 
default for any controller).  The user sees an error message saying that 
the view app/views/hello/index.j

DO NOT REPLY [Bug 36472] - Zooloon preview patch

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36472


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

DO NOT REPLY [Bug 25295] - XUL support

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25295


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-10-07 15:37 ---
*** Bug 36472 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

DO NOT REPLY [Bug 36472] - Zooloon preview patch

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36472


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2005-10-07 15:37 ---
Unfortunately this bug or the patch adds nothing new to bug #25295 - on which
I'm currently working.

*** This bug has been marked as a duplicate of 25295 ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

DO NOT REPLY [Bug 36963] New: - reader caching does not consider mime-type

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36963

   Summary: reader caching does not consider mime-type
   Product: Cocoon 2
   Version: Current SVN 2.2
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Changing the mime type on a reader in a caching pipeline does not invalidate its
former usage with another mime type.

Sample:


  


changed to


  


still results in delivery with text/xml. Carsten already saw it at the hackathon
when I played around with XUL.

Jörg

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

[RT] contrib directory

[Bertrand Delacretaz]

We talked about that this morning with Jeremy at the GT: how about 
creating a "contrib" directory in our repository, for stuff that we 
want to stay available, without being directly tied to our releases.


This could contain:
-example apps like bricks-cms
-blocks that we'd like to remove from 2.2 yet keep around, but without 
any guarantees

-useful tools: raccoon, etc.
-more?

Decoupling this stuff from releases would make it easier to release 
more often, and draw a better line between critical, fully supported 
stuff and more experimental or legacy stuff.


WDYT?
-Bertrand

[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 55 projects,
 and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- lenya :  Content Management System


Full details are available at:
http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-07102005.jar
 -Dbuild=build/cocoon-07102005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 

[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 55 projects,
 and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- lenya :  Content Management System


Full details are available at:
http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-07102005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-07102005.jar
 -Dbuild=build/cocoon-07102005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 

Re: svn commit: r306551 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms: formmodel/ generation/ resources/ system/i18n/ transformation/

[Jorg Heymans]

Sylvain Wallez wrote:
> 
> I would like to avoid instruction proliferation in the template
> language. We already have  that does the exact same
> job.
> 
> Any objection for me to remove  (I'm
> ready to commit!)?
> 

yup I missed that one sorry.

+1

Jorg

Re: Re-reading Jar files...

[Vadim Gritsenko]

Niclas Hedhman wrote:

Hi,
We normally don't deal with Jar/zip files, but a case have come up where we 
need to read XML inside zip files, which are modified at times.


The developer added a
src="jar:http://our.server.com/cocoon-mountpoint/zips/abc.zip!file-in-question.xml";
using the standard filegenerator. Works... but doesn't reload.

If a jar:file:///" URL is given, exceptions are thrown when the file is 
changed.


Somehow I think the URLConnection is cached somewhere, which then dictates 
that the Jar file can not be modified, but I am unable to figure out 'where' 
or 'how'. I am not sure if it is the same as the

http://issues.apache.org/bugzilla/show_bug.cgi?id=29365
issue.

Anyone knows what is happening, and what we can do to overcome this?


Try zip: protocol

Vadim

Re: Continuation Time-To-Live Config Not Being Honored

[Kris Schneider]

Bug/enhancement reports are definitely in the plans. I just wanted to
bounce our conclusions off the dev list in case there was something we
missed.

On 10/7/05, Ralph Goers <[EMAIL PROTECTED]> wrote:
>
>
> Kris Schneider wrote:
>
> >I work with Dan and here's the rest of the story:
> >
> >We ran into severe enough problems using flowscript on WebLogic 8.1
> >(Rhino issues, really), that we had to switch to Java flow. As we've
> >gone down that road, we've come to the realization that all of our
> >continuations seem to have a time to live of ten minutes, regardless
> >of how we configure the  element in
> >cocoon.xconf. As it turns out, JavaInterpreter uses a hard-coded,
> >non-configurable value of 60 for continuation time to live. Have
> >we missed anything with regard to being able to configure that aspect
> >of JavaInterpreter?
> >
> >
> The issues with WebLogic are well known to me.  WebLogic includes its
> own version of rhino which is incompatibile with the version used in
> Cocoon 2.1.  You might be able to upgrade to the rhino version used in
> Cocoon 2.2, if you really want Javascript.
>
> Feel free to submit suggestions or patches to the JavaInterpreter if it
> has a bug or doesn't do what you would like.
>
> Ralph
>


--
Kris Schneider 

FYI: 2.2 samples pages reorganized

[Bertrand Delacretaz]

I've just committed the changes that we started yesterday at the 
Hackathon, the first page of samples now shows links to a minimum 
number of samples, the rest being on a different page.


I'd appreciate it if people could give it a try, I haven't had time to 
check all the samples yet.


All formerly existing samples should still be there for now, but the 
page building mechanism is slightly different, so please check if your 
favorite sample is still there.


-Bertrand

Re-reading Jar files...

[Niclas Hedhman]

Hi,
We normally don't deal with Jar/zip files, but a case have come up where we 
need to read XML inside zip files, which are modified at times.

The developer added a
src="jar:http://our.server.com/cocoon-mountpoint/zips/abc.zip!file-in-question.xml";
using the standard filegenerator. Works... but doesn't reload.

If a jar:file:///" URL is given, exceptions are thrown when the file is 
changed.

Somehow I think the URLConnection is cached somewhere, which then dictates 
that the Jar file can not be modified, but I am unable to figure out 'where' 
or 'how'. I am not sure if it is the same as the
http://issues.apache.org/bugzilla/show_bug.cgi?id=29365
issue.

Anyone knows what is happening, and what we can do to overcome this?


Cheers
Niclas 

Re: svn commit: r306551 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms: formmodel/ generation/ resources/ system/i18n/ transformation/

[Reinhard Poetz]

Sylvain Wallez wrote:

I would like to avoid instruction proliferation in the template 
language. We already have  that does the exact same 
job.


Any objection for me to remove  (I'm 
ready to commit!)?


yes, please

--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc






___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: svn commit: r306551 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms: formmodel/ generation/ resources/ system/i18n/ transformation/

[Vadim Gritsenko]

Sylvain Wallez wrote:
I would like to avoid instruction proliferation in the template 
language. We already have  that does the exact same 
job.


Any objection for me to remove  (I'm 
ready to commit!)?


+1!

Vadim

DO NOT REPLY [Bug 34802] - PageLabelLinkService genereate wrong url when using 3 layer tab combine showallnav.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34802


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-07 11:02 ---
The patch you provided was applied as is to both the 2.1.x branch and to the
trunk. Please test this yourself and then close it.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [Docs] Semi-automatic update process of the Cocoon documentation

[Ross Gardler]

David Crossley wrote:

Ross Gardler wrote:


hepabolu wrote:

After talks to several people I feel we need a semi-automatic update 
process of the Cocoon documentation to cocoon.apache.org.



We have always needed this, but not possible with the
current setup of the project publishing mechanism at apache.org
If committers want to help, then subscribe to site-dev at a.o





All sounds great, in fact, most of the "automated" publishing side an be 
done by the ForrestBot. See http://forrest.zones.apache.org/


The forrestbot can publish via various methods including SVN.


...


For Forrest's own website, the committers use a local
forrestbot. Two easy commands and a publish is done:
'build; deploy'. Then we have a cronjob on the server
to do 'svn update'.
See forrest-trunk/etc/publishing_our_site.txt


Actually, that is what I was suggestion for Cocoon in the short term. 
Note the subject is for a "semi-automatic" update process. That is what 
out local "forrest bot" process is (actually for me it is automatic 
because David seems to be the only one who ever runs it ;-)


Use zones for the staging area (using the Forrest zone since it is 
already set up). Committers run locally to actually publish.



That is the method that i recommend at this stage.


+1

Thanks for clarifying David.

Ross

Re: svn commit: r306551 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms: formmodel/ generation/ resources/ system/i18n/ transformation/

[Sylvain Wallez]

[EMAIL PROTECTED] wrote:


Author: jheymans
Date: Thu Oct  6 01:27:55 2005
New Revision: 306551

URL: http://svn.apache.org/viewcvs?rev=306551&view=rev
 




--- 
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/formmodel/Repeater.java 
(original)
+++ 
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/formmodel/Repeater.java 
Thu Oct  6 01:27:55 2005
 


+public void generateValidationMessage(ContentHandler contentHandler) 
throws SAXException {
+if (validationError != null ) {
+contentHandler.startElement(Constants.INSTANCE_NS, 
REPEATER_VALIDATION_MESSAGE_EL, Constants.INSTANCE_PREFIX_COLON + 
REPEATER_VALIDATION_MESSAGE_EL, XMLUtils.EMPTY_ATTRIBUTES);
+this.validationError.generateSaxFragment(contentHandler);
+contentHandler.endElement(Constants.INSTANCE_NS, 
REPEATER_VALIDATION_MESSAGE_EL, Constants.INSTANCE_PREFIX_COLON + 
REPEATER_VALIDATION_MESSAGE_EL);
+}
}
 





--- 
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml 
(original)
+++ 
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml 
Thu Oct  6 01:27:55 2005
@@ -77,7 +77,16 @@
 


+
+
+http://apache.org/cocoon/forms/1.0#template";>
+  
+
+  
+
+
 



I would like to avoid instruction proliferation in the template 
language. We already have  that does the exact same 
job.


Any objection for me to remove  (I'm 
ready to commit!)?


Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

DO NOT REPLY [Bug 33545] - [PATCH] Make StatusGenerator show Cocoon version information

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33545


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-07 10:45 ---
Some comments about the patch :)

  PLEASE USE SPACES, NO TABS!

:)

I also used configure() instead of setup() for showLib flag.
Added source release() for libDirectory.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.

DO NOT REPLY [Bug 36781] - [PATCH] repeater min and maxsize attributes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36781


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Cocoon Fat Test

[Carsten Ziegeler]

Niclas Hedhman wrote:
> 
> However, to me "fatness" in distribution is somewhat moot point nowadays. I 
> have had some concerns over the runtime RAM footprint, but have no conclusive 
> numbers, whether it is a leak problem, or just caching going nuts. Scheduled 
> server restarts doesn't sound like a good solution, but at the moment it is 
> the 'cheapest' thing to do.
> 
Usually there are two reasons for this: the memory cache is becomming to
big or you have a memory leak :) The first one can be handled easily by
configuring the store janitor correctly. As soon as you have configured
this one correctly, the only reason for an out of memory exception is a
real memory leak.
I think if you're using the ordinary Cocoon stuff, we are not aware of
any memory leaks. We did search memory leaks for many customers and most
time, the memory leak was in there own code which we could find very easily.

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Cocoon Fat Test

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
> 
> 
> With a serious diet and an improved build system, cocoon could lose half 
> of its weight and generate webapps that are much more friendly for 
> smaller sites or for inclusion in places where size is an issue.
> 
> But even when size is not an issue, having smaller webapps helps in 
> making users perceive what core functionality the cocoon framework gives 
> them and what is add-on, something that we were never very good at 
> marketing.
> 
> Hope this helps.
> 
Yepp, we are currently working on exactly this with the maven build of
2.2. So with the m2 build system we will not ship libs that we just need
for compilation anymore, like our version of Xalan and so on.

We will also strip down the core, reducing the size and the required
libs even more. And this then will lead to different distributions, like
a minimum core dist, a big "show us everything one", and perhaps more.

And finally, building your webapp will be easy as well, you will just
say, "include this block" in your maven descriptor and the rest is done
by maven.

So, we know where we want to go, we know how it can be done, there are
no real technical problems anymore. All is missing, is just doing it :)

And I agree, not having the "jx" transformer/generator in the core
anymore is really annoying. If you forget to include the template block
it breaks your application immediately. But I hope we will fix this, as
well.

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [VOTE] snapshot "release" of the bricks-cms example app

[Vadim Gritsenko]

Bertrand Delacretaz wrote:
I'd like to  put a snapshot of the bricks-cms [1] example on our 
download servers, so that people can get it without requiring an SVN 
client.


It is not a formal "release", but I'd like to have the community's 
approval before doing it.


Please cast your votes, here's my own:
+1


+1

Vadim

Re: Continuation Time-To-Live Config Not Being Honored

[Ralph Goers]

Kris Schneider wrote:


I work with Dan and here's the rest of the story:

We ran into severe enough problems using flowscript on WebLogic 8.1
(Rhino issues, really), that we had to switch to Java flow. As we've
gone down that road, we've come to the realization that all of our
continuations seem to have a time to live of ten minutes, regardless
of how we configure the  element in
cocoon.xconf. As it turns out, JavaInterpreter uses a hard-coded,
non-configurable value of 60 for continuation time to live. Have
we missed anything with regard to being able to configure that aspect
of JavaInterpreter?
 

The issues with WebLogic are well known to me.  WebLogic includes its 
own version of rhino which is incompatibile with the version used in 
Cocoon 2.1.  You might be able to upgrade to the rhino version used in 
Cocoon 2.2, if you really want Javascript.


Feel free to submit suggestions or patches to the JavaInterpreter if it 
has a bug or doesn't do what you would like.


Ralph

Re: [VOTE] snapshot "release" of the bricks-cms example app

[Ralph Goers]

Bertrand Delacretaz wrote:

I'd like to  put a snapshot of the bricks-cms [1] example on our 
download servers, so that people can get it without requiring an SVN 
client.


It is not a formal "release", but I'd like to have the community's 
approval before doing it.


Please cast your votes, here's my own:
+1

-Bertrand

[1] http://wiki.apache.org/cocoon/BricksCms



+1

DO NOT REPLY [Bug 31275] - Add SitemapPathModule input module

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31275





--- Additional Comments From [EMAIL PROTECTED]  2005-10-07 09:07 ---
Created an attachment (id=16614)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16614&action=view)
patch including the proposed input module

The code in the patch does not use the Environment object (which is internal to
the Cocoon engine) and the CocoonComponentManager.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.