date:20130821

You need to check inside the callback's onSuccess/onFailure method if the 
callback should still be executed. Something like:

service.callServerMethod(new Callback() {

  final Item selectedItemOnCallback = currentItem; //currentItem is an 
instance variable of the presenter

  void onSuccess() {
if(selectedItemOnCallback.equals(this.currentItem)) {
   // continue work
}
  }
}

If this.currentItem changes after the callback as been created if won't 
execute its onSuccess anymore.

For Activities that are recreated whenever the data changes I use an active 
flag that is set to true in Activity.start() and to false in 
Activity.onStop/onCancel. Callbacks then check this boolean flag.

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deploy GWT application on multiple servers behind load balancer

2013-08-21 Thread cutout33

Hi Jens,

Thanks for your response, I think everything will work fine once we cache 
the sessions and make them available to all running instances :)

thanks again

On Tuesday, August 20, 2013 11:14:31 AM UTC+3, Jens wrote:

 I don't now how spring security works, but normally your app server should 
 replicate the user session across your cluster nodes. If that works then 
 spring security should probably work as well in the cluster. If you use 
 Jetty as server you could use 3rd party libraries for implementing session 
 clustering, e.g. Hazelcast, Terracotta, Ehcache, and others.

 XsrfTokens will work across servers if you can recreate the token on each 
 server. For example if you choose to generate a token using MD5(session id 
 + user id) or similar. As long as session replication works and you have 
 the user id on each server available (could be stored in the session) you 
 can recreate the token and check it against the one the client provides 
 with its request. The default implementation of GWTs XsrfTokenService just 
 does MD5(session id from session cookie) but you can easily change this if 
 you want.

 -- J.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Internal Compiler Error / Xerces

2013-08-21 Thread Ronan Quillevere

As said by DP,

I had to add the following to my pom.cml to make it work

dependency
groupIdxerces/groupId
artifactIdxercesImpl/artifactId
version2.11.0/version
/dependency
dependency
groupIdxml-apis/groupId
artifactIdxml-apis/artifactId
version1.4.01/version
/dependency

On Friday, April 19, 2013 9:25:19 PM UTC+2, DP wrote:

 I had similar problem.  I resolved it by adding xercesImpl artifact to my 
 Maven pom.xml

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GWT Button becoming transparent due to CSS?

Well I further investigated the problem, and it turns out its a bug in 
WebKit browsers.
The widget is not redrawn by the browser, despite the fact it's newly 
created.

Does anyone know how to manually trigger a widget redraw or a browser 
Resize event?

Hope anyone knows.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Manually Trigger Browser Resize

In one of my applications I am ResizeHandler to resize the GUI of my app.
This works fine, but there is one part in my code where I would like to 
manually trigger a Resize.
Does anyone know how I can do that?

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Manually Trigger Browser Resize

If you want to resize the browser window then use the Window class. If you 
just want to execute the ResizeHandler code without having a ResizeEvent 
then just create a method for it and let the ResizeHandler call that 
method. Then you can call the method from elsewhere too.

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Manually Trigger Browser Resize

This is a part of my code:

Window.addResizeHandler(new PageResizeHandler());

and 

private class PageResizeHandler implements ResizeHandler {
@Override
public void onResize(ResizeEvent event) {
mainFrame.handleResize(event.getWidth(), event.getHeight());
}
}

This code does the job fine when the browser resizes. However now I would 
like manually trigger the browser resize event to force a WebKit browser to 
redraw.
simply invoking the handleResize method does not do the job.

On Wednesday, August 21, 2013 8:01:34 PM UTC+8, AgitoM wrote:

 In one of my applications I am ResizeHandler to resize the GUI of my app.
 This works fine, but there is one part in my code where I would like to 
 manually trigger a Resize.
 Does anyone know how I can do that?


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Manually Trigger Browser Resize

GWT's Window class has methods to modify the browser window size which 
should trigger a global repaint. But I am not sure if that is also true for 
tablets/phones as their apps always run in full screen browsers whose size 
you can not change.

To just repaint a widget / html element you could hide and show it again by 
adding and removing display:none but this could cause some flicker effects.


-- J.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Manually Trigger Browser Resize

Thank your help so far Jens. Any example on which Window method I can use?
I tried looking for it, but couldn't find it.

On Wednesday, August 21, 2013 8:01:34 pm UTC +8, AgitoM wrote:

 In one of my applications I am ResizeHandler to resize the GUI of my app.
 This works fine, but is there one part in my code YogyakartaT I would like 
 to manually trigger a resizing.
 Does anyone know how I can do that?


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Manually Trigger Browser Resize

resizeTo() ?

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: issue with tomcat server

2013-08-21 Thread Michael Joyner

You need to change how much memory java is allowed to allocate for the
tomcat process. The default is rather small.


On Tue, Aug 20, 2013 at 4:56 PM, fedex shashankgris...@gmail.com wrote:

 For my application I am writing 1 million records to the csv file. It
 works fine when I run in dev mode but when I deploy the application on
 tomcat it throws java heap memory issue? why?

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: issue with tomcat server

2013-08-21 Thread Juan Pablo Gardella

I've created a file with 6M of records using
http://ostermiller.org/utils/CSV.html without java heap memory issue. I
think increment the memory it is a workaround and isn't the solution. Check
how much records you are putting in memory.




2013/8/21 Michael Joyner mich...@newsrx.com

 You need to change how much memory java is allowed to allocate for the
 tomcat process. The default is rather small.


 On Tue, Aug 20, 2013 at 4:56 PM, fedex shashankgris...@gmail.com wrote:

 For my application I am writing 1 million records to the csv file. It
 works fine when I run in dev mode but when I deploy the application on
 tomcat it throws java heap memory issue? why?

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.


  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Manually Trigger Browser Resize

2013-08-21 Thread Blaze

This Window resize would be very hard to be done.

You cannot resize window if its not a window opened by your 
application...(just one opend by a opener one can be re-sized, you cannot 
resize a tab)
Why do you need the resize? If its just to force a redraw, relayout because 
you added something in the DOM and this is not sized correct then you can 
try setting a style.display on the MainFrame you have by setting it to 
once to style.display.None and then back again to style.display.block...

This also dosent mean that the relayout will work, maybe the css its just 
not correct for what you want to do...

Note: Window class inside has a check if the new size is diff then the 
previous one, just in this case fires the handler...

 Blaze

Am Mittwoch, 21. August 2013 14:01:34 UTC+2 schrieb AgitoM:

 In one of my applications I am ResizeHandler to resize the GUI of my app.
 This works fine, but there is one part in my code where I would like to 
 manually trigger a Resize.
 Does anyone know how I can do that?


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: TypeError: $doc.body.attachEvent is not a function

2013-08-21 Thread SaiP

It was a setting in the *.gwt.xml file. User agent attribute. Which was set 
to only IE. Hope it helps some one. If you comment it out, it will create 
permutations for all the browsers. Or mention gecko1_8 in it for the 
mozilla. 

On Friday, August 9, 2013 9:49:57 AM UTC-5, SaiP wrote:

 Any idea on how to fix this type of issue? obviously, i'm trying to re 
 install the GWT plugin into my RAD. Or may be the Ant did not do well. 

 On Thursday, August 8, 2013 11:07:47 AM UTC-5, Jens wrote:

 'attachEvent' is Internet Explorer specific and is used in 
 com.google.gwt.user.client.impl.DomImplTrident.java. 

 If Firefox executes it then GWT thinks your FireFox browser is Internet 
 Explorer (check the user agent string of your FireFox browser) or you use a 
 GWT library that has messed up deferred binding rules found in 
 com.google.gwt.user.DOM.gwt.xml.

 -- J.





-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: EventBus problem

2013-08-21 Thread Michael Prentice

I can't see in the code where you initialize your eventBus. I also can't 
see where you set it on your presenter.

I know that Eric K was saying that he doesn't fire events in his JUnit 
tests, instead he just calls the handler directly on the presenter and 
passes in the event.

On Tuesday, August 20, 2013 5:13:47 PM UTC-4, df wrote:

 Hello 
 I want to initialize my widget by data. I sent by eventbus to them event 
 indicating that there is new object. I tried to work with eventbus in 3 
 ways 

 1:
 for(Unit unit : createTestData()){
 eventBus.fireEvent(new ScenarioElementEvent(new 
 UnitStoreElementUnit(unit, null), ScenarioElementEventType.ADDED, 
 ScenarioElementEventObjectType.GEO_OBJECT));
 }

 2:  
 Timer t = new Timer() {
  @Override
 public void run() {
 ListUnit units = createTestData();
 Console.log(Level.INFO,Test data have  + units.size());
 for(int i = 0; i  units.size(); i ++){
 Unit unit = units.get(i);
 Console.log(Level.INFO,Fire event  + i +   + unit.getDescription());
 eventBus.fireEvent(new ScenarioElementEvent(new 
 UnitStoreElementUnit(unit, null), ScenarioElementEventType.ADDED, 
 ScenarioElementEventObjectType.GEO_OBJECT));
 }
 }
 };
 t.schedule(1);


 3:
 ListUnit units = createTestData();
 for(int i = 0; i  units.size(); i ++){
 final Unit unit = units.get(i);
 Console.log(Level.INFO,Fire event  + i +   + unit.getDescription());
 Timer t = new Timer(){

 @Override
 public void run() {
 eventBus.fireEvent(new ScenarioElementEvent(new 
 UnitStoreElementUnit(unit, null), ScenarioElementEventType.ADDED, 
 ScenarioElementEventObjectType.GEO_OBJECT)); 
 }
  };
 t.schedule(1);
 }
 }


 Only third works. 
 First - no one handler is notified
 Second - only one event is send.

 Can anybody say why?
 Thanks


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

exception when deployed on tomcat - Please help

2013-08-21 Thread fedex

I built an application where I write 1 million row of data to the csv file. 
It works great when I deploy the application on dev mode(jetty server) but 
when I deployed the same application on tomcat I get the below 
exception.Please Can anyone suggest what could be the reason?



Exception in thread http-bio-8080-exec-5 java.lang.OutOfMemoryError: Java 
heap space
at sun.util.resources.TimeZoneNames.getContents(TimeZoneNames.java:201)
at 
sun.util.resources.OpenListResourceBundle.loadLookup(OpenListResourceBundle.java:125)
at 
sun.util.resources.OpenListResourceBundle.loadLookupTablesIfNecessary(OpenListResourceBundle.java:113)
Exception in thread http-bio-8080-AsyncTimeout 
java.lang.OutOfMemoryError: Java heap space
org.apache.catalina.connector.CoyoteOutputStream@18174a0
at 
java.util.concurrent.ConcurrentLinkedQueue.iterator(ConcurrentLinkedQueue.java:667)
at 
org.apache.tomcat.util.net.JIoEndpoint$AsyncTimeout.run(JIoEndpoint.java:153)
at java.lang.Thread.run(Thread.java:722)

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: issue with tomcat server

2013-08-21 Thread fedex

how to change it? any idea?

On Wednesday, August 21, 2013 9:10:22 AM UTC-5, Michael Joyner wrote:

 You need to change how much memory java is allowed to allocate for the 
 tomcat process. The default is rather small.


 On Tue, Aug 20, 2013 at 4:56 PM, fedex shashan...@gmail.com javascript:
  wrote:

 For my application I am writing 1 million records to the csv file. It 
 works fine when I run in dev mode but when I deploy the application on 
 tomcat it throws java heap memory issue? why?
  
 -- 
 You received this message because you are subscribed to the Google Groups 
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to google-web-toolkit+unsubscr...@googlegroups.com javascript:.
 To post to this group, send email to 
 google-we...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: issue with tomcat server

2013-08-21 Thread fedex

hey juno

how to check how many records I am putting in the memory? 

On Wednesday, August 21, 2013 9:14:01 AM UTC-5, Juan Pablo Gardella wrote:

 I've created a file with 6M of records using 
 http://ostermiller.org/utils/CSV.html without java heap memory issue. I 
 think increment the memory it is a workaround and isn't the solution. Check 
 how much records you are putting in memory.




 2013/8/21 Michael Joyner mic...@newsrx.com javascript:

 You need to change how much memory java is allowed to allocate for the 
 tomcat process. The default is rather small.


 On Tue, Aug 20, 2013 at 4:56 PM, fedex shashan...@gmail.comjavascript:
  wrote:

 For my application I am writing 1 million records to the csv file. It 
 works fine when I run in dev mode but when I deploy the application on 
 tomcat it throws java heap memory issue? why?
  
 -- 
 You received this message because you are subscribed to the Google 
 Groups Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to google-web-toolkit+unsubscr...@googlegroups.comjavascript:
 .
 To post to this group, send email to 
 google-we...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.


  -- 
 You received this message because you are subscribed to the Google Groups 
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to google-web-toolkit+unsubscr...@googlegroups.com javascript:.
 To post to this group, send email to 
 google-we...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GWT 2.5.1 now available

2013-08-21 Thread SaiP

Thanks a lot for the update, My main concern is the speed of the debugger. 
Hope you guys come up with a better solution for this. Thanks.

On Monday, March 11, 2013 8:11:16 PM UTC-5, Matthew Dempsky wrote:

 Hi everyone,

 We're excited to announce the GWT 2.5.1 release!  There will be an 
 announcement soon on the GWT Blog http://googlewebtoolkit.blogspot.com/, 
 and you can download it 
 herehttps://code.google.com/p/google-web-toolkit/downloads/detail?name=gwt-2.5.1.zip.
  
  This release has been uploaded to Maven Central with the version string of 
 2.5.1.

 GWT 2.5.1 contains over 50 new bug fixes, many of which were contributed 
 by the community.  Thanks to everyone who reported issues and/or submitted 
 patches.

 -Matthew, on behalf of the GWT team


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Try a run a test and explore the memory with some tool: (visualvm,
jconsole, yourtoolkit, http://www.eclipse.org/mat/ ). If you are reading
from JDBC remember to use
TYPE_FORWARD_ONLYhttp://docs.oracle.com/javase/7/docs/api/java/sql/ResultSet.html#TYPE_FORWARD_ONLYin
the resultset to reduce the use of memory.

Regards,
Juan

2013/8/21 fedex shashankgris...@gmail.com

hey juno

how to check how many records I am putting in the memory?

On Wednesday, August 21, 2013 9:14:01 AM UTC-5, Juan Pablo Gardella wrote:

I've created a file with 6M of records using
http://ostermiller.org/utils/**CSV.htmlhttp://ostermiller.org/utils/CSV.htmlwithout
java heap memory issue. I think increment the memory it is a
workaround and isn't the solution. Check how much records you are putting
in memory.

2013/8/21 Michael Joyner mic...@newsrx.com

You need to change how much memory java is allowed to allocate for the
tomcat process. The default is rather small.

On Tue, Aug 20, 2013 at 4:56 PM, fedex shashan...@gmail.com wrote:

For my application I am writing 1 million records to the csv file. It
works fine when I run in dev mode but when I deploy the application on
tomcat it throws java heap memory issue? why?

Visit this group at
http://groups.google.com/**group/google-web-toolkithttp://groups.google.com/group/google-web-toolkit
.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ImageResource question

2013-08-21 Thread Steve C

I haven't sorted out in my mind the best approach for a few of the details, 
in particular making it reusable, but this works.  Consider it more of a 
proof of concept.

You'd need to create red.png in the war directory, or could try out a data 
url (which per my tests works with this).

For a bundle with more images, the asynchronicity gets to be a bigger 
issue, since you'd need to have something like a master callback once all 
of the individual image callbacks have completed.  Also, there's no 
facility for sprites, although I think it could be implemented.


public class DynamicResourcesDemo implements EntryPoint {

private DynamicMenuBarResources resources;
private MenuBar bar;

public void onModuleLoad() {

MenuBar.Resources defaultResources = 
GWT.create(MenuBar.Resources.class);
MyImageResource imgres = new 
MyImageResource(defaultResources.menuBarSubMenuIcon());
resources = new DynamicMenuBarResources(imgres);

imgres.load(red.png, new CallbackVoid, Throwable() {
@Override
public void onSuccess(Void result) {
showUi();
}

@Override
public void onFailure(Throwable reason) {
Window.alert(Error);
}
});
}

private void showUi() {
MenuBar fileMenu = new MenuBar(true);
fileMenu.addItem(Open, new Scheduler.ScheduledCommand() {
@Override
public void execute() {
Window.alert(Open File);
}
});
fileMenu.addItem(Exit, new Scheduler.ScheduledCommand() {
@Override
public void execute() {
Window.alert(So long!);
}
});
MenuBar actionsMenu = new MenuBar(true, resources);
actionsMenu.addItem(File, fileMenu);
bar = new MenuBar();
bar.addItem(Actions, actionsMenu);

RootPanel.get().add(bar);
}
}

//-

public class DynamicMenuBarResources implements Resources {

private static Resources base = GWT.create(Resources.class);
private ImageResource menuBarSubmenuIconResource;

public DynamicMenuBarResources() {
}

public DynamicMenuBarResources(ImageResource 
menuBarSubmenuIconResource) {
this.menuBarSubmenuIconResource = menuBarSubmenuIconResource;
}

@Override
@ImageOptions(flipRtl = true)
public ImageResource menuBarSubMenuIcon() {
if (menuBarSubmenuIconResource != null) {
return menuBarSubmenuIconResource;
} else {
return base.menuBarSubMenuIcon();
}
}

}

//

public class MyImageResource implements ImageResource {

private Image image;
private ImageResource defaultResource;
private boolean imageValid = false;

public MyImageResource(ImageResource defaultResource) {
image = new Image();
this.defaultResource = defaultResource;
}

public void load(String url, final CallbackVoid, Throwable callback) {
image.setUrl(url);
final Panel pnl = new SimplePanel();
pnl.add(image);
Style pnlStyle = pnl.getElement().getStyle();
pnlStyle.setVisibility(Visibility.HIDDEN);
pnlStyle.setPosition(Position.ABSOLUTE);
image.addLoadHandler(new LoadHandler() {
@Override
public void onLoad(LoadEvent event) {
RootPanel.get().remove(pnl);
imageValid = true;
if (callback != null) callback.onSuccess(null);
}
});
image.addErrorHandler(new ErrorHandler() {
@Override
public void onError(ErrorEvent event) {
RootPanel.get().remove(pnl);
// this lets the resource fall back to the default
if (callback != null) callback.onSuccess(null);
// this would instead invoke the error handling for the 
callback
//if (callback != null) callback.onFailure(new 
Exception(Image Resource Load Error));
}
});
RootPanel.get().add(pnl);
}

@Override
public String getName() {
return imageValid ?  : defaultResource.getName();  // ???
}

@Override
public int getHeight() {
return imageValid ? image.getHeight() : defaultResource.getHeight();
}

@Override
public int getLeft() {
return imageValid ? 0 : defaultResource.getLeft();
}

@Override
public SafeUri getSafeUri() {
return imageValid ? UriUtils.fromSafeConstant(image.getUrl()) : 
defaultResource.getSafeUri();
}

@Override
public int getTop() {
return imageValid ? 0 : defaultResource.getTop();
}

@Override
@Deprecated
public String getURL() {
return imageValid ? image.getUrl()

Re: exception when deployed on tomcat - Please help

How often do you want to ask this question again? An OutOfMemoryError is 
nothing GWT specific.

There are basically three ways to deal with it:
1.) increase Tomcat's heap memory
2.) load less stuff into memory before writing the file. E.g. use 
Input/OutputStreams along with fixed sized buffers instead of reading 
everything into a large String and then writing that large String to a File.
3.) If you think 1.) and 2.) are ok in your project then check for memory 
leaks by creating a heap dump and analyzing it

Google search has tons of results for all of the above points.

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

GXT Grid row is not selectable

2013-08-21 Thread SaiP

Hello,

I'm new to GWT. I've a grid which has simple data mapped from a BaseModel. 
When the user selects a row, it is supposed to be selected. I've checked a 
few examples and post, it seems that we are doing it correctly. Code below 
to create the grid. 

Could you please mention the senarios in which this selection will be 
blocked?

ListBaseModel gridData= new ArrayListBaseModel();
 ListColumnConfig config = new ArrayListColumnConfig();
config.add(new ColumnConfig(isPrimary,Primary,70));
config.add(new ColumnConfig(accountName,Account Name,320));
config.add(new ColumnConfig(activeProgram,Active Program,150));
config.add(new ColumnConfig(accountNumber,Account,100));
config.add(new ColumnConfig(accountXref,Account Xref,150));
config.add(new ColumnConfig(status,Status,93));
 ColumnModel cm = new ColumnModel(config);
 PagingModelMemoryProxy proxy = new PagingModelMemoryProxy(gridData);
final PagingLoaderPagingLoadResultData loader = new 
BasePagingLoaderPagingLoadResultData(proxy);
 loader.setRemoteSort(false);
store = new GroupingStoreData(loader);
final PagingToolBar toolBar = new PagingToolBar(10);
toolBar.bind(loader);
loader.load(0, 10);
 GroupingView view = new GroupingView();
view.setShowGroupedColumn(true);
view.setForceFit(true);
view.setGroupRenderer(new GridGroupRenderer() {
public String render(GroupColumnData data) {
String l = data.models.size() == 1 ? Item : Items;
return data.group.substring(data.group.indexOf(|) + 1, 
data.group.length())
+  ( + data.models.size() +   + l + );
}
});
 ContentPanel cp = new ContentPanel();
cp.setBodyBorder(false);
 cp.setButtonAlign(HorizontalAlignment.CENTER);
cp.setLayout(new FitLayout());
cp.setFrame(true);
cp.setSize(verticalPanelWidth, 300px);
cp.setBorders(hidden);
cp.setBottomComponent(toolBar);
GWT.log(store size + store.getCount());
grid = new GridData(store,cm);
final GridSelectionModelData sm = grid.getSelectionModel();
sm.setSelectionMode(SelectionMode.SINGLE);
grid.setSelectionModel(sm);
 final CellSelectionModelData csm = new CellSelectionModelData();
csm.bindGrid(grid);
 grid.setBorders(true);
grid.ensureDebugId(gridDebugId);
//grid.ensureDebugId(gridDebugId);
grid.setTabIndex(5);
cp.add(grid);
return cp;

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: issue with tomcat server

2013-08-21 Thread Michael Prentice

http://stackoverflow.com/questions/8446704/memory-allocation-in-tomcat

On Wednesday, August 21, 2013 11:41:02 AM UTC-4, fedex wrote:

 how to change it? any idea?

 On Wednesday, August 21, 2013 9:10:22 AM UTC-5, Michael Joyner wrote:

 You need to change how much memory java is allowed to allocate for the 
 tomcat process. The default is rather small.


 On Tue, Aug 20, 2013 at 4:56 PM, fedex shashan...@gmail.com wrote:

 For my application I am writing 1 million records to the csv file. It 
 works fine when I run in dev mode but when I deploy the application on 
 tomcat it throws java heap memory issue? why?




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

How do I avoid this issue?

2013-08-21 Thread Joel Cairney

I'm working on a large GWT application, and on chrome for android we're 
running into these issues:

https://code.google.com/p/chromium/issues/detail?id=258044

The HTML and CSS patterns that create this issue are commonly found in GWT 
widgets, or are easily created by combining widgets.  I haven't seen any 
movement on this issue on the Chromium list, and don't have confidence that 
their rendering will get fixed any time soon.  Can anyone recommend a way 
to work around these issues?

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

2013-08-21 Thread Alex Epshteyn

Hi Colin, please find my answers inline:

On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth niloc...@gmail.com wrote:

 I got a tweet from you asking for a donation (or rather a 'partner', which
 apparently means 'money'), but couldn't frame a useful response in 140
 chars, so since this thread is coming back, I thought to do so here
 instead.


Yes, I wanted to see if Sencha would be interested in funding this project.
 I agree, 140 chars is not enough :)  Just couldn't find your contact info
other than Twitter.

What license are you offering these code samples under - if it isn't
 something open and available, what is the benefit to an advance copy of the
 jar if I, an author of a library and several open source tools and
 applications, cannot provide it to my customers or other downstream users?


That's a good point which I hadn't considered.  I'd be willing to
immediately release the code under the same license as GWT if the project
gets funded.

(For anyone who's just joining this thread now, here's the link to my
project on IndieGoGo: http://igg.me/at/gwt-stack-traces/x/3494291)


 We've found that https://gist.github.com/niloc132/3906501 goes a heck of
 a long ways toward offering optional debug info - if not enabled, the user
 gets the normal-size application with zero size or performance hit, and by
 redirecting to a slightly different url, the full trace info can be pulled
 out (with the quirks you mention of course*), which typically goes a long
 ways toward identifying the real issue.


Yes, and you'd still be able to use that same config with my patch, except
the debug permutation will be much smaller, cleaner, and more accurate.  In
fact, the overhead is so insignificant now, that I have that debug
configuration enabled for all users on my site (typeracer.com).


 * How often have you needed to know which line of Impl.java or
 DOMImpl.java a stack trace intersects? To make your case more effectively,
 you might consider using code where it is meaningful to see those lines,
 something other than the equivelent of
 java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life
 JSNI, or an annoying IE6-9 focus() or setAttribute issue?


Certainly.  At the time of writing I only had a few artificial examples
available.  But now that I've been gathering real data from my users in
production for a month, I will add an appendix with much better real-world
examples.  I'll update this thread when I finish doing that (most likely
tomorrow).


 You touch briefly on the risk of '[exposing] your application’s
 implementation details', but unless I am mistaken, the extra metadata
 included in the file:line ints should still be enough to take apart an app
 and map it to discrete files and reconstruct methods, even un-inlining (as
 you mention) to pull out clearer details. My understanding was that the
 premise of the sourceMap was to work entirely from the stack to allow the
 actual source to be obfuscated, and avoid any other metadata from being
 left in the compiled output. Combine this with the fact that many of those
 classes are publicly available (GWT itself, etc), and it seems that you
 could reverse out a significant portion of the app - the secret sauce.
 Can you comment on using this for public applications and any reverse
 engineering attempts you've made?


Let me first just clarify how my implementation obfuscates file names (I
think you understood it correctly, but I just want to be sure).  So in my
implementation of stack emulation, the filenames are obfuscated, so you
have strings like '23:234'. The decoding table for this cipher is not
published (it's written as a new file in the same directory as the
symbolMap).  So the only thing that you can reconstruct is that the
obfuscated JavaScript expression X is on line '234' of file '23'.  I
understand that you can use this info to separate the JS output into
discrete files, but I'm just not overly concerned with that, because I
don't think it's that much more helpful to have many obfuscated files with
prettier whitespacing instead of just one lump file.  If necessary, I
suppose you could modify the compiler to add some additional obfuscating
salt to the output.

Thanks for your questions!
Alex

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Initial support for @GwtCreate (code-gen methods)




 Thanks! I think this proposal is the most conservative way to enhance 
 GWT.create(). A more radical approach would be to forget GWT.create() and 
 imitate what scala macros do, as was suggested by Gotktug:

   @Macro(SumGenerator.class)
   int sum(int arg0, int arg1) {
 return 0; // we will never be here
   }

   // Rebind space
   class SumGenerator {

 public ExprInteger sum(GeneratorContext ctx, TreeLogger logger, 
 ArgInteger arg0, ArgInteger arg1) {
   if(arg0.isLiteral()  arg1.isLiteral) {
 Integer result = arg0.getValue() + arg1.getValue();
 return ctx.compile(return  + result.toString();
} 
return ctx.compile(return %s + %s, arg0, arg1); 
 }
   }


I definitely like the API this offers.

I do maintain a hack on UnifyAst that allows manually creating magic 
methods;
https://github.com/WeTheInternet/xapi/tree/master/gwt/gwt-method-inject
It's a little ugly in the xml, since I didn't think it wise to create a new 
gwt.xml property for something that will likely never make it into master.

The example generator API w/ ArgType could be extrapolated from the magic 
method injector linked to above, using the literal finder from the other 
code review I posted.

I'm not sure if it could look exactly like the snippet posted (I just 
return JExpression to match GWT.create behavior),
but it does allow defining arbitrary magic methods for experimentation w/ 
extensions to the compiler.

The big problem, of course, is dev mode / jvms, which do not perform magic 
method injection.
Those platforms would require bytecode enhancement, or (as I've been 
doing), specifying a method body which is fully functional in a jvm 
sans-generators.


The only hard part of the scala-esque macros would be ctx.compile(...); 
I've had to either manually create AST nodes (which then lack valid 
SourceInfo), or generate classes so I can then get compiled jjs ast nodes 
from UnifyAst (make sure you call StandardGeneratorContext.finish() before 
attempting this).
I guess it would be possible to automate all of that behind the scenes,
or maybe it would be easy for someone with deeper knowledge than I about 
CompilationUnitBuilder (or wherever strings would be lexed into ast nodes).

For now, however, I think the scala macro idea is a bit too ambitious.




As for passing multiple class lits to a generator, I definitely see where 
it would be useful to have more than one class in a generator,
although UIBinder already achieves this using generic type parameters (but 
requires manually defining the interface, of course).

This would, unfortunately, likely change the Generator interface contract 
and thus break existing code (maybe fine for GWT 3.0, but definitely no 
sooner).
There is also a problem for dev mode, which I'll get into a few paragraphs 
down.


As for the object-instead-of-class details I posted above,
What do you think about:
T T GWT.construct(Class cls, Object ... params)?

It would look and feel exactly like GWT.create,
except it would support constructors with arguments (and would only be 
usable through an annotated factory method, to provide classlits for param 
types).

This would add a new feature that cannot currently be achieved, plus 
promote immutability (more final, less .setValue()).

As such, I think I'll take a stab at it using the aforelinked 
magic-method-inject module when I get some free time (of which I am in 
unfortunately very short supply).
If the experiment goes well, and I can post a working prototype, I'll be 
sure to tag you in the pull request.

The only gotcha I foresee would be dev mode (which I am not terribly 
familiar with modifying); 
about the only way I can think of the get the annotation with class lits in 
the jvm would be to use reflection to look up the call stack and grab the 
enclosing method (ick,
I really don't like seeing comments like // Do not modify the call order 
because this code depends on stack depth == n).

Speaking of which...  getting multiple class params to work in dev mode 
will face the same problem; how to safely (and preferably quickly) extract 
the method annotations within the jvm.


Anyway, they're both fun ideas to play with, and although I'm not holding 
my breath on getting either of them into master any time soon (or ever),
I still like a good challenge, and I think something like GWT.construct() 
could be a lot of fun to work on.

If you have any ideas or suggestions, do let me know!
 

 This last proposal requires a hard work to be done, and a totally new 
 generator API. Before to start with something like this, I prefer to 
 explore the code-gen compiler plugin for javac 8 mentioned by Ray in the 
 other thread. We should stay standard and portable as possible.


For posterity's sake, could you drop those links off here (or are you 
referring to the ones Ray posted in the G+ community? The phrase javac 8 
doesn't ring any bells for me).

Thanks,
James

--

[gwt-contrib] Re: Initial support for @GwtCreate (code-gen methods)




 For posterity's sake, could you drop those links off here (or are you 
 referring to the ones Ray posted in the G+ community? The phrase javac 8 
 doesn't ring any bells for me).


Nevermind.  I just browsed the group and saw the thread.  My bad. 

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

re: Heiko Braun


 it means having an optional compilation path that does not recompile the 
 entire world (as the current monolithic compile path does) and instead 
 tries to recompile just files (or or modules) that have changed.

 it is exploratory work for me right now as there are very many issues 
 standing in its way.

 if/when it is done and ready it should make a big impact on SuperDev mode 
 refresh time by reducing compile time (when compiles are run 
 non-monolithically)


I've long felt like highly modular projects could greatly benefit from 
producing gwtar files so that unchanged code does not require recompiling.
I've thought about using a maven plugin to add .gwtar to my jars, though 
this would not be a portable solution for all GWT developers.

Any portable solution using gwtar would be to create one per module (using 
a flag to enable support while still experimental), or one per java package 
(maybe not a good idea given the size of some projects).

Given that the compiler already knows to remove invalidated units, this 
does seem like a feasible option.
Producing .gwtars could also be done periodically for the whole project at 
the developers whim, perhaps through a flag to a standard full compile?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

2013-08-21 Thread Stephen Haberman

Hey John,

 it means having an optional compilation path that does not recompile
 the entire world (as the current monolithic compile path does) and
 instead tries to recompile just files (or or modules) that have
 changed.

Spiffy! Out of curiosity, would the API look something like:

theBackendCompile.recompile(ListFile filesThatChanged)

Such that the existing ResourceOracle/TypeOracle instances are mutated
with the updated state, instead of being rebuilt?

AFAIK, historically most of the optimizations around incremental
compiles have always required going back to building ResourceOracle,
TypeOracle from scratch, but speeding it up with caching.

...IIRC. It's been a little while since I've poked at the code.

I know I'm being a broken record, but I think the mutative/truly
incremental approach, while a (large) PITA to build, in the long run is
the only solution that would be fast enough to get SuperDevMode fast
enough such that it's hit save in Eclipse, the js file is updated,
done!, just like Java (and web) developers are used to.

(I know Brian really doesn't like solutions that require Eclipse, but I
think the same mutative/incremental compiler API could just as well be
called by an Eclipse plugin or an IDEA plugin or even a Java daemon
polling the file system for changes. It's not IDE-specific.)

Feel free to ignore my musings given I'm not actually contributing
anything to the effort; just curious as to how things are going.

- Stephen

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

2013-08-21 Thread John A. Tamplin

On Wed, Aug 21, 2013 at 11:34 AM, Stephen Haberman step...@exigencecorp.com
 wrote:

 AFAIK, historically most of the optimizations around incremental
 compiles have always required going back to building ResourceOracle,
 TypeOracle from scratch, but speeding it up with caching.


The problem is let's say you change file A.  How do you know what all needs
to be updated in TypeOracle?  I am sure you can keep track of it, but it
will require keeping much more data than is currently kept so you can
incrementally update TypeOracle's data structures.  For example, let's say
you remove an interface from a class.  Even if you walk down the
inheritance tree, you can't just remove that interface, because some other
ancestor might have implemented it.  The same sort of thing goes in many
other places.

Note that TypeOracle memory requirements has been a problem in the past for
large internal apps.

-- 
John A. Tamplin

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

2013-08-21 Thread Alex Epshteyn

Hi Colin, please find my answers inline:

On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth niloc...@gmail.com wrote:

 I got a tweet from you asking for a donation (or rather a 'partner', which
 apparently means 'money'), but couldn't frame a useful response in 140
 chars, so since this thread is coming back, I thought to do so here
 instead.


Yes, I wanted to see if Sencha would be interested in funding this project.
 I agree, 140 chars is not enough :)  Just couldn't find your contact info
other than Twitter.

What license are you offering these code samples under - if it isn't
 something open and available, what is the benefit to an advance copy of the
 jar if I, an author of a library and several open source tools and
 applications, cannot provide it to my customers or other downstream users?


That's a good point which I hadn't considered.  I'd be willing to
immediately release the code under the same license as GWT if the project
gets funded.

(For anyone who's just joining this thread now, here's the link to my
project on IndieGoGo: http://igg.me/at/gwt-stack-traces/x/3494291)


 We've found that https://gist.github.com/niloc132/3906501 goes a heck of
 a long ways toward offering optional debug info - if not enabled, the user
 gets the normal-size application with zero size or performance hit, and by
 redirecting to a slightly different url, the full trace info can be pulled
 out (with the quirks you mention of course*), which typically goes a long
 ways toward identifying the real issue.


Yes, and you'd still be able to use that same config with my patch, except
the debug permutation will be much smaller, cleaner, and more accurate.  In
fact, the overhead is so insignificant now, that I have that debug
configuration enabled for all users on my site (typeracer.com).


 * How often have you needed to know which line of Impl.java or
 DOMImpl.java a stack trace intersects? To make your case more effectively,
 you might consider using code where it is meaningful to see those lines,
 something other than the equivelent of
 java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life
 JSNI, or an annoying IE6-9 focus() or setAttribute issue?


Certainly.  At the time of writing I only had a few artificial examples
available.  But now that I've been gathering real data from my users in
production for a month, I will add an appendix with much better real-world
examples.  I'll update this thread when I finish doing that (most likely
tomorrow).


 You touch briefly on the risk of '[exposing] your application’s
 implementation details', but unless I am mistaken, the extra metadata
 included in the file:line ints should still be enough to take apart an app
 and map it to discrete files and reconstruct methods, even un-inlining (as
 you mention) to pull out clearer details. My understanding was that the
 premise of the sourceMap was to work entirely from the stack to allow the
 actual source to be obfuscated, and avoid any other metadata from being
 left in the compiled output. Combine this with the fact that many of those
 classes are publicly available (GWT itself, etc), and it seems that you
 could reverse out a significant portion of the app - the secret sauce.
 Can you comment on using this for public applications and any reverse
 engineering attempts you've made?


Let me first just clarify how my implementation obfuscates file names (I
think you understood it correctly, but I just want to be sure).  So in my
implementation of stack emulation, the filenames are obfuscated, so you
have strings like '23:234'. The decoding table for this cipher is not
published (it's written as a new file in the same directory as the
symbolMap).  So the only thing that you can reconstruct is that the
obfuscated JavaScript expression X is on line '234' of file '23'.  I
understand that you can use this info to separate the JS output into
discrete files, but I'm just not overly concerned with that, because I
don't think it's that much more helpful to have many obfuscated files with
prettier whitespacing instead of just one lump file.  If necessary, I
suppose you could modify the compiler to add some additional obfuscating
salt to the output.

Thanks for your questions!
Alex

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

2013-08-21 Thread Stephen Haberman

Hi John,

Thanks for reminding me about this...

 The problem is let's say you change file A.

Two things:

First is that AFAIK GWT already does this...see the Dependencies class,
which I became familiar with when trying to build a list of dependencies
for Scala-GWT ASTs so they could fit in this workflow.

Second is that I want GWT to *not* do this (right now it literally
scans every classes saying have your dependencies changed? nope. have
your dependencies changed? nope. etc.).

If I already have an IDE like Eclipse or IDEA sitting in front that is
tracking this information--why do it twice?

For example, if Eclipse sees A.java change and it knows that now B.java
must be compiled too (let's say because a method signature changed),
it could tell the GWT backend about both:

gwtBackend.update(astForA);
gwtBackend.update(astForB);

The gwtBackend would blithely trust that the front-end (whether an IDE
or a CLI daemon that has the extracted Dependencies logic in it) is
submitting a series of ASTs that is eventually well-formed.

Mutations could be done semi-non-destructively to the AST, like removing
a method doesn't actually drop the method, it makes the body alert(this
method got deleted, you shouldn't see this message).

So the user could technically load the app at this point, but they'd
get these alerts, just like in Eclipse if you run unit tests while
methods aren't compiling you get little btw this doesn't compile
runtime exceptions. Same idea.

Eventually the user will fix all of their compile errors (that they're
seeing in Eclipse/CLI), the udpated ASTs which now no longer call the
method that went away will be submitted, and things will work again.

 Even if you walk down the inheritance tree, you can't just remove that
 interface, because some other ancestor might have implemented it.

I'm making all of this up, but I would mark the interface as deleted and
leave it at that. (Lots of hand waving.)

- Stephen

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

GWTAR files are okay, but are an incomplete solution to the problem of
incremental compilation.

During a normal monolithic GWT compile:

   - ~50% of the time is spent loading Java source off disk, compiling it
   with JDT, translating the JDT Java AST to a GWT Java AST (1 AST per type),
   and populating type oracles.
   - the other ~50% of the time is spent stitching the individual type
   ASTs into one combined tree, running GWT and Javascript semantic
   normalization passes, running optimization passes, translating GWT Java AST
   to GWT Javascript AST, translating GWT Javascript AST to Javascript Source
   and linking to disk.

GWTAR has impact by effectively running that first ~50% chunk once per
module (using just the Java source available to that module) and
serializing the resulting GWT Java ASTs to disk, and reusing these per
module GWTAR caches for subsequent compiles.

So as a result, in the best possible world the maximum impact it can have
on compile time, is ~50%. In practice it has a little less than that
because reading and deserializing these GWT Java ASTs from disk takes some
(smaller) amount of time and because in large modular projects there's a
tendency for duplicate copies of the AST for the same type to accumulate in
multiple GWTAR files (thus resulting in wasted duplicate deserialization
time).

Unlike GWTAR files the incremental compilation approach i'm working on
makes/will make 90+% of the compile time split by module (the only time
left in the monlithic phase should be a small percentage of generators and
the final linking).

I don't want to discourage you from using GWTAR files, since they do have
positive impact. But I'm just saying that I'm not putting work into making
them easier to use or building easier build system integration for them,
since their maximum impact is limited.




On Wed, Aug 21, 2013 at 12:05 AM, James Nelson ja...@wetheinter.net wrote:

 re: Heiko Braun


 it means having an optional compilation path that does not recompile the
 entire world (as the current monolithic compile path does) and instead
 tries to recompile just files (or or modules) that have changed.

 it is exploratory work for me right now as there are very many issues
 standing in its way.

 if/when it is done and ready it should make a big impact on SuperDev mode
 refresh time by reducing compile time (when compiles are run
 non-monolithically)


 I've long felt like highly modular projects could greatly benefit from
 producing gwtar files so that unchanged code does not require recompiling.
 I've thought about using a maven plugin to add .gwtar to my jars, though
 this would not be a portable solution for all GWT developers.

 Any portable solution using gwtar would be to create one per module (using
 a flag to enable support while still experimental), or one per java package
 (maybe not a good idea given the size of some projects).

 Given that the compiler already knows to remove invalidated units, this
 does seem like a feasible option.
 Producing .gwtars could also be done periodically for the whole project at
 the developers whim, perhaps through a flag to a standard full compile?

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)



 So as a result, in the best possible world the maximum impact it can have 
 on compile time, is ~50%. In practice it has a little less than that 
 because reading and deserializing these GWT Java ASTs from disk takes some 
 (smaller) amount of time and because in large modular projects there's a 
 tendency for duplicate copies of the AST for the same type to accumulate in 
 multiple GWTAR files (thus resulting in wasted duplicate deserialization 
 time).


I did think of the duplicates in GWTAR, and that it might potentially cause 
problems if a type is updated in one GWTAR but not another.

 

 Unlike GWTAR files the incremental compilation approach i'm working on 
 makes/will make 90+% of the compile time split by module (the only time 
 left in the monlithic phase should be a small percentage of generators and 
 the final linking).


I can't wait to see it; when you are ready for testers, I would be glad to 
help out.
 

 I don't want to discourage you from using GWTAR files, since they do have 
 positive impact. But I'm just saying that I'm not putting work into making 
 them easier to use or building easier build system integration for them, 
 since their maximum impact is limited.


Excellent.  One other point is that the GWTAR speedup would help out on 
clean compiles, and not just recompiles.
Obviously recompiles are where the real gold is at, in terms of development 
time,
but anything that cuts down on CI hours at my work would definitely be much 
appreciated.

@Johannes - Your approach sounds like it has potential, and I would be 
glad to contribute to anything you are working on in that direction.
Even if it won't help much or at all in the new compiler, we're all still 
using the old compiler, and anything I can do to drop our 
quarter-million/year CI bill would be time well spent.
 

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

I agree that the fastest executing approach is the approach that does the
least amount of computation. And so yes, your suggestion to keep a warm
version of the AST loaded in memory, and update that AST on the fly with
just new AST's of changed classes is a fast design. But there are some
unconsidered questions: do you still have to retranslate the *entire* AST
to Javascript source (and is the resulting process still fast if you have
to do so)? Do the modified files need to trigger generator reruns? How do
you know which generators are/are not affected by the change? When
implementing this incremental generator support, how much duplication will
there be with existing generator logic in the main compile path?

If you follow this mutative/truly incremental approach in memory in
SuperDev mode, then it's unclear how to reuse this work to also speed up
normal compilation triggered by a build system or continuous integration
server (such as Maven or Jenkins).

The approach i'm working on is to make change normal compiles to be
incremental at the per module level. This should transparently speed up
not just build systems, but also SuperDev mode.

In a nutshell my approach (leaving out lots and lots of edge cases) is
this: run the GWT compiler on Module A with *just* the Java source for
Module A and the bytecode for its dependencies provided to the JDT
compiler. Take the results of this compilation and do all of the normal
transformations on it except for optimization (which are currently
inherently global) and write out the resulting Javascript (for just the
types that were provided as Java source) using a special namer that names
types/functions/variables in a globally stable way (so that cross modules
references will resolve at runtime) and write this Javascript into a
.gwtlib file. Repeat this for every module in the dependency tree,
starting at the leaf nodes. When you get to the root of the tree, run
global generators and link these precompiled Javascript chunks (that you
pull out of the accumulated .gwtlib files) into one big chunk.

This (should be) fast for 2 reasons: the amount of IO and computation for
each stage is kept to the minimum, and the the global phase is never
analyzing/transforming/outputting a global size AST (it's just
concatenating together the previously compiled Javascript for each of the
dependent modules). It's basically the same process as normal Java
compilation with separate Jar files being constructed.

It can make cold compiles better by making it possible to parallelize the
compilation of different modules in the module tree, and it can of course
make warm compiles better by requiring only the recompilation of the
particular module that contains the changed file (as well as the rerun of
global generators and linking). User.gwt.xml registers 16 generators, but
I'm expecting that I'll be able to annotate some of them as known to be
local so that they can be kept out of the global phase and for the
remaining ones it should be possible to run them partially locally and
partially globally (so as to minimize the size of the global phase).
Eventually it would be nice to deprecate and replace all generators that
require some global phase.




On Wed, Aug 21, 2013 at 8:34 AM, Stephen Haberman
step...@exigencecorp.comwrote:

 Hey John,

  it means having an optional compilation path that does not recompile
  the entire world (as the current monolithic compile path does) and
  instead tries to recompile just files (or or modules) that have
  changed.

 Spiffy! Out of curiosity, would the API look something like:

 theBackendCompile.recompile(ListFile filesThatChanged)

 Such that the existing ResourceOracle/TypeOracle instances are mutated
 with the updated state, instead of being rebuilt?

 AFAIK, historically most of the optimizations around incremental
 compiles have always required going back to building ResourceOracle,
 TypeOracle from scratch, but speeding it up with caching.

 ...IIRC. It's been a little while since I've poked at the code.

 I know I'm being a broken record, but I think the mutative/truly
 incremental approach, while a (large) PITA to build, in the long run is
 the only solution that would be fast enough to get SuperDevMode fast
 enough such that it's hit save in Eclipse, the js file is updated,
 done!, just like Java (and web) developers are used to.

 (I know Brian really doesn't like solutions that require Eclipse, but I
 think the same mutative/incremental compiler API could just as well be
 called by an Eclipse plugin or an IDEA plugin or even a Java daemon
 polling the file system for changes. It's not IDE-specific.)

 Feel free to ignore my musings given I'm not actually contributing
 anything to the effort; just curious as to how things are going.

 - Stephen

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

I guess i forgot to address your question about what the API would look
like. At this moment it looks like this:

!. Invoke GWT compiler on Module A
2. Invoke GWT compiler on Module B
3. Invoke GWT compiler on Module C, passing it .gwtlibs from Module's A
and B

When compiling Module A I'm not paying attention to which files are or are
not modified *at all*. I'm just recompiling every source file known to be
part of Module A. I'm leaving it the reponsibility of the build system that
is driving the compiler, to know which files have changed and thus know
which Modules should be recompiled as a result.

I may need to revisit some of that responsibility though, since the current
GWT Eclipse plugin owns/manages the GWT compile triggering process. I'm
toying with the idea of implementing this iterative compilation triggering
responsibility in Maven and (since GWT shouldn't try to act like a build
system) then integrating this into the GWT Eclipse plugin? I haven't
thought all the way through this part and haven't implemented any of this
part yet, so would appreciate suggestions.



On Wed, Aug 21, 2013 at 4:29 PM, John Stalcup stal...@google.com wrote:

 I agree that the fastest executing approach is the approach that does the
 least amount of computation. And so yes, your suggestion to keep a warm
 version of the AST loaded in memory, and update that AST on the fly with
 just new AST's of changed classes is a fast design. But there are some
 unconsidered questions: do you still have to retranslate the *entire* AST
 to Javascript source (and is the resulting process still fast if you have
 to do so)? Do the modified files need to trigger generator reruns? How do
 you know which generators are/are not affected by the change? When
 implementing this incremental generator support, how much duplication will
 there be with existing generator logic in the main compile path?

 If you follow this mutative/truly incremental approach in memory in
 SuperDev mode, then it's unclear how to reuse this work to also speed up
 normal compilation triggered by a build system or continuous integration
 server (such as Maven or Jenkins).

 The approach i'm working on is to make change normal compiles to be
 incremental at the per module level. This should transparently speed up
 not just build systems, but also SuperDev mode.

 In a nutshell my approach (leaving out lots and lots of edge cases) is
 this: run the GWT compiler on Module A with *just* the Java source for
 Module A and the bytecode for its dependencies provided to the JDT
 compiler. Take the results of this compilation and do all of the normal
 transformations on it except for optimization (which are currently
 inherently global) and write out the resulting Javascript (for just the
 types that were provided as Java source) using a special namer that names
 types/functions/variables in a globally stable way (so that cross modules
 references will resolve at runtime) and write this Javascript into a
 .gwtlib file. Repeat this for every module in the dependency tree,
 starting at the leaf nodes. When you get to the root of the tree, run
 global generators and link these precompiled Javascript chunks (that you
 pull out of the accumulated .gwtlib files) into one big chunk.

 This (should be) fast for 2 reasons: the amount of IO and computation for
 each stage is kept to the minimum, and the the global phase is never
 analyzing/transforming/outputting a global size AST (it's just
 concatenating together the previously compiled Javascript for each of the
 dependent modules). It's basically the same process as normal Java
 compilation with separate Jar files being constructed.

 It can make cold compiles better by making it possible to parallelize the
 compilation of different modules in the module tree, and it can of course
 make warm compiles better by requiring only the recompilation of the
 particular module that contains the changed file (as well as the rerun of
 global generators and linking). User.gwt.xml registers 16 generators, but
 I'm expecting that I'll be able to annotate some of them as known to be
 local so that they can be kept out of the global phase and for the
 remaining ones it should be possible to run them partially locally and
 partially globally (so as to minimize the size of the global phase).
 Eventually it would be nice to deprecate and replace all generators that
 require some global phase.




 On Wed, Aug 21, 2013 at 8:34 AM, Stephen Haberman 
 step...@exigencecorp.com wrote:

 Hey John,

  it means having an optional compilation path that does not recompile
  the entire world (as the current monolithic compile path does) and
  instead tries to recompile just files (or or modules) that have
  changed.

 Spiffy! Out of curiosity, would the API look something like:

 theBackendCompile.recompile(ListFile filesThatChanged)

 Such that the existing ResourceOracle/TypeOracle instances are mutated
 with the updated state, instead of being rebuilt?

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

@Johannes Barop

Your approach is interesting since it allows you to avoid cache the results
of generator execution and not have to reparse and recompile generated code
during every monolithic compile. But since it's all based on GWTAR, you're
still limited to a maximum possible impact of 50%.

The approach i'm working on should be limited only by the number of modules
you define (the more the better) and the cost of global phase generator
execution (most of which I should be able to automatically move into local
phases, aka part of specific modules). So, while I can't guarantee that
your setup will be easily adoptable to the new compiler, it shouldn't
matter since the new incremental compilation path should be faster than
your setup and thus make it unnecessary.

There's not a lot you can do to help right now but I could eventually use
some help setting up support in external build systems (like Maven and Ant,
and possibly integrated with the GWT Eclipse plugin) for triggering the GWT
compiler once per module and/or once per modified module. I'll also
probably eventually want some external testers before this goes live. So
i'll keep you in mind.



On Wed, Aug 21, 2013 at 1:46 PM, Johannes Barop j...@barop.de wrote:


 Am 21.08.2013 um 09:05 schrieb James Nelson ja...@wetheinter.net:

  I've long felt like highly modular projects could greatly benefit from
 producing gwtar files so that unchanged code does not require recompiling.
  I've thought about using a maven plugin to add .gwtar to my jars, though
 this would not be a portable solution for all GWT developers.
 
  Any portable solution using gwtar would be to create one per module
 (using a flag to enable support while still experimental), or one per java
 package (maybe not a good idea given the size of some projects).
 
  Given that the compiler already knows to remove invalidated units, this
 does seem like a feasible option.
  Producing .gwtars could also be done periodically for the whole project
 at the developers whim, perhaps through a flag to a standard full compile?

 As far as I know a usual gwtar contains only a precompiled Java AST from
 the first compilation phase. You still need to run the generators on all
 the visible code. It saves some seconds but for me the most time consuming
 part is the code generation and JavaScript compilation.

 I've currently playing around with a project where I have multiple
 modules. For each module I generate the initial Java AST, run code
 generators and throw the precompiled code in a gwttar. When building the
 final application only a small code generator which discovers all
 precomputed code runs.

 It's a special use case because I have defined decoupled modules which I
 want to link together. I'm unsure if this is any help for an intelligent
 approach :-)

 @John Stalcup
 Is it possible to contribute in this area? For example I want to ensure
 that the code for the project is easily adoptable to the new compiler.


 BTW:
 I agree with Stephen that Java IDE's also should be supported well. Yes
 SuperDevMode enabled to debug in the browser but the IDE is the tool I'm
 used too and I have to use the IDE for server code anyway.

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

Agreed. The TypeOracle (actually there are many TypeOracles) indexes, AST
references, JProgram indexes, after optimization, etc etc, are extensive
and complex. Updating them in place when swapping out the AST for a
particular Type would be very tricky and failure prone.


On Wed, Aug 21, 2013 at 2:09 PM, John A. Tamplin j...@jaet.org wrote:

 On Wed, Aug 21, 2013 at 11:34 AM, Stephen Haberman 
 step...@exigencecorp.com wrote:

 AFAIK, historically most of the optimizations around incremental
 compiles have always required going back to building ResourceOracle,
 TypeOracle from scratch, but speeding it up with caching.


 The problem is let's say you change file A.  How do you know what all
 needs to be updated in TypeOracle?  I am sure you can keep track of it, but
 it will require keeping much more data than is currently kept so you can
 incrementally update TypeOracle's data structures.  For example, let's say
 you remove an interface from a class.  Even if you walk down the
 inheritance tree, you can't just remove that interface, because some other
 ancestor might have implemented it.  The same sort of thing goes in many
 other places.

 Note that TypeOracle memory requirements has been a problem in the past
 for large internal apps.

 --
 John A. Tamplin

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)