Exciting news — https://dominokit.com is live! Our new platform stands as a beacon of inclusion, unifying detailed documentation in one centralized location to empower and educate. We invite you to explore this collective reservoir of knowledge, designed to support and inspire. Please help us spread the word by sharing this resource with your network and beyond. Together, we can create a vast community of shared wisdom and resources.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/5b2037b4-d8d9-4fbd-9e7d-4e9d8f2c853en%40googlegroups.com.
Tuesday, October 31, 2023
Monday, October 30, 2023
Illegal reflective access in RPC serializer
Hi,
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/843a1666-9ac3-49d7-9ef9-2b8681b3653an%40googlegroups.com.
Working with Java 21 I have some issues with RPC serializer causing illegal reflective access in LinkedHashMap_CustomFieldSerializer.
I see that this has been fixed in https://github.com/gwtproject/gwt/issues/9584 but the fix is not included in the 2.10 release as far as I can see.
The workaround is to use --add-opens but this basically open the full java.util package for reflection which is not ideal. I also tried to replace the custom serializer, but due to the way custom serializers are loaded (using the exact package name), this doesn't seems possible without compiling a custom jar.
Is there any plan to make a release that include the fix for this issue, either 2.11 or a path of the 2.10?
-- 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/843a1666-9ac3-49d7-9ef9-2b8681b3653an%40googlegroups.com.
Re: GWT Designer
Earlier, I remember when I clicked the source tab, it showed the source code which it is showing. And when I used to click the design tab, I could see a screen which I could modify. This is explained on (https://www.youtube.com/watch?v=kV5H3rGfqOE) at 3:00 min on the video.
I feel that I am missing something and it has been many years since I have used GWT Designer, and therefore cannot remember
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/f52d565a-7778-41a8-852d-bac896931f4an%40googlegroups.com.
I feel that I am missing something and it has been many years since I have used GWT Designer, and therefore cannot remember
Do you remember anything which could help me? Thanks
On Monday, October 30, 2023 at 7:10:14 PM UTC+5:30 Edu wrote:
Hi,If i remember correctly if you already installed the Designer plugin you need to open the java file that is linked with that xml file using the Designer editor not the default one.El lun, 30 oct 2023 a las 10:20, Sachin Bal (<sach...@gmail.com>) escribió:Hi,
I installed Eclipse Kepler and when I open any ui.xml file, I can see two tabs, source and design. In the source, I can see the code but in the design I am not able to see the generated screen. I have a feeling that I have missed something but I cannot remember exactly. Can you please advise? Attached below is the source and design screens. It would be great, if you could guide me. ThanksOn Sunday, October 29, 2023 at 7:00:22 PM UTC+5:30 Sachin Bal wrote:Thanks. I will check the old version of eclipse. I believe it was Eclipse Kepler which we had used earlier.RegardsSachinOn Saturday, October 28, 2023 at 3:13:56 AM UTC+5:30 Colin Alworth wrote:If memory serves, the GWT Designer tool was never part of GWT itself, but was a component that could be installed in Eclipse, allowing for WYSIWYG UI design (in part by running something like dev mode while you were editing?). Changes that the author of the project made were reflected in standard source files (.java and .ui.xml) that GWT itself was able to compile - as such, a newer compiler version can likely still compile (with small or minimal changes to source) such an old project. I would suggest small steps in upgrading, to keep such changes (if any) manageable.If you're hoping to run GWT Designer itself, you probably need a very old version of eclipse - my memory here is that it wasn't used enough to be worth maintaining. The code still lives at https://github.com/gwt-plugins/gwt-designer, but I can't guess what it would take to bring it back to life. I have a memory of this being based on WindowBuilder, and some internal changes in WindowBuilder requiring substantial changes to the gwt-designer project, which never was done.On Friday, October 27, 2023 at 3:19:36 PM UTC-5 sach...@gmail.com wrote:Hi All,We had created an application in 2014-2015. We had used GWT to design the UI of our application. Unfortunately, we have folded that project in 2017 . I wanted to showcase our project to a prospective customer and was keen to know whether there is some way to migrate the project to the latest version of GWT?If that is not possible, I would like to display the screens which we had designed using GWT Designer so that I can at the least create a story around it.Looking forward to some positive responsePlease advise.ThanksSachin--
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-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/1f61346d-1507-4f79-a26c-91e40655f2c7n%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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/f52d565a-7778-41a8-852d-bac896931f4an%40googlegroups.com.
Re: GWT Designer
Hi,
If i remember correctly if you already installed the Designer plugin you need to open the java file that is linked with that xml file using the Designer editor not the default one.
El lun, 30 oct 2023 a las 10:20, Sachin Bal (<sachinbal@gmail.com>) escribió:
Hi,
I installed Eclipse Kepler and when I open any ui.xml file, I can see two tabs, source and design. In the source, I can see the code but in the design I am not able to see the generated screen. I have a feeling that I have missed something but I cannot remember exactly. Can you please advise? Attached below is the source and design screens. It would be great, if you could guide me. Thanks--On Sunday, October 29, 2023 at 7:00:22 PM UTC+5:30 Sachin Bal wrote:Thanks. I will check the old version of eclipse. I believe it was Eclipse Kepler which we had used earlier.RegardsSachinOn Saturday, October 28, 2023 at 3:13:56 AM UTC+5:30 Colin Alworth wrote:If memory serves, the GWT Designer tool was never part of GWT itself, but was a component that could be installed in Eclipse, allowing for WYSIWYG UI design (in part by running something like dev mode while you were editing?). Changes that the author of the project made were reflected in standard source files (.java and .ui.xml) that GWT itself was able to compile - as such, a newer compiler version can likely still compile (with small or minimal changes to source) such an old project. I would suggest small steps in upgrading, to keep such changes (if any) manageable.If you're hoping to run GWT Designer itself, you probably need a very old version of eclipse - my memory here is that it wasn't used enough to be worth maintaining. The code still lives at https://github.com/gwt-plugins/gwt-designer, but I can't guess what it would take to bring it back to life. I have a memory of this being based on WindowBuilder, and some internal changes in WindowBuilder requiring substantial changes to the gwt-designer project, which never was done.On Friday, October 27, 2023 at 3:19:36 PM UTC-5 sach...@gmail.com wrote:Hi All,We had created an application in 2014-2015. We had used GWT to design the UI of our application. Unfortunately, we have folded that project in 2017 . I wanted to showcase our project to a prospective customer and was keen to know whether there is some way to migrate the project to the latest version of GWT?If that is not possible, I would like to display the screens which we had designed using GWT Designer so that I can at the least create a story around it.Looking forward to some positive responsePlease advise.ThanksSachin
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/1f61346d-1507-4f79-a26c-91e40655f2c7n%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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CAM5HcKqZc4NuwczWL7u7Q1-8PT1qOqwHrq7ZOHF9fMsMoRPdxw%40mail.gmail.com.
Re: GWT Designer
I installed Eclipse Kepler and when I open any ui.xml file, I can see two tabs, source and design. In the source, I can see the code but in the design I am not able to see the generated screen. I have a feeling that I have missed something but I cannot remember exactly. Can you please advise? Attached below is the source and design screens. It would be great, if you could guide me. Thanks
On Sunday, October 29, 2023 at 7:00:22 PM UTC+5:30 Sachin Bal wrote:
Thanks. I will check the old version of eclipse. I believe it was Eclipse Kepler which we had used earlier.RegardsSachinOn Saturday, October 28, 2023 at 3:13:56 AM UTC+5:30 Colin Alworth wrote:If memory serves, the GWT Designer tool was never part of GWT itself, but was a component that could be installed in Eclipse, allowing for WYSIWYG UI design (in part by running something like dev mode while you were editing?). Changes that the author of the project made were reflected in standard source files (.java and .ui.xml) that GWT itself was able to compile - as such, a newer compiler version can likely still compile (with small or minimal changes to source) such an old project. I would suggest small steps in upgrading, to keep such changes (if any) manageable.If you're hoping to run GWT Designer itself, you probably need a very old version of eclipse - my memory here is that it wasn't used enough to be worth maintaining. The code still lives at https://github.com/gwt-plugins/gwt-designer, but I can't guess what it would take to bring it back to life. I have a memory of this being based on WindowBuilder, and some internal changes in WindowBuilder requiring substantial changes to the gwt-designer project, which never was done.On Friday, October 27, 2023 at 3:19:36 PM UTC-5 sach...@gmail.com wrote:Hi All,We had created an application in 2014-2015. We had used GWT to design the UI of our application. Unfortunately, we have folded that project in 2017 . I wanted to showcase our project to a prospective customer and was keen to know whether there is some way to migrate the project to the latest version of GWT?If that is not possible, I would like to display the screens which we had designed using GWT Designer so that I can at the least create a story around it.Looking forward to some positive responsePlease advise.ThanksSachin
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/1f61346d-1507-4f79-a26c-91e40655f2c7n%40googlegroups.com.
Sunday, October 29, 2023
Re: GWT Designer
Thanks. I will check the old version of eclipse. I believe it was Eclipse Kepler which we had used earlier.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/2fd784f3-b5ed-4a9b-b545-ca6801538ce6n%40googlegroups.com.
Regards
Sachin
On Saturday, October 28, 2023 at 3:13:56 AM UTC+5:30 Colin Alworth wrote:
If memory serves, the GWT Designer tool was never part of GWT itself, but was a component that could be installed in Eclipse, allowing for WYSIWYG UI design (in part by running something like dev mode while you were editing?). Changes that the author of the project made were reflected in standard source files (.java and .ui.xml) that GWT itself was able to compile - as such, a newer compiler version can likely still compile (with small or minimal changes to source) such an old project. I would suggest small steps in upgrading, to keep such changes (if any) manageable.If you're hoping to run GWT Designer itself, you probably need a very old version of eclipse - my memory here is that it wasn't used enough to be worth maintaining. The code still lives at https://github.com/gwt-plugins/gwt-designer, but I can't guess what it would take to bring it back to life. I have a memory of this being based on WindowBuilder, and some internal changes in WindowBuilder requiring substantial changes to the gwt-designer project, which never was done.On Friday, October 27, 2023 at 3:19:36 PM UTC-5 sach...@gmail.com wrote:Hi All,We had created an application in 2014-2015. We had used GWT to design the UI of our application. Unfortunately, we have folded that project in 2017 . I wanted to showcase our project to a prospective customer and was keen to know whether there is some way to migrate the project to the latest version of GWT?If that is not possible, I would like to display the screens which we had designed using GWT Designer so that I can at the least create a story around it.Looking forward to some positive responsePlease advise.ThanksSachin
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/2fd784f3-b5ed-4a9b-b545-ca6801538ce6n%40googlegroups.com.
Friday, October 27, 2023
Re: GWT Designer
If memory serves, the GWT Designer tool was never part of GWT itself, but was a component that could be installed in Eclipse, allowing for WYSIWYG UI design (in part by running something like dev mode while you were editing?). Changes that the author of the project made were reflected in standard source files (.java and .ui.xml) that GWT itself was able to compile - as such, a newer compiler version can likely still compile (with small or minimal changes to source) such an old project. I would suggest small steps in upgrading, to keep such changes (if any) manageable.
If you're hoping to run GWT Designer itself, you probably need a very old version of eclipse - my memory here is that it wasn't used enough to be worth maintaining. The code still lives at https://github.com/gwt-plugins/gwt-designer, but I can't guess what it would take to bring it back to life. I have a memory of this being based on WindowBuilder, and some internal changes in WindowBuilder requiring substantial changes to the gwt-designer project, which never was done.
On Friday, October 27, 2023 at 3:19:36 PM UTC-5 sach...@gmail.com wrote:
Hi All,We had created an application in 2014-2015. We had used GWT to design the UI of our application. Unfortunately, we have folded that project in 2017 . I wanted to showcase our project to a prospective customer and was keen to know whether there is some way to migrate the project to the latest version of GWT?If that is not possible, I would like to display the screens which we had designed using GWT Designer so that I can at the least create a story around it.Looking forward to some positive responsePlease advise.ThanksSachin
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/e2bc0294-728c-45a5-b281-1649c2a1c828n%40googlegroups.com.
GWT Designer
Hi All,
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/3364c6af-a68e-4d34-ab43-de130fded557n%40googlegroups.com.
We had created an application in 2014-2015. We had used GWT to design the UI of our application. Unfortunately, we have folded that project in 2017 . I wanted to showcase our project to a prospective customer and was keen to know whether there is some way to migrate the project to the latest version of GWT?
If that is not possible, I would like to display the screens which we had designed using GWT Designer so that I can at the least create a story around it.
Looking forward to some positive response
Please advise.
Thanks
Sachin
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/3364c6af-a68e-4d34-ab43-de130fded557n%40googlegroups.com.
Monday, October 23, 2023
Re: GWT: Deserialize objects sent/received via websocket
On Sunday, October 22, 2023 at 3:25:18 PM UTC+2 an.s...@gmail.com wrote:
Hi everyone,
thanks for all the thoughts about the topic. After further investigation of the protocol, it seems like there is no pbject serialization involved. Instead, the application creates a websocket and establishes a AES-CBC encrypted channel. Hence, the binary blobs that I was seeing are encrypted messages. If somebody is interested, the website is https://metatraderweb.app/trade
I'm curious what made you think this is related to GWT: I don't see anything pointing to the use of GWT on that app.
The "gwt" mentions in the code (and server names) look more like an acronym of "G-something Web Trader" to me.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/8d7dbb7a-b6ee-4148-99b2-f127ff8d728cn%40googlegroups.com.
Sunday, October 22, 2023
Re: GWT: Deserialize objects sent/received via websocket
Hi everyone,
thanks for all the thoughts about the topic. After further investigation of the protocol, it seems like there is no pbject serialization involved. Instead, the application creates a websocket and establishes a AES-CBC encrypted channel. Hence, the binary blobs that I was seeing are encrypted messages. If somebody is interested, the website is https://metatraderweb.app/trade
Thanks again!
On 20.10.23 20:12, Colin Alworth <colin@colinalworth.com> wrote:
> Seeing traffic wouldn't hurt, but it would be easiest to discover by
> looking at code - finding "WebSocket" in the codebase, then seeing what
> the import is. Alternatively, the compiled JS will probably have some
> hints, depending on how it was built.
>
> As to the authentication approach you clarified - if the client sends a
> POST before the websocket is created that performs the authentication,
> it is quite likely that the server responds by setting a cookie, and
> that all subsequent HTTP requests (including the websocket) are
> authenticated with that cookie. It is also possible that the websocket's
> binary blobs contain the credentials again, or more likely, the session ID.
>
> gRPC is indeed typically binary protobuf data... but gRPC can't be used
> in a browser in 2023. gRPC-web is a thing... which can't stream binary
> data, and can't stream data to the server (using the tooling provided by
> the gRPC project itself). There are alternative gRPC-web clients that
> can support streaming binary data _from_ the server, but in 2023 the
> fetch() API is still server streaming only, even with h2. There are even
> really-alternative gRPC clients for the browser that rely on websockets
> as well, but if you get in a situation where you want more than a small
> handful of concurrent streams the browser just hangs on new calls, so I
> can't recommend that, unless you use the websocket to replace the h2
> transport rather than using it per-stream (but now you've got more work
> to make sure you clean up streams promptly, and they aren't a lot of fun
> to debug).
> On Friday, October 20, 2023 at 12:59:15 PM UTC-5 Thomas Broyer wrote:
>
> You could have a look at
> https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit <https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit> to see what GWT-RPC exchanges look like and see if they match what you're seeing. But they're not "binary".
>
> I didn't follow what gRPC (Google's RPC format: https://grpc.io/
> <https://grpc.io/>) looks like on the web, but it's possible they
> use "binary" nowadays.
>
> On Friday, October 20, 2023 at 3:10:17 PM UTC+2 an.s...@gmail.com wrote:
>
> Dear Colin,
>
> thanks for the quick response. I did observe the authentication
> approach via BurpSuite that allows me to investigate each HTTP /
> websocket request / response. From this perspective, I can see
> that upon submitting my credentials to the webapp, there is only
> one HTTP POST request from client-side that only includes the
> username. After this initial POST request, all the communication
> goes over websocket with binary blobs being exchanged. Hence, it
> is not easy for me to identify which GWT library class is in use.
>
> Is there any way how to get this information, (i.e. I could
> provide the URL of the endpoint I am talking to).
>
> Best,
> André
>
> Colin Alworth schrieb am Freitag, 20. Oktober 2023 um 14:55:53
> UTC+2:
>
> While GWT offers websocket support, the only support is "now
> you can send messages on a websocket" - no serialization is
> offered, beyond what the browser itself provides (allowing
> sending a utf8 string, arraybuffers, blobs, typedarrays, or
> arrayviews). How are you verifying messages sent/received?
> If you are observing some 3-4 websocket frame handshake
> messages on the websocket, that is probably some other GWT
> library in use - which WebSocket class are you using?
>
> I maintain (and use in production) an rpc-over-websocket
> implementation <https://github.com/vertispan/gwt-rpc>, but
> it does not explicitly support authentication. Instead
> usually the first message authenticates with the server, or
> HTTP headers are used to authenticate (potentially using
> existing cookies) before the websocket is even initiated. So
> at least we can probably rule out that implementation.
>
> See
> https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
> <https://developer.mozilla.org/en-US/docs/Web/API/WebSocket>
> for more information on what the browser's own WebSocket
> type offers.
>
> On Friday, October 20, 2023 at 7:31:03 AM UTC-5
> an.s...@gmail.com wrote:
>
> Hi,
>
> I am very new to GWT and have questions about the basic
> principles of how GWT via websockets work.
>
> I would like to analyze the authentication function of a
> given GWT web application. When authenticating with my
> credentials, I could identify that my credentials are
> sent via websocket in form of a binary blob. This most
> certainly is a serialized GWT object. The authentication
> seems to follow a protocol that involves 3-4 messages
> exchanged with the server-side.
>
> Hence, I strive to understand how the client-side
> transforms my textual credentials (username / password)
> into this binary blob. Subsequently, I would like to
> understand how I can deserialize messages coming from
> the server in order to get a better idea of the messages
> exchanged and hence the protocol.
>
> Thanks,
>
> André
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GWT Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/q0QxVCumk6I/unsubscribe <https://groups.google.com/d/topic/google-web-toolkit/q0QxVCumk6I/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscribe@googlegroups.com
> <mailto:google-web-toolkit+unsubscribe@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit/693c5f07-aac5-4580-aa8f-35684326cf83n%40googlegroups.com <https://groups.google.com/d/msgid/google-web-toolkit/693c5f07-aac5-4580-aa8f-35684326cf83n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7c834ce8-0dc8-3e53-72ad-0c6c12a596ad%40gmail.com.
thanks for all the thoughts about the topic. After further investigation of the protocol, it seems like there is no pbject serialization involved. Instead, the application creates a websocket and establishes a AES-CBC encrypted channel. Hence, the binary blobs that I was seeing are encrypted messages. If somebody is interested, the website is https://metatraderweb.app/trade
Thanks again!
On 20.10.23 20:12, Colin Alworth <colin@colinalworth.com> wrote:
> Seeing traffic wouldn't hurt, but it would be easiest to discover by
> looking at code - finding "WebSocket" in the codebase, then seeing what
> the import is. Alternatively, the compiled JS will probably have some
> hints, depending on how it was built.
>
> As to the authentication approach you clarified - if the client sends a
> POST before the websocket is created that performs the authentication,
> it is quite likely that the server responds by setting a cookie, and
> that all subsequent HTTP requests (including the websocket) are
> authenticated with that cookie. It is also possible that the websocket's
> binary blobs contain the credentials again, or more likely, the session ID.
>
> gRPC is indeed typically binary protobuf data... but gRPC can't be used
> in a browser in 2023. gRPC-web is a thing... which can't stream binary
> data, and can't stream data to the server (using the tooling provided by
> the gRPC project itself). There are alternative gRPC-web clients that
> can support streaming binary data _from_ the server, but in 2023 the
> fetch() API is still server streaming only, even with h2. There are even
> really-alternative gRPC clients for the browser that rely on websockets
> as well, but if you get in a situation where you want more than a small
> handful of concurrent streams the browser just hangs on new calls, so I
> can't recommend that, unless you use the websocket to replace the h2
> transport rather than using it per-stream (but now you've got more work
> to make sure you clean up streams promptly, and they aren't a lot of fun
> to debug).
> On Friday, October 20, 2023 at 12:59:15 PM UTC-5 Thomas Broyer wrote:
>
> You could have a look at
> https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit <https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit> to see what GWT-RPC exchanges look like and see if they match what you're seeing. But they're not "binary".
>
> I didn't follow what gRPC (Google's RPC format: https://grpc.io/
> <https://grpc.io/>) looks like on the web, but it's possible they
> use "binary" nowadays.
>
> On Friday, October 20, 2023 at 3:10:17 PM UTC+2 an.s...@gmail.com wrote:
>
> Dear Colin,
>
> thanks for the quick response. I did observe the authentication
> approach via BurpSuite that allows me to investigate each HTTP /
> websocket request / response. From this perspective, I can see
> that upon submitting my credentials to the webapp, there is only
> one HTTP POST request from client-side that only includes the
> username. After this initial POST request, all the communication
> goes over websocket with binary blobs being exchanged. Hence, it
> is not easy for me to identify which GWT library class is in use.
>
> Is there any way how to get this information, (i.e. I could
> provide the URL of the endpoint I am talking to).
>
> Best,
> André
>
> Colin Alworth schrieb am Freitag, 20. Oktober 2023 um 14:55:53
> UTC+2:
>
> While GWT offers websocket support, the only support is "now
> you can send messages on a websocket" - no serialization is
> offered, beyond what the browser itself provides (allowing
> sending a utf8 string, arraybuffers, blobs, typedarrays, or
> arrayviews). How are you verifying messages sent/received?
> If you are observing some 3-4 websocket frame handshake
> messages on the websocket, that is probably some other GWT
> library in use - which WebSocket class are you using?
>
> I maintain (and use in production) an rpc-over-websocket
> implementation <https://github.com/vertispan/gwt-rpc>, but
> it does not explicitly support authentication. Instead
> usually the first message authenticates with the server, or
> HTTP headers are used to authenticate (potentially using
> existing cookies) before the websocket is even initiated. So
> at least we can probably rule out that implementation.
>
> See
> https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
> <https://developer.mozilla.org/en-US/docs/Web/API/WebSocket>
> for more information on what the browser's own WebSocket
> type offers.
>
> On Friday, October 20, 2023 at 7:31:03 AM UTC-5
> an.s...@gmail.com wrote:
>
> Hi,
>
> I am very new to GWT and have questions about the basic
> principles of how GWT via websockets work.
>
> I would like to analyze the authentication function of a
> given GWT web application. When authenticating with my
> credentials, I could identify that my credentials are
> sent via websocket in form of a binary blob. This most
> certainly is a serialized GWT object. The authentication
> seems to follow a protocol that involves 3-4 messages
> exchanged with the server-side.
>
> Hence, I strive to understand how the client-side
> transforms my textual credentials (username / password)
> into this binary blob. Subsequently, I would like to
> understand how I can deserialize messages coming from
> the server in order to get a better idea of the messages
> exchanged and hence the protocol.
>
> Thanks,
>
> André
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GWT Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/q0QxVCumk6I/unsubscribe <https://groups.google.com/d/topic/google-web-toolkit/q0QxVCumk6I/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscribe@googlegroups.com
> <mailto:google-web-toolkit+unsubscribe@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit/693c5f07-aac5-4580-aa8f-35684326cf83n%40googlegroups.com <https://groups.google.com/d/msgid/google-web-toolkit/693c5f07-aac5-4580-aa8f-35684326cf83n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7c834ce8-0dc8-3e53-72ad-0c6c12a596ad%40gmail.com.
Friday, October 20, 2023
Re: GWT: Deserialize objects sent/received via websocket
Seeing traffic wouldn't hurt, but it would be easiest to discover by looking at code - finding "WebSocket" in the codebase, then seeing what the import is. Alternatively, the compiled JS will probably have some hints, depending on how it was built.
As to the authentication approach you clarified - if the client sends a POST before the websocket is created that performs the authentication, it is quite likely that the server responds by setting a cookie, and that all subsequent HTTP requests (including the websocket) are authenticated with that cookie. It is also possible that the websocket's binary blobs contain the credentials again, or more likely, the session ID.
gRPC is indeed typically binary protobuf data... but gRPC can't be used in a browser in 2023. gRPC-web is a thing... which can't stream binary data, and can't stream data to the server (using the tooling provided by the gRPC project itself). There are alternative gRPC-web clients that can support streaming binary data _from_ the server, but in 2023 the fetch() API is still server streaming only, even with h2. There are even really-alternative gRPC clients for the browser that rely on websockets as well, but if you get in a situation where you want more than a small handful of concurrent streams the browser just hangs on new calls, so I can't recommend that, unless you use the websocket to replace the h2 transport rather than using it per-stream (but now you've got more work to make sure you clean up streams promptly, and they aren't a lot of fun to debug).
On Friday, October 20, 2023 at 12:59:15 PM UTC-5 Thomas Broyer wrote:
You could have a look at https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit to see what GWT-RPC exchanges look like and see if they match what you're seeing. But they're not "binary".I didn't follow what gRPC (Google's RPC format: https://grpc.io/) looks like on the web, but it's possible they use "binary" nowadays.On Friday, October 20, 2023 at 3:10:17 PM UTC+2 an.s...@gmail.com wrote:Dear Colin,thanks for the quick response. I did observe the authentication approach via BurpSuite that allows me to investigate each HTTP / websocket request / response. From this perspective, I can see that upon submitting my credentials to the webapp, there is only one HTTP POST request from client-side that only includes the username. After this initial POST request, all the communication goes over websocket with binary blobs being exchanged. Hence, it is not easy for me to identify which GWT library class is in use.Is there any way how to get this information, (i.e. I could provide the URL of the endpoint I am talking to).Best,AndréColin Alworth schrieb am Freitag, 20. Oktober 2023 um 14:55:53 UTC+2:While GWT offers websocket support, the only support is "now you can send messages on a websocket" - no serialization is offered, beyond what the browser itself provides (allowing sending a utf8 string, arraybuffers, blobs, typedarrays, or arrayviews). How are you verifying messages sent/received? If you are observing some 3-4 websocket frame handshake messages on the websocket, that is probably some other GWT library in use - which WebSocket class are you using?I maintain (and use in production) an rpc-over-websocket implementation, but it does not explicitly support authentication. Instead usually the first message authenticates with the server, or HTTP headers are used to authenticate (potentially using existing cookies) before the websocket is even initiated. So at least we can probably rule out that implementation.See https://developer.mozilla.org/en-US/docs/Web/API/WebSocket for more information on what the browser's own WebSocket type offers.On Friday, October 20, 2023 at 7:31:03 AM UTC-5 an.s...@gmail.com wrote:Hi,
I am very new to GWT and have questions about the basic principles of how GWT via websockets work.
I would like to analyze the authentication function of a given GWT web application. When authenticating with my credentials, I could identify that my credentials are sent via websocket in form of a binary blob. This most certainly is a serialized GWT object. The authentication seems to follow a protocol that involves 3-4 messages exchanged with the server-side.
Hence, I strive to understand how the client-side transforms my textual credentials (username / password) into this binary blob. Subsequently, I would like to understand how I can deserialize messages coming from the server in order to get a better idea of the messages exchanged and hence the protocol.
Thanks,
André
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/693c5f07-aac5-4580-aa8f-35684326cf83n%40googlegroups.com.
Re: GWT: Deserialize objects sent/received via websocket
You could have a look at https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit to see what GWT-RPC exchanges look like and see if they match what you're seeing. But they're not "binary".
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/f0f3a831-9c9a-47d0-a647-3db32e6d5e07n%40googlegroups.com.
I didn't follow what gRPC (Google's RPC format: https://grpc.io/) looks like on the web, but it's possible they use "binary" nowadays.
On Friday, October 20, 2023 at 3:10:17 PM UTC+2 an.s...@gmail.com wrote:
Dear Colin,thanks for the quick response. I did observe the authentication approach via BurpSuite that allows me to investigate each HTTP / websocket request / response. From this perspective, I can see that upon submitting my credentials to the webapp, there is only one HTTP POST request from client-side that only includes the username. After this initial POST request, all the communication goes over websocket with binary blobs being exchanged. Hence, it is not easy for me to identify which GWT library class is in use.Is there any way how to get this information, (i.e. I could provide the URL of the endpoint I am talking to).Best,AndréColin Alworth schrieb am Freitag, 20. Oktober 2023 um 14:55:53 UTC+2:While GWT offers websocket support, the only support is "now you can send messages on a websocket" - no serialization is offered, beyond what the browser itself provides (allowing sending a utf8 string, arraybuffers, blobs, typedarrays, or arrayviews). How are you verifying messages sent/received? If you are observing some 3-4 websocket frame handshake messages on the websocket, that is probably some other GWT library in use - which WebSocket class are you using?I maintain (and use in production) an rpc-over-websocket implementation, but it does not explicitly support authentication. Instead usually the first message authenticates with the server, or HTTP headers are used to authenticate (potentially using existing cookies) before the websocket is even initiated. So at least we can probably rule out that implementation.See https://developer.mozilla.org/en-US/docs/Web/API/WebSocket for more information on what the browser's own WebSocket type offers.On Friday, October 20, 2023 at 7:31:03 AM UTC-5 an.s...@gmail.com wrote:Hi,
I am very new to GWT and have questions about the basic principles of how GWT via websockets work.
I would like to analyze the authentication function of a given GWT web application. When authenticating with my credentials, I could identify that my credentials are sent via websocket in form of a binary blob. This most certainly is a serialized GWT object. The authentication seems to follow a protocol that involves 3-4 messages exchanged with the server-side.
Hence, I strive to understand how the client-side transforms my textual credentials (username / password) into this binary blob. Subsequently, I would like to understand how I can deserialize messages coming from the server in order to get a better idea of the messages exchanged and hence the protocol.
Thanks,
André
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/f0f3a831-9c9a-47d0-a647-3db32e6d5e07n%40googlegroups.com.
Re: GWT: Deserialize objects sent/received via websocket
Dear Colin,
thanks for the quick response. I did observe the authentication approach via BurpSuite that allows me to investigate each HTTP / websocket request / response. From this perspective, I can see that upon submitting my credentials to the webapp, there is only one HTTP POST request from client-side that only includes the username. After this initial POST request, all the communication goes over websocket with binary blobs being exchanged. Hence, it is not easy for me to identify which GWT library class is in use.
Is there any way how to get this information, (i.e. I could provide the URL of the endpoint I am talking to).
Best,
André
Colin Alworth schrieb am Freitag, 20. Oktober 2023 um 14:55:53 UTC+2:
While GWT offers websocket support, the only support is "now you can send messages on a websocket" - no serialization is offered, beyond what the browser itself provides (allowing sending a utf8 string, arraybuffers, blobs, typedarrays, or arrayviews). How are you verifying messages sent/received? If you are observing some 3-4 websocket frame handshake messages on the websocket, that is probably some other GWT library in use - which WebSocket class are you using?I maintain (and use in production) an rpc-over-websocket implementation, but it does not explicitly support authentication. Instead usually the first message authenticates with the server, or HTTP headers are used to authenticate (potentially using existing cookies) before the websocket is even initiated. So at least we can probably rule out that implementation.See https://developer.mozilla.org/en-US/docs/Web/API/WebSocket for more information on what the browser's own WebSocket type offers.On Friday, October 20, 2023 at 7:31:03 AM UTC-5 an.s...@gmail.com wrote:Hi,
I am very new to GWT and have questions about the basic principles of how GWT via websockets work.
I would like to analyze the authentication function of a given GWT web application. When authenticating with my credentials, I could identify that my credentials are sent via websocket in form of a binary blob. This most certainly is a serialized GWT object. The authentication seems to follow a protocol that involves 3-4 messages exchanged with the server-side.
Hence, I strive to understand how the client-side transforms my textual credentials (username / password) into this binary blob. Subsequently, I would like to understand how I can deserialize messages coming from the server in order to get a better idea of the messages exchanged and hence the protocol.
Thanks,
André
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7c52c6bd-afae-48e3-8ac9-546ae1dd9c47n%40googlegroups.com.
Re: GWT: Deserialize objects sent/received via websocket
While GWT offers websocket support, the only support is "now you can send messages on a websocket" - no serialization is offered, beyond what the browser itself provides (allowing sending a utf8 string, arraybuffers, blobs, typedarrays, or arrayviews). How are you verifying messages sent/received? If you are observing some 3-4 websocket frame handshake messages on the websocket, that is probably some other GWT library in use - which WebSocket class are you using?
I maintain (and use in production) an rpc-over-websocket implementation, but it does not explicitly support authentication. Instead usually the first message authenticates with the server, or HTTP headers are used to authenticate (potentially using existing cookies) before the websocket is even initiated. So at least we can probably rule out that implementation.
See https://developer.mozilla.org/en-US/docs/Web/API/WebSocket for more information on what the browser's own WebSocket type offers.
On Friday, October 20, 2023 at 7:31:03 AM UTC-5 an.s...@gmail.com wrote:
Hi,
I am very new to GWT and have questions about the basic principles of how GWT via websockets work.
I would like to analyze the authentication function of a given GWT web application. When authenticating with my credentials, I could identify that my credentials are sent via websocket in form of a binary blob. This most certainly is a serialized GWT object. The authentication seems to follow a protocol that involves 3-4 messages exchanged with the server-side.
Hence, I strive to understand how the client-side transforms my textual credentials (username / password) into this binary blob. Subsequently, I would like to understand how I can deserialize messages coming from the server in order to get a better idea of the messages exchanged and hence the protocol.
Thanks,
André
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/4346318b-fe43-4454-ae90-c19bac156f55n%40googlegroups.com.
GWT: Deserialize objects sent/received via websocket
Hi,
I am very new to GWT and have questions about the basic principles of how GWT via websockets work.
I would like to analyze the authentication function of a given GWT web application. When authenticating with my credentials, I could identify that my credentials are sent via websocket in form of a binary blob. This most certainly is a serialized GWT object. The authentication seems to follow a protocol that involves 3-4 messages exchanged with the server-side.
Hence, I strive to understand how the client-side transforms my textual credentials (username / password) into this binary blob. Subsequently, I would like to understand how I can deserialize messages coming from the server in order to get a better idea of the messages exchanged and hence the protocol.
Thanks,
André
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/a46305e2-6df0-4ad6-83d4-de2074f0bb23n%40googlegroups.com.
Tuesday, October 17, 2023
Re: Convert Existing GWT Backend to SPRING BOOT
Yw, glad it worked!
On Tue, 17 Oct 2023 at 19:45, 'Eric Dufresne' via GWT Users <google-web-toolkit@googlegroups.com> wrote:
That did the trick. In my pom.xml I had my `deploy` location as `<deploy>${project.build.directory}/gwt-deploy</deploy>` but I guess that isn't on the classpath so moving it to ${project.build.directory}/public/gwt-deploy (which I believe is automatically on Spring's classpath) worked. Was able to get rid of the classpath: prefix as well.Ty for the help Leon!On Tuesday, 17 October 2023 at 00:49:13 UTC-4 Leon wrote:Hey Eric,I did this and it worked out of the box;@Override
protected SerializationPolicy doGetSerializationPolicy(HttpServletRequest request, String moduleBaseURL, String strongName) {try {
return SerializationPolicyLoader.loadFromStream(new ClassPathResource("classpath:public/my_compile_folder_name/" + strongName+".gwt.rpc").getInputStream(), null);
} catch (Exception e) {
LOGGER.error("Error loading Serialization policy - peeps with outdated application version");
return null;
}
}On Tue, Oct 17, 2023 at 12:20 AM 'Eric Dufresne' via GWT Users <google-we...@googlegroups.com> wrote:Hi!Were you successful in building out a JAR using spring boot while still using GWT RPC? I am on the last step of getting the `.gwt.rpc` files in the right place but I still get serialization errors saying the serialization policy files are missing.For the override you did:@Override
protected SerializationPolicy doGetSerializationPolicy(HttpServletRequest request, String moduleBaseURL, String strongName) {
return SerializationPolicyLoader.loadFromStream(new ClassPathResource("classpath:yourLocation/" + strongName+".gwt.rpc").getInputStream(), null);}where in the JAR did you add the gwt.rpc files and how did you access them from here?Any help would be greatly appreciated.Thanks!--On Tuesday, 6 December 2022 at 18:57:27 UTC-5 Dr. Lofi Dewanto wrote:Thanks a lot for the tips on Spring Boot packaging in JAR.Yes, the first example I showed was with packaging WAR. That works fine.I would try your tips to be able to run on the JAR packaging (second example).I'll tell you, whether I'm successful or not.It is weird, that I could run the RemoteLoggingServiceImpl.java for GWT logger on the JAR packaging but not the RemoteServlet.Thanks,LofiLeon Pennings <leon.p...@gmail.com> schrieb am Di., 6. Dez. 2022, 14:28:In addition to previous poster -> yes you can keep on using the GWT RPC.The things I had to change in order to keep it working when packaging the spring boot jar, was;1 - to make sure Spring Boot runs the servlets (enough on the web for that)2 - to make sure the gwt compile ends up in de classes folder before the .jar is created3 - to make sure the servlet can access the .gwt.rpc file to validate the servlet calls.Normally that is available to the servlet from the war package, but since it's a jar with Spring boot you need to make some changes;For that I had to override the RemoteServiceServlet method;@Override
protected SerializationPolicy doGetSerializationPolicy(HttpServletRequest request, String moduleBaseURL, String strongName) {
return SerializationPolicyLoader.loadFromStream(new ClassPathResource("classpath:yourLocation/" + strongName+".gwt.rpc").getInputStream(), null);}So the changes are quite limited and not as much Spring boot specific, but more the oddities of changing the package format from a .war to a .jarThat was all -> runs like a charm--Op maandag 5 december 2022 om 23:00:26 UTC+1 schreef lofid...@gmail.com:Hi All,you don't have to move GWT RPC to REST and JSON when you want to move the backend to Spring Boot. GWT RPC is just a servlet which you can register in Spring Boot.Here are some examples of the standard GWT Demo StockWatcher but implemented using Spring Boot with GWT RPC and REST JSON:(1) This example shows how to integrate the GWT RPC servlet to Spring Boot using @WebServlet: https://github.com/lofidewanto/stockwatcher/blob/master/stockwatcher-springboot-webapp/stockwatcher-springboot-webapp-server/src/main/java/stockwatcher/GreetingServiceImpl.java(2) This example shows to integrate the GWT RPC servlet to Spring Boot, but I think doesn't work so far. I could take a look if you want to.Cheers,LofiMichael Joyner schrieb am Montag, 21. November 2022 um 16:50:29 UTC+1:Yes! we are using GWT-RPC & currently having a single WAR of near about 500mb, having CLIENT-SHARED-SERVER in a same project.Are you using gwt-RPC ?
You can still have everything in a master parent project that builds the final WAR with all the client JS and SERVER classes in the same war.
You'll need to switch to JSON for data transport.
Is there any drawback of switching to JSON in GWT, such as impact on performance etc.You lose easy polymorphism for models, they will require an extra set of annotations at the very least if you have polymorphism as part of your DTO setup.
You'll need to use something like DominoKit REST.We found one RestyGWT, but not sure about its final impact as we haven't applied it yet. any suggestions...RestyGWT is effectively defunct. Stick with a modern GWT3 compatible approach such as DominoKit.
It would be also be best to split the project into three projects. An API project, a shared code project, and a UI project.
We cannot get why keeping SHARED CODE as a separate project is best. We are not having any library of GWT on server side. So except MODELS, what are the other stuffs we can have in SHARED CODE PROJECT.
In this case SHARED CODE is really just the MODELS and INTERFACES and possible the REST Interface.
If you are using gwt-RPC then IMHO there will need to be a big refactoring change at the very least
This is where we are stuck & looking for the solution with a minimum change and should be stable but unable to figure out yet.
I don't think you can accomplish this with a large project with minimum of change unless the client API calls are fully abstracted away (or can be) so that code could be replaced with a different class.
--On Monday, November 21, 2022 at 7:37:33 PM UTC+5:30 Michael Joyner wrote:
There are a lot of factors to consider.
Are you using gwt-RPC ? You'll need to switch to JSON for data transport.
You'll need to use something like DominoKit REST (https://github.com/DominoKit/domino-rest) for the data transport layer.
It would be also be best to split the project into three projects. An API project, a shared code project, and a UI project.
If you are using gwt-RPC then IMHO there will need to be a big refactoring change at the very least.We are having a huge project already running successfully on GWT.
But for some reasons we are planning to move our backend to SPRING-BOOT keeping front end in GWT.
Is there any way we can do it easily without a big change in our existing application.
--
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-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/c267bbb3-504f-41a8-896a-a2c2463eccdcn%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-tool...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/1790c907-ce31-4d97-a5b9-1915fef68865n%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/13cHZX5KoQA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/5535048c-bbc2-4f58-8cf4-11025a166464n%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/13cHZX5KoQA/unsubscribe.--To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/4e6ddddf-68b8-49a7-875b-e645fed2828cn%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/13cHZX5KoQA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/fbf7b862-14ff-460c-b784-86588722873an%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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CABjQu7Q%2BkOyDwwNFwYCyPeKN83hqJPjZdOSU_-RSdRAF2cyRnA%40mail.gmail.com.
Re: Convert Existing GWT Backend to SPRING BOOT
That did the trick. In my pom.xml I had my `deploy` location as `<deploy>${project.build.directory}/gwt-deploy</deploy>` but I guess that isn't on the classpath so moving it to ${project.build.directory}/public/gwt-deploy (which I believe is automatically on Spring's classpath) worked. Was able to get rid of the classpath: prefix as well.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/fbf7b862-14ff-460c-b784-86588722873an%40googlegroups.com.
Ty for the help Leon!
On Tuesday, 17 October 2023 at 00:49:13 UTC-4 Leon wrote:
Hey Eric,I did this and it worked out of the box;@Override
protected SerializationPolicy doGetSerializationPolicy(HttpServletRequest request, String moduleBaseURL, String strongName) {try {
return SerializationPolicyLoader.loadFromStream(new ClassPathResource("classpath:public/my_compile_folder_name/" + strongName+".gwt.rpc").getInputStream(), null);
} catch (Exception e) {
LOGGER.error("Error loading Serialization policy - peeps with outdated application version");
return null;
}
}On Tue, Oct 17, 2023 at 12:20 AM 'Eric Dufresne' via GWT Users <google-we...@googlegroups.com> wrote:Hi!Were you successful in building out a JAR using spring boot while still using GWT RPC? I am on the last step of getting the `.gwt.rpc` files in the right place but I still get serialization errors saying the serialization policy files are missing.For the override you did:@Override
protected SerializationPolicy doGetSerializationPolicy(HttpServletRequest request, String moduleBaseURL, String strongName) {
return SerializationPolicyLoader.loadFromStream(new ClassPathResource("classpath:yourLocation/" + strongName+".gwt.rpc").getInputStream(), null);}where in the JAR did you add the gwt.rpc files and how did you access them from here?Any help would be greatly appreciated.Thanks!--On Tuesday, 6 December 2022 at 18:57:27 UTC-5 Dr. Lofi Dewanto wrote:Thanks a lot for the tips on Spring Boot packaging in JAR.Yes, the first example I showed was with packaging WAR. That works fine.I would try your tips to be able to run on the JAR packaging (second example).I'll tell you, whether I'm successful or not.It is weird, that I could run the RemoteLoggingServiceImpl.java for GWT logger on the JAR packaging but not the RemoteServlet.Thanks,LofiLeon Pennings <leon.p...@gmail.com> schrieb am Di., 6. Dez. 2022, 14:28:In addition to previous poster -> yes you can keep on using the GWT RPC.The things I had to change in order to keep it working when packaging the spring boot jar, was;1 - to make sure Spring Boot runs the servlets (enough on the web for that)2 - to make sure the gwt compile ends up in de classes folder before the .jar is created3 - to make sure the servlet can access the .gwt.rpc file to validate the servlet calls.Normally that is available to the servlet from the war package, but since it's a jar with Spring boot you need to make some changes;For that I had to override the RemoteServiceServlet method;@Override
protected SerializationPolicy doGetSerializationPolicy(HttpServletRequest request, String moduleBaseURL, String strongName) {
return SerializationPolicyLoader.loadFromStream(new ClassPathResource("classpath:yourLocation/" + strongName+".gwt.rpc").getInputStream(), null);}So the changes are quite limited and not as much Spring boot specific, but more the oddities of changing the package format from a .war to a .jarThat was all -> runs like a charm--Op maandag 5 december 2022 om 23:00:26 UTC+1 schreef lofid...@gmail.com:Hi All,you don't have to move GWT RPC to REST and JSON when you want to move the backend to Spring Boot. GWT RPC is just a servlet which you can register in Spring Boot.Here are some examples of the standard GWT Demo StockWatcher but implemented using Spring Boot with GWT RPC and REST JSON:(1) This example shows how to integrate the GWT RPC servlet to Spring Boot using @WebServlet: https://github.com/lofidewanto/stockwatcher/blob/master/stockwatcher-springboot-webapp/stockwatcher-springboot-webapp-server/src/main/java/stockwatcher/GreetingServiceImpl.java(2) This example shows to integrate the GWT RPC servlet to Spring Boot, but I think doesn't work so far. I could take a look if you want to.Cheers,LofiMichael Joyner schrieb am Montag, 21. November 2022 um 16:50:29 UTC+1:Yes! we are using GWT-RPC & currently having a single WAR of near about 500mb, having CLIENT-SHARED-SERVER in a same project.Are you using gwt-RPC ?
You can still have everything in a master parent project that builds the final WAR with all the client JS and SERVER classes in the same war.
You'll need to switch to JSON for data transport.
Is there any drawback of switching to JSON in GWT, such as impact on performance etc.You lose easy polymorphism for models, they will require an extra set of annotations at the very least if you have polymorphism as part of your DTO setup.
You'll need to use something like DominoKit REST.We found one RestyGWT, but not sure about its final impact as we haven't applied it yet. any suggestions...RestyGWT is effectively defunct. Stick with a modern GWT3 compatible approach such as DominoKit.
It would be also be best to split the project into three projects. An API project, a shared code project, and a UI project.
We cannot get why keeping SHARED CODE as a separate project is best. We are not having any library of GWT on server side. So except MODELS, what are the other stuffs we can have in SHARED CODE PROJECT.
In this case SHARED CODE is really just the MODELS and INTERFACES and possible the REST Interface.
If you are using gwt-RPC then IMHO there will need to be a big refactoring change at the very least
This is where we are stuck & looking for the solution with a minimum change and should be stable but unable to figure out yet.
I don't think you can accomplish this with a large project with minimum of change unless the client API calls are fully abstracted away (or can be) so that code could be replaced with a different class.
--On Monday, November 21, 2022 at 7:37:33 PM UTC+5:30 Michael Joyner wrote:
There are a lot of factors to consider.
Are you using gwt-RPC ? You'll need to switch to JSON for data transport.
You'll need to use something like DominoKit REST (https://github.com/DominoKit/domino-rest) for the data transport layer.
It would be also be best to split the project into three projects. An API project, a shared code project, and a UI project.
If you are using gwt-RPC then IMHO there will need to be a big refactoring change at the very least.We are having a huge project already running successfully on GWT.
But for some reasons we are planning to move our backend to SPRING-BOOT keeping front end in GWT.
Is there any way we can do it easily without a big change in our existing application.
--
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-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/c267bbb3-504f-41a8-896a-a2c2463eccdcn%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-tool...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/1790c907-ce31-4d97-a5b9-1915fef68865n%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/13cHZX5KoQA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/5535048c-bbc2-4f58-8cf4-11025a166464n%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/13cHZX5KoQA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/4e6ddddf-68b8-49a7-875b-e645fed2828cn%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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/fbf7b862-14ff-460c-b784-86588722873an%40googlegroups.com.
Subscribe to:
Posts (Atom)