15:10:45 [INFO] Compiling module com.gen.ractan.APP
15:11:25 [WARNING] Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
15:11:25 [WARNING] at java.lang.StringBuffer.toString(StringBuffer.java:671)
15:11:25 [WARNING] at java.net.URI.toString(URI.java:1945)
15:11:25 [WARNING] at java.net.URI.<init>(URI.java:669)
15:11:25 [WARNING] at java.net.URI.<init>(URI.java:774)
15:11:25 [WARNING] at java.io.File.toURI(File.java:735)
JDK 11
@VikasGupta1993 sorry, i cannot help you, except to say that this looks like a classloader issue, two copies of org.dom4j.DocumentFactory are loaded, in different classloaders, and so an instance of one isnt compatible with the other
Updating a legacy GWT project to GWT 2.9.0 on Java 11. I have been reviewing all the dependencies and had a question on this one: net.sf.gwt-widget.local:gwt-sl:1.1. It appears it is only used in our app to override the handleInvocationTargetException and doUnexpectedFailure methods of GWTRPCServiceExporter for RPC services. Does anyone know if there is an alternative to using this class to perform custom exception handling. Is there a GWT native extension point? I would love to get rid of this dependency if possible.
By the way. Thanks @niloc132 and @tbroyer for your assistance with using the new gwt-maven-plugin. Took a bit to learn that there were at least two ways to run all the configured executions to compile all the gwt entry point modules for our legacy single maven/multi gwt module project. Either attach the executions to the package phase and call the package phase or call each execution by id. I was stuck looking for plugin docs when I needed to expand my maven knowledge. Your directions were helpful and appreciated.
@masterdany88 You could try limiting memory for the build with jvmArgs. The GWT compiler takes as much memory as it can get. With net.ltgt.gwt.maven you can set it this way:15:10:45 [INFO] Compiling module com.gen.ractan.APP 15:11:25 [WARNING] Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded 15:11:25 [WARNING] at java.lang.StringBuffer.toString(StringBuffer.java:671) 15:11:25 [WARNING] at java.net.URI.toString(URI.java:1945) 15:11:25 [WARNING] at java.net.URI.<init>(URI.java:669) 15:11:25 [WARNING] at java.net.URI.<init>(URI.java:774) 15:11:25 [WARNING] at java.io.File.toURI(File.java:735)
<plugin>
<groupId>net.ltgt.gwt.maven</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.0.0</version>
<extensions>true</extensions>
<configuration>
<jvmArgs>
<jvmArg>-Xmx1536m</jvmArg>
</jvmArgs>
GWTRPCServiceExporter is not a GWT class for RPC, it is an external project, and I'm afraid I don't know much about it specifically
Is there a GWT native extension point?
JsInterop fits this purpose - it replaces all (or 99+%) JSNI, and also provides a way to export your methods, classes, fields to JS
@mP1 chicagovps right now, but we're going to move it to the VPS we have with OVH, since while more expensive, it is also more flexible and reliable
are we having downtime again? i'm afraid i'm taking a bit of leave - server looks up and happy at a glance...
It seems all the gwt/spring integration projects I found no longer appear to be maintained. Which makes me wonder if the spring community has abandoned GWT or if a better practice has supplanted the need to have spring managed GWT RPC services?
All of these appear to be stagnant or no longer viable.
gwt-sl aka gwt-widgets (currently using)
spring4gwt
spring-gwtrpc
gwtrpc-spring
GWTSpringRPC
I also found this project which appears to be active.
resty-gwt
What does GWT have to say on the preferred way to expose services to the GWT UI?
With or without spring?
@rcsnogm my recollection (which is fuzzy, its been since approx 2010 since i touched spring) was that spring had issues injecting stuff into plain java servlets at the time, so you needed extra goo to even do something as simple as that. since gwt-rpc's server side component extended servlet (and spring's expected flow at the time was something like "no, extend our custom class instead" iirc?), you had to do some magic to make servlets work in spring at all - including the (fairly simple) gwt-rpc one
that said, gwt-rpc is somewhat out of favor (as are most rpc mechanisms, except perhaps grpc), the cool kids mostly use "json over http" and call it rest (or graphql) - the client then is often agnostic of the server's implementation. if you happen to use jax-rs to declare the server interface, something like domino-rest can generate the required gwt bits to interact with that API cleanly
if you are defining more than one client, i'd encourage something like $serialization over http, whether json or otherwise, something all your clients can speak. if you only ever expect to use a gwt client, you can get more opinionated/optimized (gwtrpc can do things that json can't out of the box, like object references/cycles, polymorphism, etc) - to make it play nice with sping, i would suggest you simply need to find a "how do i make spring work with a servlet" answer, and apply it to your gwt-rpc servlet impl
For development or production? i believe for development you are using SDM so you already have a fast compile, for production while paying attention to the produced js size, you can play with the optimization level, collapse properties and some other compiler flags.
check http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html#DevGuideCompilerOptions
check http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html#DevGuideCompilerOptions
when you avoid generators you will also get improved compilation time
@masterdany88 without seeing specifics of your setup, it is hard to say. "SDM" is called super dev mode, but i sometimes refer to it as "super draft mode", with all the "make it fast" options already set, including incremental compilation (which itself requires a few other options to be set, and these are done for you automatically)
if you mean "dev compile" as in "non-SDM", you'll need to explain a bit more what you mean, and describe your use case a bit too, why it doesnt overlap with either "run sdm because i am changing client/shared code" or "use prebuilt JS, since i am not changing any client/shared code" (the fastest code is the code you don't run at all)
I ment fast development compilation. I do use sdm for development. But some times I need whole project compilation for examples to generate jaxrs factories or rebuild dtos from other maven module. In such case sdm fails as it care only for gwt-app maven module. So I need mvn clean package optimalizations like one permutation for chrome only etc. Few years I go I had such project with dev gwt module and dev maven profile to trigger it.
I struggled to find anything on the network about it.
About generators- some of lib I use, use generators plus gwt- user.
@masterdany88 stick to one permutation (use set-property rather than collapse for best results, but collapse can let you do more work with more browsers, etc), draft mode, disable split points (esp if you have more than ... like 10, that'll make a gigantic difference), double check that the compiler has enough memory
if you can turn off more features, you can enable incremental compile (i'm rusty on this), that will let some generators avoid running on later compiles - but that data will have to go somewhere, so you can't use mvn clean or it takes it away again
of course, measure why your build is slow too - any custom generators, etc? or code that errors out that shouldn't even be in the build in the first place? etc
Is there any performance value in making small, non-overlapping GWT modules compared to a handful of "mega" modules. I was under the impression that it made no difference ... but someone suggested that unit caching and some generators run per-gwt module and thus if you have lots of small modules you can get better unit cache hits and lower generator runtimes.
Is this true or an old wives tale?
I have not looked at how generators are implemented but it is a possibility. Some generators have to access the complete object graph and will run regardless. For local generators if they only process locally then their outputs could be cached along with inputs. If dependency tracking is done at the file level then it wont make a difference but if dependency tracking is done at gwt module level then it would need to re-run generators for the module
that said generators absolutely don't just run once, each generator runs once per GWT.create invocation, even if unnecessary (and then it must be smart enough to exit early) - unless you were saying "they must run late", which is true, but potentially orthogonal, since unlike with APT, all gwt java must compile on its own before the generator runs, so you could cache that result per module
that would be like a .gwtar file, which was the "i parsed this whole module and cached the results for later" back in gwt 2.5 or so which was eventually removed since it didnt actually help at all with perf (and cyclical modules meant it often ended up with weird results)
not really because the entire build shares a common target etc and the generated would class would appear there