The GAE team has indicated on the list that they will be further
investigating the non-whitelisted classes towards this end. I don't
want to upstage anything officially announced, but rest assured the
question of what to whitelist is under discussion. What isn't clear
is how fast the particular thing WE want whitelisted will be released,
so I would seriously look at #1 and #2 until we have some sort of
confirmation about #1.
cheers,
Christian.
On 13-Apr-09, at 13:09 , Ben Gidley wrote:
I spent several hours trying to hack around this limitation using
the maven
shade plugin to produce build of woodstox that doesn't reference
javax.xml.stream. I did suceed in this, only to be defeated by an
internal
method of determining which pull parser to pick as it requires you
inherit
off javax.xml.stream.
The bad news is it seems to be nearly impossible without changing
quite a
bit of code.
So it looks like to 5.1 we have 3 options
- Find/create a Stax implementation (probably the simplest is a
patch to
woodstox) that doesn't depend on javax.xml.stream
- Use an alternative template parser when in google app engine
- Hope that google will let us use these classes!
Ben Gidley
www.gidley.co.uk
b...@gidley.co.uk
On Mon, Apr 13, 2009 at 4:57 PM, Jun Tsai <jun.t...@gmail.com> wrote:
The main exception:
java.lang.RuntimeException: Exception constructing service
'TemplateParser': Error invoking constructor
org.apache.tapestry5.internal.services.TemplateParserImpl(Map,
boolean) (at TemplateParserImpl.java:50)
via
org
.apache
.tapestry5.internal.services.InternalModule.bind(ServiceBinder)
(at InternalModule.java:65) (for service 'TemplateParser'):
* Could not initialize class
com
.google
.apphosting
.runtime.security.shared.stub.javax.xml.stream.XMLInputFactory*
at
org
.apache
.tapestry5
.ioc
.internal
.services
.JustInTimeObjectCreator
.obtainObjectFromCreator(JustInTimeObjectCreator.java:78)
at
org
.apache
.tapestry5
.ioc
.internal
.services
.JustInTimeObjectCreator.createObject(JustInTimeObjectCreator.java:
57)
at
$
TemplateParser_120a00c1dda.delegate($TemplateParser_120a00c1dda.java)
at
$
TemplateParser_120a00c1dda
.parseTemplate($TemplateParser_120a00c1dda.java)
at
org
.apache
.tapestry5
.internal
.services
.ComponentTemplateSourceImpl
.parseTemplate(ComponentTemplateSourceImpl.java:151)
I think the red line is main reason.
2009/4/13 Howard Lewis Ship <hls...@gmail.com>
I chose Stax because parsing using SAX had gotten so complicated
that
it was hard to add the many new features I wanted in 5.1. Anythings
possible, but I'd like to see how flexible the GAE people are in
terms
of opening up the STAX API.
On Mon, Apr 13, 2009 at 8:11 AM, Christian Edward Gruber
<christianedwardgru...@gmail.com> wrote:
It's the stax dependency on javax.xml.stream for the moment.
Howard,
any
thoughts about having an alternate template processor? It's
injected,
so
would that be feasible?
Christian.
On 13-Apr-09, at 11:10 , dwi ardi irawan wrote:
wow, cool....how bout tapestry 5.1 ? any progress so far ? just
curious...
--
http://dwiardiirawan.blogspot.com
"cos everyone could be extraordinary...lighten up !"
Christian Edward Gruber
e-mail: christianedwardgru...@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
regards,
Jun Tsai
Christian Edward Gruber
e-mail: christianedwardgru...@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
