[jira] [Updated] (COCOON-2371) Allow stack traces in default error pages to be disabled
[ https://issues.apache.org/jira/browse/COCOON-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Schultz updated COCOON-2371: Other Info: Patch available > Allow stack traces in default error pages to be disabled > > > Key: COCOON-2371 > URL: https://issues.apache.org/jira/browse/COCOON-2371 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core >Affects Versions: 2.1.13 >Reporter: Christopher Schultz >Priority: Minor > Attachments: COCOON-2371.diff > > > If you want to disable stack traces in Cocoon, you have to completely replace > the default error pages. It should be configurable to disable stack traces on > the default error pages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (COCOON-2371) Allow stack traces in default error pages to be disabled
[ https://issues.apache.org/jira/browse/COCOON-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514144#comment-17514144 ] Christopher Schultz commented on COCOON-2371: - This patch adds two optional parameters to exception2html.xslt: stack-traces and java-stack-traces. They are expected to be strings representing boolean flags and both default to 'true'. Setting java-stack-traces to anything other than 'true' will cause the Java stack trace to be suppressed from the default error page. Setting stack-traces to anything other than 'true' will cause both the Cocoon "stack trace" (the config-file traces and XSLTs) and the Java stack traces to be suppressed. > Allow stack traces in default error pages to be disabled > > > Key: COCOON-2371 > URL: https://issues.apache.org/jira/browse/COCOON-2371 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core >Affects Versions: 2.1.13 >Reporter: Christopher Schultz >Priority: Minor > Attachments: COCOON-2371.diff > > > If you want to disable stack traces in Cocoon, you have to completely replace > the default error pages. It should be configurable to disable stack traces on > the default error pages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (COCOON-2371) Allow stack traces in default error pages to be disabled
[ https://issues.apache.org/jira/browse/COCOON-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Schultz updated COCOON-2371: Attachment: COCOON-2371.diff > Allow stack traces in default error pages to be disabled > > > Key: COCOON-2371 > URL: https://issues.apache.org/jira/browse/COCOON-2371 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core >Affects Versions: 2.1.13 >Reporter: Christopher Schultz >Priority: Minor > Attachments: COCOON-2371.diff > > > If you want to disable stack traces in Cocoon, you have to completely replace > the default error pages. It should be configurable to disable stack traces on > the default error pages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (COCOON-2371) Allow stack traces in default error pages to be disabled
Christopher Schultz created COCOON-2371: --- Summary: Allow stack traces in default error pages to be disabled Key: COCOON-2371 URL: https://issues.apache.org/jira/browse/COCOON-2371 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.1.13 Reporter: Christopher Schultz If you want to disable stack traces in Cocoon, you have to completely replace the default error pages. It should be configurable to disable stack traces on the default error pages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] Commented: (COCOON-2270) Cocoon fails to find files when deployed into a directory containing a '#' character
[ https://issues.apache.org/jira/browse/COCOON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773554#action_12773554 ] Christopher Schultz commented on COCOON-2270: - Also, using %23 ought to have converted a # (meaning anchor) into a literal # (meaning part-of-the-path). Why does this not work as I expect? > Cocoon fails to find files when deployed into a directory containing a '#' > character > > > Key: COCOON-2270 > URL: https://issues.apache.org/jira/browse/COCOON-2270 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.1.11 >Reporter: Christopher Schultz > > I have been using Cocoon 2.1.10 and 2.1.11 for quite some time with a handful > of modest pipelines using XSLTs on the local disk. > Recently, I've been building a development server to be shared among several > developers on our team. In order to share HTTP ports and URL spaces, we've > chosen to use URL spaces like "/[username]/[appname]" rather than simply > "/[appname]" as we've used in the past. > We use Apache Tomcat 5.5 as our app server, and the proper way to deploy a > web application with a / in its context name is to use either a WAR file such > as [username]#[appname].war, or a directory with the same name (minus the > ".war", of course). > When we do this, we find that Cocoon gets tripped-up, apparently confused by > the # symbol in the path name. It can't find our templates on the disk > (maybe?) and it's also failing to find its own "exception2html.xslt" file. > Cocoon has been deployed into this directory: > /home/cschultz/projects/cocoon/app/webapps/cschultz#chadis > Our top-level sitemap has the default exception handler configuration: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When we try to execute our transformers, we get the following error: > Message: > /home/cschultz/.webapps/cocoon/8225/webapps/stylesheets/system/exception2html.xslt > (No such file or directory) > If you notice, this path is not correct. It should be: > /home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt > Note that the path element after "webapps" has been removed. > I have tried changing the path to the exception stylesheet in the top-level > sitemap to: >src="/home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt"> > But this results in the following error: > Message: /home/cschultz/.webapps/cocoon/8225/webapps/cschultz (No such file > or directory) > Note the path is truncated at the '#' symbol. > Finally, I tried changing the path to: >src="/home/cschultz/.webapps/cocoon/8225/webapps/cschultz%23chadis/stylesheets/system/exception2html.xslt"> > Message: Did not find the stylesheet root! > Description: org.apache.cocoon.ProcessingException: Unable to get transformer > handler for > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43 > full exception chain stacktrace > org.apache.cocoon.ProcessingException: Unable to get transformer handler for > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43 > at > org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:339) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:398) > at > org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:718) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:501) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProce
[jira] Commented: (COCOON-2270) Cocoon fails to find files when deployed into a directory containing a '#' character
[ https://issues.apache.org/jira/browse/COCOON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773545#action_12773545 ] Christopher Schultz commented on COCOON-2270: - Does this mean that # symbols in my file paths are a no-go? It's frustrating that Tomcat (another Apache project) uses a convention that Cocoon cannot tolerate. :( > Cocoon fails to find files when deployed into a directory containing a '#' > character > > > Key: COCOON-2270 > URL: https://issues.apache.org/jira/browse/COCOON-2270 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.1.11 >Reporter: Christopher Schultz > > I have been using Cocoon 2.1.10 and 2.1.11 for quite some time with a handful > of modest pipelines using XSLTs on the local disk. > Recently, I've been building a development server to be shared among several > developers on our team. In order to share HTTP ports and URL spaces, we've > chosen to use URL spaces like "/[username]/[appname]" rather than simply > "/[appname]" as we've used in the past. > We use Apache Tomcat 5.5 as our app server, and the proper way to deploy a > web application with a / in its context name is to use either a WAR file such > as [username]#[appname].war, or a directory with the same name (minus the > ".war", of course). > When we do this, we find that Cocoon gets tripped-up, apparently confused by > the # symbol in the path name. It can't find our templates on the disk > (maybe?) and it's also failing to find its own "exception2html.xslt" file. > Cocoon has been deployed into this directory: > /home/cschultz/projects/cocoon/app/webapps/cschultz#chadis > Our top-level sitemap has the default exception handler configuration: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When we try to execute our transformers, we get the following error: > Message: > /home/cschultz/.webapps/cocoon/8225/webapps/stylesheets/system/exception2html.xslt > (No such file or directory) > If you notice, this path is not correct. It should be: > /home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt > Note that the path element after "webapps" has been removed. > I have tried changing the path to the exception stylesheet in the top-level > sitemap to: >src="/home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt"> > But this results in the following error: > Message: /home/cschultz/.webapps/cocoon/8225/webapps/cschultz (No such file > or directory) > Note the path is truncated at the '#' symbol. > Finally, I tried changing the path to: >src="/home/cschultz/.webapps/cocoon/8225/webapps/cschultz%23chadis/stylesheets/system/exception2html.xslt"> > Message: Did not find the stylesheet root! > Description: org.apache.cocoon.ProcessingException: Unable to get transformer > handler for > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43 > full exception chain stacktrace > org.apache.cocoon.ProcessingException: Unable to get transformer handler for > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43 > at > org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:339) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:398) > at > org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:718) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:501) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipelin
[jira] Commented: (COCOON-2270) Cocoon fails to find files when deployed into a directory containing a '#' character
[ https://issues.apache.org/jira/browse/COCOON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773522#action_12773522 ] Christopher Schultz commented on COCOON-2270: - I can confirm that changing the # symbol to a - (minus) enabled Cocoon to work correctly. This is a reasonable workaround for us in the short-term, but it should be possible to use file paths (on a disk) containing # marks as deployment directories for Cocoon. > Cocoon fails to find files when deployed into a directory containing a '#' > character > > > Key: COCOON-2270 > URL: https://issues.apache.org/jira/browse/COCOON-2270 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.1.11 >Reporter: Christopher Schultz > > I have been using Cocoon 2.1.10 and 2.1.11 for quite some time with a handful > of modest pipelines using XSLTs on the local disk. > Recently, I've been building a development server to be shared among several > developers on our team. In order to share HTTP ports and URL spaces, we've > chosen to use URL spaces like "/[username]/[appname]" rather than simply > "/[appname]" as we've used in the past. > We use Apache Tomcat 5.5 as our app server, and the proper way to deploy a > web application with a / in its context name is to use either a WAR file such > as [username]#[appname].war, or a directory with the same name (minus the > ".war", of course). > When we do this, we find that Cocoon gets tripped-up, apparently confused by > the # symbol in the path name. It can't find our templates on the disk > (maybe?) and it's also failing to find its own "exception2html.xslt" file. > Cocoon has been deployed into this directory: > /home/cschultz/projects/cocoon/app/webapps/cschultz#chadis > Our top-level sitemap has the default exception handler configuration: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When we try to execute our transformers, we get the following error: > Message: > /home/cschultz/.webapps/cocoon/8225/webapps/stylesheets/system/exception2html.xslt > (No such file or directory) > If you notice, this path is not correct. It should be: > /home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt > Note that the path element after "webapps" has been removed. > I have tried changing the path to the exception stylesheet in the top-level > sitemap to: >src="/home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt"> > But this results in the following error: > Message: /home/cschultz/.webapps/cocoon/8225/webapps/cschultz (No such file > or directory) > Note the path is truncated at the '#' symbol. > Finally, I tried changing the path to: >src="/home/cschultz/.webapps/cocoon/8225/webapps/cschultz%23chadis/stylesheets/system/exception2html.xslt"> > Message: Did not find the stylesheet root! > Description: org.apache.cocoon.ProcessingException: Unable to get transformer > handler for > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43 > full exception chain stacktrace > org.apache.cocoon.ProcessingException: Unable to get transformer handler for > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133 > at - > file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43 > at > org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:339) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:398) > at > org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:718) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcess
[jira] Created: (COCOON-2270) Cocoon fails to find files when deployed into a directory containing a '#' character
Cocoon fails to find files when deployed into a directory containing a '#' character Key: COCOON-2270 URL: https://issues.apache.org/jira/browse/COCOON-2270 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.1.11 Reporter: Christopher Schultz I have been using Cocoon 2.1.10 and 2.1.11 for quite some time with a handful of modest pipelines using XSLTs on the local disk. Recently, I've been building a development server to be shared among several developers on our team. In order to share HTTP ports and URL spaces, we've chosen to use URL spaces like "/[username]/[appname]" rather than simply "/[appname]" as we've used in the past. We use Apache Tomcat 5.5 as our app server, and the proper way to deploy a web application with a / in its context name is to use either a WAR file such as [username]#[appname].war, or a directory with the same name (minus the ".war", of course). When we do this, we find that Cocoon gets tripped-up, apparently confused by the # symbol in the path name. It can't find our templates on the disk (maybe?) and it's also failing to find its own "exception2html.xslt" file. Cocoon has been deployed into this directory: /home/cschultz/projects/cocoon/app/webapps/cschultz#chadis Our top-level sitemap has the default exception handler configuration: When we try to execute our transformers, we get the following error: Message: /home/cschultz/.webapps/cocoon/8225/webapps/stylesheets/system/exception2html.xslt (No such file or directory) If you notice, this path is not correct. It should be: /home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt Note that the path element after "webapps" has been removed. I have tried changing the path to the exception stylesheet in the top-level sitemap to: But this results in the following error: Message: /home/cschultz/.webapps/cocoon/8225/webapps/cschultz (No such file or directory) Note the path is truncated at the '#' symbol. Finally, I tried changing the path to: Message: Did not find the stylesheet root! Description: org.apache.cocoon.ProcessingException: Unable to get transformer handler for file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt at - file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45 at - file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133 at - file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43 full exception chain stacktrace org.apache.cocoon.ProcessingException: Unable to get transformer handler for file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt at - file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45 at - file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133 at - file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43 at org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:339) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:398) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:718) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:501) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:453) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:144) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69) at org.apache.cocoon.components.treeprocessor.sitemap.SwitchSelectNode.invoke(SwitchSelectNode.java:99) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69) at org.apache.cocoon.components.treeprocessor.sitemap.HandleErrorsNode.invoke(HandleErrorsNode.java:90) at org.apache.cocoon.components.treeprocessor.sitemap.ErrorHandlerHelper.prepareErrorHandler(ErrorHandlerHelper.java:182) at org.apache.coco
[jira] Commented: (COCOON-1049) encoding in Content-Type header is not set by serializers
[
http://issues.apache.org/jira/browse/COCOON-1049?page=comments#action_12364504
]
Christopher Schultz commented on COCOON-1049:
-
It turns out that there's a workaround for this problem (see below).
I had assumed that with a serializer such as:
...
UTF-8
...
That the Content-Type would be set to mime-type + encoding --> "text/html;
charset=UTF-8". Apparently, the encoding only sets the charseter encoding for
the Writer that the serializers use, and the Content-Type is only set to the
value of the "mime-type" attribute.
On a (despiration) hunch, I changed my serializer's mime-type to "text/html;
charset=UTF-8" and that worked. The attribute name, then, is misleading. It
actually sets the entire content-type, which is more than just the mime-type.
This fact should at least be indicated in the documentation. If it were,
perhaps a code change might not even be necessary, FWIW.
> encoding in Content-Type header is not set by serializers
> -
>
> Key: COCOON-1049
> URL: http://issues.apache.org/jira/browse/COCOON-1049
> Project: Cocoon
> Type: Bug
> Components: * Cocoon Core
> Versions: 2.1.4
> Environment: Operating System: All
> Platform: PC
> Reporter: Stefan Burkard
> Assignee: Cocoon Developers Team
> Priority: Critical
> Attachments: MimeType.patch.txt
>
> The Cocoon Serializer does not set the encoding in the HTTP-Header, it just
> sets
> the mime-type in the header. additionally, it writes a meta-tag with mime-type
> and encoding in the html.
> if now any component (for example apache webserver) sets a (wrong) default
> encoding in the header, most browsers use this header-encoding and ignore the
> meta-tag-encoding.
> --
> here is an answer from jan uyttenhove from the cocoon-users-group to my
> question
> regarding this issue. i think this could help the developer:
> ATM, Cocoon set the meta content-type tag with the mime-type and the encoding
> of
> the serializer. Furthermore, response.setContentType *is* called, which is one
> of the ways to set the http encoding header. But it is called with argument
> mime-type only, e.g. response.setContentType("text/html"), and we should be
> able
> to do response.setContentType("text/html; charset=utf-8").
> We should be able to set the full content-type (with charset) in
> HttpEnvironment
> or in AbstractProcessingPipeline. I guess that involves changing at least the
> setSerializer(...) in AbstractProcessingPipeline and passing the encoding.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
