Re: InvocationTargetException with null cause?

I'm guessing this server has been running for a while, and possibly seen/caught other NPEs before this point? Hotspot has an optimization where it stops producing stack traces for null pointer exceptions (as well as a few other exceptions) after it is thrown a few times (usually "many", but technically "two" is possible if they are rare enough and don't affect jit codegen) - if it is being thrown and caught a lot, the JVM will remove this to avoid needing to walk the stack so many times.

You can disable this behavior with the flag "-XX:-OmitStackTraceInFastThrow". Here's the writeup that I usually find when I get bothered by this issue: https://stackoverflow.com/a/58700744/860630.

On Thursday, February 29, 2024 at 10:23:05 AM UTC-6 alex...@gmail.com wrote:

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 omitted
Caused by: java.lang.NullPointerException: null

{call stack log ends here}

Relevant GWT code from RPC class:

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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/4b95ac47-2bc7-4901-b390-67cae94a3c6fn%40googlegroups.com.

InvocationTargetException with null cause?

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 omitted
Caused by: java.lang.NullPointerException: null

{call stack log ends here}

Relevant GWT code from RPC class:

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+unsubscribe@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: Deobfuscated stack trace message and line-specific stack traces

Thanks again Thomas.  👍

<build>
  <plugins>
    <plugin>
      <groupId>net.ltgt.gwt.maven</groupId>
      <artifactId>gwt-maven-plugin</artifactId>
      <configuration>
        <moduleName>com.mycompany.mywebapp.App</moduleName>
        <moduleShortName>mywebapp</moduleShortName>
        <deploy>${project.build.directory}/${project.build.finalName}/WEB-INF/deploy</deploy>
      </configuration>
    </plugin>
  </plugins>
</build>

On Tuesday 27 February 2024 at 4:06:12 am UTC+11 Thomas Broyer wrote:

On Monday, February 26, 2024 at 11:56:45 AM UTC+1 ma...@craig-mitchell.com wrote:

Thanks Thomas, now working great!

For anyone coming from the Eclipse GWT plugin, you can do this to keep it consistant with how it used to work:

In your client pom.  Add the <deploy> like this:

<build>
  <plugins>
    <plugin>
      <groupId>net.ltgt.gwt.maven</groupId>
      <artifactId>gwt-maven-plugin</artifactId>
      <configuration>
        <moduleName>com.mycompany.mywebapp.App</moduleName>
        <moduleShortName>mywebapp</moduleShortName>
        <deploy>${project.build.directory}/mywebapp-client-HEAD-SNAPSHOT/WEB-INF/deploy</deploy>

nit: use ${project.build.finalName} rather than hard-coding the "mywebapp-client-HEAD-SNAPSHOT"

https://tbroyer.github.io/gwt-maven-plugin/compile-mojo.html#webappDirectory

--
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/c3eddfb9-5590-4be4-9db5-a4ff22cd4e61n%40googlegroups.com.

Re: Deobfuscated stack trace message and line-specific stack traces

On Monday, February 26, 2024 at 11:56:45 AM UTC+1 ma...@craig-mitchell.com wrote:

Thanks Thomas, now working great!

For anyone coming from the Eclipse GWT plugin, you can do this to keep it consistant with how it used to work:

In your client pom.  Add the <deploy> like this:

<build>
  <plugins>
    <plugin>
      <groupId>net.ltgt.gwt.maven</groupId>
      <artifactId>gwt-maven-plugin</artifactId>
      <configuration>
        <moduleName>com.mycompany.mywebapp.App</moduleName>
        <moduleShortName>mywebapp</moduleShortName>
        <deploy>${project.build.directory}/mywebapp-client-HEAD-SNAPSHOT/WEB-INF/deploy</deploy>

nit: use ${project.build.finalName} rather than hard-coding the "mywebapp-client-HEAD-SNAPSHOT"

https://tbroyer.github.io/gwt-maven-plugin/compile-mojo.html#webappDirectory

--
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/f57dfe88-40b6-4b91-af17-30148cda2d1fn%40googlegroups.com.

Re: Deobfuscated stack trace message and line-specific stack traces

Thanks Thomas, now working great!

For anyone coming from the Eclipse GWT plugin, you can do this to keep it consistant with how it used to work:

In your client pom.  Add the <deploy> like this:

<build>
  <plugins>
    <plugin>
      <groupId>net.ltgt.gwt.maven</groupId>
      <artifactId>gwt-maven-plugin</artifactId>
      <configuration>
        <moduleName>com.mycompany.mywebapp.App</moduleName>
        <moduleShortName>mywebapp</moduleShortName>
        <deploy>${project.build.directory}/mywebapp-client-HEAD-SNAPSHOT/WEB-INF/deploy</deploy>
      </configuration>
    </plugin>
  </plugins>
</build>

And then instead of reading the symbol maps directly like this:

  String path = config.getServletContext().getRealPath("/WEB-INF/deploy/<module>/symbolMaps/");

  StackTraceDeobfuscator deobfuscator = StackTraceDeobfuscator.fromFileSystem(path);

You now read them from inside the war like this:

  StackTraceDeobfuscator deobfuscator = StackTraceDeobfuscator.fromResource("/WEB-INF/deploy/<module>/symbolMaps/");

Cheers.

On Monday 26 February 2024 at 8:03:27 am UTC+11 Thomas Broyer wrote:

On Sunday, February 25, 2024 at 12:34:44 AM UTC+1 ma...@craig-mitchell.com wrote:

Sorry, I do see them in  mywebapp-client\target\gwt\deploy\mywebapp\symbolMaps

How do I get them from there, into the war?

Configure <deploy> to somewhere inside the <webappDirectory> (preferably inside WEB-INF so they won't be served)

https://tbroyer.github.io/gwt-maven-plugin/compile-mojo.html#deploy

--
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/6ae923cb-f73f-41f6-bbd8-67879122e8cfn%40googlegroups.com.

Re: Deobfuscated stack trace message and line-specific stack traces

On Sunday, February 25, 2024 at 12:34:44 AM UTC+1 ma...@craig-mitchell.com wrote:

Sorry, I do see them in  mywebapp-client\target\gwt\deploy\mywebapp\symbolMaps

How do I get them from there, into the war?

Configure <deploy> to somewhere inside the <webappDirectory> (preferably inside WEB-INF so they won't be served)

https://tbroyer.github.io/gwt-maven-plugin/compile-mojo.html#deploy

--
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/13cdf61a-f204-4b71-a7f6-312a77760740n%40googlegroups.com.

Re: Deploy to Google App Engine (GAE)

If nobody is interested in maintaining such, it could be presented as a demonstration valid in 2024. I can post my version of it and others can make revisions or advise.

Sent from Yahoo Mail on Android

On Sun, Feb 25, 2024 at 0:12, Craig Mitchell

<mail@craig-mitchell.com> wrote:

> My question is: what do you expect from such an archetype?

It would be great to have an example for a minimum viable product.  So how to do a mvn package on an app created with https://github.com/tbroyer/gwt-maven-archetypes to get an executable jar that doesn't need an existing web server.

> I could easily write a Main class that runs an embedded Jetty server with the configured GWT-RPC servlet and serving static resources from multiple dirs.

If that's what we need to get an executable jar, yes please!  🙂

On Sunday 25 February 2024 at 9:40:35 am UTC+11 Thomas Broyer wrote:

In retrospect, I think the GWT BOM (to avoid managing non-GWT dependencies where there's no need to) possibly either should only be used in the client module, or should really only list GWT artifacts. That being said, if you use the Jetty BOM in the server module (and you should), it should override the GWT BOM.

On Saturday, February 24, 2024 at 8:11:38 PM UTC+1 tim_mac...@yahoo.co.uk wrote:

The gwt artifact is indeed in dependency management, but when the jetty-main jar for jetty 11 is a dependency of server module it draws in jetty 9 dependencies and and also gwt-servlet leading to a no javax-servlet error. Remove gwt from the root fixes it.  Maybe this will cause problems beyond this sample.

Sent from Yahoo Mail on Android

On Sat, Feb 24, 2024 at 12:14, Thomas Broyer

<t.br...@gmail.com> wrote:

I could easily write a Main class that runs an embedded Jetty server jagwtvax(https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-servlet-context) with the configured GWT-RPC servlet and serving static resources from multiple dirs (https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-resource), but then there would still be a whole lot of questions either unanswered or with an necessarily opinionated answer:

• how to set "dev mode" for the Main class? (to add the codeserver's launcherDir to the resource bases; I would personally use a system property with the launcherDir's path and react to its presence/absence)
• how to package/deploy the static resources? as resources in the JAR? (that's what I'd do if I'd wanted my deliverable to be a single JAR) as a directory alongside the JAR? (that's what I'd do if my deliverable were a native deb/rpm/whatever package or a Docker image)
• that Main class would likely not be production-ready (should it use the QoSHandler? GzipHandler? how about the CrossOriginHandler? the ForwardedRequestCustomizer?)
• you'd probably want to refactor the Main class anyway to add command-line arguments and/or configuration files, a logging framework, possibly dependency-injection, etc.

My question is: what do you expect from such an archetype?

The initial goal was to show how to cleanly/clearly separate client/shared/server classpaths, which involves some configuration for how to run the server so it serves the codeserver's launcherDir. As soon as you go "custom" on the server, you have to handle that specific "dev mode" configuration, but then it's custom to your custom code, and necessarily becomes somewhat opinionated. This means that the archetype can't really "show you how to do things" without being opinionated, and I don't want to go that road (I specifically don't want to maintain such an opinionated thing). Feel free to create opinionated archetypes though, and I'll happily review them and help you set them up (this will bring my own opinions into the mix though)

On Friday, February 23, 2024 at 12:05:22 AM UTC+1 ma...@craig-mitchell.com wrote:

I know it's outside of its scope, but it would be great if https://github.com/tbroyer/gwt-maven-archetypes had an example of "If you want to create an executable jar with Jetty, this is how you could do it".  🙂

On Thursday 22 February 2024 at 5:30:51 am UTC+11 Tim Macpherson wrote:

I tried starting with the tbroyer archetype & to the server project I added the app engine stuff from the Google sample to build the appengine-staging dependencies directory.

Maybe all that should be in a separate project ?

Sent from Yahoo Mail on Android

On Wed, Feb 21, 2024 at 17:42, Thomas Broyer

<t.br...@gmail.com> wrote:

On Wednesday, February 21, 2024 at 3:11:54 PM UTC+1 tim_mac...@yahoo.co.uk wrote:

I've been trying this app engine sample for Java 11+ which uses a JAR packaged artifact that is installed locally:

it provides a Main class to instantiate an HTTP server to run an embedded web application WAR file.

github.com/GoogleCloudPlatform/java-docs-samples/tree/main/appengine-java11/appengine-simple-jetty-main

It has explicit jetty 11 dependencies.

The WAR project is

github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine-java11/helloworld-servlet

The WAR is run in a local server with:

mvn exec:java -Dexec.args="../helloworld-servlet/target/helloworld.war"

The problem I have is when I include GWT in the WAR project this draws in Jetty 9 & other dependencies

which get copied to the cloud-deployment dependencies directory.

This means you WAR have dependencies on gwt-user and/or gwt-dev, that you never want to deploy to a server. The WAR should have a dependency on gwt-servlet only (or requestfactory-server).

…and this is exactly what https://github.com/tbroyer/gwt-maven-archetypes were meant to solve.

--

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/c04ab91a-b898-489d-a509-6fafb9a363can%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/643460b0-a460-4961-9366-9b0e13cb7990n%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/88b1990a-9a18-48b3-9b88-0204f0c7cb80n%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/1159661492.689524.1708888177195%40mail.yahoo.com.

Re: Deploy to Google App Engine (GAE)

> My question is: what do you expect from such an archetype?

It would be great to have an example for a minimum viable product.  So how to do a mvn package on an app created with https://github.com/tbroyer/gwt-maven-archetypes to get an executable jar that doesn't need an existing web server.

> I could easily write a Main class that runs an embedded Jetty server with the configured GWT-RPC servlet and serving static resources from multiple dirs.

If that's what we need to get an executable jar, yes please!  🙂

On Sunday 25 February 2024 at 9:40:35 am UTC+11 Thomas Broyer wrote:

In retrospect, I think the GWT BOM (to avoid managing non-GWT dependencies where there's no need to) possibly either should only be used in the client module, or should really only list GWT artifacts. That being said, if you use the Jetty BOM in the server module (and you should), it should override the GWT BOM.

On Saturday, February 24, 2024 at 8:11:38 PM UTC+1 tim_mac...@yahoo.co.uk wrote:

The gwt artifact is indeed in dependency management, but when the jetty-main jar for jetty 11 is a dependency of server module it draws in jetty 9 dependencies and and also gwt-servlet leading to a no javax-servlet error. Remove gwt from the root fixes it.  Maybe this will cause problems beyond this sample.

Sent from Yahoo Mail on Android

On Sat, Feb 24, 2024 at 12:14, Thomas Broyer

<t.br...@gmail.com> wrote:

I could easily write a Main class that runs an embedded Jetty server jagwtvax(https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-servlet-context) with the configured GWT-RPC servlet and serving static resources from multiple dirs (https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-resource), but then there would still be a whole lot of questions either unanswered or with an necessarily opinionated answer:

• how to set "dev mode" for the Main class? (to add the codeserver's launcherDir to the resource bases; I would personally use a system property with the launcherDir's path and react to its presence/absence)
• how to package/deploy the static resources? as resources in the JAR? (that's what I'd do if I'd wanted my deliverable to be a single JAR) as a directory alongside the JAR? (that's what I'd do if my deliverable were a native deb/rpm/whatever package or a Docker image)
• that Main class would likely not be production-ready (should it use the QoSHandler? GzipHandler? how about the CrossOriginHandler? the ForwardedRequestCustomizer?)
• you'd probably want to refactor the Main class anyway to add command-line arguments and/or configuration files, a logging framework, possibly dependency-injection, etc.

My question is: what do you expect from such an archetype?

The initial goal was to show how to cleanly/clearly separate client/shared/server classpaths, which involves some configuration for how to run the server so it serves the codeserver's launcherDir. As soon as you go "custom" on the server, you have to handle that specific "dev mode" configuration, but then it's custom to your custom code, and necessarily becomes somewhat opinionated. This means that the archetype can't really "show you how to do things" without being opinionated, and I don't want to go that road (I specifically don't want to maintain such an opinionated thing). Feel free to create opinionated archetypes though, and I'll happily review them and help you set them up (this will bring my own opinions into the mix though)

On Friday, February 23, 2024 at 12:05:22 AM UTC+1 ma...@craig-mitchell.com wrote:

I know it's outside of its scope, but it would be great if https://github.com/tbroyer/gwt-maven-archetypes had an example of "If you want to create an executable jar with Jetty, this is how you could do it".  🙂

On Thursday 22 February 2024 at 5:30:51 am UTC+11 Tim Macpherson wrote:

I tried starting with the tbroyer archetype & to the server project I added the app engine stuff from the Google sample to build the appengine-staging dependencies directory.

Maybe all that should be in a separate project ?

Sent from Yahoo Mail on Android

On Wed, Feb 21, 2024 at 17:42, Thomas Broyer

<t.br...@gmail.com> wrote:

On Wednesday, February 21, 2024 at 3:11:54 PM UTC+1 tim_mac...@yahoo.co.uk wrote:

I've been trying this app engine sample for Java 11+ which uses a JAR packaged artifact that is installed locally:

it provides a Main class to instantiate an HTTP server to run an embedded web application WAR file.

github.com/GoogleCloudPlatform/java-docs-samples/tree/main/appengine-java11/appengine-simple-jetty-main

It has explicit jetty 11 dependencies.

The WAR project is

github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine-java11/helloworld-servlet

The WAR is run in a local server with:

mvn exec:java -Dexec.args="../helloworld-servlet/target/helloworld.war"

The problem I have is when I include GWT in the WAR project this draws in Jetty 9 & other dependencies

which get copied to the cloud-deployment dependencies directory.

This means you WAR have dependencies on gwt-user and/or gwt-dev, that you never want to deploy to a server. The WAR should have a dependency on gwt-servlet only (or requestfactory-server).

…and this is exactly what https://github.com/tbroyer/gwt-maven-archetypes were meant to solve.

--

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/c04ab91a-b898-489d-a509-6fafb9a363can%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/643460b0-a460-4961-9366-9b0e13cb7990n%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/88b1990a-9a18-48b3-9b88-0204f0c7cb80n%40googlegroups.com.

Re: Deobfuscated stack trace message and line-specific stack traces

Sorry, I do see them in  mywebapp-client\target\gwt\deploy\mywebapp\symbolMaps

How do I get them from there, into the war?

On Sunday 25 February 2024 at 10:30:14 am UTC+11 Craig Mitchell wrote:

Hi George,

What I did was:

1. Run https://github.com/tbroyer/gwt-maven-archetypes to generate the sample app.
2. Modify module.gwt.xml to have: <set-property name="compiler.stackMode" value="native" />
3. Run mvn clean package.

Then when I look inside mywebapp-server\target\mywebapp-server-HEAD-SNAPSHOT.war I see the mywebapp folder with all the compiled javascript, but no symbolMaps.

I also tried with:

<set-property name="compiler.stackMode" value="emulated" />
<set-configuration-property name="compiler.emulatedStack.recordLineNumbers" value="true" />
<set-configuration-property name="compiler.emulatedStack.recordFileNames" value="true"/>

Still no symbol maps.

Any ideas on what I'm missing would be great.  Thanks.

On Sunday 25 February 2024 at 12:45:57 am UTC+11 George Paret wrote:

I see the symbolmaps generated in ` target/gwt/deploy/<modulename>/symbolMaps `

I believe it is generated by default.

On Friday, February 23, 2024 at 10:27:12 PM UTC-6 Craig Mitchell wrote:

The symbol maps worked great with the Eclipse GWT plugin compiler.

Now switched to use the Maven compiler (with the https://github.com/tbroyer/gwt-maven-archetypes architecture), I don't see the symbol maps anywhere when doing a mvn clean package.

Do I need to do something extra to get them?

Thanks.

On Saturday 18 May 2019 at 8:48:47 am UTC+10 Craig Mitchell wrote:

Thank you Alexander!  That's what I was missing.

Called:

exception = SerializableThrowable.fromThrowable(exception);

before sending to the server, and now the stack traces show perfectly.  :-)

--
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/ae4ca692-8890-406a-8b6b-44eaa5412e3cn%40googlegroups.com.

Re: Deobfuscated stack trace message and line-specific stack traces

Hi George,

What I did was:

1. Run https://github.com/tbroyer/gwt-maven-archetypes to generate the sample app.
2. Modify module.gwt.xml to have: <set-property name="compiler.stackMode" value="native" />
3. Run mvn clean package.

Then when I look inside mywebapp-server\target\mywebapp-server-HEAD-SNAPSHOT.war I see the mywebapp folder with all the compiled javascript, but no symbolMaps.

I also tried with:

<set-property name="compiler.stackMode" value="emulated" />
<set-configuration-property name="compiler.emulatedStack.recordLineNumbers" value="true" />
<set-configuration-property name="compiler.emulatedStack.recordFileNames" value="true"/>

Still no symbol maps.

Any ideas on what I'm missing would be great.  Thanks.

On Sunday 25 February 2024 at 12:45:57 am UTC+11 George Paret wrote:

I see the symbolmaps generated in ` target/gwt/deploy/<modulename>/symbolMaps `

I believe it is generated by default.

On Friday, February 23, 2024 at 10:27:12 PM UTC-6 Craig Mitchell wrote:

The symbol maps worked great with the Eclipse GWT plugin compiler.

Now switched to use the Maven compiler (with the https://github.com/tbroyer/gwt-maven-archetypes architecture), I don't see the symbol maps anywhere when doing a mvn clean package.

Do I need to do something extra to get them?

Thanks.

On Saturday 18 May 2019 at 8:48:47 am UTC+10 Craig Mitchell wrote:

Thank you Alexander!  That's what I was missing.

Called:

exception = SerializableThrowable.fromThrowable(exception);

before sending to the server, and now the stack traces show perfectly.  :-)

--
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/693aea27-01f7-4bde-92df-2a8faa8fbbc2n%40googlegroups.com.

Re: Deploy to Google App Engine (GAE)

In retrospect, I think the GWT BOM (to avoid managing non-GWT dependencies where there's no need to) possibly either should only be used in the client module, or should really only list GWT artifacts. That being said, if you use the Jetty BOM in the server module (and you should), it should override the GWT BOM.

On Saturday, February 24, 2024 at 8:11:38 PM UTC+1 tim_mac...@yahoo.co.uk wrote:

The gwt artifact is indeed in dependency management, but when the jetty-main jar for jetty 11 is a dependency of server module it draws in jetty 9 dependencies and and also gwt-servlet leading to a no javax-servlet error. Remove gwt from the root fixes it.  Maybe this will cause problems beyond this sample.

Sent from Yahoo Mail on Android

On Sat, Feb 24, 2024 at 12:14, Thomas Broyer

<t.br...@gmail.com> wrote:

I could easily write a Main class that runs an embedded Jetty server jagwtvax(https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-servlet-context) with the configured GWT-RPC servlet and serving static resources from multiple dirs (https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-resource), but then there would still be a whole lot of questions either unanswered or with an necessarily opinionated answer:

• how to set "dev mode" for the Main class? (to add the codeserver's launcherDir to the resource bases; I would personally use a system property with the launcherDir's path and react to its presence/absence)
• how to package/deploy the static resources? as resources in the JAR? (that's what I'd do if I'd wanted my deliverable to be a single JAR) as a directory alongside the JAR? (that's what I'd do if my deliverable were a native deb/rpm/whatever package or a Docker image)
• that Main class would likely not be production-ready (should it use the QoSHandler? GzipHandler? how about the CrossOriginHandler? the ForwardedRequestCustomizer?)
• you'd probably want to refactor the Main class anyway to add command-line arguments and/or configuration files, a logging framework, possibly dependency-injection, etc.

My question is: what do you expect from such an archetype?

The initial goal was to show how to cleanly/clearly separate client/shared/server classpaths, which involves some configuration for how to run the server so it serves the codeserver's launcherDir. As soon as you go "custom" on the server, you have to handle that specific "dev mode" configuration, but then it's custom to your custom code, and necessarily becomes somewhat opinionated. This means that the archetype can't really "show you how to do things" without being opinionated, and I don't want to go that road (I specifically don't want to maintain such an opinionated thing). Feel free to create opinionated archetypes though, and I'll happily review them and help you set them up (this will bring my own opinions into the mix though)

On Friday, February 23, 2024 at 12:05:22 AM UTC+1 ma...@craig-mitchell.com wrote:

I know it's outside of its scope, but it would be great if https://github.com/tbroyer/gwt-maven-archetypes had an example of "If you want to create an executable jar with Jetty, this is how you could do it".  🙂

On Thursday 22 February 2024 at 5:30:51 am UTC+11 Tim Macpherson wrote:

I tried starting with the tbroyer archetype & to the server project I added the app engine stuff from the Google sample to build the appengine-staging dependencies directory.

Maybe all that should be in a separate project ?

Sent from Yahoo Mail on Android

On Wed, Feb 21, 2024 at 17:42, Thomas Broyer

<t.br...@gmail.com> wrote:

On Wednesday, February 21, 2024 at 3:11:54 PM UTC+1 tim_mac...@yahoo.co.uk wrote:

I've been trying this app engine sample for Java 11+ which uses a JAR packaged artifact that is installed locally:

it provides a Main class to instantiate an HTTP server to run an embedded web application WAR file.

github.com/GoogleCloudPlatform/java-docs-samples/tree/main/appengine-java11/appengine-simple-jetty-main

It has explicit jetty 11 dependencies.

The WAR project is

github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine-java11/helloworld-servlet

The WAR is run in a local server with:

mvn exec:java -Dexec.args="../helloworld-servlet/target/helloworld.war"

The problem I have is when I include GWT in the WAR project this draws in Jetty 9 & other dependencies

which get copied to the cloud-deployment dependencies directory.

This means you WAR have dependencies on gwt-user and/or gwt-dev, that you never want to deploy to a server. The WAR should have a dependency on gwt-servlet only (or requestfactory-server).

…and this is exactly what https://github.com/tbroyer/gwt-maven-archetypes were meant to solve.

--

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/c04ab91a-b898-489d-a509-6fafb9a363can%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/643460b0-a460-4961-9366-9b0e13cb7990n%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/6a89823a-d496-4a89-bb86-d739b941efdfn%40googlegroups.com.

Re: Deploy to Google App Engine (GAE)

The gwt artifact is indeed in dependency management, but when the jetty-main jar for jetty 11 is a dependency of server module it draws in jetty 9 dependencies and and also gwt-servlet leading to a no javax-servlet error. Remove gwt from the root fixes it.  Maybe this will cause problems beyond this sample.

Sent from Yahoo Mail on Android

On Sat, Feb 24, 2024 at 12:14, Thomas Broyer

<t.broyer@gmail.com> wrote:

I could easily write a Main class that runs an embedded Jetty server jagwtvax(https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-servlet-context) with the configured GWT-RPC servlet and serving static resources from multiple dirs (https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-resource), but then there would still be a whole lot of questions either unanswered or with an necessarily opinionated answer:

• how to set "dev mode" for the Main class? (to add the codeserver's launcherDir to the resource bases; I would personally use a system property with the launcherDir's path and react to its presence/absence)
• how to package/deploy the static resources? as resources in the JAR? (that's what I'd do if I'd wanted my deliverable to be a single JAR) as a directory alongside the JAR? (that's what I'd do if my deliverable were a native deb/rpm/whatever package or a Docker image)
• that Main class would likely not be production-ready (should it use the QoSHandler? GzipHandler? how about the CrossOriginHandler? the ForwardedRequestCustomizer?)
• you'd probably want to refactor the Main class anyway to add command-line arguments and/or configuration files, a logging framework, possibly dependency-injection, etc.

My question is: what do you expect from such an archetype?

The initial goal was to show how to cleanly/clearly separate client/shared/server classpaths, which involves some configuration for how to run the server so it serves the codeserver's launcherDir. As soon as you go "custom" on the server, you have to handle that specific "dev mode" configuration, but then it's custom to your custom code, and necessarily becomes somewhat opinionated. This means that the archetype can't really "show you how to do things" without being opinionated, and I don't want to go that road (I specifically don't want to maintain such an opinionated thing). Feel free to create opinionated archetypes though, and I'll happily review them and help you set them up (this will bring my own opinions into the mix though)

On Friday, February 23, 2024 at 12:05:22 AM UTC+1 ma...@craig-mitchell.com wrote:

I know it's outside of its scope, but it would be great if https://github.com/tbroyer/gwt-maven-archetypes had an example of "If you want to create an executable jar with Jetty, this is how you could do it".  🙂

On Thursday 22 February 2024 at 5:30:51 am UTC+11 Tim Macpherson wrote:

I tried starting with the tbroyer archetype & to the server project I added the app engine stuff from the Google sample to build the appengine-staging dependencies directory.

Maybe all that should be in a separate project ?

Sent from Yahoo Mail on Android

On Wed, Feb 21, 2024 at 17:42, Thomas Broyer

<t.br...@gmail.com> wrote:

On Wednesday, February 21, 2024 at 3:11:54 PM UTC+1 tim_mac...@yahoo.co.uk wrote:

I've been trying this app engine sample for Java 11+ which uses a JAR packaged artifact that is installed locally:

it provides a Main class to instantiate an HTTP server to run an embedded web application WAR file.

github.com/GoogleCloudPlatform/java-docs-samples/tree/main/appengine-java11/appengine-simple-jetty-main

It has explicit jetty 11 dependencies.

The WAR project is

github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine-java11/helloworld-servlet

The WAR is run in a local server with:

mvn exec:java -Dexec.args="../helloworld-servlet/target/helloworld.war"

The problem I have is when I include GWT in the WAR project this draws in Jetty 9 & other dependencies

which get copied to the cloud-deployment dependencies directory.

This means you WAR have dependencies on gwt-user and/or gwt-dev, that you never want to deploy to a server. The WAR should have a dependency on gwt-servlet only (or requestfactory-server).

…and this is exactly what https://github.com/tbroyer/gwt-maven-archetypes were meant to solve.

--

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/c04ab91a-b898-489d-a509-6fafb9a363can%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/643460b0-a460-4961-9366-9b0e13cb7990n%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/2121726668.345070.1708801851868%40mail.yahoo.com.