gretty-gradle-plugin / gretty Goto Github PK

This project forked from akhikhl/gretty

Advanced gradle plugin for running web-apps on jetty and tomcat.

License: MIT License

Groovy 70.39% HTML 11.02% Java 14.41% CSS 1.74% JavaScript 1.40% Dockerfile 0.32% Shell 0.72%

gradle-plugin jetty jetty9 tomcat tomcat9 groovy-code

gretty's Introduction

Gretty is a feature-rich Gradle plugin for running web-apps on embedded servlet containers. It supports Jetty version 11, Tomcat version 10, multiple web-apps and many more. It wraps servlet container functions as convenient Gradle tasks and configuration DSL.

A complete list of Gretty features is available in feature overview.

You are looking at Gretty's master branch which is for Gretty 4. You also might want to look at the gretty-3.x one which is for Gretty 3. It is still in development and supports older (non-Jakarta) versions of Jetty and Tomcat.

Where to start

If you are new with Gretty, try getting started page.

⭐ What's new

Version 4.1.5

July 15, 2024, Gretty 4.1.5 is out and available at Gradle Plugins and Maven Central.

Make Gretty aware of Gradle Java Toolchain (thanks @mr-serjey)

Version 4.1.4

May 22, 2024, Gretty 4.1.4 is out and available at Gradle Plugins and Maven Central.

Fix jetty redeploy with custom jetty-env.xml
Support folders under "src/resources" in fastReload configuration property

Version 4.1.3

March 18, 2024, Gretty 4.1.3 is out and available at Gradle Plugins and Maven Central.

Update Tomcat and Bouncy Castle (thanks to @pranav24gupta)

Version 4.1.2

January 6, 2024, Gretty 4.1.2 is out and available at Gradle Plugins and Maven Central.

jettyStart throws exception if using jetty-env.xml #299 (special thanks to @gy-chen.

Version 4.1.1

October 25, 2023, Gretty 4.1.1 is out and available at Gradle Plugins and Maven Central.

Fix broken restart tasks after runner classpath separation
Use appropriate class loader for servermanger commands. Thanks to Shane Hird.
Upgrade Tomcat version to 10.1.5. Thanks to @pranav24gupta.

Version 4.1.0

July 12, 2023, Gretty 4.1.0 is out and available at Gradle Plugins and Maven Central.

Drops Gradle 6 support
Enables stricter plugin validation
Adds Gradle 8 integration test build

August 24, 2022, Gretty 4.0.3 is out and available at Gradle Plugins and Maven Central.

Changes in this version:
Replace internal Gradle API usage with public API #263
Tomcat 10.0.22
Jetty 11.0.11

June 2, 2022, Gretty 4.0.2 is out and available at Gradle Plugins and Maven Central.

Changes in this version:
Use Tomcat 10.0.21
Use Jetty 11.0.9
Use Gradle 7.4.2 for testing Gretty
Added exclusion patterns for commons-cli and commons-io classes to FilteringClassLoader #258 Adding the patterns fixes a bug which gave preference to the commons-cli and commons-io versions that Gretty uses, rather than using the JARs bundled with the webapp (which is the correct behavior).
Upgrade to Logback 1.3.0-alpha14
Remove Groovy-based logging configuration in response to Log4Shell #249

February 25, 2022, Gretty 4.0.1 is out and available at Gradle Plugins and Maven Central.

Changes in this version:
Fix inability to build a product due to missing Groovy dependencies (#238).
Version upgrades to mitigate some CVEs (#252). Thanks to @dutta1kartik3.

September 1, 2021, Gretty 4.0.0 is out and available at Gradle Plugins and Maven Central.

Changes in this version:
Gretty requires JDK11+.
Gretty supports only Tomcat 10 and Jetty 11 (Jakarta versions of the containers). All thanks goes to @f4lco.

July 27, 2021, Gretty 3.0.6 is out and available at Gradle Plugins and Maven Central.

Changes in this version:
JDK 16 support

June 28, 2021, Gretty 3.0.5 is out and available at Gradle Plugins and Maven Central.

Please note that Gretty 3.0.5 is the first one not using JCenter but rather Maven Central. Be sure to change your jcenter() to mavenCentral() in your Gradle files.

Changes in this version:
Added some release details for Maven Central.
Added uploadArchives for upload to Maven Central.
Restored simple GPG signing in prep for replacement of Bintray with Maven Central.
Build with Gradle 6.x in Jitpack
Use a fixed Gecko driver version
Use Gradle 6.9 for the "global" build
Fix the gradle clean task
Update some packages
Gradle defines version as an object so we need to make sure we are doing explicit to String conversion
Revert "Purge identical builds by removing 'pull_request' trigger from GH actions"
Replace deprecated JavaExec.main usage with JavaExec.mainClass property
Merge pull request #218 from brandonramirez/loopback_address_bind
Update Gradle wrapper to 7.0-rc-2
Remove Gradle wrapper task definitions
Add Java 16 and build only against currently supported versions of Java
Update actions/setup-java
Purge identical builds by removing 'pull_request' trigger from GH actions
Run tests on JUnit 5 on Gradle 7
Upgrade dependencies in Gradle 7 build
Replace jcenter repository with Maven Central
Rely on Groovy version shipped with Gradle
Add Gradle 7 build job
Explicitly bind to loopback address rather than local address to fix a BindException.
Use the springBoot option when it is not null (#213)
Avoid calling afterEvaluate on already evaluated project
Remove unused import
Improve the code structure
Improve the dependency resolving logic
Update Gradle's version in CI
[skip ci] Remove mentions of Tomcat 10 in the changes.md file too
Remove publishing to Bintray on push
Fixed 'multiple plugins are using the same ID' error in publishPlugins. (#211)

March 30, 2021, Gretty 3.0.4 is out and available at Gradle Plugins and Bintray.

Special thanks to all contributors to this release, and especially Boris Petrov, Falco Duersch and Stefan Wolf for multiple contributions.

Changes in this version:
Gradle 7 support
Fix handling of httpsIdleTimeout in Tomcat (#144)
Fix behavior of maxPostSize in Tomcat (#144)
Guard remaining calls to Connector#setProperty with assertions (#144)
Removed calls to Jetty 9.4 deprecated method (soLingerTime) (#171)
Update Gradle's testing version to 6.6.1 and geckodriver to 0.27.0
Fix issue #104 - Bug: HotReload Exception with Composite
Correctly populate the writer field in ServerStartEventImpl
Fix issue #104 - Bug: HotReload Exception with Composite
Ability to add additinal files to product build.
Update ASM
Update default Tomcat versions
Also run the full test suite on JDK 15
Use a specific Gradle version for all Travis tasks
Update Gradle's version to 6.8.3
Non-blocking context initialization. Fix "redeploy" cleanup.
Update Groovy
Migrate from Travis CI to GitHub actions
Annotate ServerConfig to fix Gradle deprecation warnings (#195)
Annotate WebAppConfig, StartBaseTask, AppAfterIntegrationTestTask, AppBeforeIntegrationTestTask, AppServiceTask, FarmStartTask, AppRedeployTask, FarmAfterIntegrationTestTask, FarmBeforeIntegrationTestTask, FarmIntegrationTestTask, JacocoHelper
Rename annotated interfaces for tasks
Fix a bunch of Gradle deprecation warnings
Use api for libs/gretty dependencies
Lazily add source and classes dirs
Use Gradle's Task Configuration Avoidance APIs in a few places
Add validation task to gretty plugin
Use java-gradle-plugin for generating the plugin properties
Upgrade to newest version of the publishing plugin
Enable stricter validation for validatePlugins
Replace deprecated task name in jacocoInstantiateTasks itest
Move common.gradle to a precompiled script plugin
Use different configuration for library and plugin projects
Move some more things out of afterEvaluate
Fix source- and targetCompatibility versions
Use publication for uploading to bintray
Remove the maven plugin
Use new API for publishing javadoc and sources
Add a missing bintrayUserOrg property
Fix using the wrong configuration for runner-projects
Use task configuration avoidance (easy instances) #141
Add some dependencies needed by Groovy 3
Spring support: avoid classloading of webapp classes at configuration time

May 7, 2020, Gretty 3.0.3 is out and available at Gradle Plugins and Bintray.

Changes in this version:
Updated ASM to 8.0.1.
Fixed excess logging output and set initial log level (#150).
Removed deprecated check for already in-use ports (#147).
Added support for Gradle 5.6 debugging API.
Fixed incorrect serialization of the initParameters in productBuild.
Updated Tomcat 9 version and TC9 servlet API version.
Set javaExec debug options properly.
Updated Gradle 6 testing to use Gradle 6.3.

See complete list of changes for more information.

March 29, 2020, Gretty 3.0.2 is out and available at Gradle Plugins and Bintray.

This release brings Java 14 support, deprecation fixes for Gradle 6.x and bug-fixes.

https://bintray.com/javabrett/maven/org.gretty/view

December 2, 2019, Gretty 3.0.1 is out and available at Gradle Plugins and Bintray.

This release contains further fixes for Gradle 6.0 support.

December 1, 2019, Gretty 3.0.0 is out and available at Gradle Plugins and Bintray.

This release introduces Gradle 6.0 support and retires support for JDK7, Gradle versions <5.0 and Tomcat 7.x and 8.0.x.

See complete list of changes for more information.

December 5, 2018, Gretty 2.3.1 is out and available at Gradle Plugins and Bintray.

This maintenance release addresses some issues found in Gretty 2.3.0. See complete list of changes for more information.

November 28, 2018, Gretty 2.3.0 is out and available at Gradle Plugins and Bintray.

This release adds support for Gradle 5.0, which was released this week! Please raise an issue if you find any issues running Gretty 2.3+ with Gradle 5.0.

See also: complete list of changes for more information.

May 21, 2018, Gretty(.org) 2.2.0 is out and immediately available at Gradle Plugins and Bintray.

Changes in this version:
Bumped default Tomcat 9 version to 9.0.6 (was 9.0.5).
Support added for Tomcat 8.5 and Tomcat support refactoring (thanks Boris Petrov). Tomcat 8.5 replaces deprecated Tomcat 8.0.
Bumped Spring Boot version to 1.5.9 (was 1.5.4).
Bumped versions of asm (6.1.1, was 6.0), Groovy (2.4.15, was 2.4.13) and Spring (4.3.16, was 4.3.9) (thanks Henrik Brautaset Aronsen).
Fixed incompatibility with java-library plugin (thanks Ollie Freeman).
Dev: various build and test improvements.

See also: complete list of changes for more information.

Documentation

You can learn about all Gretty features in online documentation.

System requirements

Gretty requires JDK11+ and Gradle 6.0 or newer.

Since version 2.0.0 Gretty no longer supports JDK6.
Since version 3.0.0 Gretty no longer supports JDK7, Gradle <5.0, Tomcat 7.x or Tomcat 8.0.x.
Since version 4.0.0 Gretty supports only JDK 11+, Gradle 6.0+, Tomcat 10.x and Jetty 11.x

Availability

Gretty is an open-source project and is freely available in sources as well as in compiled form.

Releases of Gretty (gretty.org fork) from 2.1.0 onwards are available at Bintray. Old releases of Gretty up to and including version 2.0.0 are available at Bintray.

Copyright and License

All versions, present and past, of Gretty are licensed under MIT license.

gretty's People

Contributors

$octylfractal avatar$

Stargazers

Watchers

gretty's Issues

master build fails when --refresh-dependencies

./gradlew build --refresh-dependencies
or
./gradlew clean build --refresh-dependencies

... fails with:

* What went wrong:
Could not resolve all files for configuration ':libs:gretty-springboot:compileClasspath'.
> Could not resolve org.springframework.boot:spring-boot-starter-web:1.5.4.RELEASE.
  Required by:
      project :libs:gretty-springboot
   > Could not resolve org.springframework.boot:spring-boot-starter-web:1.5.4.RELEASE.
      > Could not parse POM https://jcenter.bintray.com/org/springframework/boot/spring-boot-starter-web/1.5.4.RELEASE/spring-boot-starter-web-1.5.4.RELEASE.pom
         > Could not resolve org.springframework.boot:spring-boot-starters:1.5.4.RELEASE.
            > Could not resolve org.springframework.boot:spring-boot-starters:1.5.4.RELEASE.
               > Could not parse POM https://jcenter.bintray.com/org/springframework/boot/spring-boot-starters/1.5.4.RELEASE/spring-boot-starters-1.5.4.RELEASE.pom
                  > Could not find org.springframework.boot:spring-boot-parent:1.5.4.RELEASE.
                    Searched in the following locations:
                       <redacted>
                        https://jcenter.bintray.com/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.pom
                        https://jcenter.bintray.com/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.jar
                        https://oss.jfrog.org/artifactory/repo/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.pom
                        https://oss.jfrog.org/artifactory/repo/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.jar
                        https://oss.jfrog.org/artifactory/repo/org.springframework.boot/spring-boot-parent/ivy-1.5.4.RELEASE.xml
                        https://oss.jfrog.org/artifactory/repo/org.springframework.boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.jar

Looking at spring-boot on jcenter: https://jcenter.bintray.com/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/ it looks like there might have been a purge of old versions there or something, only the .asc signatures remain for versions older than 1.5.9.

Good encouragement to upgrade, but might need to add mavenCentral() in for now to fix this.

I gather this must have happened somewhat recently or builds on new environments would have been failing.

Fragile integration test websocket:

Intermittent test-failure - seems like it can occur at any time or container. Fails with geb.error.NoNewWindowException at RequestResponseIT.groovy:38.

> Task :gretty-integrationTests:websocket:compileJava UP-TO-DATE
> Task :gretty-integrationTests:websocket:compileGroovy NO-SOURCE
> Task :gretty-integrationTests:websocket:processResources UP-TO-DATE
> Task :gretty-integrationTests:websocket:classes UP-TO-DATE
> Task :gretty-integrationTests:websocket:compileTestJava NO-SOURCE
> Task :gretty-integrationTests:websocket:compileTestGroovy NO-SOURCE
> Task :gretty-integrationTests:websocket:processTestResources NO-SOURCE
> Task :gretty-integrationTests:websocket:testClasses UP-TO-DATE
> Task :gretty-integrationTests:websocket:test NO-SOURCE
> Task :gretty-integrationTests:websocket:prepareInplaceWebAppFolder
> Task :gretty-integrationTests:websocket:createInplaceWebAppFolder
> Task :gretty-integrationTests:websocket:prepareInplaceWebAppClasses UP-TO-DATE
> Task :gretty-integrationTests:websocket:prepareInplaceWebApp
May 17, 2018 3:51:21 AM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-nio-8080"]
May 17, 2018 3:51:21 AM org.apache.tomcat.util.net.NioSelectorPool getSharedSelector
INFO: Using a shared selector for servlet write/read
May 17, 2018 3:51:22 AM org.apache.catalina.core.StandardService startInternal
INFO: Starting service [Tomcat]
May 17, 2018 3:51:22 AM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/8.5.30
May 17, 2018 3:51:22 AM org.apache.catalina.startup.ContextConfig getDefaultWebXmlFragment
INFO: No global web.xml found
May 17, 2018 3:51:22 AM org.apache.jasper.servlet.TldScanner scanJars
INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
May 17, 2018 3:51:23 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-nio-8080"]
03:51:23 INFO  Tomcat 8.5.30 started and listening on port 8080
03:51:23 INFO  websocket runs at:
03:51:23 INFO    http://localhost:8080/websocket
> Task :gretty-integrationTests:websocket:beforeIntegrationTest_tomcat85
> Task :gretty-integrationTests:websocket:compileIntegrationTestJava NO-SOURCE
> Task :gretty-integrationTests:websocket:compileIntegrationTestGroovy
> Task :gretty-integrationTests:websocket:processIntegrationTestResources NO-SOURCE
> Task :gretty-integrationTests:websocket:integrationTestClasses
Socket Connected: org.apache.tomcat.websocket.WsSession@44e6672d
Socket Closed: CloseReason: code [1001], reason [null]
Socket Connected: org.apache.tomcat.websocket.WsSession@6fd87ef7
Socket Connected: org.apache.tomcat.websocket.WsSession@6ab0ea0b
> Task :gretty-integrationTests:websocket:integrationTest_tomcat85
org.akhikhl.examples.gretty.websocket.RequestResponseIT > should send chat messages FAILED
    geb.error.NoNewWindowException at RequestResponseIT.groovy:38
Socket Closed: CloseReason: code [1001], reason [null]
Socket Closed: CloseReason: code [1001], reason [null]
> Task :gretty-integrationTests:websocket:integrationTest_tomcat85 FAILED
2 tests completed, 1 failed
May 17, 2018 3:51:31 AM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["http-nio-8080"]
May 17, 2018 3:51:31 AM org.apache.catalina.core.StandardService stopInternal
INFO: Stopping service [Tomcat]
May 17, 2018 3:51:31 AM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["http-nio-8080"]
May 17, 2018 3:51:31 AM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["http-nio-8080"]
> Task :gretty-integrationTests:websocket:afterIntegrationTest_tomcat85
Server stopped.

Restarting the single failed test-group in Travis and it passes with no other changes.

Hard to say whether this is:

A real intermittent bug
Something Travis-related
Selenium / WebDriver / Gecko related
A Geb problem

Gretty plugin resolves Gradle configurations in a user-managed thread

I wanted to provide a heads up around a coming Gradle deprecation that will affect the Gretty plugin. With Gradle 5.0, we will output a deprecation warning whenever a configuration is resolved outside of a Gradle-managed thread. The reason for this is because configuration resolution is an event that modifies the Gradle project model and if multiple threads are changing the model at the same time, this can produce inconsistent results. In 5.0, we are introducing some safety for this in Gradle-managed threads, but we can't guarantee safety in user-managed threads. The gretty plugin is resolving a configuration here that is being executed in a user-managed thread started here and produces a deprecation warning when run with Gradle 5.0.

To avoid this warning, I believe there's a fairly simple fix. Instead of resolving the configuration inside of the spawned thread, the plugin should resolve the configuration in the task thread (which is Gradle-managed) immediately before spawning the child thread. This will allow the configuration to be resolved safely under Gradle's control and then only the resolution results will be used in the user-managed thread.

From a reproduction/testing perspective, the first Gradle 5.0 RC is due out next week, but in the meantime, nightly builds are available here.

I hope that makes sense - if it doesn't, I'm happy to answer any questions or help with finding an alternate solution if the one proposed is not workable for some reason.

JDK9 Jasper/JSPC for Jetty 9.4.8.v20171121 is not fully JDK9-ready

I'm seeing some JSPC/Jasper JSP-compilation issues with JDK9 running testAll. Not sure yet if related, but I notice via jetty/jetty.project#2079 that Jetty 9.4.8.v20171121 running Jasper 8.5.23 is not 100% JDK9-ready. The first such Jasper release is 8.5.24, which is on the Jetty 9.4.x branch presumably to be released as 9.4.9. Snapshots are available.

We will need to determine whether its worth pulling in a Jetty 9.4.9 snapshot to see if it addresses JDK9 test-issues in order to continue, or wait for 9.4.9 release.

Respond to JEP 320: Removal of deprecated Java EE and CORBA Modules (jdk11)

Ref: http://openjdk.java.net/jeps/320 . This was discussing in #40 when JDK_JAVA_OPTIONS="--add-modules=java.xml.bind" was added to JDK9 builds as a quick-fix.

Proper fix is to add external dependencies.

Clean up TomcatServerConfigurer in gretty-runner-tomcat9

TomcatServerConfigurer in gretty-runner-tomcat9 basically overwrites TomcatServerConfigurer from gretty-runner-tomcat on the classpath, with two lines of change.

Try to that more configurable instead of copypasting code.

Ref. #26 (comment)

Work out how to run testAll on Travis

From what I can see, testAll currently won't run on Travis, despite the efforts in-place to run xvfb for Selenium/WebDriver to run the tests. Per https://travis-ci.org/gretty-gradle-plugin/gretty/jobs/349197672 currently this fails with:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
09:17:25 INFO  Jetty 7.6.16.v20140903 started and listening on port 8080
09:17:25 INFO  extraResourceBases runs at:
09:17:25 INFO    http://localhost:8080/extraResourceBases
...
:gretty-integrationTests:extraResourceBases:integrationTest_jetty7
org.akhikhl.examples.gretty.hellogretty.ExtraResourceBasesSpec > should get expected static page FAILED
    geb.driver.DriverCreationException at ExtraResourceBasesSpec.groovy:23
        Caused by: org.openqa.selenium.WebDriverException at ExtraResourceBasesSpec.groovy:23
            Caused by: org.apache.http.conn.HttpHostConnectException at ExtraResourceBasesSpec.groovy:23
                Caused by: java.net.ConnectException at ExtraResourceBasesSpec.groovy:23
    geb.driver.DriverCreationException
        Caused by: org.openqa.selenium.WebDriverException
            Caused by: org.apache.http.conn.HttpHostConnectException
                Caused by: java.net.ConnectException
    geb.driver.DriverCreationException
        Caused by: org.openqa.selenium.WebDriverException
            Caused by: org.apache.http.conn.HttpHostConnectException
                Caused by: java.net.ConnectException

So either the port is not up, or Selenium is trying to connect to something other than localhost:8080, or there's some proxy-config problem. What am I missing?

Glancing at the code it looks like the test-framework queries the running server to gather host/port details for the test client - maybe something goes wrong there.

I was a little surprised to find no integration tests running on Travis at all. It does do an NxM run across all container/versions, so took ~30 minutes on my machine, so might be better as a nightly run. But otherwise this is a manual task on developer machines.

Retire Gradle 1.x support

This is hopefully mostly a small doc task. Need to decide, based on the release version and branch whether we will deprecate Gradle 2.x (last release v2.14.1 Jul 18, 2016, v3.0 Aug 15, 2016).

/cc #46 .

Exception running application with gretty

After setting up gretty with a minimal conifguration I tried to run it with the following command:

$webproject> gradle --refresh-dependencies clean appStartWar -Pproperty=value -Pproperty2=value2

After the various build tasks I have in my project, the ones of gretty start running and get the following exception:

org.akhikhl.gretty.JettyScannerManager$1@66196cfd failed on '[....]
org.gradle.tooling.GradleConnectionException: Could not execute build using Gradle installation 'C:\opt\gradle'.
        at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:55)
        at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29)
        at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:41)
        at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerAction
Executor$1$1.run(DefaultAsyncConsumerActionExecutor.java:57)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.lang.Thread.run(Thread.java:745)
        at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
        at org.gradle.tooling.internal.consumer.DefaultBuildLauncher.run(DefaultBuildLauncher.java:77)
        at org.gradle.tooling.BuildLauncher$run.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
        at org.akhikhl.gretty.scanner.BaseScannerManager$_scanFilesChanged_closure6.doCall(BaseScannerManager.groovy:227)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
        at groovy.lang.Closure.call(Closure.java:414)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.callClosureForMapEntry(DefaultGroovyMethods.java:5276)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2117)
        at org.codehaus.groovy.runtime.dgm$164.invoke(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.akhikhl.gretty.scanner.BaseScannerManager.scanFilesChanged(BaseScannerManager.groovy:220)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:82)
        at org.akhikhl.gretty.JettyScannerManager.this$dist$invoke$2(JettyScannerManager.groovy)
        at org.akhikhl.gretty.JettyScannerManager$1.methodMissing(JettyScannerManager.groovy)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:939)
        at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1262)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:69)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166)
        at org.akhikhl.gretty.JettyScannerManager$1.filesChanged(JettyScannerManager.groovy:33)
        at org.eclipse.jetty.util.Scanner.reportBulkChanges(Scanner.java:691)
        at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:551)
        at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
        at org.eclipse.jetty.util.Scanner$1.run(Scanner.java:353)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        at java.util.TimerThread.run(Timer.java:505)
Caused by: org.gradle.api.GradleException: Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/4.4/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=4g; support was removed in 8.0
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]

        at org.gradle.launcher.daemon.bootstrap.DaemonGreeter.parseDaemonOutput(DaemonGreeter.java:34)
        at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startProcess(DefaultDaemonStarter.java:152)
        at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startDaemon(DefaultDaemonStarter.java:135)
        at org.gradle.launcher.daemon.client.DefaultDaemonConnector.doStartDaemon(DefaultDaemonConnector.java:210)
        at org.gradle.launcher.daemon.client.DefaultDaemonConnector.startDaemon(DefaultDaemonConnector.java:204)
        at org.gradle.launcher.daemon.client.DefaultDaemonConnector.connect(DefaultDaemonConnector.java:128)
        at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:138)
        at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:92)
        at org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:60)
        at org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:41)
        at org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:60)
        at org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:34)
        at org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:156)
        at org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:122)
        at org.gradle.tooling.internal.provider.DefaultConnection.getModel(DefaultConnection.java:204)
        at org.gradle.tooling.internal.consumer.connection.CancellableModelBuilderBackedModelProducer.produceModel(CancellableModelBuilderBackedModelProducer.java:53)
        at org.gradle.tooling.internal.consumer.connection.PluginClasspathInjectionSupportedCheckModelProducer.produceModel(PluginClasspathInjectionSupportedCheckModelProducer.java:41)
        at org.gradle.tooling.internal.consumer.connection.AbstractConsumerConnection.run(AbstractConsumerConnection.java:58)
        at org.gradle.tooling.internal.consumer.connection.ParameterValidatingConsumerConnection.run(ParameterValidatingConsumerConnection.java:46)
        at org.gradle.tooling.internal.consumer.DefaultBuildLauncher$1.run(DefaultBuildLauncher.java:89)
        at org.gradle.tooling.internal.consumer.DefaultBuildLauncher$1.run(DefaultBuildLauncher.java:83)
        at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:84)
        at org.gradle.tooling.internal.consumer.connection.CancellableConsumerActionExecutor.run(CancellableConsumerActionExecutor.java:45)
        at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:58)
        at org.gradle.tooling.internal.consumer.connection.RethrowingErrorsConsumerActionExecutor.run(RethrowingErrorsConsumerActionExecutor.java:38)
        at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:55)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.lang.Thread.run(Thread.java:745)Error: Could not find or load main class org.akhikhl.gretty.Runner
Exception in thread "Thread-32" org.gradle.process.internal.ExecException: Process 'command 'C:\Program Files\Java\jdk1.8.0_121\bin\java.exe'' finished with non-zero exit value 1
        at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:382)
        at org.gradle.process.internal.DefaultJavaExecAction.execute(DefaultJavaExecAction.java:31)
        at org.gradle.api.internal.file.DefaultFileOperations.javaexec(DefaultFileOperations.java:182)
        at org.gradle.api.internal.project.DefaultProject.javaexec(DefaultProject.java:1076)
        at org.gradle.api.internal.project.DefaultProject.javaexec(DefaultProject.java:1071)
        at org.gradle.api.Project$javaexec$8.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.akhikhl.gretty.DefaultLauncher.javaExec(DefaultLauncher.groovy:89)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:384)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:69)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166)
        at org.akhikhl.gretty.LauncherBase$_launchThread_closure4.doCall(LauncherBase.groovy:256)
        at org.akhikhl.gretty.LauncherBase$_launchThread_closure4.doCall(LauncherBase.groovy)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
        at groovy.lang.Closure.call(Closure.java:414)
        at groovy.lang.Closure.call(Closure.java:408)
        at groovy.lang.Closure.run(Closure.java:495)

The problem I see here is this line:
Error: Could not find or load main class org.akhikhl.gretty.Runner

My configuration

...
apply plugin: 'war'
apply from: 'https://raw.github.com/gretty-gradle-plugin/gretty/master/pluginScripts/gretty.plugin'
...

gretty {
	httpPort = 9091
}

Has anyone had this issue and how can it be solved?

Upgrade Tomcat 8.0.x support to 8.5.x

Tomcat 8.0 was end-of-lifed and Tomcat 8.5 is a mostly drop-in replacement. We should check whether the build and default Tomcat 8 can be easily switched to the Tomcat 8.5.x stream.

Task appRun doesn't deploy class files to inplaceWebapp

I'm just tinkering around with Java, groovy, gradle and jetty/gretty.

My little sample app has one java class, one groovy class and an index.xhtml (JSF).

If I run the appRun task, my app doesn't work, because gretty just copies the configuration files and index.xhtml to the inplaceWebApp directory:

build/inplaceWebapp/
build/inplaceWebapp/index.xhtml
build/inplaceWebapp/WEB-INF
build/inplaceWebapp/WEB-INF/web.xml
build/inplaceWebapp/WEB-INF/faces-config.xml
build/inplaceWebapp/META-INF

I couldn't help myself other than adding a sync task:

task sync(type: Sync) {
from "$sourceSets.main.java.outputDir"
from "$sourceSets.main.groovy.outputDir"
into "${project.buildDir}/inplaceWebapp/WEB-INF/classes"
}

project.afterEvaluate {
appRun.dependsOn sync
}

Now the inplaceWebapp folder also contains the class files:

build/inplaceWebapp/
build/inplaceWebapp/index.xhtml
build/inplaceWebapp/WEB-INF
build/inplaceWebapp/WEB-INF/web.xml
build/inplaceWebapp/WEB-INF/classes
build/inplaceWebapp/WEB-INF/classes/de
build/inplaceWebapp/WEB-INF/classes/de/dumischbaenger
build/inplaceWebapp/WEB-INF/classes/de/dumischbaenger/GroovyUserView.class
build/inplaceWebapp/WEB-INF/classes/de/dumischbaenger/UserView.class
build/inplaceWebapp/WEB-INF/faces-config.xml
build/inplaceWebapp/META-INF

I guess this job should be done by gretty, shouldn't it?

implementation dependency not included cause ClassNotFoundException

Hi,
In recent versions of gradle, compile dependency is deprecated and replaced by implementation dependency. I find this is not considered by gretty and hence not have implementation dependencies included when doing appRun and cause ClassNotFoundException.

Not Working With Java 9 and Overriding Jetty 9.4

Its not working with Java 9 if we oveide version of Jetty 9.4 to latest in gradle.properties
with property:
jetty94Version = 9.4.13.v20181111

Deprecate JDK7 support

For Gretty 3.x it is proposed to deprecate JDK7 support. See also #43 .

Farm does not properly handle duplicate webapps

The following spec will bring up only the last specified server:

farms {
  farm 'DoubleDeploy,' {
    webapp ':server', contextPath: "/control"
    webapp ':server', contextPath: "/test"
  }
}

For now, it is possible to specify 2 separate servlet containers, but its messy and results in 2 servlet containers:

farms {
    farm 'Control', {
        webapp ':karmata-server', contextPath: "/"
        httpPort = 8000
        servicePort = 8002
        statusPort = 8003
        portPropertiesFileName = "control_ports.properties"
    }
    farm 'Test', {
        webapp ':karmata-server', contextPath: "/"
        httpPort = 8004
        servicePort = 8006
        statusPort = 8007
        portPropertiesFileName = "test_ports.properties"
    }
}

Our goal is to support end-to-end visual difference testing of the webapp's javascript frontend. This approach requires separate sandboxed endpoints for the control and test sides.

JDK9 Tomcat8 testAll java.lang.NoSuchFieldException: loaderRef

Saw this running testAll with JDK9:

Mar. 06, 2018 12:16:42 PM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["http-nio-8080"]
Mar. 06, 2018 12:16:42 PM org.apache.catalina.core.StandardService stopInternal
INFO: Stopping service Tomcat
Mar. 06, 2018 12:16:42 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesResourceBundles
WARNING: Failed to clear ResourceBundle references for web application [ROOT]
java.lang.NoSuchFieldException: loaderRef
        at java.base/java.lang.Class.getDeclaredField(Class.java:2368)
        at org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesResourceBundles(WebappClassLoaderBase.java:2402)
        at org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1617)
        at org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1537)
        at org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:446)
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:221)
        at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5572)
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:221)
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1424)
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1413)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.base/java.lang.Thread.run(Thread.java:844)

Note that this seems to be a clean-up exception only, and does not impact nor fail the test.

Release 2.2.0

Placeholder issue for Release 2.2.0 discussion and finalisation/release.

Done

#37 (implementation-scope dependencies)
#30 (Tomcat 8.5)

Defer to 3.x, possible backport

#40 Upgrade to Groovy 2.5 GA when final

Release 3.0.0

Issue to collect release 3.0.0 tasks and commentary.

TODO

See https://github.com/gretty-gradle-plugin/gretty/projects/1
Deprecate JDK7 #49
Deprecate Gradle 1.x support #47
Deprecate Jettty 7+8 #51
Spring Boot 2 #43
Groovy 2.x #40

Could not get unknown property 'mainClass' for object of type org.springframework.boot.gradle.dsl.SpringBootExtension.

see： rssdev10@583b230#diff-dce4984e08a1962cae1a388a6305a75a

gretty version: 2.2.0
spring boot version : 2.0.2.RELEASE

Missing configuration dependency resolution

It looks like the gretty tasks (like jettyRun, appRun and so on) do not actually resolve the gretty configuration though they rely on it. In my case, I added a dependency to a test-configuration artifact in a sibling module like this:

gretty project(path: ':my-library', configuration: 'testConfig')

During jetty startup, I then got an error telling me that the corresponding jar file was missing on the file system. Adding this snippet solved the problem for jettyRun:

project.afterEvaluate {
    jettyRun.dependsOn configurations.gretty
}

I guess the gretty tasks should declare this dependency themselves out-of-the-box.

ArtifactResolveException: Could not resolve all files for configuration 'grettyRunnerTomcat7'

After upgrading to 2.2.0 I get this error. The documentation says that Tomcat 7 is still supported, so I'm not sure why it's not being found.

In order to get it to work, I had to add jcenter() to my project repository section (as opposed to the build script repository)

I'd prefer to keep jcenter in the buildscript section only if possible.

Tomcat9 testTomcatServerConfig fails with ReadOnlyPropertyException: Cannot set readonly property: service for class: org.apache.catalina.startup.Tomcat

Mar 12, 2018 12:42:05 PM org.apache.catalina.startup.Catalina addClusterRuleSet
INFO: Cluster RuleSet not found due to [java.lang.ClassNotFoundException: org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
Mar 12, 2018 12:42:05 PM org.apache.catalina.startup.Catalina addClusterRuleSet
INFO: Cluster RuleSet not found due to [java.lang.ClassNotFoundException: org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
Exception in thread "main" groovy.lang.ReadOnlyPropertyException: Cannot set readonly property: service for class: org.apache.catalina.startup.Tomcat
        at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:2744)
        at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:3770)
        at org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:201)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:484)
        at org.akhikhl.gretty.TomcatServerConfigurer.createAndConfigureServer(TomcatServerConfigurer.groovy:72)
        at org.akhikhl.gretty.TomcatServerConfigurer.createAndConfigureServer(TomcatServerConfigurer.groovy)
        at org.akhikhl.gretty.TomcatServerConfigurer$createAndConfigureServer.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
        at org.akhikhl.gretty.TomcatServerManager.startServer(TomcatServerManager.groovy:45)
        at org.akhikhl.gretty.ServerManager$startServer$0.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.akhikhl.gretty.Runner.run(Runner.groovy:117)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:210)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:71)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
        at org.akhikhl.gretty.Runner.main(Runner.groovy:44)

testAll run (JDK8) then blocks at:

> :testAllIntegrationTests
> :gretty-integrationTests:testTomcatServerConfig:beforeIntegrationTest_tomcat9

Relevant code: https://github.com/gretty-gradle-plugin/gretty/blob/master/libs/gretty-runner-tomcat/src/main/groovy/org/akhikhl/gretty/TomcatServerConfigurer.groovy#L72

    Tomcat tomcat = new Tomcat()
...
      tomcat.service = service

@boris-petrov PTAL if you get a chance.

Remove Jetty 7+8 support

Proposed for 3.x (#50). See also #43 .

Unrelated module's transitive dependency resolution affected in composite build

I have some weird behavior. I will also try to get a minimal project example together for reproducibility when I have time.

Context

gretty 2.2.0
Gradle 4.10-rc-3 with kotlin-dsl
using Intellij IDEA to import the Gradle project.
I'm trying to use gretty with the js module that is a kotlin multiplatform module. It is part of an app build included (a subproject of a multiproject included build) in a composite gradle project with the library it relies on.

Issue - Unrelated module composite dependency resolution affected

If I sync the project in the IDE (IDE is running task :wrapper) without the plugin applied, everything is normal (confirmed no dependency resolution issues lurking in debug output).

If I apply the gretty plugin to the js child project, gradle runs through everything fine, and then the IDE reports that it cannot resolve two modules that are transitive dependencies of the affected module. It also tries to change the dependencies to runtime dependencies (I'm not seeing any of this behavior on the actual js module where the gretty plugin was applied). The following facts I think are interesting with these results.

the affected module is a fellow child project of the js module (aka they both share the same multiproject root).
the affected module is the jvm project, and really shouldn't be touched at all (does this mean this is a side effect of some other bug? Possibly).
the transitive dependencies were supposed to be (and confirmed in debug output that they were) already substituted via composite build substitution (where gradle identifies modules and substitutes them for project dependencies).
the affected transitive dependencies, in the same sync, are also transitive dependencies of the js subproject, and resolved a-okay there.
I compared the output in the .idea/libraries directory of the run without gretty and the run with gretty applied in this way. Normally, the IDE will not generate library .xmls for local modules in a Composite build. With the gretty plugin applied, I can confirm that the IDE is the culprit for not being able to resolve, as it generates two .xmls for these particular transitive dependencies.

getFreeRandomPort() should work for httpsPort

Doing

gretty {
    httpPort = getRandomFreePort()
}

is super-convenient for integration tests.

Is there any reason that it is not supported for HTTPS?

For example, in TomcatServerConfigurer, it checks the httpPort property, but not the httpsPort property.

JDK10 testing/support

JDK10 has been released. This is a skeleton issue to track testing and support for Gretty and various containers which will support JDK10 (Jetty 9.4.9 is released and claims support).

Note that Travis support is pending.

Parallelize integrationTests/testAll by target container, avoid Travis 50-minute timeout

This is a follow-up to #35 . Now that we have a few extra container-branches, the integration-tests take a long time to run. We should provide parameters and/or tasks (if they aren't already there, should check) so that integration tests can be run separately/in-parallel by-container (jetty94, tomcat8 etc.).

Currently the testAll task collects all NxM combinations of test/container. The current execution time on Travis is between 40-50 minutes and has already timed-out once. Let's run these in-parallel which is the preferred Travis approach.

Some integrationTests run with the default (now Jetty 9.4.x) container

There's hopefully some easy explanation for this - I've been meaning to chase it down for a while but haven't found the time, so hopefully someone with a few spare cycles can take a look. You'll probably want a fork and active in Travis.

Since the integration tests were matrixed-out by jdk/container in Travis, I've noticed this - regardless of the container run for the bulk of the tests, on more than a few occasions the default (Jetty) container gets started. This used to be Jetty 9.2.x but is now Jetty 9.4.x (9.4.10 at the time of raising this issue).

Here's some Travis build links for an oraclejdk8:tomcat9 build, showing each occasion when Jetty is started:

Jetty 9.4.10 is started 6 times. Tomcat 9.0.7 is started 21 times.

Override, not merge, the default welcome-file-list of Tomcat

Usually (with standalone Tomcat) welcome-file-list of the application overriders welcome-file-list from TOMCAT_HOME/conf/web.xml.
With Gretty it happens so that in the end we have a union of default welcome files (index.html etc. inserted by DefaultWebXmlListener) and the application welcome files.

Those default welcome files are unwanted in our case and it would be nice to get rid of them.

I managed to do this by changing
TomcatServerConfigurer.groovy like this:

-      context.addLifecycleListener(new DefaultWebXmlListener())
+      context.addLifecycleListener(new DefaultWebXmlListener() {
+          @Override
+          public void lifecycleEvent(LifecycleEvent event) {
+            super.lifecycleEvent(event);
+            if (Lifecycle.BEFORE_START_EVENT.equals(event.getType())) {
+              context.setReplaceWelcomeFiles(true)
+            }
+          }
+      })

Gretty could have such feature, enabled even by default.

Register/release org.gretty plugin with Gradle Central Plugin Repository https://plugins.gradle.org/

Currently this works:

build.gradle

plugins {
  id "org.akhikhl.gretty" version "2.0.0"
}

apply plugin: 'war'

repositories {
  jcenter()
}

gretty {
  servletContainer = 'jetty9.4'
  httpPort = 8080
}

... due to the registration at https://plugins.gradle.org/plugin/org.akhikhl.gretty . org.gretty (release 2.1.0) is not registered so the equivalent:

plugins {
  id "org.gretty" version "2.1.0"
}

... does not work. This issue is about setting-up the best publishing-mechanism according to https://plugins.gradle.org/docs/publish-plugin and following that for either 2.1.0 or 2.2.0.

Release 2.1.0

Barring some documentation updates, I believe the current master is fairly ready for a release. I'm using approximately the same build in production, and it has solved the jdk9, gradle and spring related problems that I had with 2.0.0.

Is anything else missing?

Edit

List of potential release-blockers:

~~#13 JDK9 simple smoke-test fails during logback initialization~~
~~#15 JDK9 cannot complete testAll: Jasper Source option 1.5 is no longer supported. Use 1.6 or later.~~
#23 JDK9 Jasper/JSPC for Jetty 9.4.8.v20171121 is not fully JDK9-ready

Remove Tomcat 7+8 support

Remove Tomcat 7 support for release 3.x. See also discussion in #43 (comment) .

Also remove Tomcat 8.0 support, since this version was replaced by Tomcat 8.5.

JDK9 simple smoke-test fails during logback initialization

Project with this build.gradle:

apply plugin: 'war'
apply from: 'https://raw.githubusercontent.com/gretty-gradle-plugin/gretty/master/pluginScripts/gretty-SNAPSHOT.plugin'

gretty {
  servletContainer = 'jetty9.4'
  httpPort = 8080
}

..., a Gradle 4.6 wrapper and a single file src/main/webapp/index.html.

Running appRun with JDK8 is fine, with JDK9 fails with:

Exception in thread "main" java.lang.NullPointerException: Cannot invoke method getText() on null object
        at org.codehaus.groovy.runtime.NullObject.invokeMethod(NullObject.java:91)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.NullCallSite.call(NullCallSite.java:35)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.akhikhl.gretty.Runner.initLogback(Runner.groovy:65)
        at org.akhikhl.gretty.Runner$initLogback.callStatic(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:206)
        at org.akhikhl.gretty.Runner.run(Runner.groovy:115)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:210)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:71)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
        at org.akhikhl.gretty.Runner.main(Runner.groovy:44)

Relevant line of code https://github.com/gretty-gradle-plugin/gretty/blob/master/libs/gretty-runner/src/main/groovy/org/akhikhl/gretty/Runner.groovy#L65:

logbackConfigText = this.getClass().getResourceAsStream('/grettyRunnerLogback.groovy').getText('UTF-8')

getResourceAsStream returns null.

I have a candidate fix with a slightly different way of loading the resource file, but wondered if others could reproduce this. Maybe something changes in Groovy with JDK9 and classloaders/resources. Reproduces with 2.0.0 and JDK9.

farmSecure tests broken for Jetty 9.3 and 9.4

09:00:25 INFO  Configuring /MyWebApp with realm 'auth', /home/travis/build/javabrett/gretty/integrationTests/farmSecure/security/jetty-realm.properties
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
09:00:27 INFO  Configuring /MyWebService with realm 'auth', /home/travis/build/javabrett/gretty/integrationTests/farmSecure/security/jetty-realm.properties
09:00:27 INFO  Jetty 9.3.23.v20180228 started and listening on port 8443
09:00:27 INFO  MyWebApp runs at:
09:00:27 INFO    https://localhost:8443/MyWebApp
09:00:27 INFO  MyWebService runs at:
09:00:27 INFO    https://localhost:8443/MyWebService
> Task :gretty-integrationTests:farmSecure:MyWebApp:farmBeforeIntegrationTestjetty9.3
> Task :gretty-integrationTests:farmSecure:MyWebApp:beforeIntegrationTest_jetty9.3 SKIPPED
> Task :gretty-integrationTests:farmSecure:MyWebApp:compileIntegrationTestJava NO-SOURCE
> Task :gretty-integrationTests:farmSecure:MyWebApp:compileIntegrationTestGroovy
> Task :gretty-integrationTests:farmSecure:MyWebApp:processIntegrationTestResources NO-SOURCE
> Task :gretty-integrationTests:farmSecure:MyWebApp:integrationTestClasses
> Task :gretty-integrationTests:farmSecure:MyWebApp:integrationTest_jetty9.3
org.akhikhl.examples.gretty.mywebapp.LogonSpec > should accept valid credentials FAILED
    org.spockframework.runtime.ConditionFailedWithExceptionError at LogonSpec.groovy:50
        Caused by: geb.waiting.WaitTimeoutException at LogonSpec.groovy:50
            Caused by: org.openqa.selenium.UnhandledAlertException at LogonSpec.groovy:50
2 tests completed, 1 failed
> Task :gretty-integrationTests:farmSecure:MyWebApp:integrationTest_jetty9.3 FAILED
> Task :gretty-integrationTests:farmSecure:MyWebApp:afterIntegrationTest_jetty9.3 SKIPPED

Update base jetty94 to 9.4.9

Jetty 9.4.9 has been released. Has JDK10 support.

No signature of method: static org.akhikhl.gretty.ProjectUtils.getClassPath() is applicable for argument types: (org.gradle.api.internal.project.DefaultProject_Decorated, null, java.lang.String)

Hi,
When I run gradle appRun --stacktrace for sample web project under gradle-4.9\samples\webApplication\quickstart I get the following output:

> Task :prepareInplaceWebAppFolder
> Task :createInplaceWebAppFolder
> Task :compileJava
> Task :processResources
> Task :classes
> Task :prepareInplaceWebAppClasses
> Task :prepareInplaceWebApp
> Task :appRun FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':appRun'.
> No signature of method: static org.akhikhl.gretty.ProjectUtils.getClassPath() is applicable for argument types: (org.gradle.api.internal.project.DefaultProject_Decorated, null, java.lang.String) values: [root project 'quickstart', null, runtimeClasspath]
  Possible solutions: getClassPath(org.gradle.api.Project, boolean, java.lang.String), getClass()

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':appRun'.
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:110)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
	at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
	at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:101)
	at org.gradle.api.internal.tasks.execution.FinalizeInputFilePropertiesTaskExecuter.execute(FinalizeInputFilePropertiesTaskExecuter.java:44)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:91)
	at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:62)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
	at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.run(EventFiringTaskExecuter.java:51)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:300)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:292)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:174)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:46)
	at org.gradle.execution.taskgraph.LocalTaskInfoExecutor.execute(LocalTaskInfoExecutor.java:42)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareWorkItemExecutor.execute(DefaultTaskExecutionGraph.java:273)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareWorkItemExecutor.execute(DefaultTaskExecutionGraph.java:258)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:135)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:130)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.execute(DefaultTaskPlanExecutor.java:200)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.executeWithWork(DefaultTaskPlanExecutor.java:191)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.run(DefaultTaskPlanExecutor.java:130)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: groovy.lang.MissingMethodException: No signature of method: static org.akhikhl.gretty.ProjectUtils.getClassPath() is applicable for argument types: (org.gradle.api.internal.project.DefaultProject_Decorated, null, java.lang.String) values: [root project 'quickstart', null, runtimeClasspath]
Possible solutions: getClassPath(org.gradle.api.Project, boolean, java.lang.String), getClass()
	at org.akhikhl.gretty.StartBaseTask$1$2.resolveWebAppClassPath(StartBaseTask.groovy:213)
	at org.akhikhl.gretty.WebAppClassPathResolver$resolveWebAppClassPath.call(Unknown Source)
	at org.akhikhl.gretty.LauncherBase.writeWebAppClassPath(LauncherBase.groovy:392)
	at org.akhikhl.gretty.LauncherBase$_writeRunConfigJson_closure6$_closure7$_closure8.doCall(LauncherBase.groovy:365)
	at org.akhikhl.gretty.LauncherBase.launchThread(LauncherBase.groovy:274)
	at org.akhikhl.gretty.LauncherBase.launch(LauncherBase.groovy:199)
	at org.akhikhl.gretty.Launcher$launch.call(Unknown Source)
	at org.akhikhl.gretty.StartBaseTask.action(StartBaseTask.groovy:76)
	at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
	at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:786)
	at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:753)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:131)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:300)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:292)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:174)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:120)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:99)
	... 31 more


* Get more help at https://help.gradle.org

BU?LD FAILED in 3s
5 actionable tasks: 5 executed

This happens on my Windows machine. I can successfully build the same project on my Linux machine.

I think wconfig.inplace parameter for resolvedClassPath.addAll(ProjectUtils.getClassPath(proj, wconfig.inplace, runtimeConfig)) in gretty/libs/gretty/src/main/groovy/org/akhikhl/gretty/StartBaseTask.groovy:216 is being passed as null.

Unfortunately setting,

gretty {
    httpPort = 8080
    inplace = true
}

doesn't help. I think this is a bug.

Gretty, Spring MVC and hot deployment

Hi! Thanks for the great plugin, but I have an issue with its hot deployment feature, which I have described here as well. The issue is as follows:

I am learning Spring MVC and trying to use it together with Gradle and Gretty plugin. I have successfully created a "Hello World" project, however I am not able to use hot deployment with Gretty, despite setting the managedClassReload=true. I run the application by using appRun gretty task from IntelliJ. My build.gradle is as follows:

apply plugin: 'java'
apply plugin: 'application'
apply plugin: 'war'
apply from: 'https://raw.github.com/gretty-gradle-plugin/gretty/master/pluginScripts/gretty.plugin'

group = 'lukeg'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8
mainClassName = 'lukeg.LearnApplication'

repositories {
	mavenCentral()
	maven {
		url 'https://repo.spring.io/libs-snapshot'
	}
}


dependencies {
	compileOnly('org.projectlombok:lombok:+')
	compile('org.springframework:spring-webmvc:4.3.17.RELEASE')
	compile("org.aspectj:aspectjweaver:1.8.11")
	compile('org.springframework:spring-context:4.3.18.BUILD-SNAPSHOT')
	providedCompile group: 'javax.servlet', name: 'javax.servlet-api', version: '3.1.0'
}

gretty {
	httpPort = 8080
	contextPath = '/'
	servletContainer = 'tomcat9'
	//reloadOnClassChange=true
	managedClassReload=true
	loggingLevel='DEBUG'
}

It does not matter whether I use tomcat9 or jetty9 for servlet container: the logs do not show that the changes to source files in project are detected by Gretty.

Interesingly enough, when I comment out the managedClassReload=true line and uncomment reloadOnClassChange=true the changes to source files are detected and the project is automatically reloaded.

What can be the cause for gretty's hot deployment not working? Does springloaded not work together with Spring MVC?

systemProperty/systemProperties and jvmArg(s) apply to pre-container Runner, can cause Groovy side-effects

The gretty extension allows the definition of jvmArg/jvmArgs and systemProperty/systemProperties (undocumented) which will be applied to the launched servlet-container. These are applied via the JavaExec which launches (in a separate JVM) the Gretty Runner which wraps, starts and monitors that servlet-container.

An issue can arise where either of these are used in a way that interacts with code in the Runner which executes prior to the embedded servlet-container launch. An example of this is shown in this stack-trace as highlighted in akhikhl#412 :

gretty {
  ...
  systemProperty 'java.util.logging.manager', 'org.apache.logging.log4j.jul.LogManager'
}

Could not load Logmanager "org.apache.logging.log4j.jul.LogManager"
java.lang.ClassNotFoundException: org.apache.logging.log4j.jul.LogManager
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
        at java.logging/java.util.logging.LogManager$1.run(LogManager.java:239)
        at java.logging/java.util.logging.LogManager$1.run(LogManager.java:223)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.logging/java.util.logging.LogManager.<clinit>(LogManager.java:223)
        at java.logging/java.util.logging.Logger.demandLogger(Logger.java:648)
        at java.logging/java.util.logging.Logger.getLogger(Logger.java:717)
        at java.logging/java.util.logging.Logger.getLogger(Logger.java:701)
        at org.codehaus.groovy.runtime.DefaultGroovyMethodsSupport.<clinit>(DefaultGroovyMethodsSupport.java:37)
        at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:97)
        at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:74)
        at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:36)
        at org.codehaus.groovy.runtime.InvokerHelper.<clinit>(InvokerHelper.java:66)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallConstructorSite(CallSiteArray.java:87)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:239)
        at org.akhikhl.gretty.Runner.main(Runner.groovy:36)

In this case the project also has:

dependencies {
    compile group: 'org.apache.logging.log4j', name: 'log4j-api', version: '2.8'
    compile group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.8'
    compile group: 'org.apache.logging.log4j', name: 'log4j-web', version: '2.8'
    compile group: 'org.apache.logging.log4j', name: 'log4j-jul', version: '2.8'
}

The systemProperty 'java.util.logging.manager', 'org.apache.logging.log4j.jul.LogManager' requests JUL to be configured with a specific manager, which will eventually be on the container classpath, but is only on the classpath for the execution of the embedded container via its configured classloader. The above stacktrace shows a Groovy runtime init problem, since it sees the JVM arg too, but does not have access to the matching class.

One potential solution I can think of for this is to split the meaning of jvmArgs and systemProperties. For JavaExec and currently also for Gretty, systemProperties can be thought of as a shortcut to jvmArgs with -Dname=value. It might be possible to change the meaning of systemProperties, pass it as an argument rather than a JVM-argument, then use embedded container support to apply it. Some versions of Jetty at least support this, Tomcat I would need to check.

I don't expect that the meaning of jvmArgs could or should be changed - it would still apply to the entire Runner launch, so if you needed sysprops to only apply once the container is launched, you would need to use systemProperties.

Any feedback on the above idea is welcome.

Upgrade gradle-bintray-plugin once Gradle 4.8 compatibility achieved

Current version is 1.2. We should upgrade to something newer than 1.8 once bintray/gradle-bintray-plugin#234 is resolved.

Convert most classes to use `@CompileStatic`

The Gretty plugin can have a negative impact on configuration time since all of it currently uses dynamic Groovy. Using CompileStatic on a significant number if not on all classes would improve configuration time already a lot.

Reinstate Jetty 9.3 + 9.4 integration tests

These have been disabled since before the fork. There's a comment about problems with authentication/login (test helloGrettySecure and a farm test) and I've been doing a little work on that. There will probably be other issues.

Obviously important for integration-tests to run on latest/default Jetty 9.4 at a minimum. Currently Jetty 9.2 is being tested.

Webapp with Form-Based Authentication shows empty page instead of login page

I have a webapp with Form-Based Authentication configured in web.xml and gretty configured to use tomcat9 with a serverConfigFile where Realm is configured.

The the app works fine when run from war on normal tomcat install, but when started with gretty's tomcat, trying to load a secured page shows only a blank page (or browser's own 403 page on chrome). Non-secured pages work as intended.

Gretty version is 2.2.0

Support All Dependencies Override In Project gradle.properties file

I have tried gretty 3.0.0-SNAPSHOT. But not supporting overide of following dependencies:
jetty7_version = 7.6.21.v20160908
jetty7_servlet_api_version = 2.5
jetty8_version = 8.1.22.v20160922
jetty8_servlet_api_version = 3.0.1
jetty9_version = 9.2.26.v20180806
jetty93_version = 9.3.24.v20180605
jetty94_version = 9.4.11.v20180605
jetty9_servlet_api_version = 3.1.0
tomcat85_version = 8.5.33
tomcat85_servlet_api_version = 3.1.0
tomcat9_version = 9.0.11
tomcat9_servlet_api_version = 4.0.0
asm_version = 7.0
groovy_version = 2.4.15
spock_version = 1.1-groovy-2.4
logback_version = 1.1.3
slf4j_version = 1.7.12
springBootVersion = 2.0.2.RELEASE
springLoadedVersion = 1.2.8.RELEASE
springVersion = 5.0.6.RELEASE

by gradle.properties of my project:. When I list following dependecies in my project gradle.properties file by:
jetty94_version = 9.4.14.v20181114
tomcat85_version = 8.5.35
tomcat9_version = 9.0.13
Its downloading the version listed in plugin instead of version listed by me. I ahve read in this stackflow post that overiding dependencies version are supported:
https://stackoverflow.com/questions/37339515/how-to-select-specific-jetty-version-in-gretty-plugin
And in plugin documentation at this url:
http://akhikhl.github.io/gretty-doc/Overriding-servlet-container-versions.html
So please add support for this dependency overide as well. The only alternative we have if we don't have this feature is to build plugin from source code overiding dependencies ourself and use it from
local maven repository.

Not working with Java 11 selecting Jetty9.4 as servlet container

On running it with Java 11 and selecting jetty9.4 asservlet coontainer we end with following stack trace:
java.lang.RuntimeException: Error scanning file /home/ankur/Development/projects/gradle-web/build/classes/java/main/HelloWorldServlet.class
at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:743) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:829) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:163) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:471) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:754) ~[jetty-util-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:672) ~[jetty-util-9.4.9.v20180320.jar:9.4.9.v20180320]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 55
at org.objectweb.asm.ClassReader.(ClassReader.java:166) ~[asm-6.1.1.jar:na]
at org.objectweb.asm.ClassReader.(ClassReader.java:148) ~[asm-6.1.1.jar:na]
at org.objectweb.asm.ClassReader.(ClassReader.java:136) ~[asm-6.1.1.jar:na]
at org.objectweb.asm.ClassReader.(ClassReader.java:237) ~[asm-6.1.1.jar:na]
at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:932) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:737) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
... 6 common frames omitted

Gretty 2.2 cannot find resources in java-library project dependencies

Please see the example at https://github.com/carey/gretty-resources.

If I start this by running

./gradlew clean :web:appRun

then the servlet in the lib module cannot load the hello.properties resource in the same module from the class path. I can fix this by using the java plugin for lib instead of java-library, or by running

./gradlew clean :lib:jar :web:appRun

I assume this is related to #37.

Feature request: Faster Startups

Given that Gretty is used heavily for testing, I'm surprised there isn't more discussion about minimizing startup time. Both Tomcat and Jetty waste 5-8 seconds waiting for SecureRandom to initialize.

WINDOWS:

The easiest solution is to promote the windows-specific security provider:
https://stackoverflow.com/questions/49322948/

gretty {
    // Do not use SystemProperty, which replaces the JRE's java.security settings.
    jvmArgs = ['-Djava.security.properties=java-overrides.security']
    // Only needed for tomcat
    contextConfigFile = "test-context.xml"
}

java-overrides.security:

security.provider.1=SunMSCAPI
security.provider.12=SUN

test-context.xml (Only needed for Tomcat):

<Context>
    <Manager pathname="" secureRandomAlgorithm="Windows-PRNG"/>
</Context>

LINUX:

For production systems, the easiest solution is haveged :
https://stackoverflow.com/questions/28201794/

System-level configurations aren't appropriate for a gradle plugin, but it's probably helpful to point the jvm to file:/dev/urandom instead:

java-overrides.security:

securerandom.source=file:/dev/urandom

These configurations are probably complex enough that most people probably won't bother. It should be possible for gretty to expose a single option that applies the appropriate solution for the given servlet container / operating system:

gretty {
    fastSecureRandomInitialization = true
}

Either way, I'm happy to add small section to the gretty documentation on how to improve startup times, which would also include information on how to configure jar scanning on tomcat.

Unable to use Gretty with Gradle 4.6+

I get a stack trace that looks like this:

* Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring project ':tems-struts'.
        at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:94)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:89)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.doConfigure(LifecycleProjectEvaluator.java:70)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.access$100(LifecycleProjectEvaluator.java:34)
        at org.gradle.configuration.project.LifecycleProjectEvaluator$ConfigureProject.run(LifecycleProjectEvaluator.java:110)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:50)
        at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:667)
        at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:136)
        at org.gradle.execution.TaskPathProjectEvaluator.configure(TaskPathProjectEvaluator.java:35)
        at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:62)
        at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:38)
        at org.gradle.initialization.DefaultGradleLauncher$ConfigureBuild.run(DefaultGradleLauncher.java:261)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.initialization.DefaultGradleLauncher.configureBuild(DefaultGradleLauncher.java:173)
        at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:132)
        at org.gradle.initialization.DefaultGradleLauncher.executeTasks(DefaultGradleLauncher.java:115)
        at org.gradle.internal.invocation.GradleBuildController$1.call(GradleBuildController.java:78)
        at org.gradle.internal.invocation.GradleBuildController$1.call(GradleBuildController.java:75)
        at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:152)
        at org.gradle.internal.invocation.GradleBuildController.doBuild(GradleBuildController.java:100)
        at org.gradle.internal.invocation.GradleBuildController.run(GradleBuildController.java:75)
        at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
        at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
        at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$1.run(RunAsBuildOperationBuildActionRunner.java:43)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:40)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionRunner.run(SubscribableBuildActionRunner.java:51)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:49)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:32)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:39)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:25)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:80)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:53)
        at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:57)
        at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:32)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:36)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:25)
        at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:43)
        at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:29)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:64)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:29)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:59)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:44)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:45)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:30)
        at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51)
        at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:285)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:258)
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:251)
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:185)
        at org.gradle.launcher.Main.doAction(Main.java:36)
        at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
        at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
        at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
        at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
        at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:31)
        at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:108)
        at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
Caused by: org.gradle.api.tasks.TaskInstantiationException: Could not create task of type 'AppStartTask'.
        at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:121)
        at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:116)
        at org.gradle.util.GUtil.uncheckedCall(GUtil.java:458)
        at org.gradle.api.internal.AbstractTask.injectIntoNewInstance(AbstractTask.java:189)
        at org.gradle.api.internal.project.taskfactory.TaskFactory.create(TaskFactory.java:116)
        at org.gradle.api.internal.project.taskfactory.TaskFactory.createTask(TaskFactory.java:74)
        at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory.createTask(AnnotationProcessingTaskFactory.java:44)
        at org.gradle.api.internal.tasks.DefaultTaskContainer.create(DefaultTaskContainer.java:80)
        at org.gradle.api.internal.project.DefaultProject.task(DefaultProject.java:1209)
        at org.gradle.api.Project$task$6.call(Unknown Source)
        at org.akhikhl.gretty.GrettyPlugin.addTasks(GrettyPlugin.groovy:343)
        at org.akhikhl.gretty.GrettyPlugin.afterProjectEvaluate(GrettyPlugin.groovy:701)
        at org.akhikhl.gretty.GrettyPlugin$_apply_closure64.doCall(GrettyPlugin.groovy:808)
        at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:40)
        at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:25)
        at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
        at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:230)
        at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:149)
        at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
        at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:324)
        at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:234)
        at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:140)
        at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
        at com.sun.proxy.$Proxy27.afterEvaluate(Unknown Source)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:76)
        ... 70 more
Caused by: java.lang.NullPointerException
        at org.gradle.testing.jacoco.plugins.JacocoPluginExtension.applyTo(JacocoPluginExtension.java:117)
        at org.gradle.testing.jacoco.plugins.JacocoPluginExtension$applyTo.call(Unknown Source)
        at org.akhikhl.gretty.StartBaseTask.initJacoco(StartBaseTask.groovy:156)
        at org.akhikhl.gretty.StartBaseTask.<init>(StartBaseTask.groovy:41)
        at org.akhikhl.gretty.AppStartTask.<init>(AppStartTask.groovy)
        at org.akhikhl.gretty.AppStartTask_Decorated.<init>(Unknown Source)
        at org.gradle.api.internal.DependencyInjectingInstantiator.newInstance(DependencyInjectingInstantiator.java:81)
        at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:119)
        ... 95 more

Unexpected behavior compared to legacy jetty plugin

(this is a cross-post of the original issue posted here)

We're in the process of migrating our projects from Gradle 3.x to 4.x and thus, migrating from the legacy jetty core-plugin to gretty as advertised by the Gradle folks. At first, gretty looks like a drop-in replacement for the legacy jetty plugin. However, we're seeing an unexpected change in behavior:

The way it used to work

We build jax-ws webservices with Metro. The way we deploy them is that we have a classic WEB-INF/web.xml file which declares a servlet of type com.sun.xml.ws.transport.http.servlet.WSServlet. This makes Metro look for a WEB-INF/sun-jaxws.xml file which in turn declares the WebService implementation classes and handler-chains. When we comment out the servlet declaration in web.xml, the whole Metro jax-ws isn't deployed anymore. It works that way in the legacy jetty plugin as well as in our own custom JettyLauncher class, which simply uses the programmatic Jetty API to configure and launch the container.

The way gretty behaves

In gretty, the jax-ws WebService seems to be deployed as soon as a WEB-INF/sun-jaxws.xml file and the Metro webservice runtime jar webservices-rt.jar are present in the war. It doesn't seem to be looking at the WEB-INF/web.xml file for that. When I declare a spring ContextLoaderListener in the web.xml, I see that the jax-ws WebService is deployed way before the Spring context is being initialized, so my guess is that gretty deploys anything it can find, regardless of whether there is a web.xml or not.

This behavior, however, isn't compatible with the legacy jetty plugin and our Jetty-API-based launcher. It doesn't seem to be on jetty's end however: I made sure I was using the same jetty version in our launcher and it turns out the exact same jetty version is behaving differently when used in our launcher class compared to gretty, so I'm assuming it must be something gretty does...

I built a simple project to demonstrate the change in behavior. It can be run with Gradle 3.x's jettyRun and with Gradle 4.x/Gretty's appRun tasks, just comment out the inappropriate section in build.gradle.
This project shows that while the Metro Servlet is commented out in web.xml, with Gradle 3.x, the WebService isn't instantiated, while with Gradle 4.x, it's the very first thing that happens.

gretty-org-test.zip

Can this be considered a bug? And if it's intentional behavior, could you explain what is causing the different behavior and how to make it backwards-compatible? (of course, we'd need the behavior which is compatible to our launcher class, used in production).

JDK9 with Jetty 9.2 testAll error with AnnotationParser/asm

11:54:46 WARN  Failed startup of context o.a.g.JettyWebAppContext@78830d9a{/extraResourceBases,[file:/Users/bsrandal/git/gretty/integrationTests/extraResourceBases/build/inplaceWebapp/, file:/Users/bsrandal/git/gretty/integrationTests/extraResourceBases/extra1/, jar:file:/Users/bsrandal/.gradle/caches/modules-2/files-2.1/org.webjars/bootstrap/3.2.0/aadbf822539bc170014701382cff887094c4c3df/bootstrap-3.2.0.jar!/META-INF/resources, jar:file:/Users/bsrandal/.gradle/caches/modules-2/files-2.1/org.webjars/jquery/2.1.1/dd89e356066869550b5509c4370f995ad6698d9a/jquery-2.1.1.jar!/META-INF/resources],STARTING}
java.lang.RuntimeException: Error scanning file ExampleServlet.class
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:708) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:824) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:164) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:549) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) ~[jetty-util-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) ~[jetty-util-9.2.22.v20170606.jar:9.2.22.v20170606]
        at java.base/java.lang.Thread.run(Thread.java:844) ~[na:na]
Caused by: java.lang.IllegalArgumentException: null
        at org.objectweb.asm.ClassReader.<init>(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
        at org.objectweb.asm.ClassReader.<init>(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
        at org.objectweb.asm.ClassReader.<init>(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
        at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:973) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:702) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        ... 11 common frames omitted
11:54:46 INFO  Jetty 9.2.22.v20170606 started and listening on port 8080
11:54:46 INFO  extraResourceBases runs at:
11:54:46 INFO    http://localhost:8080/extraResourceBases

> Task :gretty-integrationTests:extraResourceBases:integrationTest_jetty9 
...

org.akhikhl.examples.gretty.hellogretty.ExtraResourceBasesSpec > should get expected static page FAILED
    org.spockframework.runtime.SpockComparisonFailure at ExtraResourceBasesSpec.groovy:25

org.akhikhl.examples.gretty.hellogretty.ExtraResourceBasesSpec > should get expected response from servlet FAILED
    org.spockframework.runtime.SpockComparisonFailure at ExtraResourceBasesSpec.groovy:33

org.akhikhl.examples.gretty.hellogretty.ExtraResourceBasesSpec > should get page from extra resource base FAILED
    org.spockframework.runtime.SpockComparisonFailure at ExtraResourceBasesSpec.groovy:41

3 tests completed, 3 failed

> Task :gretty-integrationTests:extraResourceBases:afterIntegrationTest_jetty9 
Server stopped.

This will possibly become another case of don't-bother-with-Jetty-9.2 with JDK9.

Edit actually this is also occurring with latest Jetty 9.4.8.v20171121 so not-so-simple.

JDK9 cannot complete testAll: Jasper Source option 1.5 is no longer supported. Use 1.6 or later.

Once you get past the issue in #13, running testAll with JDK9 the next problem encountered is:

> Task :gretty-integrationTests:extraResourceBases:integrationTest_jetty7 
...
Mar. 06, 2018 8:35:15 AM org.apache.jasper.compiler.Compiler generateClass
SEVERE: Error compiling file: /Users/bsrandal/git/gretty/integrationTests/extraResourceBases/build/serverBaseDir_jetty7/webapps-exploded/extraResourceBases/jsp/org/apache/jsp/index_html.java
08:35:15 WARN  
org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP

PWC6199: Generated servlet error:
Source option 1.5 is no longer supported. Use 1.6 or later.

PWC6199: Generated servlet error:
Target option 1.5 is no longer supported. Use 1.6 or later.


        at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:126) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:296) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:372) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:433) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:608) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:476) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) ~[servlet-api-2.5.jar:2.5]
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652) ~[jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1317) ~[jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at javax.servlet.FilterChain$doFilter.call(Unknown Source) ~[na:na]
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) ~[groovy-2.4.13.jar:2.4.13]
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) ~[groovy-2.4.13.jar:2.4.13]
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133) ~[groovy-2.4.13.jar:2.4.13]
        at org.akhikhl.gretty.RedirectFilter.doFilter(RedirectFilter.groovy:123) ~[gretty-filter-2.0.1-20180305.213359-2.jar:na]
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1288) ~[jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:443) [jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:556) [jetty-security-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372) [jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.Server.handle(Server.java:369) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:933) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:995) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) [jetty-http-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) [jetty-http-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) [jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) [jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
        at java.base/java.lang.Thread.run(Thread.java:844) [na:na]

Appears that some source/target-directives will be needed if possible for Jetty7 tests, or they will need to be excluded from JDK9 test-runs.