[JAVASERVERFACES_SPEC_PUBLIC-696] Option to suppress xml declaration in Facelets Created: 11/Dec/09  Updated: 01/Aug/14  Resolved: 03/Nov/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Blocker
Reporter: mojavelinux Assignee: rogerk
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Attachments: Text File changebundle.txt    
Issuezilla Id: 696
Status Whiteboard:

size_large importance_large

Tags: adf, changelog_2_1


The XML declaration is added to the Facelets template to make the tooling happy,
but Facelets allows this markup to pass straight through the browser. The
problem is that there are certain browsers which choke (or behave differently)
when the XML declaration is included in the rendered response.

The XML declaration really has no business being in the rendered output, so the
best approach is to have Facelets suppress this markup. But if there are
developers who prefer it, perhaps because they are using Facelets to generate an
XML feed, then there should be a setting somewhere that allows them to control
the terminus of the declaration (either suppressed or passed through). This is
no different than the "omitXmlDeclaration" setting on most XML printers,
including XSLT.

What's odd is that Facelets does not pass through the DTD declaration, which is
arguably even more of a problem. However, there is an easy workaround. Simply
include a DTD-generating tag.

Comment by mojavelinux [ 11/Dec/09 ]

Target milestone.

Comment by mojavelinux [ 11/Dec/09 ]

Also, the same problem exists for CDATA.

We (quoting Andy Schwartz) run into similar problems with CDATA sections. For
example, the following code uses the Trinidad trh:script component to insert a
script into the page:

if (0 < 1) alert("Woohoo! Zero is less than one!");

The CDATA section is meant to apply to the Facelets page itself - not to the
generated content. That is, the CDATA section provides a way to tell the
Facelets parser not to parse the specified character data. This is not intended
to be used as an instruction to the browser (just to Facelets XML parser).
However, Facelets passes the CDATA through to the browser. As a result, in the
case where we render HTML content, we end up with bogus CDATA sections inside of
our generated HTML document, which causes the browsers to get confused.

Comment by driscoll [ 11/Dec/09 ]

Unforunately, unlike the xml declaration (which you'll almost always want to
leave off, thanks MS), CDATA is something that you'll often want to include in
your page.

In fact, CDATA is something that users may want to include in the page sent to
the browser in the same page as a CDATA block that they don't want to send to
the browser. Ick.

In the specific case mentioned, the Trinidad script component, it should be
possible for the component to detect and properly process the included text -
that's what Mojarra does for script tags, in fact.

So, I'd love to see a different example, if anyone has one.

Comment by mojavelinux [ 18/Dec/09 ]

Update target milestone to 2.0 Rev a

Comment by Ed Burns [ 04/Mar/10 ]


Comment by Ed Burns [ 17/May/10 ]

Move to 2.1

Comment by Ed Burns [ 22/Jun/10 ]


Comment by Ed Burns [ 22/Jun/10 ]


Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 22/Jul/10 ]

Move to M4. Add ADF keyword because it's related to issue 697.

Comment by Ed Burns [ 26/Jul/10 ]

Created an attachment (id=262)
Fix for this bug, first iteration.

Comment by Ed Burns [ 27/Jul/10 ]

Fix checked in. r8517

Comment by Hanspeter Duennenberger [ 27/Jul/10 ]


Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Ed Burns [ 01/Nov/10 ]

This needs to be removed from the spec in favor of what we have in <facelets-processing>

Comment by Ed Burns [ 01/Nov/10 ]


Comment by Ed Burns [ 03/Nov/10 ]

Committed revision 8701.
Rolled this out in favor of what we did on issue 490.

Comment by Ed Burns [ 03/Nov/10 ]

Resolved in issue 490.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

Generated at Thu Oct 27 19:38:23 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.