Skip to content
This repository has been archived by the owner on Sep 1, 2022. It is now read-only.
Christian W edited this page Feb 4, 2017 · 6 revisions

Gretty is a feature-rich Gradle plugin for running webapps on embedded servlet containers. So far, tds, dtswar, and d4ts are configured to run on Gretty.

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 will wait for a debugger (like IntelliJ) to be attached before they will execute.

Embedded webapps in thredds

  • :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 info for those resources is read from tds/src/test/resources/auth/tomcat-users.xml.
    • TDS expects the tds.content.root.path system property to be defined. All system properties passed to the Gradle process are propagated to the Gretty web-apps. The easiest way to do this is in gradle.properties, but you can define it on the command-line if you like.
    • Tomcat log messages and stdout/stderr output will be written to the console and tds/build/serverBaseDir_tomcat8/logs.
    • TDS log messages will be written to tds/src/test/content/thredds/logs.
  • :opendap:dtswar
    • Runs at http://localhost:8082/dts.
    • Tomcat log messages and stdout/stderr output will be written to the console and opendap/dtswar/build/serverBaseDir_tomcat8/logs.
    • DTS log messages will be written to ????. Need to create a log4j2.xml file.
  • :dap4:d4ts
    • Runs at http://localhost:8083/d4ts.
    • Tomcat log messages and stdout/stderr output will be written to the console and dap4/d4ts/build/serverBaseDir_tomcat8/logs.
    • D4TS log messages will be written to ????. Need to create a log4j2.xml file.

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.