Gretty adds javaparser to Tomcat classpath, overriding the web app javaparser version

[Artur-]

git clone git@github.com:vaadin/base-starter-gradle.git
cd base-starter-gradle
git checkout tomcat
./gradlew appRun 

fails with

May 09, 2025 9:26:39 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Allocate exception for servlet [com.vaadin.flow.server.startup.ServletDeployer]
java.lang.ExceptionInInitializerError: Exception java.lang.NoSuchFieldError: Class com.github.javaparser.ParserConfiguration$LanguageLevel does not have member field 'com.github.javaparser.ParserConfiguration$LanguageLevel JAVA_21' [in thread "main"]
        at com.vaadin.copilot.Copilot.<clinit>(Copilot.java:28)
        at com.vaadin.copilot.CopilotIndexHtmlLoader.serviceInit(CopilotIndexHtmlLoader.java:44)
        at com.vaadin.flow.server.VaadinService.lambda$init$0(VaadinService.java:271)

because as you can see when running with

./gradlew appRun --debug

the servlet container classpath has an old javaparser version that gets picked up

2025-05-09T09:27:12.829+0300 [DEBUG] [org.akhikhl.gretty.LauncherBase] {
    "servletContainerId": "tomcat10",
    "servletContainerDescription": "Tomcat 10.1.19",
    "servletContainerClasspath": [
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-ant-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-astbuilder-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-console-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-datetime-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-dateutil-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-groovydoc-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-json-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-nio-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-sql-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-templates-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-test-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/groovy-xml-3.0.17.jar",
        "/.../.gradle/wrapper/dists/gradle-8.7-bin/bhs2wmbdwecv87pi65oeuq5iu/gradle-8.7/lib/javaparser-core-3.17.0.jar",

[boris-petrov]

Oh wow, that's a funny... and unfortunate case. 😄 I believe it happens because we add Groovy to the runner classpath here and Groovy comes with javaparser 3.17. We must add Groovy to the runner classpath as otherwise Gretty can't run (see the second part of this comment).

I don't have a good solution for this. The only thing I can think of is explicitly adding the latest version of javaparser to be used instead of the one that comes with Groovy. And hope that it is backwards-compatible with the old one so that Groovy works correctly.

@f4lco any other ideas?

[Artur-]

This is one idea from the Vaadin forum https://vaadin.com/forum/t/vaadin-gradle-skeleton-starter-compatibility-with-java-17/168866/8

[boris-petrov]

We could remove the loader.setDelegate(true) line but wouldn't that mean that if a webapp has Groovy 4 in their dependencies, it would be used for Gretty's code instead of the bundled Groovy 3?

[Yasushi]

@boris-petrov

I tested this patch and it fixed my Groovy version conflicts - the webapp's Groovy dependencies are now properly isolated from Gretty's bundled version.
Just curious about your concern regarding webapp Groovy affecting Gretty's code - does Gretty inject Groovy code into the webapp classloader? My understanding was that the runner handles Gretty's Groovy code separately from the webapp's classloader, so I'm wondering if there are specific cases where webapp Groovy versions could interfere with Gretty functionality.
Would be interested to understand the architecture better if you have time to explain!

diff --git a/libs/gretty-runner-tomcat/src/main/groovy/org/akhikhl/gretty/TomcatServerConfigurer.groovy b/libs/gretty-runner-tomcat/src/main/groovy/org/akhikhl/gretty/TomcatServerConfigurer.groovy
index f36c3a36..d126c3ae 100644
--- a/libs/gretty-runner-tomcat/src/main/groovy/org/akhikhl/gretty/TomcatServerConfigurer.groovy
+++ b/libs/gretty-runner-tomcat/src/main/groovy/org/akhikhl/gretty/TomcatServerConfigurer.groovy
@@ -227,8 +227,8 @@ class TomcatServerConfigurer {
     context.setParentClassLoader(classLoader)
     context.setJarScanner(configurer.createJarScanner(context.getJarScanner(), new JarSkipPatterns()))
     WebappLoader loader = new WebappLoader(classLoader)
-    loader.setLoaderClass(TomcatEmbeddedWebappClassLoader.class.getName())
-    loader.setDelegate(true)
+    // loader.setLoaderClass(TomcatEmbeddedWebappClassLoader.class.getName())
+    // loader.setDelegate(true)
     context.setLoader(loader)

     webapp.initParameters?.each { key, value ->

[boris-petrov]

@Yasushi I would also like to understand the architecture as this code is not something that I've written. 😄 I just "inherited" support of Gretty...

As for your comment - now that I think about it, I think you're right. The Runner classpath acts as the System classloader of the webapp (right?) so removing the setDelegate line should resolve the issue.

I'll create a new release with the removal of this call early next week.

Why did you also remove the call to setLoaderClass in your patch? Do you know what does Gretty's specific class-loader do? From a quick glance, I can't seem to see anything special.

[Yasushi]

@boris-petrov Thanks for taking over maintenance of Gretty! It's such a valuable plugin and I really appreciate you keeping it alive. 😊

Exactly, I have the same understanding about the classloader architecture. You're right that the Runner classpath acts as the system classloader for the webapp, and the Runner itself shouldn't need to use the webapp classloader.

Regarding setLoaderClass - I had to remove it because it was throwing a NoSuchMethodError. Given that the custom classloader changes are probably over 10 years old, it's likely not relevant for current Tomcat versions anyway. Using the standard Tomcat WebappLoader worked fine in my testing.

Looking forward to the next release with the setDelegate fix!

Caused by: java.lang.NoSuchMethodError: org.akhikhl.gretty.TomcatEmbeddedWebappClassLoader.filter(Ljava/lang/String;)Z
	at org.akhikhl.gretty.TomcatEmbeddedWebappClassLoader.loadClass(TomcatEmbeddedWebappClassLoader.java:42)
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1163)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
	at javax.xml.parsers.FactoryFinder$1.run(FactoryFinder.java:294)
        ...

[boris-petrov]

I've released 3.1.7 and 4.1.7. @Artur-, @Yasushi, please try the version you use and let me know if it works for you. Thanks!

[Yasushi]

@boris-petrov That was incredibly fast! Thank you so much for the quick release. 🙏