[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-dev
Subject:    [jira] Commented: (WW-2594) XSL errors in action of type="xslt"
From:       "Victor Voronenko (JIRA)" <jira () apache ! org>
Date:       2008-04-28 1:19:05
Message-ID: 598170572.1209345545803.JavaMail.jira () brutus
[Download RAW message or body]


    [ https://issues.apache.org/struts/browse/WW-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43758#action_43758 \
] 

Victor Voronenko commented on WW-2594:
--------------------------------------

Sorry, but this issue IS NOT QUITE RESOLVED.

The XSLTResult class with enchanced error handling added by Don still can generate \
the UNCAUGHT EXCEPTION, for example for <xsl:include>.

The error occurrs in execute() method right BEFORE Don's code that would set the \
transformer.setErrorListener:

if (location != null) {
    templates = getTemplates(location);
    transformer = templates.newTransformer(); // <---------- here \
(java.lang.NullPointerException) } else
    transformer = TransformerFactory.newInstance().newTransformer();

The error message is:
ERROR [com.tss.admin.revreal.transform.XSLTResult] - Unable to render XSLT Template, \
'/WEB-INF/xsl/dealSheet.xsl' java.lang.NullPointerException

SystemErr R (Location of error unknown)Cannot handle procotol of resource \
/WEB-INF/xsl/applicationUtils.xsl

This misspelled word from the message can serve as a marker to find the origin of an \
error: "p r o c o t o l " ("proCoTol" instead of "proToCol").

Googling this issue may bring a very old advice from Don to add the "request:" prefix \
to included path, something like this: <xsl:include \
href="request:/WEB-INF/xsl/applicationUtils.xsl"/>

Unfortunately, does not work for me. 

> XSL errors in action of type="xslt" generate uncatchable exceptions
> -------------------------------------------------------------------
> 
> Key: WW-2594
> URL: https://issues.apache.org/struts/browse/WW-2594
> Project: Struts 2
> Issue Type: Bug
> Environment: Windows XP, WebSphere 6.1.7
> Reporter: Victor Voronenko
> Assignee: Don Brown
> Fix For: 2.1.2
> 
> 
> When XSL file attached to the action of result type="xslt" has even simple error \
> (e.g. missing single quote), then the exception it generates can not caught by any \
> means. JSP defined to handle the result type="error" for this action is ignored and \
> exception is promoted to front-end as HTTP 404 (page not found) error. The \
> situation is not limited by only syntax errors in XSL. The problem is even more \
> generic. Eventually any error during XSLT would break the action and this exception \
> may not be caught. The problem is that XSLT is performed out of Action class and \
> Struts does not offer any way to register an exception handling for this operation. \
> It might be possible to instantiate the XSLTResult class but it is not clear (not \
> documented) if there is a way to set it as default transformation class. Struts \
> should give users means of control over XSLTResult. The best way would be if action \
> classes could implement some XSLT interface with the control over exception \
> handling, URL resolving etc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic