I'll submit your change after the API Checker config file is updated.
We should
just need to add these lines to it:
java.lang.Boolean::FALSE FINAL_ADDED
java.lang.Boolean::TRUE FINAL_ADDED
Great, that sounds good to me. Thanks, John.
http://gwt-code-reviews.appspot.com/1710804/
--
Ok, thanks.
2012/5/29 Rajeev Dayal rda...@google.com
Just verified that you're added to the corporate CLA list. I think I was
looking at an outdated spreadsheet.
You're all good!
On Fri May 25 10:15:54 GMT-400 2012, Alexandre Ardhuin
alexandre.ardh...@gmail.com wrote:
Confirmation
On 2012/05/29 22:07:38, skybrian wrote:
Actually, are we working on dead code? Where is serialize/deserialize
of a
DefaultProxyStore used? I'm looking for the code that calls encode()
and I can't
seem to find it. I traced back usages of ProxyStore to
RequestFactory.getSerializer() but can't
I just updated the CL with a very minor fix: in encode() I saved nextId
+ 1 (so as to never store a '0' and be able to detect a payload
serialized by the old, broken DefaultProxyStore), but never reverted the
+ 1 in the constructor, resulting in skipping a value each time to
serialize/deserialize
Additional note: requestfactory-client.jar is supposed to be used on
Android (not only, but that's one of the advertized goal), so it shouldn't
bundle org.json, as this is already provided by the Android platform:
http://developer.android.com/reference/org/json/package-summary.html
As for
On 2012/05/30 01:39:13, skybrian wrote:
On 2012/05/26 15:20:15, tbroyer wrote:
On 2012/05/25 19:35:47, skybrian wrote:
Having two levels of class nesting is rather confusing. Could you
move the
Driver and other 4 inner classes up a level?
Done.
Do you think the
https://gwt-code-reviews.appspot.com/1646803/diff/1/user/src/com/google/web/bindery/requestfactory/server/Resolver.java
File user/src/com/google/web/bindery/requestfactory/server/Resolver.java
(right):
On Wed, May 30, 2012 at 12:24 PM, Ray Cromwell cromwell...@google.com wrote:
For GWT 2.5, we might be able to use the elemental json
implementation, it has both pure JRE and super-source implementations,
and simultaneously replaces org.json and the com.google.gwt.json
packages.
That'd be
Just created an issue for it on the issue tracker with an attached example
project. The project contains a Place with a constructor that does not
create a valid instance of that place because of missing prototype
assignment. The project can be imported into eclipse and should run out of
the
On 2012/05/30 06:16:52, stephenh wrote:
I'll submit your change after the API Checker config file is
updated. We
should
just need to add these lines to it:
java.lang.Boolean::FALSE FINAL_ADDED
java.lang.Boolean::TRUE FINAL_ADDED
Great, that sounds good to me. Thanks, John.
Thanks for
LGTM. Looks like we're missing the deletion of the 23_24 config file?
http://gwt-code-reviews.appspot.com/1721803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM.
https://gwt-code-reviews.appspot.com/1646803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
We don't delete the old files, we just add a new file.
http://gwt-code-reviews.appspot.com/1721803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/05/30 15:49:24, jlabanca wrote:
We don't delete the old files, we just add a new file.
But maybe we should revert the changes made to the 23_24 file after the
2.4 release was cut out, no?
(re. Many API changes were added to the 2.3_2.4 file because we never
created the 2.4_2.5 config
That would involve creating 2.3-modified jars, syncing to the 2.4
release, and running API Checker, just to update a file that is no
longer used. I'll leave it for the next guy to worry about.
It's convenient to have the history of conf files when creating a new
config file, even if they aren't
committed as r11000.
http://gwt-code-reviews.appspot.com/1721803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Hello,
I rebuilt GWT with the latest in the source tree and am now getting a class
not found exception for com.google.gwt.core.client.GWTBridge in my servlet
RPC implementation. Should that class exist in gwt-servlet.jar? When I add
it to that jar file, the class not found exception goes
The workaround is to inject a server dependency on :gwt-dev, aka
gwt-dev.jar, which supplies that class.
It's a side effect of a refector we did recently, but I haven't reviewed
for what made it become necessary where it wasn't before.
On Tue May 29 16:43:48 GMT-400 2012, Jimo
On Tue, May 29, 2012 at 4:43 PM, Jimo jponei...@gmail.com wrote:
I rebuilt GWT with the latest in the source tree and am now getting a
class not found exception for com.google.gwt.core.client.GWTBridge in my
servlet RPC implementation. Should that class exist in gwt-servlet.jar?
When I add it
I rebuilt GWT with the latest in the source tree and am now getting a
class not found exception for com.google.gwt.core.client.GWTBridge in
my servlet RPC implementation. Should that class exist in
gwt-servlet.jar? When I add it to that jar file, the class not found
exception goes away.
https://gwt-code-reviews.appspot.com/1646803/diff/14003/user/test/com/google/web/bindery/requestfactory/gwt/client/RequestFactoryTest.java
File
user/test/com/google/web/bindery/requestfactory/gwt/client/RequestFactoryTest.java
(right):
Reviewers: rdayal,
Please review this at http://gwt-code-reviews.appspot.com/1722803/
Affected files:
M user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java
Index: user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java
diff --git
Seems like maybe SerializabilityUtil should use shared.GWT.isClient()
instead? It has a setBridgeMethod too, but the type there is
shared.client.GWTBridge, which is in the servlet jar, so should work.
This worked. Patch is here:
http://gwt-code-reviews.appspot.com/1722803
- Stephen
--
LGTM
Thanks, this is one of the cases where server-side code was using code
from c.g.g.*.client and it was working, but that is always going to be
very dangerous. Over time, we should fix all these cases and make it so
server-side code can't even see any client packages.
Do you know what class is referencing c.g.g.client.GWTBridge? There is a
shared version (which the client one derives from) that should be there,
but referencing client code in the server is dangerous.
You could integrate Macker (http://innig.net/macker/index.html) into your
GWT ant
On Wed, May 30, 2012 at 7:09 PM, Jens jens.nehlme...@gmail.com wrote:
You could integrate Macker (http://innig.net/macker/index.html) into your
GWT ant script and define a rule that checks for any reference from
*.server.* to *.client.* packages. May be helpful to detect such
violations.
I got this feedback from someone who requested a rollback but decided to
work around it instead. I wonder how widespread this sort of thing is?
Our use of the editor/driver stuff assumed the editors would be
rebuilt when driver.edit(T) was invoked. This isn't true with this CL,
as the point of
LGTM (assuming tests still pass)
http://gwt-code-reviews.appspot.com/1601806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
28 matches
Mail list logo
