by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    VikasGupta1993
    @VikasGupta1993
    I am using JDK11
    Daniel Korbel
    @masterdany88
    Hi I cant compile gwt on Jenkins. I am getting an error: 14:44:58 [WARNING] java.lang.OutOfMemoryError: GC overhead limit exceeded
    How many memory should be given?
    Daniel Korbel
    @masterdany88
    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)
    VikasGupta1993
    @VikasGupta1993

    @niloc132 ,can you help me??

    org.dom4j.DocumentFactory cannot be cast to class org.dom4j.DocumentFactory Jenkin issue

    JDK 11
    Colin Alworth
    @niloc132
    @masterdany88 add more memory until it builds? you probably need a bit more than that, so that the system has room to not GC constantly. also consider reducing the worker thread count, since that means more memory is needed (each thread works on its own copy of your program)
    @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
    Miroslav Pokorny
    @mP1
    @masterdany88 try jre11 it uses far less than jre9
    Miroslav Pokorny
    @mP1
    becuase of Strings using byte[] rather than a char[] internally
    rcsnogm
    @rcsnogm

    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.

    Miroslav Pokorny
    @mP1
    @niloc132 Who do you use to host your (vertispan) maven repo ?
    Tino Desjardins
    @TDesjardins
    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)
    @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:
    <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>
    Colin Alworth
    @niloc132
    @rcsnogm in gwt 2.8 or so and beyond, GWT.setUncaughtExceptionHandler can deal with plain js errors that reach the top frame, not just ones that leave java, so it should be sufficient.
    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...
    Thomas Broyer
    @tbroyer
    @niloc132 @rcsnogm gwt-sl is IIRC a Spring thing, and GWTRPCServiceExporter is a server side class from that project. AFAICT you'll have some work moving out of it and exposing actual RPC servlets (and call them from client side). Might be worth it if gwt-sl is unmaintained.
    Miroslav Pokorny
    @mP1
    @niloc132 no vertispan maven repo is good :!)
    rcsnogm
    @rcsnogm

    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?
    Colin Alworth
    @niloc132
    @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
    Frank Hossfeld
    @FrankHossfeld
    @rcsnogm in addition to what @niloc132 said, you can use Spring Boot with GWT. That work really nice
    Daniel Korbel
    @masterdany88
    hi. Can You guys share Your development compilation optimalisation for gwt? I need the fastest compillation.
    Daniel Korbel
    @masterdany88
    Is there any article to read about fast dev compile?
    Ahmad K. Bawaneh
    @vegegoku
    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
    when you avoid generators you will also get improved compilation time
    Colin Alworth
    @niloc132
    @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)
    Daniel Korbel
    @masterdany88
    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.
    Ahmad K. Bawaneh
    @vegegoku
    For jax-rs factories i assume you mean those are domino-rest, in our applications we have those in the shared module which is not gwt, just a normal jar with pojos and interfaces, and a simple rebuild on the file the module from the ide is enough.
    Colin Alworth
    @niloc132
    @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
    Peter Donald
    @realityforge
    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?
    Miroslav Pokorny
    @mP1
    How could that be possible, generators will only run "once" regardless of where or how they are packaged. If a child runs a generator, users of that child module will see the generated type exists...
    Peter Donald
    @realityforge
    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
    Colin Alworth
    @niloc132
    almost certain this is urban legend, except for the fact that forcing good modularization will also prevent some other problems that can impact performance. the compiler runs on everything in a single shot, i'm almost certain...
    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)
    Peter Donald
    @realityforge
    Sounds good to me ... as I was not looking forward to the work required to experiment and determine whether this was true ;)
    Miroslav Pokorny
    @mP1
    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
    not really because the entire build shares a common target etc and the generated would class would appear there
    Colin Alworth
    @niloc132
    agreed, generators are the one thing that absolutely cant be prebuilt per module