Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

gwtproject/gwt

GWT Open Source Project

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

https://github.com/ascendtech/simplerest

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

the usage inside of dominio is async as well. https://github.com/gwtboot/domino-rest-enum-date/blob/master/domino-rest-enum-date-client/src/main/java/com/example/client/BasicGwtEntryPoint.java#L72

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...