Maven Doxia

default XML encoding (UTF-8) or XML encoding set in XML files is ignored: inputEncoding is used instead

Details

  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    4

Description

Encoding can be specified per file, in the XML header: <?xml version="1.0" encoding="xxx"?>, or defaults to UTF-8

But DefaultSiteRenderer class always read files with inputEncoding: reader = new InputStreamReader( new FileInputStream( fullPathDoc ), context.getInputEncoding() );

When the source file is XML (xdoc, xhtml), should use XmlReader from PLXUTILS-11 to detect the XML stream encoding instead.

Test case included in MSITE-239, site-plugin-test14

  1. File
    DOXIA-133_doxia.diff
    05/Aug/07 3:43 AM
    4 kB
    Herve Boutemy
  2. File
    DOXIA-133_doxia.diff
    29/Jul/07 12:07 PM
    6 kB
    Herve Boutemy
  3. File
    DOXIA-133_doxia.diff
    12/Jul/07 12:29 PM
    5 kB
    Herve Boutemy
  4. File
    DOXIA-133_doxia-siterenderer.diff
    12/Jul/07 12:29 PM
    3 kB
    Herve Boutemy

Issue Links

depends upon

Bug - A problem which impairs or prevents the functions of the product. PLXUTILS-11 MXParser can't handle the encoding declaration in XML declaration

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MNG-2932 Encoding chaos

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. DOXIA-278 Character encoding autodetection fails for APT source files

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. DOXIA-345 UTF-8 problems with APT and XDOC format

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MSITE-239 encoding declaration in site.xml is ignored

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Herve Boutemy added a comment -

here are 2 patches to add XML encoding detection for contents that are defined in XML: xdoc, xhtml, docbook, fml

Show
Herve Boutemy added a comment - here are 2 patches to add XML encoding detection for contents that are defined in XML: xdoc, xhtml, docbook, fml
Hide
Permalink
Herve Boutemy added a comment -

see http://docs.codehaus.org/display/MAVENUSER/XML+encoding for the roadmap to XML encoding support in Maven2

Show
Herve Boutemy added a comment - see http://docs.codehaus.org/display/MAVENUSER/XML+encoding for the roadmap to XML encoding support in Maven2
Hide
Permalink
Herve Boutemy added a comment -

re-did the patch with latest trunk revision

Show
Herve Boutemy added a comment - re-did the patch with latest trunk revision
Hide
Permalink
Herve Boutemy added a comment -

patch reworked after the big refactoring in revision 562838.

Show
Herve Boutemy added a comment - patch reworked after the big refactoring in revision 562838.
Hide
Permalink
Vincent Siveton added a comment -

From an API point of view, I am not at ease with Doxia.isXmlSource( String parserId ). I propose you a better approach which sounds better for me:

Doxia.java
...
    /**
     * @param parserId Identifier for the parser to use.
     * @return the parser defining for parserId.
     * @throws ParserNotFoundException if no parser could be found
     * for the given id.
     */
    Parser getParser( String parserId )
        throws ParserNotFoundException;
...
Parser.java
...
    /**
     * @return xml for xml parser, text for text parser
     */
    String getType();
...
DefaultSiteRenderer.java
...
             boolean isXml = doxia.getParser( renderingContext.getParserId() ).getType().equals("xml");
...

Thoughts?

Show
Vincent Siveton added a comment - From an API point of view, I am not at ease with Doxia.isXmlSource( String parserId ). I propose you a better approach which sounds better for me: Doxia.java ... /** * @param parserId Identifier for the parser to use. * @ return the parser defining for parserId. * @ throws ParserNotFoundException if no parser could be found * for the given id. */ Parser getParser( String parserId ) throws ParserNotFoundException; ... Parser.java ... /** * @ return xml for xml parser, text for text parser */ String getType(); ... DefaultSiteRenderer.java ... boolean isXml = doxia.getParser( renderingContext.getParserId() ).getType().equals( "xml" ); ... Thoughts?
Hide
Permalink
Herve Boutemy added a comment -

+1 on Doxia.getParser(String): Parser

-0 on Parser.getType():String
At least, there should be constants for "text" and "xml".
I prefer Parser.isXml() because getType() seems too open for me

Show
Herve Boutemy added a comment - +1 on Doxia.getParser(String): Parser -0 on Parser.getType():String At least, there should be constants for "text" and "xml". I prefer Parser.isXml() because getType() seems too open for me
Hide
Permalink
Vincent Siveton added a comment -

Constants was implicit for me

IMHO isXml() is too specific for an api.

Show
Vincent Siveton added a comment - Constants was implicit for me IMHO isXml() is too specific for an api.
Hide
Permalink
Herve Boutemy added a comment -

why not, today this attribute is used only for encoding algorithm selection, but it could be used more later: such a choice is more extensible
then go for it

Show
Herve Boutemy added a comment - why not, today this attribute is used only for encoding algorithm selection, but it could be used more later: such a choice is more extensible then go for it
Hide
Permalink
Herve Boutemy added a comment -

instead of String constants, why not use int constants, which would more clearly show that not any value can be used: each value has a precise meaning in the code
and the code could switch(parser.getType()) instead of a suite of if (parser.getType().equals(Parser.TYPE_XML)) {} else if...

Show
Herve Boutemy added a comment - instead of String constants, why not use int constants, which would more clearly show that not any value can be used: each value has a precise meaning in the code and the code could switch(parser.getType()) instead of a suite of if (parser.getType().equals(Parser.TYPE_XML)) {} else if ...
Hide
Permalink
Vincent Siveton added a comment -

Patch applied with modifications discussed there.
Thanks again Herve.

Show
Vincent Siveton added a comment - Patch applied with modifications discussed there. Thanks again Herve.

People

  • Assignee:
    Vincent Siveton
    Reporter:
    Herve Boutemy
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: