from:"Ryan"

FunkForce, do the math.  If GWT 2.4 came out before the browser was even in 
beta, how could they have tested it?

Now with that said, browsers are generally tested against a multitude of 
different sites.  At least a few of them are using GWT. So it's highly 
improbable that your site won't work at all.  There will be a few things 
off though, for sure.  A border that's not quite right here, a button 10 
pixels off of where it should be there, that kind of thing.

The biggest problem is usually IE.  They allow a meta tag that tells the 
browser render it in version X please that you can put in your base html. 
 That should get you through until you can fix whatever small thing is off.

Ryan

On Monday, August 6, 2012 3:05:55 AM UTC-5, funkforce wrote:

 Thomas,

 Reading this:

 but until then, GWT will have adapt to each new browser version, and your 
 app would have to be recompiled with the newer version of GWT to take 
 advantage of it. 


 Do you meant that if I deploy an app compiled with GWT 2.4 today and in a 
 few weeks a new browser version is released , that app wont work with the 
 new browser? 

 Regards 
 FF

 Den fredagen den 27:e juli 2012 kl. 17:32:15 UTC+2 skrev Thomas Broyer:



 On Friday, July 27, 2012 4:53:43 PM UTC+2, Andrei wrote:

 A few thoughts on the future of GWT.

 1. GWT, as we currently know it, will die. It will be replaced by a more 
 native way of writing apps for the web. This process will take years. 
 Hopefully, GWT will also adjust, keeping its relevance for a long time. 
 Elemental is the step in that direction.

 2. Google wants to kill Java. It started with a lawsuit from Oracle - 
 Google responded by launching Dart and Go. It won't be clear for at least 
 another year if either Dart or Go become viable alternatives to Java. I 
 will not be surprised if both of these efforts will be quietly abandoned by 
 Google now that the threat from Oracle is over. They will most likely make 
 no such decision any time soon, but I would not recommend starting any 
 major projects in Dart for at least another year.


 I absolutely do NOT agree with the above two points.

 Dart isn't there to replace GWT, it's been created to compete with 
 JavaScript (and compile to JavaScript for a smooth transition: you don't 
 want to code your app twice, right?) because the dynamic nature of 
 JavaScript makes it really hard to optimize JS engines.

 And Go has been created to compete with C++, at least for some usage of 
 it (
 http://commandcenter.blogspot.fr/2012/06/less-is-exponentially-more.html)

 Finally, I cannot see a single reason Google would like to kill Java. 
 Sure there was the Oracle lawsuit, but Google has too much dependency on 
 Java. Switching over from Java would likely kill Android, and could cost 
 Google way too much to be a viable move, unless Google would have no other 
 choice (e.g. if Oracle had won the case, but then Oracle would have killed 
 Java, not the other way around).

 3. Even though GWT is not as enthusiastically supported by Google as it 
 should be (in my opinion), I would certainly recommend against forcing your 
 team to learn a completely new platform. If you are a Java shop, GWT is the 
 best available option for any project starting this year.

 4. Web browsers have really matured (i.e. stabilized) over the past 
 couple of years. Unless you are building a cutting-edge 3D game or a 
 web-based replacement for Photoshop, your new GWT app will stay relevant 
 for a decade. It will morph, like all good projects do, but GWT is a very 
 solid foundation for data manipulation, i18n, history management, and page 
 rendering. And you can add as much (or as little) HTML5 and CSS3 on the 
 presentation side as you want - I don't feel like GWT is restricting me in 
 any way.


 +1 to that though (even though you'd have to recompile your app regularly 
 against the updated versions of GWT if you want it to last a decade: 
 browsers have matured, but GWT still has to handle each one of them 
 specifically; in the future maybe we'd have a single permutation across all 
 browsers, but until then, GWT will have adapt to each new browser version, 
 and your app would have to be recompiled with the newer version of GWT to 
 take advantage of it.



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/RFR3SeYai14J.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: RequestFactory Error -- java.lang.IllegalArgumentException: Something other than a Java object was returned from JSNI method

It's already been reported here: 
http://code.google.com/p/google-web-toolkit/issues/detail?id=5778

Looks like it's a devMode only issue.

Ryan

On Wednesday, April 25, 2012 10:14:04 PM UTC-5, Pradeep B Pillai wrote:



 The following is the other error i get  frequently and this seems like 
 its more related to request factory 
 and I dont know why its happening ..Should I open a bug ? 

 I'm using GWT 2.4, browser Chrome 18.0.1025.1065 

 One or more exceptions caught, see full set in 
 UmbrellaException#getCauses - 
  CAUSE java.lang.IllegalArgumentException: Something other than a Java 
 object was returned from JSNI method 
 '@com.google.web.bindery.autobean.gwt.client.impl.ClientPropertyContext 
 $Setter::beanSetter(Lcom/google/web/bindery/autobean/shared/impl/ 
 AbstractAutoBean;Ljava/lang/String;)': JS value of type boolean, 
 expected java.lang.Object 
 java.lang.IllegalArgumentException: Something other than a Java object 
 was returned from JSNI method 
 '@com.google.web.bindery.autobean.gwt.client.impl.ClientPropertyContext 
 $Setter::beanSetter(Lcom/google/web/bindery/autobean/shared/impl/ 
 AbstractAutoBean;Ljava/lang/String;)': JS value of type boolean, 
 expected java.lang.Object 
  STACKTRACE : 
 com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext 
 $StandardPayloadDialect.processPayload(AbstractRequestContext.java: 
 387) 
 com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext 
 $5.onTransportSuccess(AbstractRequestContext.java:1108) 
 com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport 
 $1.onResponseReceived(DefaultRequestTransport.java:136) 
 com.citrix.ws.democenter.module.shared.client.requestfactory.DemoCenterRequestTransport
  

 $1.onResponseReceived(DemoCenterRequestTransport.java:84) 
 com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java: 
 287) 
 com.google.gwt.http.client.RequestBuilder 
 $1.onReadyStateChange(RequestBuilder.java:395) 
 sun.reflect.GeneratedMethodAccessor352.invoke(Unknown Source) 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
  

 25) 
 java.lang.reflect.Method.invoke(Method.java:597) 
 com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103) 
 com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71) 
 com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java: 

 172) 
 com.google.gwt.dev.shell.BrowserChannelServer.reactToMessagesWhileWaitingForReturn(BrowserChannelServer.java:
  

 337) 
 com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:
  

 218) 
 com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java: 
 136) 
 com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java: 
 561) 
 com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java: 
 269) 
 com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:
  

 91) 
 com.google.gwt.core.client.impl.Impl.apply(Impl.java) 
 com.google.gwt.core.client.impl.Impl.entry0(Impl.java:213) 
 sun.reflect.GeneratedMethodAccessor345.invoke(Unknown Source) 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
  

 25) 
 java.lang.reflect.Method.invoke(Method.java:597) 
 com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103) 
 com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71) 
 com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java: 

 172) 
 com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:
  

 292) 
 com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:
  

 546) 
 com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java: 

 363) 
 java.lang.Thread.run(Thread.java:680) 
  from 
 sourceClasscom.google.web.bindery.event.shared.UmbrellaExceptionwith 
 exception com.google.web.bindery.event.shared.UmbrellaException: One 
 or more exceptions caught, see full set in UmbrellaException#getCauses

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/r-_YNz5nAWgJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: RequestFactory Error -- java.lang.IllegalArgumentException: Something other than a Java object was returned from JSNI method

I've been seeing something similar for ages.  My code isn't anywhere in 
this stack trace.  I have no idea what to do.  I'll report it.

java.lang.IllegalArgumentException: Something other than a Java object was 
returned from JSNI method 
'@com.google.gwt.core.client.impl.Impl::apply(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)':
 JS value of type boolean, expected java.lang.Object
at com.google.gwt.dev.shell.JsValueGlue.get(JsValueGlue.java:178)
at 
com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:271)
at 
com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91)
at com.google.gwt.core.client.impl.Impl.apply(Impl.java)
at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:213)
at sun.reflect.GeneratedMethodAccessor181.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)
at 
com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
at 
com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)
at 
com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:292)
at 
com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:546)
at 
com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:363)
at java.lang.Thread.run(Thread.java:619)


Ryan


On Wednesday, April 25, 2012 10:14:04 PM UTC-5, Pradeep B Pillai wrote:



 The following is the other error i get  frequently and this seems like 
 its more related to request factory 
 and I dont know why its happening ..Should I open a bug ? 

 I'm using GWT 2.4, browser Chrome 18.0.1025.1065 

 One or more exceptions caught, see full set in 
 UmbrellaException#getCauses - 
  CAUSE java.lang.IllegalArgumentException: Something other than a Java 
 object was returned from JSNI method 
 '@com.google.web.bindery.autobean.gwt.client.impl.ClientPropertyContext 
 $Setter::beanSetter(Lcom/google/web/bindery/autobean/shared/impl/ 
 AbstractAutoBean;Ljava/lang/String;)': JS value of type boolean, 
 expected java.lang.Object 
 java.lang.IllegalArgumentException: Something other than a Java object 
 was returned from JSNI method 
 '@com.google.web.bindery.autobean.gwt.client.impl.ClientPropertyContext 
 $Setter::beanSetter(Lcom/google/web/bindery/autobean/shared/impl/ 
 AbstractAutoBean;Ljava/lang/String;)': JS value of type boolean, 
 expected java.lang.Object 
  STACKTRACE : 
 com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext 
 $StandardPayloadDialect.processPayload(AbstractRequestContext.java: 
 387) 
 com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext 
 $5.onTransportSuccess(AbstractRequestContext.java:1108) 
 com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport 
 $1.onResponseReceived(DefaultRequestTransport.java:136) 
 com.citrix.ws.democenter.module.shared.client.requestfactory.DemoCenterRequestTransport
  

 $1.onResponseReceived(DemoCenterRequestTransport.java:84) 
 com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java: 
 287) 
 com.google.gwt.http.client.RequestBuilder 
 $1.onReadyStateChange(RequestBuilder.java:395) 
 sun.reflect.GeneratedMethodAccessor352.invoke(Unknown Source) 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
  

 25) 
 java.lang.reflect.Method.invoke(Method.java:597) 
 com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103) 
 com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71) 
 com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java: 

 172) 
 com.google.gwt.dev.shell.BrowserChannelServer.reactToMessagesWhileWaitingForReturn(BrowserChannelServer.java:
  

 337) 
 com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:
  

 218) 
 com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java: 
 136) 
 com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java: 
 561) 
 com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java: 
 269) 
 com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:
  

 91) 
 com.google.gwt.core.client.impl.Impl.apply(Impl.java) 
 com.google.gwt.core.client.impl.Impl.entry0(Impl.java:213) 
 sun.reflect.GeneratedMethodAccessor345.invoke(Unknown Source) 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
  

 25) 
 java.lang.reflect.Method.invoke(Method.java:597) 
 com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103) 
 com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71) 
 com.google.gwt.dev.shell.OophmSessionHandler.invoke

Re: GWT ui:style how big of a bad idea (or not) is it to use it?

I don't use JQuery, and I can't see a reason why you would.  JQuery is 
Javascript, which brings you back into the world of not having your code 
compiled until you (or worse your user) executes it.

If you really want to use JQuery for something, you can always us the 
@external flag.  Then it won't get obstruficated.  

http://code.google.com/p/google-web-toolkit/wiki/CssResource#External_and_legacy_scopes



Ryan

On Saturday, August 4, 2012 9:40:23 AM UTC-5, Nuno Godinho de Matos wrote:

 Hi,
 I am wondering how big a mistake is it to take advantage of the ui:style 
 feature in ui binder interfaces?
 Say your styles are all comprised within ui:style tags, and you always 
 refer to them using the {style.} notation.
 Now, on the browser, this shall all become obfuscated after 
 gwt:compilation, the style name are not recognizable.
 If we were to follow this approach for every style used on the 
 application, wouldn't we also lose the potential of navigating the page dom 
 with css selectors for example using library such as the Jquery gwt wrapper?
 What's the policy here? 
 One should never depend on the defined style names for executing, say, 
 presentation logic such as collapsing dom elements?






-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/vDlEbkLHFNMJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Problem with RequestFactoryGenerator and ExtraTypes annotation

2012-07-11 Thread Ryan McFall

Hi:
 
I have an @ExtraTypes annotation on my RequestContext extension interface 
to pick up proxies associated with inheritance.  For 3 of the 4 developers 
in the group, everything works fine.  For the 4th, when the application is 
started up the Development Mode console window says
Unknown class:  in @ExtraTypes
 
There are two other sub-types in the @ExtraTypes annotation which work 
correctly.
 
I have tried cleaning the project and even deleting the generated 
RequestFactoryDeobfuscatorBuilder.java class in .apt_generated, which has 
worked in the past when I've had issues associated with adding new requests 
or annotations to the RequestContext extension, but this has had no effect.
 
Does anyone have any ideas on what else to try to get this particular 
developer's copy of the project running correctly?  Everything in his 
checkout is up-to-date, and since others have had success updating to the 
version that contains the new proxy interface, I do not think that any 
files are not committed to the repository.
 
Thanks for any suggestions!
Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/9VOnbn5OoAcJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Problems using JavaMail within hosted mode in Eclipse

2012-06-21 Thread Ryan McFall

In trying to configure an SMTPAppender for use with log4j so that error 
reports on the server can be emailed out, I ran into difficulties getting 
JavaMail to work correctly.  I found many posts indicating that the problem 
is either:

   1. multiple copies of the JavaMail classes in the classpath
   2. issues with classloaders, related to the servlet container

To isolate the problem, I created a sample webapp using the GWT Eclipse 
plugin, and modified the auto-generated server-side greet method to log an 
error message, with an appropriately configured log4j.properties file.  The 
only two jar files in the WEB-INF/lib folder are the log4j-1.2.17.jar, 
mail.jar and gwt-servlet.jar files.  The AppEngine is not being used; I've 
seen the docs that mention that the AppEngine jar file contains 
implementations of the javax.mail classes, and that both the AppEngine jar 
and mail.jar should not be present in the classpath.
 
Using this configuration, when the log4j implementation tries to log an 
error message, the following debug info and stack trace is produced:

DEBUG: getProvider() returning 
javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun 
Microsystems, Inc]

java.lang.NoSuchMethodException: : 
com.sun.mail.smtp.SMTPTransport.init(javax.mail.Session, 
javax.mail.URLName)

along with an error message indicating that the SMTP provider can't be 
found:

javax.mail.NoSuchProviderException: smtp

However, I found that if I compile and deploy a much more complicated 
application with basically the same configuration to a Tomcat server, it 
works as expected.  This makes me suspect that the embedded server somehow 
contains mail.jar in its runtime classpath (I can't reference the classes 
in javax.mail in my project unless I include mail.jar in the classpath, so 
I'm positive they don't exist anywhere else in my project).  But, if I 
remove mail.jar from the WEB-INF lib directory and try to do a 
Class.forName on, say, javax.mail.Address, it can't be found.

Anyone have any ideas why this works when I deploy it, but not when running 
within Eclipse?

Thanks,
Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/tCjp7_JZ5WAJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Having domain objects implement EntityProxy - bad idea?

2012-06-12 Thread Ryan McFall

Wow, I'm embarrassed to say that I have always assumed that an interface 
can only extend a single interface, because that's the way that it works 
for classes.  There's no reason it should be that way, though, and it makes 
life a lot easier to know that it's possible.  I would have done it this 
way originally over a year ago had I known this!
 
Thanks,
Ryan

On Tuesday, June 12, 2012 2:53:55 AM UTC-4, Thomas Broyer wrote:

 I can't see any reason it wouldn't work, but I think you'd rather extract 
 an interface, implemented by your domain object, and extended by your proxy 
 (in addition to EntityProxy).

 interface Domain { /* getters and setters */ }

 class DomainImpl implements Domain { … }

 interface DomainProxy extends Domain, EntityProxy { … }

 In case you were wondering, this approach has been proven to work.
 One exception is currently if your Domain interface references another 
 interface (as opposed to simple value types), where you'd face 
 http://code.google.com/p/google-web-toolkit/issues/detail?id=5926
 This issue will be fixed in GWT 2.5.1, which we expect to release by the 
 end of the summer.

 On Monday, June 11, 2012 9:35:02 PM UTC+2, Ryan McFall wrote:

 One of the things I don't like about the design of the RequestFactory 
 is the fact that client-side proxies need to extend EntityProxy; I 
 think I understand why this is needed, but it makes it more difficult 
 to write code that can operate on both proxies and actual domain 
 objects. 

 One way of getting around this is to have the domain objects implement 
 the proxy interface.  This means that the domain objects must 
 implement EntityProxy, giving a stableId method that shouldn't 
 actually be called, but allows utility code to treat proxies and 
 domain objects in the same way. 

 Before going down this route, I'm wondering if there are reasons it 
 won't work that I haven't thought about. 

 Thanks! 
 Ryan


 On Monday, June 11, 2012 9:35:02 PM UTC+2, Ryan McFall wrote:

 One of the things I don't like about the design of the RequestFactory 
 is the fact that client-side proxies need to extend EntityProxy; I 
 think I understand why this is needed, but it makes it more difficult 
 to write code that can operate on both proxies and actual domain 
 objects. 

 One way of getting around this is to have the domain objects implement 
 the proxy interface.  This means that the domain objects must 
 implement EntityProxy, giving a stableId method that shouldn't 
 actually be called, but allows utility code to treat proxies and 
 domain objects in the same way. 

 Before going down this route, I'm wondering if there are reasons it 
 won't work that I haven't thought about. 

 Thanks! 
 Ryan



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/f8stn8zYlUMJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Having domain objects implement EntityProxy - bad idea?

2012-06-11 Thread Ryan McFall

One of the things I don't like about the design of the RequestFactory
is the fact that client-side proxies need to extend EntityProxy; I
think I understand why this is needed, but it makes it more difficult
to write code that can operate on both proxies and actual domain
objects.

One way of getting around this is to have the domain objects implement
the proxy interface.  This means that the domain objects must
implement EntityProxy, giving a stableId method that shouldn't
actually be called, but allows utility code to treat proxies and
domain objects in the same way.

Before going down this route, I'm wondering if there are reasons it
won't work that I haven't thought about.

Thanks!
Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-07 Thread Ryan McFall

I'm well on my way to getting this to work. I can determine whether
the method to be invoked requires authentication, and whether or not
the user is currently authenticated.

Currently, what I've done is defined a new runtime exception and
thrown that exception in my ServiceLayerDecorator if an
unauthenticated user tries to invoke a method requiring
authentication. I've then overridden doPost in my sub-class of
RequestFactoryServlet to catch this exception and set the status code
of the response to be 401.

Unfortunately, this doesn't quite work. I get the following in my
server console when this exception is thrown by my code:

SEVERE: Unexpected error
edu.hope.cs.surveys.editor.server.SessionExpiredException: Session
expired
at
edu.hope.cs.surveys.editor.server.ActiveSessionDecorator.invoke(ActiveSessionDecorator.java:
17)
at
com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.invoke(ServiceLayerDecorator.java:
111)
at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.processInvocationMessages(SimpleRequestProcessor.java:
455)
at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:
225)
at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:
127)
at
com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:
133)
at
edu.hope.cs.surveys.editor.server.JandyRequestFactoryServlet.doPost(JandyRequestFactoryServlet.java:
28)

I see that SimpleRequestProcessor has a setExceptionHandler method
which is responsible for creating a ServerFailure object. Do I need
to provide a custom exception handler to the RequestProcessor? Or is
there some other way of catching the failure caused by the invoke
method of my ServiceLayerDecorator?

Thanks,
Ryan

On Jun 5, 11:13 am, Ashwin Desikan ashwin.desi...@gmail.com wrote:
Thomas is correct. I had tried the route of creating two separate RF's. But
that involves more work in comparison to annotations. In fact I changed my
approach post Thomas suggestion in this forum quite sometime bac

~Ashwin

Sent from my iPhone

On Jun 5, 2012, at 7:38 PM, Thomas Broyer t.bro...@gmail.com wrote:

On Tuesday, June 5, 2012 3:58:22 PM UTC+2, Ryan McFall wrote:
After I wrote my original follow-up to Thomas' message, I thought of
having different services - one for methods that require
authentication, and one for those that don't. Then I can map my
ServletFilter to the URL for the service that requires authentication,
and not map it to those that don't.

That seems easier to me than the annotation route. Anyone have any
reasons to think otherwise?

It won't work. RequestFactoryServlet loads from the classpath, so unless
you somehow constrain the classpath of each servlet to only contain the
classes you want to expose, the unauthenticated servlet would be able to
load the services requiring authentication, therefore allowing
unauthenticated access to them.
In other words, that's not how RF has been designed.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view this discussion on the web
visithttps://groups.google.com/d/msg/google-web-toolkit/-/fl0PLdvGKHUJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/google-web-toolkit?hl=en.

--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-07 Thread Ryan McFall

Thanks, Thomas, I searched through the methods in
ServiceLayerDecorator for something like this, but somehow missed
these.

Using report() from with the ServiceLayerDecorator doesn't allow me to
re-fire the RequestFactory request, giving me the A request is
already in progress error. If I call die() then the exception is
still printed out, but the onFailure method of the Receiver is in fact
called, and I can re-fire the request.

Ryan

On Jun 7, 3:06 pm, Thomas Broyer t.bro...@gmail.com wrote:
If you go the ServiceLayerDecorator route, you can no longer use an HTTP
status detected by a custom RequestTransport, you're pluggin *into* the RF
protocol, not *around* it.
Try using the die() or report() methods from ServiceLayerDecorator and see
how they behave.

On Thursday, June 7, 2012 8:30:35 PM UTC+2, Ryan McFall wrote:

I'm well on my way to getting this to work. I can determine whether
the method to be invoked requires authentication, and whether or not
the user is currently authenticated.

Unfortunately, this doesn't quite work. I get the following in my
server console when this exception is thrown by my code:

SEVERE: Unexpected error
edu.hope.cs.surveys.editor.server.SessionExpiredException: Session
expired
at
edu.hope.cs.surveys.editor.server.ActiveSessionDecorator.invoke(ActiveSessionDecorator.java:

17)
at
com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.invoke(ServiceLayerDecorator.java:

111)
at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.processInvocationMessages(SimpleRequestProcessor.java:

455)
at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:

225)
at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:

127)
at
com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:

133)
at
edu.hope.cs.surveys.editor.server.JandyRequestFactoryServlet.doPost(JandyRequestFactoryServlet.java:

28)

Thanks,
Ryan

On Jun 5, 11:13 am, Ashwin Desikan ashwin.desi...@gmail.com wrote:
Thomas is correct. I had tried the route of creating two separate RF's.
But that involves more work in comparison to annotations. In fact I changed
my approach post Thomas suggestion in this forum quite sometime bac

~Ashwin

Sent from my iPhone

On Jun 5, 2012, at 7:38 PM, Thomas Broyer t.bro...@gmail.com wrote:

That seems easier to me than the annotation route. Anyone have any
reasons to think otherwise?

It won't work. RequestFactoryServlet loads from the classpath, so
unless you somehow constrain the classpath of each servlet to only contain
the classes you want to expose, the unauthenticated servlet would be able
to load the services requiring authentication, therefore allowing
unauthenticated access to them.
In other words, that's not how RF has been designed.
--
You received this message because you are subscribed to the Google
Groups Google Web Toolkit group.
To view this discussion on the web visithttps://
groups.google.com/d/msg/google-web-toolkit/-/fl0PLdvGKHUJ.
To post to this group, send email to
google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group athttp://
groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-05 Thread Ryan McFall

Thanks for the ideas, Thomas.

Two questions on the response:
1.  I was hoping to detect this within my service method, rather than
at a higher level like a servlet filter.  Is it possible to return a
non-200 error code from within the service method?  I tried getting
the thread local HttpResponse object and changing its status code, but
this had no effect.

2.  If I do write a servlet filter, there are only certain service
methods that I want this code to apply to (for example, I use a
service method, rather than the built in servlet authentication to
authenticate the user, and I certainly don't want to require a valid
session during this call).  From what I see in the sample code you
posted, it looks like that application is doing this on every
request.  What is the best way to differentiate which service
method(s) are being called as part of the request?  Are there classes
available that will help me parse the request payload on the server
and identify the methods being called?

Ryan

On Jun 5, 5:21 am, Thomas Broyer t.bro...@gmail.com wrote:
 On Monday, June 4, 2012 10:17:52 PM UTC+2, Ryan McFall wrote:

  I am having issues when I want to resubmit some requests to the server
  when the server-side logic indicates it should happen.  In particular,
  here's what happens:

  1.  The user logins in, which causes an object (SurveyResponseHeader)
  to be created on the server-side, and sent back to the client.  edit
  is then called on the client side on that object.

  2.  The user fills in a set of SurveyResponse objects into a list
  contained by the SurveyResponseHeader object (and a corresponding
  request is made to save the object on the server).

  3.  The user submits the survey responses, but the session has timed
  out on the server.  An error code is sent back to the client, and the
  user is asked to re-authenticate.

  At this point, I want to resubmit the request that caused the error;
  it should succeed on the server now because the session has been
  restarted.  However, I can't use the same request object because I'll
  get the request is already in progress error message.

  Rather than tell you everything I've tried, I'd like to hear what
  people think is the right way to accomplish this.  I can provide more
  details if needed, but I want to keep the description simple at least
  to start.

 You have to make sure you convey the session-expiry-error as a transport
 error or general failure, and not as a service method return value.
 Using the DefaultRequestTransport, any non-200 response from the server
 will be a transport error, so handling session expiration from a servlet
 filter on the server and responding with a non-200 status code (let's say,
 for instance, a 401, or 400; make sure you don't redirect to your login
 page though!) should Just Work(tm).
 To tell the difference between a real server failure and session expiration
 though, you'll have to make your own RequestTransport on the client
 (possibly extending DefaultRequestTransport) and define some kind of
 protocol (shared knowledge) with the server. Have a look at how it's done
 in the MobileWebApp sample in the GWT 
 SDK:http://code.google.com/p/google-web-toolkit/source/browse/trunk/sampl...It's
 specific to Google AppEngine but is really easy to adapt to whatever you
 use. The trick is to make sure you don't set a security-constraint on the
 RequestFactoryServlet in your web.xml, and instead handle the absence of
 authenticated user from code (in a servlet filter is the easiest)

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-05 Thread Ryan McFall

After I wrote my original follow-up to Thomas' message, I thought of
having different services - one for methods that require
authentication, and one for those that don't.  Then I can map my
ServletFilter to the URL for the service that requires authentication,
and not map it to those that don't.

That seems easier to me than the annotation route.  Anyone have any
reasons to think otherwise?

Ryan

On Jun 5, 8:22 am, Jens jens.nehlme...@gmail.com wrote:
  You can create your own custom annotation (for example : LoggedIn). Apply
  this on all methods you want to authenticate the user/ session to be
  validated.

 Better do it the opposite way if you only have few methods that are allowed
 for unauthenticated users (I think thats more typically), e.g. create a
 @AllowUnauthenticated annotation and if its absent assume the user must be
 logged in. That way you have few opt-out methods instead of many opt-in
 methods.

 -- J.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Resubmitting RequestFactory request when server side logic requires it

2012-06-04 Thread Ryan McFall

I am having issues when I want to resubmit some requests to the server
when the server-side logic indicates it should happen.  In particular,
here's what happens:

1.  The user logins in, which causes an object (SurveyResponseHeader)
to be created on the server-side, and sent back to the client.  edit
is then called on the client side on that object.

2.  The user fills in a set of SurveyResponse objects into a list
contained by the SurveyResponseHeader object (and a corresponding
request is made to save the object on the server).

3.  The user submits the survey responses, but the session has timed
out on the server.  An error code is sent back to the client, and the
user is asked to re-authenticate.

At this point, I want to resubmit the request that caused the error;
it should succeed on the server now because the session has been
restarted.  However, I can't use the same request object because I'll
get the request is already in progress error message.

Rather than tell you everything I've tried, I'd like to hear what
people think is the right way to accomplish this.  I can provide more
details if needed, but I want to keep the description simple at least
to start.

Thanks,
Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Client-side code not seeing multiple return types

2012-05-27 Thread Ryan McFall

I am trying to use the polymorphism features of GWT 2.4, and am
running into a problem that the client side code is not seeing the
right kind of proxy returned.

I have the following objects:
-  A Survey object, which contains a list of SurveyQuestion objects.
There are corresponding RF proxy interfaces declared for both Survey
(ISurvey) and SurveyQuestion (ISurveyQuestion)
-  MultipleChoiceQuestion is a subclass of SurveyQuestion, with a
corresponding proxy interface declared (IMultipleChoiceQuestion),
which extends the proxy for SurveyQuestion (ISurveyQuestion)
-  My service method is annotated with the @ExtraTypes annotation and
includes the class IMultipleChoiceQuestion

When the server side method that returns a Survey is invoked, the type
of the object in the Survey's list of SurveyQuestion objects is in
fact MultipleChoiceQuestion (instead of SurveyQuestion).

But, the proxy returned on the client is an instance of
ISurveyQuestion, not IMultipleChoiceQuestion, as I expect it to be.

Am I missing something?

Thanks,
Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Client-side code not seeing multiple return types

2012-05-27 Thread Ryan McFall

I updated my GWT SDK to the most recent version of 2.4, and it seems
to be working now.  I was using the January release and updated to the
May release.

Ryan

On May 27, 7:19 am, Ryan McFall mcfall.r...@gmail.com wrote:
 I am trying to use the polymorphism features of GWT 2.4, and am
 running into a problem that the client side code is not seeing the
 right kind of proxy returned.

 I have the following objects:
 -  A Survey object, which contains a list of SurveyQuestion objects.
 There are corresponding RF proxy interfaces declared for both Survey
 (ISurvey) and SurveyQuestion (ISurveyQuestion)
 -  MultipleChoiceQuestion is a subclass of SurveyQuestion, with a
 corresponding proxy interface declared (IMultipleChoiceQuestion),
 which extends the proxy for SurveyQuestion (ISurveyQuestion)
 -  My service method is annotated with the @ExtraTypes annotation and
 includes the class IMultipleChoiceQuestion

 When the server side method that returns a Survey is invoked, the type
 of the object in the Survey's list of SurveyQuestion objects is in
 fact MultipleChoiceQuestion (instead of SurveyQuestion).

 But, the proxy returned on the client is an instance of
 ISurveyQuestion, not IMultipleChoiceQuestion, as I expect it to be.

 Am I missing something?

 Thanks,
 Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Nested entity not loaded all the time; possible race condition?

2012-02-01 Thread Ryan McFall

In an application using RequestFactory from GWT 2.3.0, I have the
following object structure:
Survey
  --  ListISurveyQuestion thisSurveysQuestions
--  ChoiceGroup choiceGroup
  --  ListIChoiceGroupItem choices

A method is invoked which loads a Survey object by its ID on the
server side, as follows:

Request request = RequestFactory.getRequest();
request.loadSurveyByID(1).with (componentsToLoad).fire () ...

where componentsToLoad is an array of strings, containing (among
others):
thisSurveysQuestions, thisSurveysQuestions.choiceGroup,
thisSurveysQuestions.choiceGroup.choices

When this code is run within Eclipse, most of the time, but not all of
the time, both the choiceGroup for an individual ISurveyQuestion and
its associated choices are correctly loaded.

When I compile the module and deploy it, the choiceGroup object has
always been null every time that I have tried it.

Since it works some of the time in Eclipse, it doesn't seem like I
have one of the names of the properties spelled wrong in my .with( )
call, or that there's any other error.  It seems more likely to be a
bug in the RequestFactory code.

Has anyone else seen behavior like this, or have ideas what could be
going wrong?

Thanks,
Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Nested entity not loaded all the time; possible race condition?

2012-02-01 Thread Ryan McFall

Hi Thomas:

I moved to 2.4, and the compiler told me about an error in my proxy
related to ChoiceGroup that I had not caught.  Oone of the server side
methods was using an interface for which there was no proxy.  I
remember complaining about the lack of tool support for this last
summer, with the fragility of unchecked strings in annotations, and
you had mentioned that better support would exist in the next version
of RF  the Eclipse plugin.

There was a reasonable amount of headache in moving to 2.4, but once
that was done, the code started working as expected on the deployed
version.

Thanks for your suggestion!
Ryan

On Feb 1, 5:26 pm, Thomas Broyer t.bro...@gmail.com wrote:
 I would have said
 it'shttp://code.google.com/p/google-web-toolkit/issues/detail?id=6710but
 you said you're using 2.3, not 2.4; and it doesn't looks
 likehttp://code.google.com/p/google-web-toolkit/issues/detail?id=6115
 either.

 Anyway, if you use RF, stick to the latest version (run from trunk,
 possibly applying my patches, if you can), so first upgrade to 2.4 or trunk.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: RequestFactory: Download entity, add to collection, persist on server, see collection change. Should this work?

2012-01-26 Thread Ryan McFall

Not sure I understand your issue actually, but RF won't persist your
Response objects for you, you have to either persist them individually, or
persist them when you persist the Header object.
Seehttp://code.google.com/p/google-web-toolkit/issues/detail?id=5389,http://code.google.com/p/google-web-toolkit/issues/detail?id=5724
andhttp://code.google.com/p/google-web-toolkit/issues/detail?id=5776
(see chained persistence
inhttp://tbroyer.posterous.com/gwt-211-requestfactory-part-ii, this article
is a little old, but still mostly relevant)

I am using Hibernate on the server, in case I wasn't clear on that.
Let me try to make the issue a little clearer. I am:
1. Downloading a proxy for the header object
(including .with(responses) to make sure that collection of proxies
is loaded),
2. Adding new objects to the responses list for the proxied header
object
3. Sending a request to the server which includes the header object
as a parameter (which causes the associated Hibernate object to be
loaded in place of the proxied object)
4. Asking Hibernate to save the header object.

I've looked through the the issues that you've posted; the comments at
the end of 5839 seem to indicate that some people have gotten this to
work.

When I get to step 3, I first observe RequestFactory creating new
instances of the Response object, and then loading my Header object,
with Hibernate subsequently calling the setter for the response list.
The setter is also called by the RequestFactory framework
(SimpleRequestProcessor$1(AutoBeanVisitor).visitCollectionProperty),
but the list passed to the setter is empty; it seems the value
parameter in the visitCollectionProperty method, which I think should
be the list of ResponseObjects, is null on the server side, but there
definitely are response proxies in the list on the client side before
the header object is sent to the service method.

Ryan

RequestFactory: Download entity, add to collection, persist on server, see collection change. Should this work?

2012-01-24 Thread Ryan McFall

I have an entity class Header, which contains a list of Response
objects.  Via a RequestFactory service I create a Header object and
send it back to the client, ensuring that the list of Response objects
is initialized before sending it to the client.

Then, on the client, I use the create method to create several
Response objects and add them to the Header proxy on the client side.
I then send another request to call a method (saveResponses) which
persists the Header object on the server, including a call to .with
(responses), and then fire the request.

However, on the server side, the response objects are contained in the
list of responses for the Header object in the saveResponses method.

Should I expect this to work?  If so, are there any constraints on the
context in which it will work?  If not, why not - it seems like this
is basic functionality that should exist.  I have gotten around it by
writing methods to explicitly save the Response objects before saving
the Header object, but I don't think I should have to do this.

Thanks in advance for any pointers.

Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: GWT Developer Plugin for Firefox 9

2012-01-11 Thread Ryan Johnson

Can someone help me out?  When I try to download the plugin the page 
refreshes, but I never see a download and I can't find the file.  If 
someone can send me the file that would also be great.

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/PQE-zHs6IasJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

com.google.gwt.user.client.rpc.StatusCodeException: 12002 exception in IE8 (not Chrome or FF)

2012-01-09 Thread Ryan Groten

We have a GWT 2.4 app that makes regular (every 5 seconds) async rpc calls 
to request data from an httpd/tomcat web server.  In Firefox and Chrome 
everything works as expected but in IE8 after a seemingly random amount of 
time the calls start to fail with one of two errors:

com.google.gwt.user.client.rpc.StatusCodeException: 12002
com.google.gwt.user.client.rpc.StatusCodeException: 12031

12002 is apparently an ERROR_INTERNET_TIMEOUT and 12031 is 
ERROR_INTERNET_CONNECTION_RESET

The app will work fine for only a few minutes, and sometimes it will work 
for up to a whole day..
When the calls start to fail, I see nothing on the web server side (in the 
httpd logs or using tcpdump I see nothing happening).

Has anyone run into anything like this before?  Any thoughts?

Thanks,
Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/9tUy9pZhHIIJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Multiple Webapps - Can I Debug Only One?

2011-11-12 Thread Ryan Kruse

Our website is Drupal driven and we drop in GWT scripts for some
applications.  In this particular page we have two applications on the
same page.  When I go to debug one it looks for the source of the
other and fails.  Doing both at the same time would be great but I
only need one but I still want the other one to load as normal
javascript should and not to try to attach to code in my debugger.
Any tips on how to accomplish this?

The html source (from a Drupal template).
  script type=text/javascript language=javascript src=/webapp-
advancedtools/AdvancedTools/AdvancedTools.nocache.js/script
  script type=text/javascript language=javascript src=/webapp-
activesearch/ActiveSearch/ActiveSearch.nocache.js/script

I'm currently trying to attach to only my ActiveSearch application.
And here is the error.
   19:30:46.498 [ERROR] [AdvancedTools] Unable to find
'AdvancedTools.gwt.xml' on your classpath; could be a typo, or maybe
you forgot to include a classpath entry for source?

I added the AdvacedTools project to my run configuration for
ActiveSearch but I haven't been able to get that to work either.
Really that didn't feel like the right path anyways, I just want
AdvancedTools to load like plain-old javascript.

BTW, we're doing multiple applications because we need to maintain the
ability to separately deploy one application without the other needing
to be touched.  I already realize the downfalls of the extra core css
and javascript that is going to be doubled up on this page.

I'd really appreciate any pointers here.  Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

[gwt-contrib] Re: More TCK tests (issue1567804)

2011-10-17 Thread Ray Ryan

Missed this, looking now.

On Mon, Oct 17, 2011 at 10:26 AM, ncha...@google.com wrote:

 On 2011/10/13 18:53:54, Nick Chalko wrote:

 ping

 http://gwt-code-reviews.**appspot.com/1567804/http://gwt-code-reviews.appspot.com/1567804/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: More TCK tests (issue1567804)

2011-10-17 Thread Ray Ryan

LGTM
On Oct 17, 2011 4:26 PM, ncha...@google.com wrote:


 http://gwt-code-reviews.**appspot.com/1567804/diff/1/**
 user/test/org/hibernate/**jsr303/tck/tests/bootstrap/**customprovider/**
 TckTestValidatorFactory.javahttp://gwt-code-reviews.appspot.com/1567804/diff/1/user/test/org/hibernate/jsr303/tck/tests/bootstrap/customprovider/TckTestValidatorFactory.java
 File
 user/test/org/hibernate/**jsr303/tck/tests/bootstrap/**customprovider/**
 TckTestValidatorFactory.java
 (right):

 http://gwt-code-reviews.**appspot.com/1567804/diff/1/**
 user/test/org/hibernate/**jsr303/tck/tests/bootstrap/**customprovider/**
 TckTestValidatorFactory.java#**newcode16http://gwt-code-reviews.appspot.com/1567804/diff/1/user/test/org/hibernate/jsr303/tck/tests/bootstrap/customprovider/TckTestValidatorFactory.java#newcode16
 user/test/org/hibernate/**jsr303/tck/tests/bootstrap/**customprovider/**
 TckTestValidatorFactory.java:**16:
 package org.hibernate.jsr303.tck.**tests.bootstrap.**customprovider;
 On 2011/10/17 20:55:03, rjrjr wrote:

 Is it really appropriate for this to be in the org.hibernate space

 rather than

 com.google.gwt?


 This is the same directory as the test.   For some of the tests it was
 important to be in the same package.

 http://gwt-code-reviews.**appspot.com/1567804/http://gwt-code-reviews.appspot.com/1567804/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add HasEnabled to SuggestBox (issue1567803)

2011-10-14 Thread Ray Ryan

When I run your sample I never see the suggest box. What should I be typing?

On Wed, Oct 12, 2011 at 9:10 PM, stephen.haber...@gmail.com wrote:

 I published a demo here:

 http://sh-hello.appspot.com/


 http://gwt-code-reviews.**appspot.com/1567803/http://gwt-code-reviews.appspot.com/1567803/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Generate unique class names in AbstractClientBundleGenerator at design time. (issue1565805)

2011-10-11 Thread Ray Ryan

LGTM

On Tue, Oct 11, 2011 at 11:53 AM, scheg...@google.com wrote:

 Reviewers: rjrjr,

 Description:
 Generate unique class names in AbstractClientBundleGenerator at design
 time.


 Please review this at 
 http://gwt-code-reviews.**appspot.com/1565805/http://gwt-code-reviews.appspot.com/1565805/

 Affected files:
  M user/src/com/google/gwt/**resources/rebind/context/**
 AbstractClientBundleGenerator.**java


 Index: user/src/com/google/gwt/**resources/rebind/context/**
 AbstractClientBundleGenerator.**java
 ==**==**===
 --- user/src/com/google/gwt/**resources/rebind/context/**
 AbstractClientBundleGenerator.**java (revision 10696)
 +++ user/src/com/google/gwt/**resources/rebind/context/**
 AbstractClientBundleGenerator.**java (working copy)
 @@ -50,6 +50,7 @@
  import com.google.gwt.user.rebind.**ClassSourceFileComposerFactory**;
  import com.google.gwt.user.rebind.**SourceWriter;

 +import java.beans.Beans;
  import java.io.PrintWriter;
  import java.io.Serializable;
  import java.net.URL;
 @@ -968,6 +969,11 @@

 toReturn.append(_ + getClass().getSimpleName());

 +// If design time, generate new class each time to allow reloading.
 +if (Beans.isDesignTime()) {
 +  toReturn.append(_designTime + System.currentTimeMillis());
 +}
 +
 return toReturn.toString();
   }





-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Change the superclass of the translatable version of (issue1565803)

2011-10-06 Thread Ray Ryan

LGTM
On Oct 6, 2011 5:07 PM, skybr...@google.com wrote:
 Reviewers: rjrjr,

 Description:
 Change the superclass of the translatable version of
 junit.framework.AssertionFailedError to match the JVM version,
 for consistency when catching java.lang.AssertionError in
 testing tools.

 Fixes issue 6863.


 Please review this at http://gwt-code-reviews.appspot.com/1565803/

 Affected files:
 M

user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java


 Index:

user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java
 ===
 ---

user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java

 (revision 10689)
 +++

user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java

 (working copy)
 @@ -18,7 +18,7 @@
 /**
 * Translatable version of JUnit's codeAssertionFailedError/code.
 */
 -public class AssertionFailedError extends Error {
 +public class AssertionFailedError extends AssertionError {

 public AssertionFailedError() {
 }



-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Serialization of Final Fields in RPC (issue1380807)

2011-10-04 Thread Ray Ryan

Not really practical.

On Tue, Oct 4, 2011 at 10:35 AM, stephen.haber...@gmail.com wrote:

 I meant to comment; this would all be a lot simpler if GWT-RPC could
 serialize final fields as the default/only behavior (basically remove
 any configuration variables to turn it on/off).

 I understand this isn't viable for the next release, as it's a breaking
 change, and users might be putting values in final fields that they
 don't want to go over the wire (although hopefully that is rare).

 But, just throwing it out there, would it be possible to deprecate all
 of the configuration variables, and say that in the next major release,
 final fields will always be serialized?

 Then a lot of the conditional flags and logic could be removed, and the
 implementation would be simplified. Which isn't critical, but I think
 would be nice.

 http://gwt-code-reviews.**appspot.com/1380807/http://gwt-code-reviews.appspot.com/1380807/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: ScrollPanel not shoing up!

2011-09-29 Thread Ryan Groten

Why not try putting the view into a DockLayoutPanel itself to separate the 
header from content?

g:DockLayoutPanel size=30
  g:north
g:FlexTable ui:field='header' styleName='{style.header}' cellSpacing='0' 
cellPadding='0'/
  /g:north
  g:center
g:ScrollPanel
  g:FlexTable ui:field='table' styleName='{style.table}' 
cellSpacing='0' cellPadding='0'/ 
/g:ScrollPanel
  /g:center
/g:DockLayoutPanel

Also may want to consider replacing your mainPanel DockLayoutPanel with 
something like a SimpleLayoutPanel if it's only going to hold a single view.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/QVQ7S1f23DwJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: What do you think?

2011-09-28 Thread Ryan Groten

I'm still very new but I'm enjoying it a lot.  Like cueman said though, 
can't please everybody.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/E6hRHb8NoUgJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: UiBinder errors not very helpful -- am i missing a compiler option?

2011-09-28 Thread Ryan Groten

When I get the failed to resolved ... via deferred binding errors there's 
usually a useful error message in the output above it (missing required 
attribute or can only have 1 child element, etc).  You don't get those 
types of error messages?

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/MyWouRuCU9oJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

[gwt-contrib] Re: Do RF validation via APT instead of command line. (issue1547804)

2011-09-15 Thread Ray Ryan

Jeff, how are you launching your app under eclipse? Are you making m2e fire
gwt:run, or are you using Google Plugin for Eclipse  Run as Web App?

On Thu, Sep 15, 2011 at 2:58 AM, Jeff Larsen larse...@gmail.com wrote:

 I know I would like it if the RequestFactory stuff was pushed into maven
 central.

 Don't make gwt-servlet into a real dependency, add it to the list of
 dependencies in your plugin.


   plugin
 groupIdorg.bsc.maven/**groupId
 artifactIdmaven-processor-**plugin/artifactId
 version2.0.5/version
 executions
   execution
 idprocess/id
 goals
   goalprocess/goal
 /goals
 phasegenerate-sources/**phase
 configuration
   !-- TODO(rjrjr) Can this explicit processor line go away if

 we depend
on requestfactory-apt directly? Is that jar in maven
 central?
 --
   processors

 processorcom.google.web.**bindery.requestfactory.apt.**
 RfValidator/processor
   /processors
 /configuration
   /execution
 /executions
 dependencies
   dependency
 groupIdcom.google.gwt/groupId
artifactIdgwt-servlet/artifactId
version${gwt-version}/version
 /dependency
 /dependencies
 /plugin
   /plugins


 When you switch that to requestfactory-apt, you should be able to get rid
 of the explicit binding as well, but I have it in mine for documentation
 purposes.

 I was just working on this last week for some annotation processors I've
 written for my application to get around writing the proxies for
 RequestFactory, building the columns that map to those proxies then also
 building the constantswithlookup to map the values in there.

 I needed to do some additional steps when doing this with m2e aswell. Since
 there are no m2e connectors for any of the annotation processor maven
 plugins, I worked around that with the build-helper plugin.

 The build helper plugin allows you to specify additional source folders, so
 I just mapped a new source folder to where my maven annotation processor was
 going. I think I found a bug in build-helper-connector where you can't
 specify source folders under target, but maybe you'll have better luck.

 Then because I added a new source folder, I needed to add the maven clean
 plugin to make sure the generated artifacts were getting removed every time
 a maven clean happened.

 tl;dr

 here are the relevant bits of the pom that I was using to get all this
 working together.
 plugin
 groupIdorg.codehaus.mojo/groupId
  artifactIdbuild-helper-maven-plugin/artifactId
 version1.7/version
  executions
 execution
 idadd-source/id
  phasegenerate-sources/phase
 goals
 goaladd-source/goal
  /goals
 configuration
 sources
  source${basedir}/generated-sources/annotations/source
 /sources
 /configuration
  /execution
 /executions
 /plugin
 plugin
 artifactIdmaven-clean-plugin/artifactId
 version2.4.1/version
  configuration
 filesets
 fileset
  directorygenerated-sources/annotations/directory
 includes
 include**/*/include
  /includes
 /fileset
 /filesets
  /configuration
 /plugin
 plugin

 groupIdorg.bsc.maven/groupId
 artifactIdmaven-processor-plugin/artifactId
  executions
 execution
 idprocess/id
  goals
 goalprocess/goal
 /goals
  phasegenerate-sources/phase
 /execution
 /executions
  dependencies
 dependency
 groupIdcom.ecologic/groupId
  artifactIdrfprocessor/artifactId
 version0.0.1-SNAPSHOT/version
 /dependency
  /dependencies

 configuration
 outputDirectory${basedir}/generated-sources/annotations/outputDirectory
  processors
 processorcom.ecologic.rfprocessor.CreateDefaults/processor
 /processors
  /configuration






-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Update the checkstule path for validation sample (issue1547803)

2011-09-14 Thread Ray Ryan

LGTM

Oops. Thanks Nick. I'll need to remember to put this on the 2.4 branch.
On Sep 13, 2011 7:27 PM, ncha...@google.com wrote:
 Reviewers: rjrjr,

 Description:
 Update the checkstule path for validation sample
 Fix the @NotSupported count


 Please review this at http://gwt-code-reviews.appspot.com/1547803/

 Affected files:
 M samples/common.ant.xml
 M user/build.xml


 Index: samples/common.ant.xml
 ===
 --- samples/common.ant.xml (revision 8405)
 +++ samples/common.ant.xml (working copy)
 @@ -189,8 +189,8 @@
 target name=checkstyle description=Static analysis of source
 gwt.checkstyle outputdirectory=${sample.build}
 fileset dir=src 
 - exclude name=org/**/super/org/**/*.java/
 - exclude
 name=com/google/gwt/sample/validation*/**/ValidationMessages.java /
 + exclude name=main/java/org/**/super/org/**/*.java/
 + exclude

name=main/java/com/google/gwt/sample/validation*/**/ValidationMessages.java

 /
 /fileset
 /gwt.checkstyle
 /target
 Index: user/build.xml
 ===
 --- user/build.xml (revision 8405)
 +++ user/build.xml (working copy)
 @@ -803,13 +803,14 @@
 countfilter match=@Failing property=jsr303.marked.Failing
 init=0/
 countfilter match=@NonTckTest
 property=jsr303.marked.NonTckTest init=0/
 countfilter match=@NotSupported
 property=jsr303.marked.NotSupported init=0/
 - countfilter match=@TestNotCompatible
 property=jsr303.marked.NotSupported init=0/
 + countfilter match=@TestNotCompatible
 property=jsr303.marked.TestNotCompatible init=0/
 /filterchain
 /scan

 !-- force to zero if not set above --
 property name=jsr303.marked.Failing value=0/
 property name=jsr303.marked.NonTckTest value=0/
 + property name=jsr303.marked.NotSupported value=0/
 property name=jsr303.marked.TestNotCompatible value=0/

 echo message=Marked Failing = ${jsr303.marked.Failing} /



-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Converts the validation sample to build with maven. (issue1537805)

2011-09-12 Thread Ray Ryan

It's resolved if Nick gives his LGTM

On Mon, Sep 12, 2011 at 9:34 AM, rchan...@google.com wrote:

 LGTM. Once the ScriptAssert issue gets resolved.

 On 2011/09/12 16:27:34, rjrjr wrote:



 http://gwt-code-reviews.**appspot.com/1537805/http://gwt-code-reviews.appspot.com/1537805/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: When -XdisableClassMetadata is used, Class.getName() can return Class$SseedNumber as a class n... (issue1540804)

2011-09-12 Thread Ray Ryan

LGTM

Nice catch. Is there really no test to extend for this? :-(

On Mon, Sep 12, 2011 at 5:39 PM, cromwell...@google.com wrote:

 Reviewers: rjrjr,

 Description:
 When -XdisableClassMetadata is used, Class.getName() can return
 Class$SseedNumber as a class name. However, there are other modes
 where it can return Class$obfuscated function name. In some rare
 cases, these two could collide of if an obfuscated name of a class ended
 up as something like 'S123'. This patch changes the WebModeClientOracle
 to treat Class$S123 differently than 'S123' when deobfuscating class
 names.


 Please review this at 
 http://gwt-code-reviews.**appspot.com/1540804/http://gwt-code-reviews.appspot.com/1540804/

 Affected files:
  M user/src/com/google/gwt/rpc/**server/WebModeClientOracle.**java


 Index: user/src/com/google/gwt/rpc/**server/WebModeClientOracle.**java
 ==**==**===
 --- user/src/com/google/gwt/rpc/**server/WebModeClientOracle.**java
 (revision 10636)
 +++ user/src/com/google/gwt/rpc/**server/WebModeClientOracle.**java
 (working copy)
 @@ -383,12 +383,14 @@
   @Override
   public String getTypeName(String seedName) {
 // TODO: Decide how to handle the no-metadata case
 +ClassData data = null;
 if (seedName.startsWith(Class$)**) {
   seedName = seedName.substring(6);
 -}
 -ClassData data = seedNamesToClassData.get(**seedName);
 +  data = seedIdsToClassData.get(**seedName);
 +}
 +
 if (data == null) {
 -  data = seedIdsToClassData.get(**seedName);
 +  data = seedNamesToClassData.get(**seedName);
 }
 return data == null ? null : data.typeName;
   }




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Converts the validation sample to build with maven. (issue1537805)

My main problem was that I had lost the web.xml file (duh).

Still trying to figure out the ScriptAssertValidator issue. I wonder if an
extra copy is being pulled in by maven.


On Thu Sep 08 18:15:07 GMT-700 2011, Nick Chalko wrote:



  org.hibernate.validator.**constraints.impl.**ScriptAssertValidator



 So ScriptAssertValidator should not be getting compiled.  Let me try to
 find where it is excluded.


 user/src/org/hibernate/validator/HibernateValidator.gwt.xml  excludes that
 file with.

   source path=constraints

 exclude name=impl/scriptassert/ /

 exclude name=super/ /

   /source

 Not sure why this is not used.

 --
 Nick Chalko | Software Engineer | 
 ncha...@google.comhttp://www.google.com/url?sa=Dq=mailto%3Anchalko%40google.com
  |   :-)



-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Converts the validation sample to build with maven. (issue1537805)

Thanks.

Do I need the validation-api dependency (in any of samples/*/pom.xml), or
does gwt 2.4.0 bring that along?

On Fri, Sep 9, 2011 at 12:09 PM, drfibona...@google.com wrote:


 http://gwt-code-reviews.**appspot.com/1537805/diff/2002/**
 samples/validation/pom.xmlhttp://gwt-code-reviews.appspot.com/1537805/diff/2002/samples/validation/pom.xml
 File samples/validation/pom.xml (right):

 http://gwt-code-reviews.**appspot.com/1537805/diff/2002/**
 samples/validation/pom.xml#**newcode200http://gwt-code-reviews.appspot.com/1537805/diff/2002/samples/validation/pom.xml#newcode200
 samples/validation/pom.xml:**200:
 artifactIdexec-maven-plugin**/artifactId
 Looks like the whole pluginManagement section can be omitted as I don't
 see exec-maven-plugin anywhere else in the POM.


 http://gwt-code-reviews.**appspot.com/1537805/http://gwt-code-reviews.appspot.com/1537805/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Converts the validation sample to build with maven. (issue1537805)

On Thu, Sep 8, 2011 at 6:15 PM, Nick Chalko ncha...@google.com wrote:



  org.hibernate.validator.**constraints.impl.**ScriptAssertValidator



 So ScriptAssertValidator should not be getting compiled.  Let me try to
 find where it is excluded.


 user/src/org/hibernate/validator/HibernateValidator.gwt.xml  excludes that
 file with.

   source path=constraints

 exclude name=impl/scriptassert/ /

 exclude name=super/ /

   /source

 Not sure why this is not used.


It looks like the ScriptAssertValidator problem is actually on the
@ScriptAssert annotation itself:

@Target({ TYPE })
@Retention(RUNTIME)
*@Constraint(validatedBy = ScriptAssertValidator.class)*
@Documented
public @interface ScriptAssert {

The type oracle tries to process ScriptAssertValidator.class, but it can't
because of nick's excludes line. No harm is done, but the console noise is
unpleasant. And I wonder what would happen if someone actually tried to use
@ScriptAssert?

Nick, do you emulate the rest of those constraints, or do they just work?
Should I exclude the whole package?

Or perhaps I should put in a no-op super source implementation
of ScriptAssertValidator. We've done that kind of thing before.

rjrjr

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Scripts and configuration to upload GWT bits to Maven repos (issue1520810)

LGTM

On Fri, Sep 9, 2011 at 1:26 PM, rchan...@google.com wrote:


 http://gwt-code-reviews.**appspot.com/1520810/diff/7016/**maven/lib-gwt.shhttp://gwt-code-reviews.appspot.com/1520810/diff/7016/maven/lib-gwt.sh
 File maven/lib-gwt.sh (right):

 http://gwt-code-reviews.**appspot.com/1520810/diff/7016/**
 maven/lib-gwt.sh#newcode99http://gwt-code-reviews.appspot.com/1520810/diff/7016/maven/lib-gwt.sh#newcode99
 maven/lib-gwt.sh:99: maven-deploy-file $mavenRepoUrl $mavenRepoId
 $pomDir/gwt/pom.xml $pomDir/gwt/pom.xml
 On 2011/09/09 19:59:04, rjrjr wrote:

 This should happen between the for loops.


 Done.


 http://gwt-code-reviews.**appspot.com/1520810/http://gwt-code-reviews.appspot.com/1520810/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Converts the validation sample to build with maven. (issue1537805)

On Fri, Sep 9, 2011 at 1:15 PM, Ray Ryan rj...@google.com wrote:

 On Thu, Sep 8, 2011 at 6:15 PM, Nick Chalko ncha...@google.com wrote:



  org.hibernate.validator.**constraints.impl.**ScriptAssertValidator



 So ScriptAssertValidator should not be getting compiled.  Let me try to
 find where it is excluded.


 user/src/org/hibernate/validator/HibernateValidator.gwt.xml  excludes that
 file with.

   source path=constraints

 exclude name=impl/scriptassert/ /

 exclude name=super/ /

   /source

 Not sure why this is not used.


 It looks like the ScriptAssertValidator problem is actually on the
 @ScriptAssert annotation itself:

 @Target({ TYPE })
 @Retention(RUNTIME)
 *@Constraint(validatedBy = ScriptAssertValidator.class)*
 @Documented
 public @interface ScriptAssert {

  The type oracle tries to process ScriptAssertValidator.class, but it can't
 because of nick's excludes line. No harm is done, but the console noise is
 unpleasant. And I wonder what would happen if someone actually tried to use
 @ScriptAssert?

 Nick, do you emulate the rest of those constraints, or do they just work?
 Should I exclude the whole package?

 Or perhaps I should put in a no-op super source implementation
 of ScriptAssertValidator. We've done that kind of thing before.

 rjrjr


Hmm. You already have a super source ScriptAssertValidator, just like all
the other ones. I still don't get what's special about this one.

Deleting that exclude line doesn't change anything. Making it exclude the
entire impl packages gets rid of the error and the sample still works.
Seeing what that does to the tests. (I assume there's a reason you aren't
already doing that.)

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Converts the validation sample to build with maven. (issue1537805)

On Fri, Sep 9, 2011 at 1:40 PM, Ray Ryan rj...@google.com wrote:



 On Fri, Sep 9, 2011 at 1:15 PM, Ray Ryan rj...@google.com wrote:

 On Thu, Sep 8, 2011 at 6:15 PM, Nick Chalko ncha...@google.com wrote:



  org.hibernate.validator.**constraints.impl.**ScriptAssertValidator



 So ScriptAssertValidator should not be getting compiled.  Let me try to
 find where it is excluded.


 user/src/org/hibernate/validator/HibernateValidator.gwt.xml  excludes
 that file with.

   source path=constraints

 exclude name=impl/scriptassert/ /

 exclude name=super/ /

   /source

 Not sure why this is not used.


 It looks like the ScriptAssertValidator problem is actually on the
 @ScriptAssert annotation itself:

 @Target({ TYPE })
 @Retention(RUNTIME)
 *@Constraint(validatedBy = ScriptAssertValidator.class)*
 @Documented
 public @interface ScriptAssert {

  The type oracle tries to process ScriptAssertValidator.class, but it
 can't because of nick's excludes line. No harm is done, but the console
 noise is unpleasant. And I wonder what would happen if someone actually
 tried to use @ScriptAssert?

 Nick, do you emulate the rest of those constraints, or do they just work?
 Should I exclude the whole package?

 Or perhaps I should put in a no-op super source implementation
 of ScriptAssertValidator. We've done that kind of thing before.

 rjrjr


 Hmm. You already have a super source ScriptAssertValidator, just like all
 the other ones. I still don't get what's special about this one.

 Deleting that exclude line doesn't change anything. Making it exclude the
 entire impl packages gets rid of the error and the sample still works.
 Seeing what that does to the tests. (I assume there's a reason you aren't
 already doing that.)


Ah ha! It is you, *you Nick Chalko* that are making this happen! In your
super source you have a copy of ScriptAssert.java, where you have no other
annotations emulated. It includes an annotation with the reference to the
ScriptAssertValidator.class. (I suspect this is a bug in super source if you
squint just right, but I don't care.)

If I delete that file the noise goes away, the sample runs, and the tests
all pass. Any idea why it's there?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Deprecate DeferredCommand and IncrementalCommand. (issue982802)

2011-09-08 Thread Ray Ryan

This isn't a release notes issue. The deprecation happened quite a while
ago. DevGuideCodingBasicsDelayed.html is very, very out of date.

On Thu, Sep 8, 2011 at 3:31 PM, Doug Anderson do...@google.com wrote:

 Eric:

 I can note this and any other deprecation you want in the release notes for
 next release, say 2.5  (or, if anything was deprecated for 2.4 and we missed
 it, I can also update the 2.4 notes!).

 The actual Javadoc is maintained by you folks, so any changes you want in
 that needs to be made at your end, I'm pretty sure.

 Doug



 On Thu, Sep 8, 2011 at 3:01 PM, Eric Ayers zun...@google.com wrote:


 http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/user/client/DeferredCommand.html

 has a pointer to the blessed alternative (Scheduler).

 @Doug, can you flag this page as needing an update?

 On Thu, Sep 8, 2011 at 4:43 PM, mark.w...@potentbyte.com wrote:

 Since this is deprecated what is the alternative to these classes?

 The documentation continues to provide these as examples.
 http://code.google.com/**webtoolkit/doc/latest/**
 DevGuideCodingBasicsDelayed.**htmlhttp://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsDelayed.html

 On 2010/10/13 17:13:43, rjrjr wrote:

 On Wed, Oct 13, 2010 at 5:28 AM, mailto:zun...@google.com wrote:


  
  http://gwt-code-reviews.**appspot.com/982802/diff/1/5http://gwt-code-reviews.appspot.com/982802/diff/1/5
  File user/src/com/google/gwt/user/**client/DeferredCommand.java

 (right):

 
  http://gwt-code-reviews.**appspot.com/982802/diff/1/5#**newcode27http://gwt-code-reviews.appspot.com/982802/diff/1/5#newcode27
  user/src/com/google/gwt/user/**client/DeferredCommand.java:**27: *
   API prevents effective mocking.
  On 2010/10/13 03:50:36, rjrjr wrote:
 
  I thought it was deprecated because it was redundant...TMI?
 
 
  IMHO, I don't think you can give too much information on the impetus
  behind this change.  Its going to be painful to see all those
  deprecation warnings come out the first time for most users.



  We might want to provide more justification then. We're not just

 deprecating

 the thing for mockability, it's redundant code, right?


  
 
  http://gwt-code-reviews.**appspot.com/982802/showhttp://gwt-code-reviews.appspot.com/982802/show
 




 http://gwt-code-reviews.**appspot.com/982802/http://gwt-code-reviews.appspot.com/982802/




 --
 Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Event handling support for UiRenderer (issue1534806)

2011-09-07 Thread Ray Ryan

LGTM

On Wed Sep 07 11:50:58 GMT-700 2011, rchan...@google.comgt wrote:



 http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.javahttp://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java
 File
 user/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java
 (right):


 http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java#newcode60
 user/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java:60http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java%23newcode60%0Auser/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java:60
 :
 if (!isParentOrRenderer(parentOrRoot, RENDERED_ATTRIBUTE)) {
 On 2011/09/07 17:30:19, rjrjr wrote:
  Should call the single arg version.

 No, because UiRendererDispatcher is a static class, so it can only call
 static methods.


  This method is null tolerant. Should it NPE instead?

 Done. Added validation for null on the first three parameters, throwing
 NPEs on null receiver, root and events.

  If so, does that fix belong
  in isParentOrRenderer(Element, String)?


 No, isParentOrRenderer(Element, String) is designed to be a safe test
 and it is used elsewhere in that way. I'd find a NPE from it kind of
 surprising.


 http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java#newcode322
 user/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java:322http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java%23newcode322%0Auser/src/com/google/gwt/uibinder/client/impl/AbstractUiRenderer.java:322
 :
 * Walks up the parents of the {@code rendered} element to ascertain that
 it is attached to the
 On 2011/09/07 17:30:19, rjrjr wrote:
  In DevMode, ...
  ... Always returns true in ProdMode

 Done.


 http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/UiBinderUtil.javahttp://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/UiBinderUtil.java
 File user/src/com/google/gwt/uibinder/client/impl/UiBinderUtil.java
 (right):


 http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/UiBinderUtil.java#newcode28
 user/src/com/google/gwt/uibinder/client/impl/UiBinderUtil.java:28http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1534806/diff/10001/user/src/com/google/gwt/uibinder/client/impl/UiBinderUtil.java%23newcode28%0Auser/src/com/google/gwt/uibinder/client/impl/UiBinderUtil.java:28
 :
 public class UiBinderUtil {
 On 2011/09/07 17:30:19, rjrjr wrote:
  As we discussed offline, it might not be the right time to make this
 move. But
  if you keep it, could you add a note to the issue tracker mentioning
 it as a
  breaking change (tag ReleaseNote=breakingChange)

 I'd rather back off. The fix in GPE is not obvious to me.

 http://gwt-code-reviews.appspot.com/1534806/http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1534806/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] dependencies/qualified refs

2011-09-07 Thread Ray Ryan

Scott says:

Stephen misunderstands what Dependencies.apiRefs means (which isn't
suprising, it's not well commented).

The simple and qualified references answer the question What references do
I depend on to correctly parse and resolve the source code?

Api refs answer the question What program elements do I need to construct a
TypeOracle representation of this class?

In other words, api refs only include things like superclass, implemented
interfaces, method parameter and return types, field types, etc. Things you
have to have to construct a valid TypeOracle representation. Method bodies
do not contribute to this list at all.

Simple and qualified references is generally a superset of that, includes
anything references in method bodies.

On Wed, Sep 7, 2011 at 8:52 AM, Stephen Haberman stephen.haber...@gmail.com
wrote:

Hi,

There was one place in the name mangling that I had to leave an ugly
replacement:

https://github.com/stephenh/scalagwt-gwt/blob/embed/dev/core/src/com/google/gwt/dev/javac/CompilationStateBuilder.java#L109

allValidClasses is by internal name now, but the qualified references
coming from ecj are by source name.

(Hm, if these are top-level only units, then a simple replacement would
be okay. Does anyone know if that is the case, off the top of their
heads? I'll fire up the debugger later and see if I can tell.)

But the other reason I ask on the list instead of in the review is that,
for scalagwt itself, I don't have these ecj data structures, so I'm
inferring the simple and qualified refs from the api refs:

https://github.com/stephenh/scalagwt-gwt/blob/embed/dev/core/src/com/google/gwt/dev/javac/Dependencies.java#L62

I'm pretty sure this approach is okay, but my concern is that, poking
around in the debugger, ecj, ends up with a whole lot more strings as
simple/qualified refs than my current, albeit somewhat naive approach
in buildFromApiRefs.

Given I'd already written buildFromApiRefs, I was tempted to use it
for the .java files as well, since api refs are already internal names,
and then I could remove the source - internal mangling. But I didn't
have enough confidence to do that just yet.

If anyone could comment on buildFromApiRefs, both in theory and the
current implementation, just for scalagwt but also whether it's
potentially usable for the java side, I'd appreciate it.

But I'll nonetheless look into whether the qualifiedReferences are
only top-level units, in which case the name mangling should be okay.
I didn't think of that until just now.

- Stephen

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: Inherited exceptions in GWT-RPC

2011-09-06 Thread Ryan

Thanks, Colin.  I'll double-check my module file and make sure the
exceptions are being included for the GWT compiler.  That may be the
reason they're being missed.

On Sep 1, 2:14 pm, Colin Alworth niloc...@gmail.com wrote:
 On Thursday, August 25, 2011 3:09:22 PM UTC-5, Ryan wrote:
  However, if I declare AException in the client, but throw either of
  the two child classes in the server, GWT wraps it in an
  InvocationException.

 This is the key to your issue - if the client can't de-serialize it (because
 the code only exists where the server can see it, not the client), it can't
 allow it to be thrown to the client.

 Unless I've misunderstood, and all three are declared in the client package,
 but only AException is declared as part of the RPC method signature. If that
 is the case, this should work as you expect. A few other things could B, C
 from being available to be deserialized, such as being blacklisted in your
 module file, or not having default (i.e. no-arg) constructors, things that
 would affect any other DTO expected to work with RPC.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: [gwt-contrib] Comment on RequestFactory_2_4 in google-web-toolkit

Fixed, thanks.

On Monday, September 5, 2011, wrote:

 Comment by ido@gmail.com:

 In Improved request batching section the sample has typo:
 ctxB.requestB().to(new ReceiverBoolean(){});
 should be

 ctxB.requestB().to(new ReceiverInteger(){});

 For more information:
 http://code.google.com/p/**google-web-toolkit/wiki/**RequestFactory_2_4http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_4

 --
 http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://groups.google.com/group/Google-Web-Toolkit-Contributors


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Event handling support for UiRenderer (issue1534806)

Oh, crazy! I didn't notice that you were invoking it at compile time. And I
suppose that's going to let it fail at compile time instead of runtime,
isn't it? Okey doke.

On Tuesday, September 6, 2011, wrote:

 On 2011/09/02 00:01:48, rjrjr wrote:

 http://gwt-code-reviews.**appspot.com/1534806/diff/1/**
 user/src/com/google/gwt/**uibinder/rebind/**UiBinderWriter.java#**
 newcode1202http://gwt-code-reviews.appspot.com/1534806/diff/1/user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java#newcode1202

 user/src/com/google/gwt/**uibinder/rebind/**UiBinderWriter.java:1202: try

 {

 Should use the TypeOracle, not reflection


 Here I need to actually call XEvent.getType().getName() to figure out
 the string the class is associated with. How do I go about using
 TypeOracle for that?


 http://gwt-code-reviews.**appspot.com/1534806/http://gwt-code-reviews.appspot.com/1534806/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Updates pom.xml to use new Request Factory libraries (issue1541803)

LGTM

Nice!

On Tue, Sep 6, 2011 at 1:22 PM, rchan...@google.com wrote:

 Reviewers: rjrjr, drfibonacci,

 Description:
 Updates pom.xml to use new Request Factory libraries


 Please review this at 
 http://gwt-code-reviews.**appspot.com/1541803/http://gwt-code-reviews.appspot.com/1541803/

 Affected files:
  M samples/mobilewebapp/pom.xml


 Index: samples/mobilewebapp/pom.xml
 ==**==**===
 --- samples/mobilewebapp/pom.xml(revision 10615)
 +++ samples/mobilewebapp/pom.xml(working copy)
 @@ -48,10 +48,15 @@
 !-- Google Web Toolkit (GWT) itself --

 dependency
 -  groupIdcom.google.gwt/**groupId
 -  artifactIdgwt-servlet/**artifactId
 +  groupIdcom.google.web.**bindery/groupId
 +  artifactIdrequestfactory-**server/artifactId
   version${gwtVersion}/**version
   scoperuntime/scope
 +/dependency
 +dependency
 +  groupIdcom.google.web.**bindery/groupId
 +  artifactIdrequestfactory-**apt/artifactId
 +  version${gwtVersion}/**version
 /dependency
 dependency
   groupIdcom.google.gwt/**groupId
 @@ -75,12 +80,6 @@
 /dependency

 !-- GWT RequestFactory will use JSR 303 javax.validation if you let it
 --
 -dependency
 -  groupIdjavax.validation/**groupId
 -  artifactIdvalidation-api/**artifactId
 -  version1.0.0.GA/version
 -  classifiersources/**classifier
 -/dependency
 dependency
   groupIdorg.hibernate/**groupId
   artifactIdhibernate-**validator/artifactId
 @@ -97,17 +96,7 @@
   /exclusions
 /dependency

 -!-- GWT RequestFactory requires org.json --
 -!-- TODO: can we declare the json and validation dependencies
 somewhere for the world to pick up,
 -rather than requiring everyone to know about them? --
 -dependency
 -  groupIdorg.json/groupId
 -  artifactIdjson/artifactId
 -  version20090211/version
 -/dependency
 -
 !-- Google App Engine (GAE) itself --
 -
 dependency
   groupIdcom.google.appengine**/groupId
   artifactIdappengine-api-1.0-**sdk/artifactId
 @@ -172,11 +161,11 @@
   version1.6.1/version
 /dependency
   /dependencies
 -
 +
   build
 -!-- Generate compiled stuff in the folder used for developing mode
 --
 +!-- Generate compiled stuff in the folder used for developing mode
 --
 outputDirectory${project.**build.directory}/${project.**
 build.finalName}/WEB-INF/**classes/outputDirectory
 -
 +
 plugins
   !-- GWT Maven Plugin--
   plugin
 @@ -200,7 +189,7 @@
 version${gwtVersion}/**version
   /dependency
 /dependencies
 -!-- JS is only needed in the package phase, this speeds up
 testing --
 +!-- JS is only needed in the package phase, this speeds up
 testing --
 executions
   execution
 phaseprepare-package/phase
 @@ -209,8 +198,8 @@
 /goals
   /execution
 /executions
 -!-- Plugin configuration. There are many available options,
 - see gwt-maven-plugin documentation at codehaus.org --
 +!-- Plugin configuration. There are many available options,
 + see gwt-maven-plugin documentation at codehaus.org --
 configuration
   !-- URL that should be automatically opened in the GWT shell
 (gwt:run). --
   runTargetMobileWebApp.html/**runTarget
 @@ -255,7 +244,7 @@
   useManifestOnlyJarfalse/**useManifestOnlyJar
   forkModealways/forkMode

 -  !-- Folder for generated testing stuff --
 +  !-- Folder for generated testing stuff --
   systemProperties
 property
   namegwt.args/name




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] less name mangling

Thanks Steve!

We chatted, and Ray C is up for reviewing this, but I'm afraid it'll be the
usual maybe-this-week drill.


On Fri Sep 02 13:06:44 GMT-700 2011, Stephen Haberman wrote:


  I'd prefer this problem to be addressed in separate CL independent
  from of our effort.

 Here is a commit with just the name mangling. If there are any
 volunteers from the GWT team to review it, I'll promote it to
 an issue.


 https://github.com/stephenh/scalagwt-gwt/commit/5fb1f9717424b8c604f9f2c84b0bc713dcb2http://www.google.com/url?sa=Dq=https://github.com/stephenh/scalagwt-gwt/commit/5fb1f9717424b8c604f9f2c84b0bc713dcb2

 I do have a dangling todo in there, but it's somewhat
 tangential, so I'll avoid it until prompted.

 - Stephen

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Convert DynaTableRF to use maven. Clean up the docs in the other two (issue1537803)

2011-09-02 Thread Ray Ryan

ping, ready for review

On Thu Sep 01 15:08:29 GMT-700 2011, rj...@google.comgt wrote:

 http://gwt-code-reviews.appspot.com/1537803/http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1537803/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] [ANN] Scala+GWT 0.1-M1 released

2011-09-01 Thread Ray Ryan

Woo hoo!

On Thu Sep 01 09:26:47 GMT-700 2011, Grzegorz Kossakowski wrote:

Hello,

I'm excited to announce first milestone of Scala+GWT project.

Download (and then follow README instructions) from here:
http://goo.gl/Ym3xUhttp://www.google.com/url?sa=Dq=http%3A%2F%2Fgoo.gl%2FYm3xU

Release notes (included below) can be found here:
http://goo.gl/H8sanhttp://www.google.com/url?sa=Dq=http%3A%2F%2Fgoo.gl%2FH8san

Scala+GWT 0.1-M1

The first official milestone release from the Scala+GWT project.

This release consists of just samples packaged along with snapshot
of jars needed to build them. Those jars include our own version
of both GWT and Scala.

This release doesn't come with any official artifacts apart from the
tarball you can download from
http://github.com/scalagwt/scalagwt-samplehttp://www.google.com/url?sa=Dq=http%3A%2F%2Fgithub.com%2Fscalagwt%2Fscalagwt-sample
.

### What works

Samples show it the best. Here are some highlights:

* Mixed Scala/Java projects work very well (for GWT-supported Java
subset)
* Most of Scala language constructs are supported
* Most of Scala library code that makes sense in a browser context is
supported, including Scala collections

It's fair to say that we are not sure how far one can go with this release.
It might be that you can already
build something useful with what we already have. The only way to be sure
is start hacking!

### Known issues

* Compilation is very, very slow.
* `scala.immutable.{TreeMap, TreeSet}` are not supported due to various
bugs (thus sorted collections don't work)
* many patterns in pattern matching logic are not supported (tough issue)
examples include
* pattern alternatives (`|`)
* guard patterns (`if` guard)
* GWT's development mode is broken
* We are compiling with all optimizations turned off. This results in a
slow and very large JavaScript code.

### Reporting issues

We appreciate feedback. If you find something that doesn't work (e.g.
crashes either Scala or GWT compiler)
or JavaScript gives you weird results we'd love to hear about it. The most
effective way of reporting issues
is to modify `Hello World` sample to show your problem. Exact steps are:

1. Fork `scalagwt-sample` repo from here:
http://github.com/scalagwt/scalagwt-samplehttp://www.google.com/url?sa=Dq=http%3A%2F%2Fgithub.com%2Fscalagwt%2Fscalagwt-sample
2. Clone it: `git clone git://
github.com/YOUR_USER_NAME/scalagwt-sample.git`http://www.google.com/url?sa=Dq=http%3A%2F%2Fgithub.com%2FYOUR_USER_NAME%2Fscalagwt-sample.git
3. Modify hello world sample located in
`src/com/google/gwt/sample/jribble/client`
4. Commit and publish your example.
5. File a ticket here:
http://github.com/scalagwt/scalagwt-samplehttp://www.google.com/url?sa=Dq=http%3A%2F%2Fgithub.com%2Fscalagwt%2Fscalagwt-sample
and
mention your
fork while explaining your issue.

If you want to discuss your problem before reporting it, join
[scala...@googlegroups.comhttp://www.google.com/url?sa=Dq=mailto%3Ascalagwt%40googlegroups.com
](http://groups.google.com/group/scalagwt).

### What if I don't know GWT?

That shouldn't be a big problem. You've got Scala source code for samples
that show basic functionality
and provides basic setup. You may want to start with channging hello world
sample, recompiling it and
testing in a browser.

### What if I don't know Scala?

You might still want to check out samples to see how they might look like
in other language than Java.
We'll be cutting a lot more of boilerplate code once GWT libraries and APIs
receive enough of Scala's
[pimp-love](http://www.artima.com/weblogs/viewpost.jsp?thread=179766http://www.google.com/url?sa=Dq=http%3A%2F%2Fwww.artima.com%2Fweblogs%2Fviewpost.jsp%3Fthread%3D179766
).

### Need help? Want to discuss something?

Join us here:
[scala...@googlegroups.comhttp://www.google.com/url?sa=Dq=mailto%3Ascalagwt%40googlegroups.com
](http://groups.google.com/group/scalagwt).

Happy playing!

--
Grzegorz Kossakowski

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] [ANN] Scala+GWT 0.1-M1 released

2011-09-01 Thread Ray Ryan

Woo hoo!

On Thu Sep 01 09:26:47 GMT-700 2011, Grzegorz Kossakowski wrote:

Hello,

I'm excited to announce first milestone of Scala+GWT project.

Download (and then follow README instructions) from here:
http://goo.gl/Ym3xUhttp://www.google.com/url?sa=Dq=http%3A%2F%2Fgoo.gl%2FYm3xU

Release notes (included below) can be found here:
http://goo.gl/H8sanhttp://www.google.com/url?sa=Dq=http%3A%2F%2Fgoo.gl%2FH8san

Scala+GWT 0.1-M1

The first official milestone release from the Scala+GWT project.

This release consists of just samples packaged along with snapshot
of jars needed to build them. Those jars include our own version
of both GWT and Scala.

### What works

Samples show it the best. Here are some highlights:

### Known issues

### Reporting issues

### What if I don't know GWT?

### What if I don't know Scala?

### Need help? Want to discuss something?

Join us here:
[scala...@googlegroups.comhttp://www.google.com/url?sa=Dq=mailto%3Ascalagwt%40googlegroups.com
](http://groups.google.com/group/scalagwt).

Happy playing!

--
Grzegorz Kossakowski

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: Inherited exceptions in GWT-RPC

2011-08-31 Thread Ryan



On Aug 26, 12:51 am, Paul Robinson ukcue...@gmail.com wrote:
 You shouldn't need to do anything. It should work as you thought. That is, 
 you can throw any subclass of the declared exception(s).

 Is there something about BException and CException that stops them from being 
 gwt-serializable?

No, and in fact, if I declare them explicitly, then GWT throws them as-
is, rather than wrapping them in InvocationException.

 Alternatively, maybe it's because AException extends RuntimeException, and is 
 therefore not a checked exception. It could be that, being an unchecked 
 exception, GWT silently drops it (or rather, its subclasses) from the list of 
 exceptions to expect.

 Try AException extends Exception instead.

That's what I'm afraid of.  It looks like GWT will only allow declared
exceptions, and not subclasses.  I don't want to extend Exception,
because it means the Java compiler will force me to handle the
exception explicitly:

try {
service.remoteMethodThatThrowsException( ... , new
AsyncCallbackVoid() {
@Override
public void onFailure( Throwable caught ) { ... }

@Override
public void onSuccess( Void result ) {...}
} );
} catch (Exception e) {}

That sort of defeats the purpose for handling the exception in the
onFailure() method to begin with.



 HTH
 Paul

 On 25/08/11 21:09, Ryan wrote:







  My understanding is that in GWT-RPC, if a service throws an exception
  declared in the signature, then GWT will report that exception back to
  the client as-is.  If it's any other exception that's thrown, then GWT
  wraps it in an InvocationException.

  I have a hierarchy of exceptions that could get thrown in my
  application.  For example:

  class AException extends RuntimeException {}
  class BException extends AException {}
  class CException extends AException {}

  If I declare AException in the client, and throw it in the server,
  then the onFailure() method gets called with AException as expected.
  However, if I declare AException in the client, but throw either of
  the two child classes in the server, GWT wraps it in an
  InvocationException.

  What is the best way to intercept ALL the child exceptions?  The only
  thing I can see so far is declaring each possible child exception in
  the service signature, but that seems very brittle to me.

  Thanks,
  Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

[gwt-contrib] Re: Fixes for MobileWebApp pom.xml (issue1520809)

2011-08-31 Thread Ray Ryan

LGTM

On Wed, Aug 31, 2011 at 1:18 PM, drfibona...@google.com wrote:

 LGTM


 http://gwt-code-reviews.**appspot.com/1520809/http://gwt-code-reviews.appspot.com/1520809/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Make UmbrellaException a bit more convenient to read, and test it. (issue1532803)

2011-08-26 Thread Ray Ryan

r10584


On Thu Aug 25 23:08:59 GMT-700 2011, cromwell...@google.comgt wrote:

 lgtm

 http://gwt-code-reviews.appspot.com/1532803/http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1532803/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Inherited exceptions in GWT-RPC

2011-08-25 Thread Ryan

My understanding is that in GWT-RPC, if a service throws an exception
declared in the signature, then GWT will report that exception back to
the client as-is.  If it's any other exception that's thrown, then GWT
wraps it in an InvocationException.

I have a hierarchy of exceptions that could get thrown in my
application.  For example:

class AException extends RuntimeException {}
class BException extends AException {}
class CException extends AException {}

If I declare AException in the client, and throw it in the server,
then the onFailure() method gets called with AException as expected.
However, if I declare AException in the client, but throw either of
the two child classes in the server, GWT wraps it in an
InvocationException.

What is the best way to intercept ALL the child exceptions?  The only
thing I can see so far is declaring each possible child exception in
the service signature, but that seems very brittle to me.

Thanks,
Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: [gwt-contrib] maven source jars

2011-08-25 Thread Ray Ryan

Stephen, if you're game to do the research and the work, we're certainly
happy to have it done. Thanks either way.

On Wed Aug 24 12:39:51 GMT-700 2011, Stephen Haberman wrote:


  Hm, perhaps a few. I saw instructions on patching emma; nothing else
  is leaping out at me.

 Okay, there are patch files for json and streamhtmlparser. The latter is
 rebased. Leaving anything that is rebased or patched in the jar seems
 fine to me, since it's only a few.

 (I'm replying to myself, but I sent my previous message from the
 wrong email address, so it is probably moderated/dropped. Here's
 the text in case my previous message never shows up:)

 Taking gwt-dev-nodeps further, it looks like most of the deps come from
 bundling tomcat and htmlunit. Neither of which I use. I think it would
 be fairly easily, at least from a packaging perspective, to make
 gwt-dev-nodeps, gwt-tomcat, and gwt-htmlunit jars, none of which have
 their dependencies in them, but instead pulled in however projects
 otherwise manage transitive dependencies (poms/what have you).

 If I got a gwt-dev-nodeps/gwt-tomcat/gwt-htmlunit build working, would
 anyone be interested in that?

 - Stephen

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Make UmbrellaException a bit more convenient to read, and test it. (issue1532803)

2011-08-25 Thread Ray Ryan

How's that?

On Thu Aug 25 17:04:18 GMT-700 2011, cromwell...@google.comgt wrote:



 http://gwt-code-reviews.appspot.com/1532803/diff/1/user/src/com/google/web/bindery/event/shared/UmbrellaException.javahttp://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1532803/diff/1/user/src/com/google/web/bindery/event/shared/UmbrellaException.java
 File user/src/com/google/web/bindery/event/shared/UmbrellaException.java
 (right):


 http://gwt-code-reviews.appspot.com/1532803/diff/1/user/src/com/google/web/bindery/event/shared/UmbrellaException.java#newcode53
 user/src/com/google/web/bindery/event/shared/UmbrellaException.java:53http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1532803/diff/1/user/src/com/google/web/bindery/event/shared/UmbrellaException.java%23newcode53%0Auser/src/com/google/web/bindery/event/shared/UmbrellaException.java:53
 :
 return causes.size() == 1 ? ONE + message : MULTIPLE + message;
 Couldn't we tack on the rest of the exception messages here when there's
 multiple instead of just the first?

 http://gwt-code-reviews.appspot.com/1532803/http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1532803/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Changes setters/clearers com.google.gwt.dom.client.Style to return Style instead of void (issue1530803)

2011-08-22 Thread Ray Ryan

No good. This defeats compiler optimizations big time. We don't like void
returns either, but we like big fat slow apps even less.
On Aug 22, 2011 7:50 PM, larse...@gmail.com wrote:
 Reviewers: jlabanca, rjrjr,

 Description:
 Changes Style to return itself instead of returning void.

 issue 6717

 http://code.google.com/p/google-web-toolkit/issues/detail?id=6717

 Please review this at http://gwt-code-reviews.appspot.com/1530803/

 Affected files:
 user/src/com/google/gwt/dom/client/Style.java



-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Updates MobileWebApp to use GWT Maven Plugin 2.3.0-1 (issue1525806)

2011-08-18 Thread Ray Ryan

LGTM

D'oh! I thought that was meant to be *our* version string. Sorry.

On Thu Aug 18 08:55:54 GMT-700 2011, Rodrigo Chandia wrote:

 According to the GWT maven plugin web page 2.3.0-1 is the latest version.

 http://mojo.codehaus.org/gwt-maven-plugin/http://www.google.com/url?sa=Dq=http%3A%2F%2Fmojo.codehaus.org%2Fgwt-maven-plugin%2F

 El 18 de agosto de 2011 11:53, 
 rchan...@google.comhttp://www.google.com/url?sa=Dq=mailto%3Archandia%40google.com
  escribió:


 http://gwt-code-reviews.**appspot.com/1525806/diff/1/**
 samples/mobilewebapp/pom.xmlhttp://www.google.com/url?sa=Dq=http%3A%2F%2Fgwt-code-reviews.appspot.com%2F1525806%2Fdiff%2F1%2Fsamples%2Fmobilewebapp%2Fpom.xml
 File samples/mobilewebapp/pom.xml (right):

 http://gwt-code-reviews.**appspot.com/1525806/diff/1/**
 samples/mobilewebapp/pom.xml#**newcode191http://www.google.com/url?sa=Dq=http%3A%2F%2Fgwt-code-reviews.appspot.com%2F1525806%2Fdiff%2F1%2Fsamples%2Fmobilewebapp%2Fpom.xml%23newcode191
 samples/mobilewebapp/pom.xml:**191: version2.3.0-1/version
 On 2011/08/18 15:34:16, rjrjr wrote:

 What's the -1 for? Also, tab character in this line.

 Done, untabified the file. The -1 is part of the version string
 2.3.0-1


 http://gwt-code-reviews.**appspot.com/1525806/http://www.google.com/url?sa=Dq=http%3A%2F%2Fgwt-code-reviews.appspot.com%2F1525806%2F




 --
 Rodrigo Chandia | Software Engineer | 
 rchan...@google.comhttp://www.google.com/url?sa=Dq=mailto%3Archandia%40google.com
  | 678 7431725



-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix http://code.google.com/p/google-web-toolkit/issues/detail?id=6161 (issue1520807)

2011-08-18 Thread Ray Ryan

No, but I'm not sure it can be. The error is actually legitimate: you have
@UiField Label and you're trying to stick an instance of Element in it, in
this case a funny looking one: g:Label...

My alternative is to make this error fatal, which means that you could not
use binder to render prefixed dom elements. Not a very compelling use case,
I agree, but who knows how many existing templates are already making this
error. I'm not really in the mood to be hunted down by the people I'd
break...



On Thu Aug 18 09:59:22 GMT-700 2011, mros...@google.comgt wrote:



 http://gwt-code-reviews.appspot.com/1520807/diff/1/user/src/com/google/gwt/uibinder/elementparsers/HtmlInterpreter.javahttp://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1520807/diff/1/user/src/com/google/gwt/uibinder/elementparsers/HtmlInterpreter.java
 File
 user/src/com/google/gwt/uibinder/elementparsers/HtmlInterpreter.java
 (right):


 http://gwt-code-reviews.appspot.com/1520807/diff/1/user/src/com/google/gwt/uibinder/elementparsers/HtmlInterpreter.java#newcode104
 user/src/com/google/gwt/uibinder/elementparsers/HtmlInterpreter.java:104http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1520807/diff/1/user/src/com/google/gwt/uibinder/elementparsers/HtmlInterpreter.java%23newcode104%0Auser/src/com/google/gwt/uibinder/elementparsers/HtmlInterpreter.java:104
 :
 writer.warn(elem, Prefix \%s:\ has unrecognized xmlns \%s\, 
 Will this warning be shown in proximity to where an ERROR is shown when
 it does fail?

 http://gwt-code-reviews.appspot.com/1520807/http://www.google.com/url?sa=Dq=http://gwt-code-reviews.appspot.com/1520807/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adding a new CellTableHeaderBuilder API, which allows custom headers and footers in CellTable. C... (issue1499808)

LGTM

On Wed, Aug 17, 2011 at 7:32 AM, jlaba...@google.com wrote:

 A patch is coming that modifies the TableBuilder API to make it more
 flexible.  TableBuilder.Utility is going away completely, and the event
 handling implementation is moved from AbstractCellTable into
 AbstractTableBuilder.  This will allow users to implement a simple grid
 based TableBuilder with faster rendering and event handling logic.

 The new API is also much more builder-like, and simpler to boot.Once
 those changes are in, I'll revisit HeaderCreator and apply similar
 changes, hopefully eliminating the Helper class.  Either way, there will
 be follow-up changes that
 unify the terminology used in TableBuilder/HeaderCreator.



 http://gwt-code-reviews.**appspot.com/1499808/diff/**
 14004/samples/showcase/src/**com/google/gwt/sample/**
 showcase/client/content/cell/**CwCustomDataGrid.javahttp://gwt-code-reviews.appspot.com/1499808/diff/14004/samples/showcase/src/com/google/gwt/sample/showcase/client/content/cell/CwCustomDataGrid.java
 File
 samples/showcase/src/com/**google/gwt/sample/showcase/**
 client/content/cell/**CwCustomDataGrid.java
 (right):

 http://gwt-code-reviews.**appspot.com/1499808/diff/**
 14004/samples/showcase/src/**com/google/gwt/sample/**
 showcase/client/content/cell/**CwCustomDataGrid.java#**newcode79http://gwt-code-reviews.appspot.com/1499808/diff/14004/samples/showcase/src/com/google/gwt/sample/showcase/client/content/cell/CwCustomDataGrid.java#newcode79
 samples/showcase/src/com/**google/gwt/sample/showcase/**
 client/content/cell/**CwCustomDataGrid.java:79:
 * Example file.
 On 2011/08/16 02:16:25, skybrian wrote:

 Defines a custom table that displays a contact in each row.
 This is an example that shows how to completely customize the

 appearance of the

 headers, data rows, and footers in a CellTable.


 Done.


 http://gwt-code-reviews.**appspot.com/1499808/diff/**
 14004/samples/showcase/src/**com/google/gwt/sample/**
 showcase/client/content/cell/**CwCustomDataGrid.java#**newcode143http://gwt-code-reviews.appspot.com/1499808/diff/14004/samples/showcase/src/com/google/gwt/sample/showcase/client/content/cell/CwCustomDataGrid.java#newcode143
 samples/showcase/src/com/**google/gwt/sample/showcase/**
 client/content/cell/**CwCustomDataGrid.java:143:
 * A custom header builder.
 On 2011/08/16 02:16:25, skybrian wrote:

 Renders custom headers that ...


 Done.


 http://gwt-code-reviews.**appspot.com/1499808/diff/**
 14004/samples/showcase/src/**com/google/gwt/sample/**
 showcase/client/content/cell/**CwCustomDataGrid.java#**newcode164http://gwt-code-reviews.appspot.com/1499808/diff/14004/samples/showcase/src/com/google/gwt/sample/showcase/client/content/cell/CwCustomDataGrid.java#newcode164
 samples/showcase/src/com/**google/gwt/sample/showcase/**
 client/content/cell/**CwCustomDataGrid.java:164:
 public void buildHeader(Helper**ContactInfo utility) {
 On 2011/08/16 02:16:25, skybrian wrote:

 s/utility/helper/


 Done.


 http://gwt-code-reviews.**appspot.com/1499808/diff/**
 14004/samples/showcase/src/**com/google/gwt/sample/**
 showcase/client/content/cell/**CwCustomDataGrid.java#**newcode209http://gwt-code-reviews.appspot.com/1499808/diff/14004/samples/showcase/src/com/google/gwt/sample/showcase/client/content/cell/CwCustomDataGrid.java#newcode209
 samples/showcase/src/com/**google/gwt/sample/showcase/**
 client/content/cell/**CwCustomDataGrid.java:209:
 * Build a single header.
 On 2011/08/16 02:16:25, skybrian wrote:

 Renders the header of one column, with the given options.


 Done.


 http://gwt-code-reviews.**appspot.com/1499808/diff/**
 14004/samples/showcase/src/**com/google/gwt/sample/**
 showcase/client/content/cell/**CwCustomDataGrid.java#**newcode211http://gwt-code-reviews.appspot.com/1499808/diff/14004/samples/showcase/src/com/google/gwt/sample/showcase/client/content/cell/CwCustomDataGrid.java#newcode211
 samples/showcase/src/com/**google/gwt/sample/showcase/**
 client/content/cell/**CwCustomDataGrid.java:211:
 * @param utility the utility used to builder the header
 On 2011/08/16 02:16:25, skybrian wrote:

 used to build


 Done.


 http://gwt-code-reviews.**appspot.com/1499808/diff/**
 14004/samples/showcase/src/**com/google/gwt/sample/**
 showcase/client/content/cell/**CwCustomDataGrid.java#**newcode213http://gwt-code-reviews.appspot.com/1499808/diff/14004/samples/showcase/src/com/google/gwt/sample/showcase/client/content/cell/CwCustomDataGrid.java#newcode213
 samples/showcase/src/com/**google/gwt/sample/showcase/**
 client/content/cell/**CwCustomDataGrid.java:213:
 * @param header the header to buil
 On 2011/08/16 02:16:25, skybrian wrote:

 the Header to render


 Done.


 http://gwt-code-reviews.**appspot.com/1499808/diff/**
 14004/samples/showcase/src/**com/google/gwt/sample/**

[gwt-contrib] Re: Provides an integration test for IsRenderable (issue1527804)

I like #1 too. I think we should try to narrow the visibility of
PotentialElement as much as we can.

So #1 means two things , right?

• Widgets are seated in their @UiFields immediately
• In an IsRenderable owner, Element and subclasses are only available via
LazyDomElement, and @UiField Element is a compile time error

I've tweaked the test a bit (will update soon), and I'm happy to report that
composites around non-IsRenderables work as expected, with element fields
filled immediately. Given that I don't think we need to delay the switch to
using lazy widget builder by default.

On Wed Aug 17 06:14:52 GMT-700 2011, Hermes Freitas wrote:

WidgetInterpreter and WidgetPlaceholderInterpreter shouldn't output
LazyDomElement. Rafa, do you remember why? I don't think this aggregates any
performance gain for us, am I missing something?

And I vote for #1

On Tue, Aug 16, 2011 at 10:10 PM, Rafael Castro
rdcas...@google.comhttp://www.google.com/url?sa=Dq=mailto%3Ardcastro%40google.com
wrote:

+hermes

Good point, this is really tricky. The problem here is that we don't
actually have the DOM element until the widget is attached. I see 2 options:
1-) We force the UiField to be a LazyDomElement, so this is explicit.
2-) We use PotentialElement with a resolver that throws an Exception (i.e.,
it's only really resolved when it's attached).

what do you think?

ps.: really nice tests, thanks for putting them together!

On Tue, Aug 16, 2011 at 5:13 PM,
rj...@google.comhttp://www.google.com/url?sa=Dq=mailto%3Arjrjr%40google.com
wrote:

On 2011/08/17 00:12:24, rjrjr wrote:

Ready for review.

Rafa, this turned up one issue that concerns me: most @UiField fields
are not filled in until the widget is attached to the dom, but we're not
consistent about it. See the big comment in testDeep.

http://gwt-code-reviews.**appspot.com/1527804/http://www.google.com/url?sa=Dq=http%3A%2F%2Fgwt-code-reviews.appspot.com%2F1527804%2F

--
--Hermes Freitas

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Provides an integration test for IsRenderable (issue1527804)

Cool, I've filed
http://code.google.com/p/google-web-toolkit/issues/detail?id=6701.

Can I get an LGTM and submit this thing?

On Wed Aug 17 09:58:03 GMT-700 2011, Rafael Castro wrote:

Awesome, I like #1 too. I was driving to work this morning and thinking
about it: #2 actually encourages bad behavior, because it'll seem it's OK to
fiddle with the elements between calling bind and attaching, and it's really
not. We _could_ make an effort to make it work, but it's much better to make
the flow clearer this way: if you're using lazy widgets, your elements have
to be lazy too.

On Wed, Aug 17, 2011 at 9:41 AM, Ray Ryan
rj...@google.comhttp://www.google.com/url?sa=Dq=mailto%3Arjrjr%40google.com
wrote:

I like #1 too. I think we should try to narrow the visibility of
PotentialElement as much as we can.

So #1 means two things , right?

• Widgets are seated in their @UiFields immediately
• In an IsRenderable owner, Element and subclasses are only available via
LazyDomElement, and @UiField Element is a compile time error

I've tweaked the test a bit (will update soon), and I'm happy to report
that composites around non-IsRenderables work as expected, with element
fields filled immediately. Given that I don't think we need to delay the
switch to using lazy widget builder by default.

On Wed Aug 17 06:14:52 GMT-700 2011, Hermes Freitas wrote:

WidgetInterpreter and WidgetPlaceholderInterpreter shouldn't output
LazyDomElement. Rafa, do you remember why? I don't think this aggregates any
performance gain for us, am I missing something?

And I vote for #1

On Tue, Aug 16, 2011 at 10:10 PM, Rafael Castro
rdcas...@google.comhttp://www.google.com/url?sa=Dq=mailto%3Ardcastro%40google.com
wrote:

+hermes

what do you think?

ps.: really nice tests, thanks for putting them together!

On Tue, Aug 16, 2011 at 5:13 PM,
rj...@google.comhttp://www.google.com/url?sa=Dq=mailto%3Arjrjr%40google.com
wrote:

On 2011/08/17 00:12:24, rjrjr wrote:

Ready for review.

Rafa, this turned up one issue that concerns me: most @UiField fields
are not filled in until the widget is attached to the dom, but we're not
consistent about it. See the big comment in testDeep.

http://gwt-code-reviews.**appspot.com/1527804/http://www.google.com/url?sa=Dq=http%3A%2F%2Fgwt-code-reviews.appspot.com%2F1527804%2F

--
--Hermes Freitas

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: Re: [gwt-contrib] Aw: Regression: instanceof compiler issue