I can't give a definitive answer, but I can indifinitively (??) say
that there is an ongoing discussion about what to whitelist next, and
there are definite plans to whitelist more code where possible, but
that the XML manipulation stuff would have to have a bit more of an
audit because of some security concerns around file writes and subtle
side-effects in some javax.xml areas.
Again, none of this indicates timeline, and I would be hesitant to
rely on the GAE team to give a timeline on any particular class or
package being whitelisted until they actually get to it - which means
we won't know until it's almost there. The problem is merely deciding
if it'll take less time to remove stax, or less time to wait for the
whitelist, and since we have no data on the latter, it's worth at
least considering the level of effort of the former.
cheers,
Christian.
On 17-Apr-09, at 10:42 , Howard Lewis Ship wrote:
I'm willing to remove Woodstox in 5.2 if neccessary, but I'd prefer to
wait for a definitive statement about StAX being added to the GAE
whitelist.
On Fri, Apr 17, 2009 at 4:22 AM, Ben Gidley <[email protected]> wrote:
I don't think using Stax will help. It is not woodstox that breaks
app
engine but the stax api itself.
Ben Gidley
www.gidley.co.uk
[email protected]
On Fri, Apr 17, 2009 at 11:07 AM, Christian Köberl <
[email protected]> wrote:
While analyzing the Google App Engine problem with Stax I tried to
eliminate the dependency to Woodstox (because i thought it was the
problem).
I found it quite easy to remove the dependency and use "plain"
Stax. So I
thought: why is this dependency necessary? In my opinion
frameworks (like
Tapestry) should minimize dependencies. So why is Woodstox used
instead of
Stax? Is this a performance reason or simply just the feature of
parsing the
DTD header?
Here are the steps to replace Woodstox with Stax (see also
http://derkoe.wordpress.com/2009/04/16/tapestry-51-woodstox/)
* use XMLInputFactory instead of XMLInputFactory2 in
TemplateParserImpl
* remove inputFactory.configureForSpeed(); in TemplateParserImpl
* use XMLStreamReader instead of XMLStreamReader2 in
StaxTemplateParser
* change the dtd() method StaxTemplateParser to (this could be
nicer):
private void dtd() throws XMLStreamException
{
String dtd = reader.getText();
String[] dtdElements = dtd.split(" ");
if(dtdElements.length > 3)
{
String rootName = dtdElements[1];
String publicId = null;
String systemId = null;
if("PUBLIC".equals(dtdElements[2]))
{
publicId = dtdElements[3];
if(dtdElements.length > 4)
systemId = dtdElements[4];
}
else if("SYSTEM".equals(dtdElements[2]))
{
systemId = dtdElements[3];
}
tokenAccumulator.add(new DTDToken(rootName, publicId,
systemId, getLocation()));
}
}
--
Chris
--
View this message in context:
http://n2.nabble.com/Woodstox-dependency-needed--tp2645025p2645025.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Christian Edward Gruber
e-mail: [email protected]
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]