tapestry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Zeigler (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TAP5-745) Remove Woodstox-specific Stax implementation usage
Date Fri, 03 Jul 2009 05:04:47 GMT

    [ https://issues.apache.org/jira/browse/TAP5-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726792#action_12726792

Robert Zeigler commented on TAP5-745:

Complicated. :)

http://jira.codehaus.org/browse/WSTX-78 (closed)

talks about the spec saying that getText() on the dtd element returns the "internal subset"
of the DTD (which is true in java 1.6 docs; 1.5 docs (via webservices) says simply: String
value of the DTD).  Basically, what this means is that there is no implementation-independent
manner of dealing with dtd's right now.  Incidentally, the maintenance release of the stax
jsr mentioned in WSTX-78 has been withdrawn.  There's a pending maintenance release now, but,
it doesn't touch dtd's.

I've now tried running the full tapestry-core test suite with the patch with:

  a) woodstox as the underlying parser
  b) stax:stax:1.2.0 as the underlying parser
  c) recompiling with java 1.6 and using the built-in parser

a: fails due to getText() returning the empty string for the DTD
b: likewise fails, but additionally fails due to not supporting external entities
c: worst of all. Can't handle namespace prefixes; at least, it ignores them as the code is
now (plus it would make tapestry require java 1.6, which is a nogo; this was more for my curiosity
than anything else).

At this point, it appears that there is no good way to deal with DTD's via the standard stax
API, but properly dealing with DTD's is critically important since client interpretation of
css depends on the doctype used.   Thus, I'm closing this issue as "won't fix" and woodstox-independence
will have to wait until either:

1) TAP5-713 is resolved or
2) A user who cares about woodstox independence is willing to step up and provide a patch
that actually works (please: be sure to run all of the tapestry-core tests, at least, and
make sure they pass before submitting! And be sure to test with java 1.5!)

> Remove Woodstox-specific Stax implementation usage
> --------------------------------------------------
>                 Key: TAP5-745
>                 URL: https://issues.apache.org/jira/browse/TAP5-745
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions:,,,,,, 5.1
>            Reporter: Christian Köberl
>            Assignee: Robert Zeigler
>            Priority: Critical
>         Attachments: TAP5-745-
> Tapestry uses some special extensions to StaX (out of Woodstox) in the template parser.
This leads to the problem that Tapestry will usually not run on any application server because
the appservers will use their own implementation of Stax.
> There is a workaround but a main stream web application framework should run on JEE compatible
web and application servers without tweaking.
> The main problem is in org.apache.tapestry5.internal.services.TemplateParserImpl.<init>(TemplateParserImpl.java:44).
Here, XMLInputFactory2 is asked for an instance - but XMLInputFactory2 does not implement
the method newInstance. This is delegated to XMLInputFactory. So, the original XMLInputFactory
is used - which returns the platform implementation of Stax.
> Workaround:
> Add the system property below to Application Server (either via startup script or admin
> -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory

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

View raw message