Re: How to speed up Hosted mode
As bizzare as it sounds, try IE 9 - seems to run faster than FF in dev mode. On Tue, Apr 19, 2011 at 8:06 PM, Aladdin wrote: > > I know that you can use cluster to compile your app > > So , 2000$ can build you 6 diskless computers :) > > Look that up in youtube or google > > > > On Apr 18, 2:49 pm, maticpetek wrote: >> Hello, >> We are developing our app in GWT now for a couple of years. And code base >> is becoming bigger every day And hosted mode is also become very slow. >> Refresh in browser takes around 1 minute. Forms opening a couple of seconds. >> All this time my CPU is on around 160% (if I look Activity monitor). This >> happend in FF. Chrome is not useful because it takes too much time (I gave >> up after 10 minutes). >> Any idea how could we speed up hosted mode? Would code split with >> GWT.runAsync do any help? Or on the end you just must have very fast CPU? >> Thank you for help. >> >> My environment : >> - OS X Show Leopard >> - JDK 1.6 >> - GWT 2.2 >> - GXT 2.2.3 >> - Firefox 3.6 >> >> Regards, >> Matic >> -- >> GWT stuff twitter -http://twitter.com/#!/gwtstuff > > -- > 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. > > -- 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 RPC Serialization - circular references not allowed?
I'm serializing to the client from Java using the standard GWT RPC mechanism (using Async Service, not the factory introduced in 2.1). I'm seeing an issue with deserialization at the client when my serialized object has circular references. This is what I see: Serializing a "Result" object that has a "Fund" object reference. This fund has a reference to a "Distributor" object that contains a list of Funds, one of which is the same as the Fund that result references. So it is a two-hop circular reference. The Fund object's hashCode method is overridden to use the fund-id's hashcode (fund-id is a string). The error I get is that the hashcode threw a NullPointerException. Here is the stacktrace: at com.foo.dm.fund.Fund.hashCode(Fund.java:709) at java.util.HashMap.put(HashMap.java:372) at java.util.HashSet.add(HashSet.java:200) at com.google.gwt.user.client.rpc.core.java.util.Collection_CustomFieldSerializerBase.deserialize(Collection_CustomFieldSerializerBase.java:35) at com.google.gwt.user.client.rpc.core.java.util.HashSet_CustomFieldSerializer.deserialize(HashSet_CustomFieldSerializer.java:32) at com.google.gwt.user.client.rpc.core.java.util.HashSet_FieldSerializer$Handler.deserialize(HashSet_FieldSerializer.java:11) at com.google.gwt.user.client.rpc.impl.SerializerBase.deserialize(SerializerBase.java:91) at com.google.gwt.user.client.rpc.impl.ClientSerializationStreamReader.deserialize(ClientSerializationStreamReader.java:108) at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamReader.readObject(AbstractSerializationStreamReader.java:119) at com.foo.dm.user.Distributor_FieldSerializer.deserialize(Distributor_FieldSerializer.java:42) Are circular references not allowed? I can't believe this is the first time I'm running across this in 2 years! -- 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 without creating proxies? Anyone else reminded of J2EE early days?
Thomas, Thanks for your response. Here are a few follow ups: 1) The idea of forcing separation between client and server code so that GWT can generate client code is perhaps too restrictive. We have a lot of getter methods with intelligence or decoration of the returned value. Currently, we know this will work on the client and server side. But with RF, I have to move that logic elsewhere. Keeping the entities common and forcing them to be GWT actually has a nice side-effect - it forces you to keep your entities clear of useless dependencies. 2) Its nice that a command line validator is provided, but that just means more build time checks for something that Java could natively do. So the advantages of incremental compilation via Eclipse/IDEA etc are gone. Also, there will be additional delays before this trickles down to maven plugins and other artifacts. Note: With the command pattern, my async interface only has one method - Result execute(Action a); that is generified so I never have to worry about it (and it is burried in common-library). Actions and Results get associated by simply being defined as spring beans and everything works like magic. On Tue, Dec 14, 2010 at 9:18 AM, Daniel Simons wrote: > I have a project that utilizes RequestFactory and works in 2.1 but not in > 2.1.1. Is there an example out there making use of the 2.1.1 RequestFactory > improvements? > > On Tue, Dec 14, 2010 at 8:05 AM, Thomas Broyer wrote: >> >> >> On Tuesday, December 14, 2010 1:14:30 PM UTC+1, kabram wrote: >>> >>> We have a significant sized app built using GWT 2.0 and we have simple >>> Command pattern based abstraction for sending entities back and forth >>> between the server and client. The new RequestFactory while >>> interesting seems to require too much "scaffolding" interfaces and >>> classes. >>> >>> - Why should I create duplicate proxy interfaces? Can't I just reuse the >>> entity? >> >> No. >> One of the goal of RF is to completely separate server code from client >> code, so that a) you can use whatever you want on the server side (including >> directly in your entities) and b) the client-side can be optimized at will >> because it's enterily generated by GWT. >> See https://wave.google.com/wave/waveref/googlewave.com/w+WU4iAICkI >>> >>> - The requirement that the service implement the RequestContext >>> interface but not really - leads to poor code maintainability as one >>> cannot simply rename methods taking advantage of IDE features. >> >> >> See http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/requestfactory/server/RequestFactoryInterfaceValidator.html >> You can use it as a command-line tool to validate your client-side >> interface against your server-side implementations. >> I believe the next version of the Google Plugin for Eclipse (or at least a >> future version) will integrate it, just like it validates the sync and async >> interfaces of GWT-RPC (which suffer from the exact same issue). >> >>> >>> - The 2.1 idea of have DAO methods in entities? >> >> Not necessarily. But then methods *have* to be static. >>> >>> What was the thinking here? >> >> AFAIK, Spring Roo generating static methods on entities, similar to Rails' >> ActiveRecord and the like (but Ruby allows monkey patching which makes >> testing and mocks possible, something that a statically typed language like >> Java cannot do) >>> >>> Seems 2.1.1 is addressing it. >> >> Yes! >> >>> >>> - The requirement to have findEntity() on the entity itself - leads to >>> very poor separation of concerns. >> >> See above, but 2.1.1 addresses that one too. >> >>> >>> - The requirement to have getVersion() - well, what if I don't want my >>> entity to be versionable? Why am I being forced here? This is another >>> example of forcing the framework user to write code to make the >>> framework do its work. >> >> Versions are necessary for the "update" mechanism. The constraint was >> initially relaxed in 2.1.1 but re-added last >> week: http://code.google.com/p/google-web-toolkit/source/detail?r=9381 >> >>> >>> - The requirement to explicitly edit() an entity (again, just so the >>> framework can figure out changes) is burdensome. >> >> It makes you intents clear. Your proxies are there so you can communicate >> with the server, so edit()ing a proxy is kind of like creating a "request >> builder". You then add an "invocation" (service method call) and fire() the >> request. And everything is "magically" replayed on the server. >> >>> >>> My concern now is that other libraries (e.g. Ext GWT) will adopt this >>> forcing theRequestFactory upon everyone. How far does 2.1.1 go in >>> alleviating the above? I think I'm going to stick with the simple >>> GWT-RPC. Hopefully that is not going away anytime soon. >> >> The new Google Groups is using GWT-RPC, so I believe it's there to stay! >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this
RequestFactory without creating proxies? Anyone else reminded of J2EE early days?
We have a significant sized app built using GWT 2.0 and we have simple Command pattern based abstraction for sending entities back and forth between the server and client. The new RequestFactory while interesting seems to require too much "scaffolding" interfaces and classes. - Why should I create duplicate proxy interfaces? Can't I just reuse the entity? - The requirement that the service implement the RequestContext interface but not really - leads to poor code maintainability as one cannot simply rename methods taking advantage of IDE features. - The 2.1 idea of have DAO methods in entities? What was the thinking here? Seems 2.1.1 is addressing it. - The requirement to have findEntity() on the entity itself - leads to very poor separation of concerns. - The requirement to have getVersion() - well, what if I don't want my entity to be versionable? Why am I being forced here? This is another example of forcing the framework user to write code to make the framework do its work. - The requirement to explicitly edit() an entity (again, just so the framework can figure out changes) is burdensome. My concern now is that other libraries (e.g. Ext GWT) will adopt this forcing theRequestFactory upon everyone. How far does 2.1.1 go in alleviating the above? I think I'm going to stick with the simple GWT-RPC. Hopefully that is not going away anytime soon. -- 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-tool...@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 2.0.3 + Maven2 + Eclipse
Use the gwt-maven-plugin version 1.2-SNAPSHOT to have your project work with GWT 2.x -- 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-tool...@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: frustrated with Google Eclipse Plugin and Maven gwt-maven-plugin integration
I don't have it working with the Google eclipse plugin ... but I did get it working where compilation is no slower than the Google Eclipse plugin and debugging is just as fast (using maven compile target and java app launch config for debugging). I did have to get gwt-maven-plugin 1.2-SNAPSHOT to get it going. I don't have a ready-to-share version ... just as yet. Give me a few days and I can perhaps share the code with you. On Wed, Dec 2, 2009 at 4:04 PM, bkbonner wrote: > Does anyone have this working well and can share a decent archetype > for 2.0 RC2 that works with maven and google eclipse plugin? > > Does anyone have google eclipse plugin and maven working well together > and can generate an archetype (it's a simple command) that can be > shared? > > Brian > > -- > > 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-tool...@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. > > > -- 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-tool...@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: EXCEPTION_ACCESS_VIOLATION in HotSpot Virtual Machine:
I had the same issue with GWT 2.0.0-rc1 and rc2 with JDK1.5 update 22. I switched to JDK 1.6 and the problem went away. I only had this happen in "development" mode, and consistently so. On Tue, Dec 1, 2009 at 1:47 PM, Bruce Petro wrote: > I'm hitting the error shown below in my code in the following manner... > Working with a fairly complex object composed of several component objects - > so quite a bit of memory probably... > a) Editing an object, saving the results, then without clearing the screen, > request the another object via RPC with the intention of refilling the > screen with the new fresh values for the new object. When the RPC send > attempts to happen, the browser (IE or hosted) vanishes. If I'm in hosted > mode then Eclipse console contains the error and reference to a detailed > error file. (attached). > b) Interesting! If instead of requesting a new object to edit, I instead go > to the menu and re-draw the screen from scratch - then no error occurs. > Theories: > a) We're running out of memory and I need to up the memory (can that be done > in IE browser running javascript?) > b) The UI and its "ties" to the data module object is getting totally > confused by swapping the model out from under it. > The detail file included seems to be hinting at memory, but I may be reading > it wrong. Any ideas from anyone out there? If it is memory, how does one go > about increasing memory in a running javascript application? > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x420c87ea, pid=1552, > tid=5616 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_18-b02 mixed mode) > # Problematic frame: > # C [Dxtrans.dll+0x87ea] > # > # An error report file with more information is saved as hs_err_pid1552.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > -- > > 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-tool...@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. > -- 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-tool...@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 2.0.0 rc2 - failing to compile annotation (when used with Maven plugin 1.2-SNAPSHOT)
I have a class in the "client" subpackage (lets call it Foo) that has an annotation (say @Bar) that is in a client.gwt.rpc sub-package. This construct compiles fine with GWT eclipse plugin (1.2 rc2, eclipse galileo) but when I compile using the maven plugin, I get a ClassNotFoundException in the compile phase and the compiler says [WARN] Ignoring unresolvable annotation type ... Has anyone run into a similar problem or does anyone have a workaround? Thanks K -- 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-tool...@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.
