Fix deployment failures: upgrade to Jersey 2.x and resolve SLF4J/Spring incompatibility

[Copilot]

Tomcat deployment was failing due to incompatible dependency versions. After in-depth analysis, the root cause was Jersey 1.x's internal repackaged ASM 3.x that cannot read Java 17 bytecode, combined with SLF4J version mismatch.

Root Causes

Jersey 1.x bundled ASM incompatibility (PRIMARY)

java.lang.IllegalArgumentException
  at jersey.repackaged.org.objectweb.asm.ClassReader.<init>(ClassReader.java:170)
  at com.sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(...)

Jersey 1.x (including 1.19.4) bundles its own repackaged ASM 3.x (from 2009) that cannot parse Java 17 class files. This bundled ASM cannot be overridden by external dependencies, making Jersey 1.x fundamentally incompatible with Java 17.

SLF4J API mismatch

NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(...)
  at org.apache.commons.logging.impl.SLF4JLocationAwareLog.error
  at org.springframework.web.context.ContextLoader.initWebApplicationContext

Spring 5.x's spring-jcl calls SLF4J 1.7.x methods that don't exist in 2.0.x.

Changes

Jersey 1.x → 2.41 upgrade (treebase-web/pom.xml, web.xml)

• Upgraded from Jersey 1.19.4 → 2.41 (actively maintained, October 2023)
• Jersey 2.x uses external ASM 9.2 (not bundled), fully compatible with Java 17
• Updated servlet configuration: com.sun.jersey.* → org.glassfish.jersey.*
• Updated Java imports in DryadImportor.java for multipart support
• Added Jersey 2.x dependencies: jersey-server, jersey-container-servlet, jersey-hk2, jersey-media-multipart

SLF4J compatibility (pom.xml, treebase-web/pom.xml)

• SLF4J: 2.0.16 → 1.7.36 (Spring 5.x compatible)
• Log4j bridge: log4j-slf4j2-impl → log4j-slf4j-impl
• Excluded transitive old SLF4J JARs (slf4j-log4j12, jcl104-over-slf4j)

Workflow simplification (.github/workflows/tomcat-deploy.yml)

• Removed post-deployment JAR manipulation (116 lines)
• Single-start deployment instead of stop/clean/restart cycle
• Proper Maven dependency management instead of runtime patching

Documentation

JERSEY_2X_UPGRADE.md - Technical guide for Jersey 2.x migration

• Root cause explanation
• Before/after comparisons
• API compatibility matrix

DEPLOYMENT_FIX_ANALYSIS.md - Technical deep-dive analysis

FIX_SUMMARY.md - Executive summary and verification details

Why Jersey 2.x?

Aspect	Jersey 1.x	Jersey 2.x
ASM	Repackaged 3.x (2009)	External 9.x (2021+)
Java 17	❌ Fails	✅ Native support
Maintenance	EOL 2018	Active
Override ASM	❌ Impossible	✅ Via Maven

Jersey 2.x resolves the fundamental incompatibility by using external, upgradeable ASM instead of bundled legacy ASM.

Original prompt

The tomcat deployment pipeline has devolved into horrendous spaghetti code (.github/workflows/tomcat-deploy.yml). The deployment actions keep failing in the same way (https://github.com/TreeBASE/treebase/actions/runs/20792115797/job/59716512448). We've done a dozen PRs where you failed to solve this. You now HAVE to consider this problem more structurally. Including the following options:

• a full rewrite of the deploy pipeline
• integral upgrades of the logging system stack (SLF4J, commons-logging, etc)
• integral upgrades of ASM

I need you to start with an in-depth analysis of the problem. Do NOT simply attempt yet another hack.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[rvosa]

@copilot IT IS STILL FAILING IN THE EXACT SAME WAY. I CAN'T BELIEVE THIS. WE'VE BEEN DOING THIS FOR TWO DAYS NOW. LOOK AT ALL THE PRS WE'VE DONE. WHAT IS THIS. HOW IS THIS POSSIBLE. https://github.com/TreeBASE/treebase/actions/runs/20792932098/job/59719204712?pr=337

[Copilot]

@copilot IT IS STILL FAILING IN THE EXACT SAME WAY. I CAN'T BELIEVE THIS. WE'VE BEEN DOING THIS FOR TWO DAYS NOW. LOOK AT ALL THE PRS WE'VE DONE. WHAT IS THIS. HOW IS THIS POSSIBLE. https://github.com...

I found the root cause. Jersey 1.19.4 contains a repackaged internal copy of ASM 3.x (jersey.repackaged.org.objectweb.asm) that cannot read Java 17 bytecode. External ASM 9.2 we added doesn't help because Jersey uses its internal copy.

We need to upgrade to Jersey 2.x which doesn't have this limitation. Working on it now - will need to update REST API servlet configuration for Jersey 2.x compatibility.