Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Colin Alworth
    @niloc132
    that is the actual java object which is failing to be serialized
    understanding why that exception is being thrown will explain your issue
    unless you are deliberately sending that exception to your client?
    dmitriygg
    @dmitriygg
    @niloc132 Thank you! I rummage in this direction.
    Frank Hossfeld
    @FrankHossfeld
    @niloc132 I had the same issue (seriializable - IsSerialiazble - problem) a few days ago. The project uses RPC and the codeserver port was zero, so SDM was not able to read the rpc policy file.
    zhivko
    @zhivko

    But useIncrementalCompilation=true (the default), does stale checks (https://github.com/apache/maven-compiler-plugin/blob/31d868bbd0316d34b10efb58b1e0a661ebf9e671/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L824); so honestly I doubt it's the cause of spurious GWT recompilations here.

    For me mvn -X outputs: [DEBUG] useIncrementalCompilation disabled

    [DEBUG] (f) useIncrementalCompilation = false [DEBUG] (f) verbose = false [DEBUG] -- end configuration -- [DEBUG] Using compiler 'javac'. [DEBUG] Adding /home/klemen/git/Dis/Dis-client/target/generated-test-sources/test-annotations to test-compile source roots: /home/klemen/git/Dis/Dis-client/src/test/java [DEBUG] New test-compile source roots: /home/klemen/git/Dis/Dis-client/src/test/java /home/klemen/git/Dis/Dis-client/target/generated-test-sources/test-annotations [DEBUG] CompilerReuseStrategy: reuseCreated [DEBUG] useIncrementalCompilation disabled
    VikasGupta1993
    @VikasGupta1993

    Hi Folks
    I was getting some unknown exception

    Problem loading builtinTypes.xml
    Exception when loading from USE_CONTAINER/Uman/sc/system/schema/builtinTypes.xml:
    java.net.MalformedURLException

    guys do you have any idea ?

    VikasGupta1993
    @VikasGupta1993
    @niloc132 , can you help in above issue ?
    Matt Davis
    @mdavis95
    I am working on a GWT REST client based on the Fetch browser API based loosely off autorest. Goal was to be as lightweight as possible. Still really raw but I would love feedback
    Colin Alworth
    @niloc132
    @VikasGupta1993 it appears that builtinTypes.xml is a smartgwt feature of some kind - you are probably better off asking in a smartgwt forum, or having someone who can dig into the exception and debug it directly
    Dr. Lofi Dewanto
    @lofidewanto_twitter

    @mdavis95 Thanks for the info! I like everything which is lightweight 👍

    A question: is there any reason why the client and server use different APIs / contracts? Actually I would expect to have the same APIs on client and server? In Domino REST I could do this. The same APIs are used on client and server... see example: https://github.com/gwtboot/domino-rest-enum-date

    Matt Davis
    @mdavis95
    @lofidewanto_twitter with new GWT stuff we keep our code bases totally separate so we didn't design it that way
    We are not totally settled on a design yet but we would like to 1) use the fetch api 2) JS DTOs 3) Minimum dependencies (javax.ws.rs:jsr311-api:1.1.1, com.google.elemental2:elemental2-dom:1.1.0)
    domino rest was definitely one we looked at earlier, and autorest is what we currently use
    Dr. Lofi Dewanto
    @lofidewanto_twitter

    @mdavis95 What I meant is why do we have to use different APIs for client and server?

    Client:
    @PUT
    @Path("/add")
    void addToDo(ToDoDTO toDo, SingleCallback<ToDoDTO> callback);

    Server:
    @Put("/add")
    public HttpResponse<ToDo> add(@Body ToDo todo) {
    todoService.addTodo(todo);
    return HttpResponse.created(todo);
    }

    Why do we need SingleCallback<ToDoDTO> callback as a param instead of just return HttpResponse<ToDo>?

    Colin Alworth
    @niloc132
    it has to be non-blocking in the browser, right?
    or is HttpResponse non-blocking? based on its usage, i cant imagine how it would be
    Matt Davis
    @mdavis95
    yeah in the browser it is non blocking
    we could do magic in the APT generation to change ToDoDTO addToDo(ToDoDTO toDo) to void addToDo(ToDoDTO toDo, SingleCallback<ToDoDTO> callback);
    so the interface is common
    even though the interface is shared
    Dr. Lofi Dewanto
    @lofidewanto_twitter

    Yes, the APIs experience for the developers is important IMHO, at the end the developers will use them, right? 😉

    I feel that today nobody is interested in the programming experience for the developers... 🥲

    Therefore we have compilers, transpilers, generators like APT to make better APIs experience for devs...
    Miroslav Pokorny
    @mP1
    example?
    Dr. Lofi Dewanto
    @lofidewanto_twitter
    The discussion above, it's a simple API to be shared client and server... Why should it be different for client and server?
    Miroslav Pokorny
    @mP1
    because the server wants a blocking api, while the browser wants an async call to prevent blocking which freezes up the ui
    every single browser network or out of process call is async for this reason
    fetch, ajax (ignore the sync vers), all the localdb stuff, window.postMessage etc
    Dr. Lofi Dewanto
    @lofidewanto_twitter
    Yes, but it still works nicely, like what Domino REST offers... You don't have to get the result on the second param, you can have return param...
    Miroslav Pokorny
    @mP1
    is that a q or a statement ?
    Dr. Lofi Dewanto
    @lofidewanto_twitter
    It's not about async or sync / non-blocking or blocking, is about the design of the APIs...
    It's a statement... 😉
    Miroslav Pokorny
    @mP1
    You don't have to get the result on the second param, you can have return param...
    this is a requirement becaues it is async.
    it makes no sense for the api to return an async callback, because by definition it would do nothing
    except consume the "callback" at runtime.
    as a client you cant "insert" or "change" that callback to call your own stuff, and they are trying to avoid using a call this method in a blocking way
    using await
    Ahmad K. Bawaneh
    @vegegoku
    Domino-rest offers the share of interface which is a good thing to keep the server and client in sync in terms of contract, in terms of usage from the client side it still uses the callbacks but it does in a fluent api style inspired by vertx api
    At the end as said before just having a return type and not using callback at all does not work unless you block the browser which is a bad thing.
    The callbacks will be there in a form or another.
    Dr. Lofi Dewanto
    @lofidewanto_twitter
    @vegegoku Yes, that's what I meant... I like it and that's what I meant with APIs for developers... At the end the devs will use it, so it should be enjoyable to use 😂
    Dr. Lofi Dewanto
    @lofidewanto_twitter

    Not a good example is e.g. RestyGWT, it added a second possibility to use the same APIs client and server later on with DirectRestService... But very very late and you need to extend from DirectRestService, see: https://resty-gwt.github.io/documentation/restygwt-user-guide.html

    ...
    or if using REST.withCallback(..).call(..), you can reuse the same interface on the server side as well:
    ...

    IMHO Domino REST has a very good API design (with the help of APT)... 👍

    Miroslav Pokorny
    @mP1
    re: server, no because most people dont want an async, given one is the consumer (browser) and the other the provider (server) except for dtos and the interface def, there is no diff, the internals of both are different.
    Stanislav Spiridonov
    @foal
    BTW for me, the main advantage of the same API on server and client is "single source". All Spring controllers on the server and GWT rest services extend the same interface from the shared project
    Dr. Lofi Dewanto
    @lofidewanto_twitter
    @foal exactly like my example above with Domino REST and Spring Boot.
    Stanislav Spiridonov
    @foal
    :thumbsup:
    Dr. Lofi Dewanto
    @lofidewanto_twitter

    @FrankHossfeld I found this nice example integration of Electron, Vue.js and Spring Boot: https://github.com/wuruoyun/electron-vue-spring

    It can be directly updated to GWT I think... Just the integration of logger, app from JS (in this case Vue.js) to Electron has to be migrated to GWT...