Re: hwo to get the server working?

I stand corrected on Jetty, it seems in recent years they have included a selective subset of Java EE tech that I wasn't aware of. 

I work on large enterprise apps and DevMode is invaluable for rapidly recompiling on the front end during development. However, your point is well-made placed, that if you couldn't run DevMode on your actual production environment it would be essentially useless. 

This is the section of my pom.xml file that makes this possible. This change prevents the plugin from starting up the built-in Jetty server and instead deploys on the development server in Netbeans. To start dev mode I simply run the gwt-run goal, re-run the webapp and refresh the page. 

When I deploy, I stop the dev mode server and "Clean and Build", producing a non-development war file. This completely eliminates any compatibility issues between the test environment and the final deployment. They are both the same. The simple argument why this is safe is this: the only meaningful difference from the webapp's point of view is that the GWT compiler only compiles 1 permutation and that the front end code is sourced through the DevMode code server. Otherwise, the running app doesn't know any different. 

Annoyances occasionally arise when changing classes serialized between the client and server. The dev plugin doesn't appear to pick up on these changes with every server back end. The Netbeans Glassfish plugin was the best, only requiring me to re-run the generateAsync goal for most cases. With wilffly I often have to run a Build and Run after making such changes. But the majority of the time, the DevMode plugin correctly handles changes to the front end. 

<pre>

  <plugin>

                <groupId>org.codehaus.mojo</groupId>

                <artifactId>gwt-maven-plugin</artifactId>

                <version>${gwt.version}</version>

                <executions>

                    <execution>

                        <goals>                            

                            <goal>compile</goal>

                            <goal>generateAsync</goal>        

                        </goals>

                    </execution>

                </executions> 

                <configuration>

                    <!-- https://gwt-maven-plugin.github.io/gwt-maven-plugin/run-mojo.html -->

                    <noServer>true</noServer>

                    <runTarget>YourAppNameHere</runTarget>

                    <port>8080</port>

                    <extraJvmArgs>-Xmx4g -Xms2g</extraJvmArgs>

                </configuration>    

            </plugin>

</pre>

On Monday, August 27, 2018 at 1:16:50 PM UTC-3, Thomas Broyer wrote:

On Monday, August 27, 2018 at 2:14:24 PM UTC+2, Andrew Somerville wrote:

No problem, Mike. 

Jetty isn't a Java EE container, it's simply a servlet container. That means it runs your app with a very minimal set of built-in functionality and none of the Java EE functionality. Essentially, everything your app does, it must do itself, including authentication, database access, etc.. Your app must include the libraries for whatever type of servlet it uses. Essentially no services are made available to your app by the container. This is great if you're not even using Java EE, and are instead using some other Java web framework. Lets say you're using Spring, for example...

This is wrong. Jetty can do authentication and database access on your behalf: see https://www.eclipse.org/jetty/documentation/9.4.x/jetty-javaee.html (and more specifically https://www.eclipse.org/jetty/documentation/9.4.x/configuring-security.html and https://www.eclipse.org/jetty/documentation/9.4.x/jndi-configuration.html#configuring-datasources)

The embedded Jetty server from the DevMode however is not really configurable, and is really only meant for webapps that don't use any of those features (i.e. that you can deploy in any servlet container without any specific configuration).

Fwiw, DevMode is discouraged nowadays for most production apps (because of those limitations, and the way it loads the webapp's classes and resources, which can easily break your apps in weird and hard-to-diagnose ways). It's great for small applications  though, like the StockWatcher example, where you want to jump right into coding with GWT (or small repro cases for bugs) and don't have many (or any) third-party dependencies. That way, you can learn GWT and Java servlet development "fast", and gradually acquire skills and switch to more "industrial" tools like Maven or Gradle as build tools, external servlet containers (either run from your IDE, or by your build tool), etc.

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.