Re: %=x% expression syntax bug in XML jsp?
Hi Craig - I'm curious whether the expert group has discussed what might be done in the future about this unfortunate aspect of JSP. In what I would think would be a really common case in the future, where one wants to design an app using clean, readable, and purely XML templates (perhaps XHTML for example), but editing by hand rather than with some JSP savvy tool, the choices are: * Create a custom tag foo:text which just dumps out the corresponding text tag Wrapping all the tags in every markup of interest is impractical * Write the XML syntax in the way that the JSP compiler expects: jsp:text![CDATA[text y=10 x=]] jsp:expressionxpos/jsp:expression jsp:text![CDATA[test/test/jsp:text This is an unreadable mess, especially considering scaling up to a substantial size of template * Use the JSP syntax, where %= % expressions *are* recognized everywhere. This is not XML any more Cheers - Mark
Re: [BUG] Jasper parsing of XML documents
On the off chance anyone needs to know (and I appear to be the only one who cares about XML syntax issues :) it looks from the code like what Jasper is doing is that, while parsing a tag, it outputs any uninterpreted child tags it encounters, but accumulates all child sections of character data until the end tag of the parent and then writes it all out at once in a single CDATA. This gives the effect I described in a previous mail where a mixture of markup and data comes out of Jasper in a different order, with the CDATA at the end. I guess this means a solution is to wrap all such data in jsp:text tags. Perhaps this is even a requirement; the spec is not entirely clear on the distinction between template data and XML fragments. Most of the time, character data seems to be handled ok by Jasper without the jsp:text tags, but maybe that is misleading and wrong. Does anyone clearly understand the intent of the spec here? Mark
Re: [BUG] Jasper parsing of XML documents
At 04:02 PM 8/23/2001, Craig R. McClanahan wrote: Do you have uninterpreted text that is *not* inside a jsp:text block? I don't think that is actually allowed. I will check with the spec lead. What I actually see is that the following JSP fragment: tagAtagBtext/tagBtagA appears just like that in the output, without wrapping the text in a jsp:text tag. I assumed this was because the text was being considered part of an XML fragment, but the precise definition of that is unclear. However, this JSP fragment: tagAtagB/tagBtexttagB/tagB/tagA appears as tagAtagB/tagBtagB/tagB/tagAtext unless the text is wrapped in a jsp:text, in which case it appears as written in the JSP. I can clearly see where in the Jasper code it does this reshuffling. I tend to agree with you that the first example ought NOT to to work without the jsp:text (unfortunately, since it is convenient), so the fact that it does is a bug. Clarification would be great if you can get it. And the second example should not silently reshuffle the text either; in both cases the parser should flag the lack of a jsp:text as an error, I guess. I'll file a bug on this, since it seems something must be wrong in any case... Thanks! Mark
[BUG] Jasper parsing of XML documents
Has anyone seen this sort of behavior out of Jasper (tc4b7) before? I give it a trivially simple JSP page in XML syntax: ?xml version=1.0 ? jsp:root version=1.2 xmlns:jsp=http://java.sun.com/JSP/Page; html body table tr td img src= /amp;nbsp; img src= /amp;nbsp; /td /tr /table /body /html /jsp:root and then if I view source on the browser (IE), I get: --- html body table tr td img src=/imgimg src=/img nbsp; nbsp; /td /tr /table /body /html Note that one of the non-breaking spaces has migrated from being between the two img tags to being after them both. Thanks - Mark
Re: JSP Document parsing
Hi again - since no one voiced an opinion on the right way to
approach this bug, I've done the simplest possible fix and attached a patch.
This change will cause Jasper to always emit its own hardcoded values
for the xmlns:jsp and version attributes of the jsp:root tag, ignoring any
occurrences of those attributes in documents. This makes processing of
JSP documents consistent whether they were specified in XML or JSP
syntax. I also made the trivial fix to the double end tag problem.
I suspect that a more elaborate solution might be desirable for the version
attribute, since if the document says it is version 1.3 (when we have such
a version), but the compiler only handles 1.2, this ought to indicate a
problem. But I'm not sure how to do that at this point, so this patch gets
past the immediate problems that make valid documents unusable.
Cheers - Mark
Index: XmlOutputter.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
retrieving revision 1.15
diff -u -p --unified=5 -r1.15 XmlOutputter.java
--- XmlOutputter.java 2001/07/25 01:49:10 1.15
+++ XmlOutputter.java 2001/08/20 18:14:35
@@ -126,12 +126,12 @@ public class XmlOutputter {
void addRootAttrs(Attributes attrs) {
jspRootLevel++;
int attrsLength = attrs.getLength();
for (int i = 0; i attrsLength; i++) {
String qName = attrs.getQName(i);
- if (attrs.getQName(i).startsWith(xmlns:jsp)
-jspRootLevel 1) continue;
+ if ((qName.startsWith(xmlns:jsp) ||
+qName.equals(version))) continue;
rootAttrs.addAttribute(attrs.getURI(i), attrs.getLocalName(i),
attrs.getQName(i), attrs.getType(i), attrs.getValue(i));
}
}
@@ -142,18 +142,15 @@ public class XmlOutputter {
rootAttrs.addAttribute(, xmlns, xmlns: + prefix, CDATA, uri);
}
/*
- * Only put the /jsp:root tag when we're dealing
- * with the top level 'container' page.
+ * Don't append the root end tag here because the
+ * getPageData method will append it later.
*/
void rootEnd() {
jspRootLevel--;
- if (jspRootLevel == 0) {
- append(jsp:root);
- }
}
/**
* Append the cdata to the XML stream.
*/
JSP Document parsing
Hi all - I've noticed a couple of problems with Jasper when processing JSP documents, that is, JSP pages authored in the XML syntax. I'm using the tomcat-b7 release. The documents I've tried contain explicit jsp:root elements, as it seems they ought to. Unfortunately, the XmlOutputter class in Jasper, while making an effort to avoid choking on multiple jsp:root elements encountered while processing included pages, does not handle the case where the outermost containing page itself contains such an element. One result is that two /jsp:root end tags get emitted into the page. The more subtle issue has to do with the xmlns:jsp and version attributes on the jsp:root start tag. Jasper inserts hardcoded values for those attributes corresponding to the JSP 1.2 release. But in order to be truly valid, the document itself should contain those attributes (at least version is required). So two instances of each attribute end up in the output, causing the resulting XML stream to be invalid when parsed by, for example, the tag library validator in JSPTL. Maybe the attributes in the outermost containing page ought to override any hardcoded defaults Jasper wants to assert? Or maybe Jasper should report an error if the version attribute in the document doesn't agree with the JSP version it thinks it is processing? What do you think? I may be able to provide diffs for a solution if I was sure what to do. Thanks - Mark
Re: [TC4.0] Disabling debug output...
I believe the Java Language Spec makes specific requirements on the order of evaluation of static finals to facilitate this kind of usage. In the past I have gone so far as to compile test programs and disassemble the byte code and on every JVM I have ever tried, code wrapped in if statements that evaluate a static final boolean doesn't even generate byte code for the contents of the block if the boolean is false. So there is no performance or size penalty. The real problem with this sort of thing is more subtle. How do you control the value of the boolean? Should there be a single public static final in a class that is referred to everywhere? More likely one wants to turn on and off debugging in a single class, or package, or globally, depending on what is being tested. Having to do search and replace on scattered variables is annoying at best. How is the make system coerced into doing debug builds vs production builds in a simple manner, in the absence of a preprocessor? These are specifically the sort of problems the new java.util.logging package in JDK 1.4 is addressing. I believe the philosophy there is to always leave the code in place, be liberal in writing tracing log calls and assume that integer comparisons to decide whether to execute a particular logging call are so cheap that there is essentially no performance penalty at runtime. I am not as familiar with log4j. Cheers - Mark At 08:56 AM 7/19/2001, Craig R. McClanahan wrote: On Wed, 18 Jul 2001, Justin Erenkrantz wrote: On Thu, Jul 19, 2001 at 12:16:27AM +0100, Pier P. Fumagalli wrote: Checking out the source code, I see a lot of // (commented out lines) when debug() is supposed to be called... Can't we have a global constant boolean called DEBUG and replace the // with if (DEBUG), so that we can simply compile in and out the debugging information without touching the sources? Check out org.apache.catalina.connector.warp.Constants and WarpLogger... Old trick we used in JServ. :) I *believe* most Java compilers do not have constant conditional optimizations (they certainly could, but I don't think they did last time I checked). Without that optimization, you must check that value each time you execute the statement. That might hurt. -- justin In trivial experiments a long while back, I seem to recall that this trick worked if your constant was static final. But I haven't looked lately. There are also some cases where you want to be able to set the debug level at runtime, without having to recompile. In such cases, I typically am real liberal about debug statements when first creating a module, and then comment them out (versus removing them) in high-frequency-of-use portions of the code. That way, you've got ready-made debug code to uncomment if you run into problems later. Craig
