You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Abbott <Ma...@openwave.com> on 2001/08/23 02:50:21 UTC
[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="" />&nbsp;
<img src="" />&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=""></img><img src=""></img>
</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: Request: binary mod_webapp.so for Solaris built with -DEAPI
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Eryq" <er...@zeegee.com> wrote:
> I was using the mod_webapp.so connector for Solaris
> which I downloaded from apache.org
> All was going well until I rebuilt my Apache (1.3.20)
> with SSL support. Now I get:
>
> [warn] Loaded DSO libexec/mod_webapp.so uses plain Apache 1.3 API,
> this module might crash under EAPI! (please recompile it with -DEAPI)
>
> Well, I didn't compile it, so I can't recompile it.
> I expect that a number of other users will be in the same boat.
>
> Is there any compelling reason not to build with -DEAPI?
> What will really happen if this mod_webapp.so is used?
It will happen that the NON-EAPI server will complain because of unresolved
dependancies... :(
Pier
Request: binary mod_webapp.so for Solaris built with -DEAPI
Posted by Eryq <er...@zeegee.com>.
I was using the mod_webapp.so connector for Solaris
which I downloaded from apache.org
All was going well until I rebuilt my Apache (1.3.20)
with SSL support. Now I get:
[warn] Loaded DSO libexec/mod_webapp.so uses plain Apache 1.3 API,
this module might crash under EAPI! (please recompile it with -DEAPI)
Well, I didn't compile it, so I can't recompile it.
I expect that a number of other users will be in the same boat.
Is there any compelling reason not to build with -DEAPI?
What will really happen if this mod_webapp.so is used?
--
Eryq
Re: [BUG] Jasper parsing of XML documents
Posted by Mark Abbott <Ma...@openwave.com>.
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:
<tagA><tagB>text</tagB><tagA>
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:
<tagA><tagB></tagB>text<tagB></tagB></tagA>
appears as
<tagA><tagB></tagB><tagB></tagB></tagA>text
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
Re: [BUG] Jasper parsing of XML documents
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 23 Aug 2001, Mark Abbott wrote:
> Date: Thu, 23 Aug 2001 15:04:49 -0700
> From: Mark Abbott <Ma...@openwave.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org, tomcat-dev@jakarta.apache.org
> Subject: 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.
>
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.
> 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?
>
The way I read things, the goal of the spec is that a page in the original
syntax, and the same page in its corresponding XML syntax, should generate
identical output. The rules for transforming JSP syntax to XML syntax say
to embed *all* template text in <jsp:text> elements, which would imply
that (in the XML syntax view of the page) there would be no uninterpreted
template text anywhere *except* inside <jsp:text> tags (suitably escaped
with CDATA as needed).
> Mark
Craig
Re: [BUG] Jasper parsing of XML documents
Posted by Mark Abbott <Ma...@openwave.com>.
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