Bug: HotReload Exception with Composite Build #104

gbalthasar · 2018-12-11T09:49:59Z

Hi,
using

Windows 10
JDK 8
Gradle 2.4.12
Gretty 2.3.1
Tomcat 8.5

a composite build structure throws Exception upon hot reload of my WebApp after continues build recompiles the lib. I included an example project structure (see .zip) to reproduce:

Extract somewhere
New Console/CMD at '\lib\greeter': gradle -t build
New Console/CMD at '\web\hello': gradle apprunwar
http://localhost:8080/hello shows 'Hello Gradle!'
Change return value at '\lib\greeter' Greeter.java say() Method from "Gradle" to "Gretty" and save file
Continues Build rebuilds
Gretty tries to reload war but fails with exception:

org.akhikhl.gretty.JettyScannerManager$1@55df6fbb failed on '[G:\temp\lib\greeter\build\libs\greeter-1.0.0.jar]
java.lang.IllegalStateException: Resolving configuration 'implementation' directly is not allowed
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.assertResolvingAllowed(DefaultConfiguration.java:897)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveToStateOrLater(DefaultConfiguration.java:435)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getResolvedConfiguration(DefaultConfiguration.java:430)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getResolvedConfiguration(Unknown Source)
        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.MetaBeanProperty.getProperty(MetaBeanProperty.java:59)
        at org.gradle.internal.metaobject.BeanDynamicObject$MetaClassAdapter.getProperty(BeanDynamicObject.java:228)
        at org.gradle.internal.metaobject.BeanDynamicObject.tryGetProperty(BeanDynamicObject.java:171)
        at org.gradle.internal.metaobject.CompositeDynamicObject.tryGetProperty(CompositeDynamicObject.java:55)
        at org.gradle.internal.metaobject.AbstractDynamicObject.getProperty(AbstractDynamicObject.java:59)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getProperty(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:50)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:296)
        at org.akhikhl.gretty.scanner.BaseScannerManager$_scanFilesChanged_closure3.doCall(BaseScannerManager.groovy:158)
        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 org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
        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.BooleanReturningMethodInvoker.invoke(BooleanReturningMethodInvoker.java:51)
        at org.codehaus.groovy.runtime.callsite.BooleanClosureWrapper.call(BooleanClosureWrapper.java:53)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.findAll(DefaultGroovyMethods.java:4331)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.findAll(DefaultGroovyMethods.java:4203)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.findAll(DefaultGroovyMethods.java:4188)
        at org.codehaus.groovy.runtime.dgm$203.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:157)
        at org.akhikhl.gretty.JettyScannerManager.scanFilesChangedOverride(JettyScannerManager.groovy:57)
        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)

Workaround by change index.jsp at '\web\hello' and save
Gretty reloads correctly now
http://localhost:8080/hello shows 'Hello Gretty!'

Please fix as I need this feature for our development with shared/distributed libraries. At the moment we are using the 'old' original Gretty plugin as we are still at JDK 7 there but once we completly switch to JDK 8 and Tomcat 8.5 we need the official as the 'old' one doesn't support newer Tomcats.

Thank you very much! Regards,
gbalthasar

The text was updated successfully, but these errors were encountered:

javabrett · 2018-12-11T23:44:49Z

Thanks for the report. Can you:

Update above with a more complete stacktrace.
Confirm whether or not the problem occurs when running Gradle 4.10.2 or 5.0.0.

gbalthasar · 2018-12-12T07:47:19Z

Thanks for the fast reply. I have:

Updated the exception with full stacktrace (see initial post)
Tested Gradle 4.10.2 and Gradle 5.0.0 and with both versions the same exception occurs

javabrett · 2018-12-12T22:57:09Z

I think this was introduced by 1531ea0, which was replacing the deprecated compile configuration with implementation. In the code in-question here, I think it probably needs to be compileClasspath.

gbalthasar · 2018-12-13T07:30:55Z

I think this is the actual problem, see also https://stackoverflow.com/questions/47910578/not-able-to-copy-configurations-dependencies-after-upgrading-gradle-plugin-for-a?rq=1

Solutions there point out to use compileClasspath instead or to extend an own configuration from implementation. I don't know which approach is better for the future, so it doesn't break again with newer Gradle versions:

configurations {
  customConfig.extendsFrom implementation
}

I hope it gets fixed with the next gretty version 2.3.2. Thank you.

tmohme · 2019-01-31T14:52:04Z

Same problem here with a "simple" multi-project build (Gradle 5.1.1, gretty-gradle-plugin 2.3.1, task "appRun") when changing the code in one of the projects and doing a "./gradlew build".

Complete stacktrace:

java.lang.IllegalStateException: Resolving configuration 'implementation' directly is not allowed
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.assertIsResolvable(DefaultConfiguration.java:1198)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveToStateOrLater(DefaultConfiguration.java:529)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getResolvedConfiguration(DefaultConfiguration.java:524)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getResolvedConfiguration(Unknown Source)
	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:104)
	at groovy.lang.MetaBeanProperty.getProperty(MetaBeanProperty.java:59)
	at org.gradle.internal.metaobject.BeanDynamicObject$MetaClassAdapter.getProperty(BeanDynamicObject.java:228)
	at org.gradle.internal.metaobject.BeanDynamicObject.tryGetProperty(BeanDynamicObject.java:171)
	at org.gradle.internal.metaobject.CompositeDynamicObject.tryGetProperty(CompositeDynamicObject.java:55)
	at org.gradle.internal.metaobject.AbstractDynamicObject.getProperty(AbstractDynamicObject.java:59)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getProperty(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:298)
	at org.akhikhl.gretty.scanner.BaseScannerManager$_scanFilesChanged_closure3.doCall(BaseScannerManager.groovy:158)
	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:104)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:326)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:41)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
	at org.codehaus.groovy.runtime.callsite.BooleanReturningMethodInvoker.invoke(BooleanReturningMethodInvoker.java:51)
	at org.codehaus.groovy.runtime.callsite.BooleanClosureWrapper.call(BooleanClosureWrapper.java:53)
	at org.codehaus.groovy.runtime.DefaultGroovyMethods.findAll(DefaultGroovyMethods.java:4892)
	at org.codehaus.groovy.runtime.DefaultGroovyMethods.findAll(DefaultGroovyMethods.java:4764)
	at org.codehaus.groovy.runtime.DefaultGroovyMethods.findAll(DefaultGroovyMethods.java:4749)
	at org.codehaus.groovy.runtime.dgm$228.invoke(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:246)
	at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:55)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:127)
	at org.akhikhl.gretty.scanner.BaseScannerManager.scanFilesChanged(BaseScannerManager.groovy:157)
	at org.akhikhl.gretty.JettyScannerManager.scanFilesChangedOverride(JettyScannerManager.groovy:57)
	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)

Our workaround is, to go back to gretty-gradle-plugin 2.1.0 and convert "implementation" dependencies to "compile".
The gradle documentation has a diagram with coloured boxes that explains the connection between the various configurations and explains, which configuration should (must) be used for which purpose.
According to the docs, "compileClasspath" and "runtimeClassPath" are intended "for consumption by tasks", while "implementation" is meant to declare dependencies against.

tmohme · 2019-02-03T18:25:47Z

1531ea0 introduced two changes in BaseScannermanager.groovy.

The second one (on L#155) is wrong and can be fixed by replacing implementation with runtimeClasspath. I was able to create a corresponding test-setup for this. Unfortunately I failed to create a fully automated test for this (could nevertheless create a pull-request for it).

For the first one (on L#77): I don't really understand it (yet).
Obviously implementation is wrong because then gretty doesn't collect the dependencies' SourceSets. On the other hand, neither compileClasspath nor runtimeClasspath leads to success.
Only compile successfully collects the dependencies' SourceSets.
I guess, I'll have to dig in a bit deeper.

The other changes introduced with 1531ea0 look good to me.

…mposite

tmohme · 2019-02-09T11:58:07Z

Now that my PR finally passed travis-ci, it would be great if could make progress here.

tmohme · 2019-05-10T10:01:34Z

We are coming to the limits of our workaround for this problem.
To make a good decision for which way to continue, we need to know if (and when) my PR will find its way into the project.

gbalthasar · 2019-05-14T13:49:23Z

We need to migrate within the next 3 month. I need a statement whether gretty will be developed on and this bug will be solved or not. It's the base for our decision whether to stay with gretty or try to find another solution that works for us.

fokkoru · 2019-12-31T00:09:36Z

Hey, any updates for this bug, I faced the same problem?

javabrett · 2019-12-31T00:12:42Z

@fokkoru JDK, Gradle, Gretty and Container versions please.

fokkoru · 2019-12-31T00:17:03Z

Gretty v. 3.0.1, servletContainer = "jetty9.3"

$ ./gradlew -v

------------------------------------------------------------
Gradle 5.6.4
------------------------------------------------------------

Build time:   2019-11-01 20:42:00 UTC
Revision:     dd870424f9bd8e195d614dc14bb140f43c22da98

Kotlin:       1.3.41
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.14 compiled on March 12 2019
JVM:          1.8.0_222 (AdoptOpenJDK 25.222-b10)
OS:           Mac OS X 10.15.2 x86_64

fokkoru · 2020-02-03T20:49:23Z

Hey, @javabrett, any luck finding this bug, can I help you with it?

gbalthasar · 2020-09-11T23:42:42Z

Manually tested the Pull Request, see #113 (comment)

…mposite

Fix issue #104 - Bug: HotReload Exception with Composite

javabrett self-assigned this Dec 12, 2018

javabrett added the kind/bug Something isn't working label Dec 12, 2018

javabrett modified the milestone: 2.2.0 Dec 12, 2018

tmohme added a commit to tmohme/gretty that referenced this issue Feb 5, 2019

Fix issue gretty-gradle-plugin#104 - Bug: HotReload Exception with Co…

0bd46ca

…mposite

boris-petrov pushed a commit to tmohme/gretty that referenced this issue Sep 12, 2020

Fix issue gretty-gradle-plugin#104 - Bug: HotReload Exception with Co…

b013ee9

…mposite

boris-petrov linked a pull request Sep 14, 2020 that will close this issue

Fix issue #104 - Bug: HotReload Exception with Composite #113

Merged

boris-petrov closed this as completed in #113 Sep 16, 2020

boris-petrov added a commit that referenced this issue Sep 16, 2020

Merge pull request #113 from tmohme/issue-104

9670c83

Fix issue #104 - Bug: HotReload Exception with Composite

f4lco pushed a commit that referenced this issue Sep 17, 2020

Fix issue #104 - Bug: HotReload Exception with Composite

c15d4fe

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bug: HotReload Exception with Composite Build #104

Bug: HotReload Exception with Composite Build #104

gbalthasar commented Dec 11, 2018 •

edited

Loading

javabrett commented Dec 11, 2018 •

edited

Loading

gbalthasar commented Dec 12, 2018

javabrett commented Dec 12, 2018

gbalthasar commented Dec 13, 2018

tmohme commented Jan 31, 2019

tmohme commented Feb 3, 2019

tmohme commented Feb 9, 2019

tmohme commented May 10, 2019

gbalthasar commented May 14, 2019

fokkoru commented Dec 31, 2019

javabrett commented Dec 31, 2019

fokkoru commented Dec 31, 2019 •

edited

Loading

fokkoru commented Feb 3, 2020

gbalthasar commented Sep 11, 2020

Bug: HotReload Exception with Composite Build #104

Bug: HotReload Exception with Composite Build #104

Comments

gbalthasar commented Dec 11, 2018 • edited Loading

javabrett commented Dec 11, 2018 • edited Loading

gbalthasar commented Dec 12, 2018

javabrett commented Dec 12, 2018

gbalthasar commented Dec 13, 2018

tmohme commented Jan 31, 2019

tmohme commented Feb 3, 2019

tmohme commented Feb 9, 2019

tmohme commented May 10, 2019

gbalthasar commented May 14, 2019

fokkoru commented Dec 31, 2019

javabrett commented Dec 31, 2019

fokkoru commented Dec 31, 2019 • edited Loading

fokkoru commented Feb 3, 2020

gbalthasar commented Sep 11, 2020

gbalthasar commented Dec 11, 2018 •

edited

Loading

javabrett commented Dec 11, 2018 •

edited

Loading

fokkoru commented Dec 31, 2019 •

edited

Loading