On Thursday, July 22, 2010 02:01:53 pm Ray Ryan wrote:
Thanks for the patch!
We just noticed this ourselves, and a broader patch should soon go in that
includes this fix.
Great.. are we going to be able to extend a RequestFactory with this
patch? I described the issue there:
On Tuesday, August 03, 2010 00:15:14 codesite-nore...@google.com wrote:
Revision: 8452
Author: cromwell...@google.com
Date: Fri Jul 30 17:29:09 2010
Log: Implement ROO-933 and ROO-935. Handle
java.lang.{Byte/Short/Character/Integer/Long/BigDecimal/BigInteger/Date/Flo
at/Double} as return
On Friday, August 06, 2010 00:48:34 codesite-nore...@google.com wrote:
Revision: 8484
Author: cromwell...@google.com
Date: Wed Aug 4 22:08:44 2010
Log: Fix support for null fields and Boolean type types in RequestFactory.
Null fix patch by icsy
Review at
On Friday, August 06, 2010 18:05:04 Ray Cromwell wrote:
I'm going to change it to treat undefined as null. In theory, I could
change RecordJsoImpl to initialize all property fields to null or a
default value, according to JLS semantics, but this just makes the client
code bigger, and JSON
On Saturday, August 07, 2010 22:22:19 codesite-nore...@google.com wrote:
Revision: 8503
Author: rj...@google.com
Date: Sat Aug 7 16:11:36 2010
Log: Fix datatype renderers to handle nulls properly for some primitive
types. We now expect renderers to produce for null, and parsers to
return
On Tuesday, August 17, 2010 12:34:29 Patrick Julien wrote:
Same for Abstract list, yeah, providing a default for showDetails is
nice, making it private is not so much
That's right... you can always create a new SelectionModel to have
something else than showDetails() that is being called, but
On Wednesday, August 18, 2010 12:55:04 Patrick Julien wrote:
On Wed, Aug 18, 2010 at 12:40 PM, John Tamplin j...@google.com wrote:
On Wed, Aug 18, 2010 at 12:15 PM, Patrick Julien pjul...@gmail.com wrote:
As of yesterday, using dev mode in chrome no longer works.
What exactly changed
On Wednesday, August 18, 2010 14:15:55 John Tamplin wrote:
On Wed, Aug 18, 2010 at 2:02 PM, Pascal Patry i...@invalidip.com wrote:
So, I know the issue is located between 8515:8553 but I'm still trying
to locate the offending patch.
Ok, so you know r8515 works fine with the same version
On Wednesday, August 18, 2010 14:36:38 Ray Ryan wrote:
We need a version number for Chrome.
Chrome 5.0.375.126 on Windows 7
GWT Dev plugin 1.0.7263
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Wednesday, August 18, 2010 16:33:04 Ray Cromwell wrote:
I have a feeling this is actually working as its supposed to on Chrome, but
silently failing on the other browsers. The stack trace indicates that a
JSON payload that it thought was a JSO object turned out to be a JS Number,
so the
On Wednesday, August 18, 2010 16:41:39 you wrote:
On Wednesday, August 18, 2010 16:33:04 Ray Cromwell wrote:
I have a feeling this is actually working as its supposed to on Chrome,
but silently failing on the other browsers. The stack trace indicates
that a JSON payload that it thought was
On Thursday, August 19, 2010 13:48:53 rjrjr wrote:
We believe this was fixed at r8572. Can anyone confirm?
sure, won't be long.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Thursday, August 19, 2010 13:48:53 rjrjr wrote:
We believe this was fixed at r8572. Can anyone confirm?
It fixed the latest issue in Firefox, however, Chrome is still broken.
Stack Trace:
java.lang.IllegalArgumentException: invoke arguments: JS value of type int,
expected
On Thursday, August 19, 2010 14:15:56 Ray Ryan wrote:
Your gwt-servlet jar might be stale, try re-genning it. (ant dist-dev)
I don't think, since I'm usually building as:
ant clean; ant buildonly doc; cd distro-source; ant
It did make a difference by fixing Firefox completely. The problem is
On Thursday, August 19, 2010 16:36:36 Ray Cromwell wrote:
Could you use the Chrome Inspector to post the JSON payload that came back?
Sure, the response that fails on the client side is:
{result:3,related:{}}
The request here was a RequestObjectLong and I do expect 3 to be the
response of this
On Friday, August 20, 2010 14:24:47 John LaBanca wrote:
Do you see this error every time, or just intermittently?
Every time with a RequestObjectLong. I suspect any other kind of
request using RequestObject would also trigger it.
As I previously mentioned, it's a chrome only issue.
--
On Friday, August 20, 2010 15:31:55 John LaBanca wrote:
We tracked it down to a Chrome dev mode oddity. Chrome dev mode adds a
__gwt_ObjectId attribute to all objects passed between Java and JSNI. I'm
testing a simple fix now.
Great, thank you
--
On Friday, August 20, 2010 15:51:10 Amit Manjhi wrote:
Can you try John's fix at http://gwt-code-reviews.appspot.com/760803/show ?
Thanks.
Yes, it won't be long..
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Friday, August 20, 2010 16:05:32 Patrick Julien wrote:
I actually reported this issue already a while back:
http://code.google.com/p/google-web-toolkit/issues/detail?id=5110
On Fri, Aug 20, 2010 at 3:31 PM, John LaBanca jlaba...@google.com wrote:
We tracked it down to a Chrome dev mode
On Friday, August 20, 2010 16:16:02 jlaba...@google.com wrote:
http://gwt-code-reviews.appspot.com/760803/show
Works fine
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Wednesday, September 15, 2010 16:16:06 Patrick Julien wrote:
public String getValue(R object) {
-return renderer.render(object.get(property));
+ProxyImpl proxyImpl = (ProxyImpl) object;
+return renderer.render(proxyImpl.Tget(property, String.class));
}
This blows up on
I'm currently having 2 issues with JsonRequestProcessor.validateKeys().
These requests are coming from updates that we want to perform on entities
that are driven by EntityProxy.
The first issue is with inheritance. We have a base class for all our
entities on the server side in order to not have
22 matches
Mail list logo
