Development appserver config poisened after execution of buildUberJar

Hi

This could be an interesting one to solve…

My steps before encountering the problem:

  • I added and executed the buildUberJar task to the build.gradle in order to create a docker image.
  • Building and running the docker image with the uber jar works fine.
  • When returning to developping new features, running cuba with the “development app server” did no more work.
  • No amount of disabling the uber jar build / cleaning / config cleanup / cuba studio and whole computer restart could solve the problem.
  • After reproducing the steps with a commit from before building the uber jar, I again got a poisoned development app server after execution of the buildUberJar task.

How can execute both the buildUberJar and develop “as before” with the dev app server?

Cheers
Oliver

Errors:

Requesting “http://localhost:8080/app” in the Browser returns a HTTP 404 with the error message
“The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.”

the catalina.out shows the following first error

...
INFORMATION: Starting Servlet engine: [Apache Tomcat/9.0.27]
Okt. 28, 2020 10:57:34 VORM. org.apache.catalina.startup.HostConfig deployDirectory
INFORMATION: Deploye Web-Applikations-Verzeichnis [/home/bjsvwjek/Dokumente/git/simi_ws/prevs/simi/code/deploy/tomcat/webapps/app-core]
Okt. 28, 2020 10:57:34 VORM. org.apache.tomcat.util.descriptor.web.WebXmlParser parseWebXml
SCHWERWIEGEND: Parse error in application web.xml file at [file:/home/bjsvwjek/Dokumente/git/simi_ws/prevs/simi/code/deploy/tomcat/conf/web.xml]
org.xml.sax.SAXNotSupportedException: not supported setting property http://xml.org/sax/properties/lexical-handler
	at org.gjt.xpp.sax2.Driver.setProperty(Driver.java:204)
	at org.apache.tomcat.util.digester.Digester.getXMLReader(Digester.java:824)
	at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1458)
	at org.apache.tomcat.util.descriptor.web.WebXmlParser.parseWebXml(WebXmlParser.java:119)
	at org.apache.catalina.startup.ContextConfig.getDefaultWebXmlFragment(ContextConfig.java:1582)
	at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1107)
	at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:774)
	at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301)
	at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5051)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705)
	at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1133)
	at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1867)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
	at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
	at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1045)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1576)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309)
	at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
	at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
	at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936)
	at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
	at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
	at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.StandardService.startInternal(StandardService.java:421)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:633)
	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:566)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:344)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475)

Hi,
We had a similar topic: Upgrade from version 7.2.6 to 7.2.7 - CUBA.Platform

The error was caused by the Gradle of incompatible version used in the project.

In any case the problem is caused by the “org.gjt.xpp.sax2” (most probably pull-parser-2) library appearing in the Tomcat when it should not be there. Maybe it’s a transitive dependency. So you probably should investigate it in this direction.

Thank you Alex for linking the similar issue Upgrade from version 7.2.6 to 7.2.7

As to finding the cause, let me add a few things that I found out:

  • For some time, I suspected the gradle version, but going back vom gradle 6.6.1 to gradle 5(.6.4) did not change anything.
  • It must be some “artifact” introduced into tomcat through the gradle task buildUberJar, because:
    • As long as there is no buildUberJar task, it works
    • When it is broken, the “brute force fix” checkout from git into new local folder works.

Does the org.gjt.xpp.sax2 lib “land” in tomcat due to the gradle task buildFatJar?
How to get rid of it? Specific “cleanup task” after buildFatJar?

Cheers
Oliver