I currently rate getting a stable 5.1 release out at a higher priority
than GAE compatibility. I'm really in a bug fixing mode now, and
retooling the template parser (again!) is a bit more work than I want
to take on. We do have some very fine tests, so if someone else wants
to take a crack at it,
cool. all valid points. :) :) :)
Alex Kotchnev wrote:
Fernando,
you're so right, I will probably have to wait a few weeks or
months. I mentioned something, as there have been a couple of
discussions on the subject on the list, and on top of that Howard
asked what the showstoppers were to rele
Fernando,
you're so right, I will probably have to wait a few weeks or
months. I mentioned something, as there have been a couple of
discussions on the subject on the list, and on top of that Howard
asked what the showstoppers were to releasing 5.1 . I think that this
is a good way to rephrase t
Ah, check. I'm going to check on that, as I don't think it's a quota,
it's a scaling factor. My apps on my own load balancing
infrastructure can't do better - if I put more threads up, I still
start to incur more latency because of context-switching costs. I
think it's a warning that if
Cool. I think this conversation is probably over.. as to let's wait one
week to see what Howard comes up with..
But let me clarify what I was talking about:
I am talking about concurrent requests (which in my mind translates to #
of request handler threads in tomcat or jetty). And the number
You're not allowed to have any concurrent threads. What do you mean?
Concurrent requests? There's 30 seconds max response on those.
There's 10 cron jobs available... I'm confused. The docs say: "The
total number of requests to the app. The per-minute quotas for
application with billing
Don't forget right now GAE/Java is really really beta. You are only
allowed to have 30 cuncurrent threads? Unless your app is only serving
a small number of users, I can't vote to use GAE/Java for actual
production apps, not yet..
And like someone just said, this just came out a week ago. G
I will use gae to build some small app.It's free.
2009/4/17 Otho
> Yes, the missing referential integrity, the (factual) need to duplicate
> data
> over multiple classes for fast reads and the resulting necessity to
> manually
> cascade writing operations will be a pita for most applications.
>
>
Yes, the missing referential integrity, the (factual) need to duplicate data
over multiple classes for fast reads and the resulting necessity to manually
cascade writing operations will be a pita for most applications.
2009/4/17 Thiago H. de Paula Figueiredo
> On Fri, Apr 17, 2009 at 5:22 AM, Ot
On Fri, Apr 17, 2009 at 5:22 AM, Otho wrote:
> In how far shoult GAE be a showstopper for anything? It is neither the
> promised land, nor some gift from the gods. I would rather find it a
> showstopper, if shady compromises were made just to cater to a somewhat
> castrated platform which is actua
In how far shoult GAE be a showstopper for anything? It is neither the
promised land, nor some gift from the gods. I would rather find it a
showstopper, if shady compromises were made just to cater to a somewhat
castrated platform which is actually only beneficial, if you should happen
to have the
Well, I did, but I wasn't allowed to say anything. ;p
Christian.
On 16-Apr-09, at 23:58 , Thiago H. de Paula Figueiredo wrote:
Em Fri, 17 Apr 2009 00:42:45 -0300, Alex Kotchnev
escreveu:
I'm not sure about everyone else, but for me this is a BIG issue and
is one of the reasons holding me
Em Fri, 17 Apr 2009 00:42:45 -0300, Alex Kotchnev
escreveu:
I'm not sure about everyone else, but for me this is a BIG issue and
is one of the reasons holding me back from moving my app to the 5.1
beta. Most likely I'll hold off on upgrading to 5.1 final if it
doesn't support GAE.
The funny
I'm not sure about everyone else, but for me this is a BIG issue and
is one of the reasons holding me back from moving my app to the 5.1
beta. Most likely I'll hold off on upgrading to 5.1 final if it
doesn't support GAE.
Howard was asking earlier about any showstoppers preventing 5.1 from
moving
I grepped over the tapestry-core sources for "javax.xml.stream" and only
found them imported in TemplateParser and StaxTemplateParser.
Would it then be sufficient to just contribute another TemplateParser which
isn't using Woodstox (maybe the one from 5.0.1.8)?
I just tried to eliminate Woodsto
Can you post your GAE application's folder structure (also how you
integrated tapestry jars in it) and if possible the source of the demo app.
I tried 5.0.18 version and I am getting NoClassDefFoundError on an inner
class corelib.components.Loop$1
I get the same error on the local GAE test serv
I'm getting the same issues. Very frustrating. Something strange is
going on with the Instantiator code that isn't being politely treated
by the appengine.
Christian.
On 12-Apr-09, at 07:05 , ஸ்ரீராம்
கீர்த்தி wrote:
Running a GAE app locally via eclipse and using tapestry 5.0.18, I
g
Running a GAE app locally via eclipse and using tapestry 5.0.18, I get the
following exception:
Actually I am getting the same exception when running locally using 5.1.0.3
and 5.1.0.4.
HTTP ERROR: 500
org/apache/tapestry5/corelib/components/Loop$1
RequestURI=/
Caused by:
java.lang.NoClassDefFou
Thanks Christian K,
Can you post your GAE application's folder structure (also how you
integrated tapestry jars in it) and if possible the source of the demo app.
I tried 5.0.18 version and I am getting NoClassDefFoundError on an inner
class corelib.components.Loop$1
Thanks,
Sriram Keerthy
On Su
I grepped over the tapestry-core sources for "javax.xml.stream" and only
found them imported in TemplateParser and StaxTemplateParser.
Would it then be sufficient to just contribute another TemplateParser which
isn't using Woodstox (maybe the one from 5.0.1.8)?
ben.gidley wrote:
>
> I have jus
I have just spent a bit of time looking into this - the reason is because
google have decided to not allow javax.xml.stream.* to be used on appengine.
Woodstox extends classes in javax.xml.stream - therefore it doesn't.
The bad bit here is, unless Google change their policy, this would suggest
ther
I have Tapestry 5.0.18 working: http://tapestry-mail.appspot.com/
Tapestry 5.1.0.2 does not work on GAE - there seems to be a problem with the
Woodstox Stax2 lib.
--
Chris
http://derkoe.wordpress.com/
--
View this message in context:
http://n2.nabble.com/Java-support-added-to-Google-AppEngin
I am also trying to get this working and have hit a similar issue (I am
using the latest snapshot). It all works fine locally it is only a problem
when uploaded to Google App Engine.
It seems to be because google app engine has restricted the XMLInputFactory
and that seems pretty crucial to tapestr
I'm also trying to get the latest Tapestry running on Java App Engine but now
I got stuck.
Uncaught exception from servlet
java.lang.RuntimeException: Exception constructing service 'TemplateParser':
Error invoking constructor
org.apache.tapestry5.internal.services.TemplateParserImpl(Map, boolea
Oh, I'll be blogging.
Christian.
On Apr 8, 2009, at 11:22 AM, Thiago H. de Paula Figueiredo wrote:
On Wed, Apr 8, 2009 at 12:19 PM, Christian Edward Gruber
wrote:
I'm already on it.
Nice! Please post your impressions here or at a blog. :)
--
Thiago
---
On Wed, Apr 8, 2009 at 12:19 PM, Christian Edward Gruber
wrote:
> I'm already on it.
Nice! Please post your impressions here or at a blog. :)
--
Thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additi
I'm already on it.
Christian.
On Apr 8, 2009, at 11:08 AM, Thiago H. de Paula Figueiredo wrote:
Hi!
Yesterday it was announced that the Google AppEngine now supports Java
applications. Some libraries are already supported, others not.
JavaMail is supported, Hibernate isn't, JPA is, JSF supppo
27 matches
Mail list logo