Point 1 is a potentially a serious concern for basically any tooling that
decouples through interprocess communication, including grpc+protobuf (with
ostensibly "perfect backwards/forwards compatibility") - in tooling that
doesn't explicitly force compatibility as GWT-RPC does, you have to
If you define a non-existent html cache and/or update your server early in
the morning or late in the evening you will not have a problem. All browser
clients will reload the latest version.
Fallback is to show a warning in the GWT client that the browser needs a
cache clearing when you get a
Thanks for that answer Jens. Makes perfect sense.
Regarding point 1, I am thinking about a more seamless upgrade process that
minimizes client interruption. Such that old clients can remain working on
"old" server versions for a while, while new clients work on new servers in
parallel, until all
Finally I've decided to stick to RPC and use gwt-servlet-jakarta. We will
have a lot of applications (50+) to migrate to jakarta at some point, this
will be the fastest way.
Thanks all for your comments.
On Mon, 15 Jan 2024 at 11:26, Jens wrote:
>
> Some mention "some annoying downsides" or
Some mention "some annoying downsides" or "is imperfect in a lot of ways"
regarding gwt-rpc. What are does?
1. Client and server always need to be in sync because of serialization
policy. So a user must reload the web app if you redeploy your application
and have modified shared classes.
One thing I really like about using JSON for my message formats is that
they are human readable (YMMV).
If you're wondering whether a problem is client side or server side, or
when you just want to know exactly what information the client was given,
being able to read the content of messages can
gwt-rpc is one of the parts I like the most about GWT and why we chose GWT
to start with. Same DTOs on client and server and you don't have to care
(too much) about de/serialization. Why do I care about JSON, or binary or
whatever serialized format, as long as it is secure, performant and
+1 nats.io
On Fri, Jan 12, 2024 at 10:33 AM Jens wrote:
> If you do not have special needs I think GWT-RPC is still fine especially
> with a jakarta version now available. But while it is easy to use it also
> has some annoying downsides you have to live with.
>
> However there are quite some
If you do not have special needs I think GWT-RPC is still fine especially
with a jakarta version now available. But while it is easy to use it also
has some annoying downsides you have to live with.
However there are quite some options:
- JsInterop based DTOs + JSON.parse/stringify. However you
Fully agree - and very much like the example!
Leon Pennings schrieb am Fr. 12. Jan. 2024 um
14:59:
> I think moving away from gwt-rpc is a bad idea.
> A big advantage of GWT is that I can code everything in java and do not
> have to serialize anything to and from text.
> That to me is one of
I think moving away from gwt-rpc is a bad idea.
A big advantage of GWT is that I can code everything in java and do not
have to serialize anything to and from text.
That to me is one of the usp's of GWT.
Going from java -> json -> java (or gwt java), is like trying to have a
complex
Hi Vegegoku,
Thanks for clearing that up.
At some point I will definitely try the domino-rest/jackson.
For now I dread the time I will eventually be forced to port my current
setup.
On Thu, Jan 11, 2024 at 5:13 PM Vegegoku wrote:
> The annotation on the POJO is not required at all,
The annotation on the POJO is not required at all, Domino-rest will auto
generate the json-mapping classes if the jax-rs/jakarata resource
consumes/produces a json even if the annotation is missing, so you can keep
the POJO clean or only have Jackson compatible annotations. ;-)
On Thursday,
Domino-rest is up-to-date well documented and in our next release
-Currently available in the HEAD-SNAPSHOT- we are moving to jakarta
namespace.
Full documentation can be found in our website
here https://dominokit.com/solutions/domino-rest/v1/docs/getting-started
On Wednesday, January 10,
Using domino-rest, the POJO have usually only one annotation: @JSONMapper.
Vassilis Virvilis schrieb am Donnerstag, 11. Januar 2024 um 09:35:05 UTC+1:
> First of all thanks for doing this work. It is hugely appreciated and
> required in order to avoid GWT and GWT projects look like zombies in a
First of all thanks for doing this work. It is hugely appreciated and
required in order to avoid GWT and GWT projects look like zombies in a dead
landscape.
I am using RestyGWT and yes I also believe it uses Generators (GWT.create()
?). I am facing a problem there since RestyGWT is deadish
With 2.11 released, GWT-RPC (and RequestFactory) work on jakarta.servlet.
There are no specific improvements that I'm aware of that require updating
beyond the Servlet API 5.0, which is what gwt-servlet-jakarta uses.
I _believe_ that RestyGWT relies on Generators, so might make an eventual
You should investigate the DominoKit project. They have a much more
up-to-date JSON/Jackson-ish implementation.
Ref: https://github.com/DominoKit/domino-rest
On 1/10/24 11:26, Christian Hebert wrote:
Hi guys, I've seen the changes in the new release regarding jakarta
servlets, which is
Hi guys, I've seen the changes in the new release regarding jakarta
servlets, which is great, it's a step toward jakarta but to this day, GWT
is still based on the Servlet API 3.1.
Prior of seeing that change, I tried to move away from RPC calls and use
http requests instead. I found a nice
19 matches
Mail list logo
