InvocationTargetException with null cause?

[Alex Karg]

Hi

I am afraid this is probably more a general Java question than a pure GWT
question. But I am suspecting the problem somewhere in GWT server-side
hence asking here.

I am looking for help to read my stack trace around GWT RPC
and InvocationTargetException Btw the system recovered after a server
restart, without changing anything.

Stack trace was:
...



*at java.lang.Thread.run(Thread.java:748)Caused by:
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public
abstract xx.webapp.shared.domain.xxDTO xx.share> at
com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:416)*

*at
com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:605)*

*at
com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:571)*

*at
xxx.server.spring.SpringGwtRemoteServiceServlet.processCall(SpringGwtRemoteServiceServlet.java:120)*

*... 101 common frames omittedCaused by: java.lang.NullPointerException:
null*
*{call stack log ends here}*

Relevant GWT code from RPC class:

[image: image.png]

RPC class checks for cause==null so that's not it. But then why is it not
showing the actual line of code where the causing exception is thrown?

Regards,
Alex

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/CAHcNM3LsXyzksUv2i7BE8Nee%2By9abiah7UZqTqqsuq2v5-WxcQ%40mail.gmail.com.

Re: Is moving away from RPC a good idea?

[Alex Karg]

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 old clients are migrated in a controlled process. Once
no old clients are connected any more, the old servers are shut down and
the upgrade process is completed.

Is there any suggested standard approach (e.g. Load Balancer Setups,
Client-Server Interface Versioning) to achieve this? Anyone doing this
successfully?

Freundliche Grüsse,
Alexander Karg



On Mon, Jan 15, 2024 at 5:26 PM Jens  wrote:

>
> 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.
> 2. If you want to use J2CL in the future you should not use it.
> 3. You can only use it with GWT clients unless you reimplement the wire
> format in other languages / applications. Only unofficial information about
> the wire format exists.
> 4. No async servlet support
> 5. Command pattern doesn't work well with GWT-RPC because you cannot code
> split the client side serialization data. So your initial or leftover
> fragment contains everything that goes over the wire. Code splitting only
> works well if you have one GWT-RPC service per code split condition.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit/cc4b2a17-a072-4685-b138-34f31e46cc5fn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/CAHcNM3K8e4KTDhB04yDDKPpP%3Dmp1C7776dPJSdR4%2B5wemXdUww%40mail.gmail.com.

Re: Is moving away from RPC a good idea?

[Alex Karg]

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 
serialization is able to handle my object relation structures?

Some mention "some annoying downsides" or "is imperfect in a lot of ways" 
regarding gwt-rpc. What are does? The only argument I understood so far, is 
that it may require you to have gwt-rpc *and* REST/RequestFactory 
client-server channels in parallel. We had that since the very beginning, 
because of OAuth, captcha, file download links etc.. I never saw any 
practical issues with that set up. For example with spring-security we can 
easily map both channels to the same user/roles/rights concept.

On Wednesday, January 10, 2024 at 5:26:04 PM UTC+1 Christian Hebert wrote:

> 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 library called RestyGWT (
> https://resty-gwt.github.io/) who can really simplify the process of 
> handling json data from/to a Rest API.
>
> So I converted my GWT remote servlets to a Rest API, made a few minor 
> changes in my client code and voilà, I was able to deploy it on a Jakarta 
> Application server since there is no GWT involved on the server side 
> anymore. 
>
> The last version of RestyGWT has been release in 2020 so I'm not sure how 
> active this project is but from what I've seen it's enough for me.
>
> So, I would like to get your thoughts on that.  Would you go on that road? 
> stick to RPC calls and wait for a version of GWT based on Jakarta? build 
> your "own" GWT with the changes introduced in the vew version?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/392768b6-58aa-4c71-b54f-cdb0d3aacf53n%40googlegroups.com.

Re: Article Planning Spring Boot and GWT Boot with Domino + Nalu

[Alex Karg]

Hi Lofi, +1, this article would certainly be a great read. Did you actually 
manage to create it yet? Thanks, Alex

On Sunday, December 18, 2022 at 1:04:48 PM UTC+1 lofid...@gmail.com wrote:

> Hi All,
>
> I'm looking forward for Xmas holidays... Preparing an article for GWT / 
> J2CL:
>
> *Spring Boot and GWT Boot with DominoKit - Introduction - I would take the 
> "StockWatcher" example and build a Domino UI and Nalu web app.*
>
> Any other wishes? ☺️
>
> Another question, I see some questions about moving from old GWT to a 
> newer version. Mostly they still use Eclipse based development and maybe 
> Ant?
>
> Is it worth it to create a "recipe" in *OpenRewrite* to be able to move 
> all the old GWT webapps automatically to the newer structure with TBroyer 
> Maven? It's a pity that people stuck in the older structure.
>
> Thanks,
> Lofi
>
> Debugging in Chrome is already very good, and we are actually independent 
> of the IDE with the Maven plugin...
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/c3f8cac0-ee38-4ab7-8109-d6cf69f5c9a4n%40googlegroups.com.