[gwt-contrib] Issue 5549: fix is/has support for boolean properties (issue1272801)
Reviewers: bobv, Description: There are 3 issues: - AutoBean server code incorrectly assume the getter prefix is always get (or rather, 3-chars long) - same thing in the RequestFactory generator (RequestFactoryModel) - and in RequestFactory server code (ReflectiveServiceLayer) I've also replaced the decapitalization code with java.bean.Introspector.decapitalize(). Please review this at http://gwt-code-reviews.appspot.com/1272801/show Affected files: user/src/com/google/gwt/autobean/rebind/model/AutoBeanMethod.java user/src/com/google/gwt/autobean/server/BeanMethod.java user/src/com/google/gwt/autobean/server/BeanPropertyContext.java user/src/com/google/gwt/autobean/server/GetterPropertyContext.java user/src/com/google/gwt/autobean/server/ProxyAutoBean.java user/src/com/google/gwt/requestfactory/rebind/model/RequestFactoryModel.java user/src/com/google/gwt/requestfactory/server/ReflectiveServiceLayer.java user/test/com/google/gwt/autobean/client/AutoBeanTest.java user/test/com/google/gwt/requestfactory/shared/BoxesAndPrimitivesTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Issue 5549: fix is/has support for boolean properties (issue1272801)
http://gwt-code-reviews.appspot.com/1272801/diff/1/3
File user/src/com/google/gwt/autobean/server/BeanMethod.java (right):
http://gwt-code-reviews.appspot.com/1272801/diff/1/3#newcode52
user/src/com/google/gwt/autobean/server/BeanMethod.java:52: String
inferName(Method method) {
Similar to AutoBeanMethod but using Java reflection. Also, contrary to
AutoBeanMethod, it doesn't decapitalize the name.
Note that actually only the GET.inferName is ever called.
http://gwt-code-reviews.appspot.com/1272801/diff/1/6
File user/src/com/google/gwt/autobean/server/ProxyAutoBean.java (right):
http://gwt-code-reviews.appspot.com/1272801/diff/1/6#newcode66
user/src/com/google/gwt/autobean/server/ProxyAutoBean.java:66: Class?
returnType = method.getReturnType();
Oops, I moved that line before factoring inferName into BeanMethod and
forgot to undo the move afterwards.
http://gwt-code-reviews.appspot.com/1272801/diff/1/8
File
user/src/com/google/gwt/requestfactory/server/ReflectiveServiceLayer.java
(right):
http://gwt-code-reviews.appspot.com/1272801/diff/1/8#newcode248
user/src/com/google/gwt/requestfactory/server/ReflectiveServiceLayer.java:248:
return domainClass.getMethod(get + capitalizedProperty);
Should some kind of caching be added? (MapClass?,MapString,Method)
http://gwt-code-reviews.appspot.com/1272801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: This change adds couple of things: (issue1251801)
http://gwt-code-reviews.appspot.com/1251801/diff/11001/12010
File user/src/com/google/gwt/user/server/rpc/XsrfUtils.java (right):
http://gwt-code-reviews.appspot.com/1251801/diff/11001/12010#newcode62
user/src/com/google/gwt/user/server/rpc/XsrfUtils.java:62: public static
T extends Annotation T getClassAnnotation(Class? clazz,
On 2011/01/06 18:52:37, jat wrote:
Rather than copying, I would prefer to simply move it to a more
central location
if you don't want to just use it where it is.
As discussed over IM, AnnotationUtil use JClassType and requires oracle.
http://gwt-code-reviews.appspot.com/1251801/diff/11001/12010#newcode85
user/src/com/google/gwt/user/server/rpc/XsrfUtils.java:85: * consistency
in duplicate cookies handling.
On 2011/01/06 18:52:37, jat wrote:
I don't understand this comment -- why does being package-private help
consistency? Also, it seems like it isn't package-private -- is this
just an
outdated comment?
Yep, outdated comment. Fixed.
http://gwt-code-reviews.appspot.com/1251801/diff/11001/12010#newcode124
user/src/com/google/gwt/user/server/rpc/XsrfUtils.java:124: public
static String getMd5DigestHexString(byte[] input) {
On 2011/01/06 18:52:37, jat wrote:
Use Util.computeStrongName instead of recreating it here.
This brings in a bunch of dependencies (TreeLogger, Utility, TypeOracle,
UnableToCompleteException, etc) to servlet-impl, is that ok?.
Alternatively, I think it'll make sense to have MD5Utils, similar to
Base64Utils in com.google.gwt.user.server, what do you think?
http://gwt-code-reviews.appspot.com/1251801/diff/11001/12015
File user/test/com/google/gwt/user/client/rpc/XsrfTestServiceAsync.java
(right):
http://gwt-code-reviews.appspot.com/1251801/diff/11001/12015#newcode23
user/test/com/google/gwt/user/client/rpc/XsrfTestServiceAsync.java:23:
void setSessionCookieName(String cookieName, AsyncCallbackVoid
callback);
On 2011/01/06 18:52:37, jat wrote:
Should we detect if annotations are placed on the Async interface
instead of the
sync one? That seems like an error that could be easily made, and it
would
result in possibly no protection where it was expected.
I think if we decide to perform those checks then they should not only
be performed for Async interfaces but also on RPC servlets.
Alternatively, we could have an app context initialization parameter
gwt.xsrf.enable_on_all_RPCs, which would enforce XSRF protection on
all RPCs and would help catch misplaced annotations.
Thoughts?
http://gwt-code-reviews.appspot.com/1251801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
