Skip to content
This repository has been archived by the owner on Sep 1, 2022. It is now read-only.

Gretty

Jump to bottom
Christian W edited this page Feb 7, 2017 · 6 revisions

Gretty is a feature-rich Gradle plugin for running web-apps on embedded servlet containers. The original author did not work on the project for much of 2016 and was unresponsive to issues and pull requests. This led me to create my own fork, which we're now using.

Update: A new version of the original Gretty was released on 2017-02-01 and the author hinted at monthly updates going forward. If he is indeed back for good, I'll try to get my fixes into mainline so that we can go back to using it.

Embedded web-apps in thredds

Currently, the :tds, :opendap:dtswar, and :dap4:d4ts web-apps can be run on Gretty.

Configuration common to all web-apps

  • They all run on Tomcat 8 – v8.0.33 as of 2017-02-06.
  • Log messages from Tomcat – as well as output written to STDOUT and STDERR – are written both to the console and to $projectDir/build/serverBaseDir_tomcat8/logs. Log messages from the web-app itself are written elsewhere, depending on the log4j2 config.
  • All system properties passed to the Gradle process (except blacklisted ones) are propagated to the Gretty web-apps, as well as to the test executors. The easiest way to set system properties is with gradle.properties, but you can define them on the command-line if you wish.
  • Test coverage data is recorded for both the client and server portions of our integration tests.

Individual web-app configuration

  • :tds
    • Runs at http://localhost:8081/thredds and https://localhost:8443/thredds.
    • The embedded Tomcat uses the self-signed certificate in tds/src/test/resources/auth/keystore to enable SSL connections. As a result, access to restricted resources (protected datasets and the admin console) is possible. Authorization credentials for those resources are read from tds/src/test/resources/auth/tomcat-users.xml.
    • TDS expects the tds.content.root.path system property to be defined.
    • Log messages from the web-app are written to tds/src/test/content/thredds/logs.
  • :opendap:dtswar
    • Runs at http://localhost:8082/dts.
    • Log messages from the web-app are written to ????. Need to create a log4j2.xml file.
  • :dap4:d4ts
    • Runs at http://localhost:8083/d4ts.
    • Log messages from the web-app are written to ????. Need to create a log4j2.xml file.

Tasks

Gretty adds a ton of tasks to the project, but the most interesting ones are named appXXX. For a full list of Gretty (and all other) tasks, you can always run ./gradlew tasks.

Starting a web-app

  • appRun: Starts web-app in-place, in interactive mode. To stop the server, hit <Any-key> <Return>. Example: ./gradlew :tds:appRun.
  • appStart: Starts web-app in-place. Similar to appRun, but can be run in the background.
  • appRestart: Restarts a web-app that was started with appStart.
  • appStop: Stops a web-app that was started with appStart.
  • appRunWar: Similar to appRun, but assembles a WAR first, rather than running the web-app in-place.
  • appStartWar: Similar to appStart, but assembles a WAR first, rather than running the web-app in-place. Stop with appStop.

Debugging

Each of the start tasks (excluding appRestart) have a corresponding task with "Debug" appended to the name. The debug tasks simply add debugging support to the base tasks. For example, :dap4:d4ts:appRunDebug adds debugging to :dap4:d4ts:appRun. They wait for a debugger (like IntelliJ) to be attached before they execute.

Integration testing

Several projects launch an embedded web-app as part of their integration tests.

  • :it
    • Starts :tds instance in :it:appBeforeIntegrationTest.
    • Runs integration tests in :it:test.
    • Stops instance in :it:appAfterIntegrationTest.
  • :opendap
    • Starts :opendap:dtswar instance in :opendap:appBeforeIntegrationTest.
    • Runs integration tests in :opendap:test.
    • Stops instance in :opendap:appAfterIntegrationTest.
  • :httpservices
    • Starts :opendap:dtswar instance in :httpservices:appBeforeIntegrationTest.
    • Runs integration tests in :httpservices:test.
    • Stops instance in :httpservices:appAfterIntegrationTest.
    • Doesn't specifically require dtswar; any valid HTTP endpoint would work.
  • :dap4:d4tests
    • Starts :dap4:d4ts instance in :dap4:d4tests:appBeforeIntegrationTest.
    • Runs integration tests in :dap4:d4tests:test.
    • Stops instance in :dap4:d4tests:appAfterIntegrationTest.

Out of convenience, we're leaving the embedded web-app running throughout the entire duration of a project's test task, even though many tests don't require a running instance. This is especially true with opendap – mosts tests don't require dtswar. In the future, we could have a separate integrationTest task for each project that would ONLY execute tests that needed a running server. The regular unit tests would continue to be run in test.

Possible workflows

Since incorporating Gretty, I've completely stopped running Tomcat from IntelliJ. Instead, for tests that require a running webapp, I'll start the server with Gradle, and then run the test from IntelliJ. This matches how servers are run on Travis an Jenkins, and eliminates weird cases where running from IntelliJ would give unexpected behavior.

Clone this wiki locally