Hello Apache Geode Community, I have completed the Jakarta EE 10 migration work (GEODE-10466) which is now ready for review on GitHub. This migration represents a significant modernization effort with breaking changes that will impact the release strategy. I would like to discuss the branching approach with the community before proceeding.
================================================================================ MIGRATION SUMMARY ================================================================================ Complete modernization of Apache Geode to Jakarta EE 10 ecosystem with comprehensive framework upgrades, extensive testing, and production-ready implementation. Core Migrations Completed: - Jakarta EE 10: All javax.* → jakarta.* (173+ files) - Spring Framework: 5.3.21 → 6.1.14 - Spring Security: 5.6.5 → 6.3.4 - Spring Boot: 2.6.7 → 3.3.5 - Spring Shell: 1.2.0 → 3.3.3 - Jetty: 9.4.57 → 12.0.27 - Apache HttpComponents: 4.5.13 → 5.3.1 - Apache Lucene: 6.6.6 → 9.12.3 - JLine: 2.x → 3.x Test Results: - All 1,360+ active tests passing (100%) - Zero compilation errors - Build verification successful - All quality checks passed (Spotless, RAT, PMD, Javadoc) Files Changed: - 603 files changed - 14,339 insertions, 5,106 deletions - Production code: 173+ files - Test code: 120+ files - Build files: 40+ files ================================================================================ BREAKING CHANGES ================================================================================ This migration includes breaking changes that require careful release planning: 1. TOMCAT SESSION USERS - Must upgrade to Tomcat 10.1+ or 11.x - Geode 1.x users on Tomcat 6/7/8/9 cannot upgrade - Rolling upgrade NOT supported (javax/jakarta incompatibility) - Session manager class changed to Tomcat10DeltaSessionManager 2. API CHANGES - All javax.* imports changed to jakarta.* - Source-level breaking change for all Java EE APIs - Binary incompatibility with Java EE applications - Servlet API: javax.servlet → jakarta.servlet (Servlet 6.0) - JTA: javax.transaction → jakarta.transaction - JAXB: javax.xml.bind → jakarta.xml.bind - JCA, Mail, Annotations, CDI all migrated 3. FRAMEWORK CHANGES - Spring Security: WebSecurityConfigurerAdapter removed - Spring Shell: Command annotations changed - JLine: 2.x APIs replaced with 3.x - HttpClient: 4.x APIs replaced with 5.x - Jetty: 9.4 APIs replaced with 12 EE10 4. MINIMUM REQUIREMENTS - Java 17+ required (completed in GEODE-10465) - Servlet container must support Jakarta EE 10 - Tomcat 10.1+ for session module users ================================================================================ QUESTIONS FOR THE COMMUNITY ================================================================================ 1. VERSION NUMBER What should the target version be for this work? Option A: 2.0.0 (major version - reflects breaking changes) - Per release documentation: major releases allow breaking changes - Clearly signals incompatibility to users - Aligns with semantic versioning practices Option B: 1.16.0 (minor version) - If community prefers to defer major version Option C: Other suggestion? 2. SUPPORT BRANCH TIMING When should we create the support branch? Option A: Create support/2.0 branch now (or soon) for stabilization - Allows focused testing on release candidate - Isolates develop from release work Option B: Merge to develop first, create branch later when ready to release - More time for community review - Additional features can be added before branching Option C: Wait for more features before branching? 3. DEPRECATION PERIOD Should we maintain parallel support for both versions? - The javax → jakarta change is binary incompatible - Can we support both 1.x (javax) and 2.x (jakarta) simultaneously? - How long should 1.x remain supported after 2.0 release? - What is our responsibility to Tomcat 6/7/8/9 users? 4. MIGRATION PATH FOR USERS What guidance should we provide? - Big-bang upgrade only (no rolling upgrade possible) - Should we provide migration tools/scripts? - Documentation requirements? - Timeline for migration window? 5. FEATURE FREEZE RULES If we create a support branch now: - What are the rules for backporting to support/2.0? - Critical fixes only, or allow additional features? - Timeline for RC creation? - Acceptance testing period duration? 6. COMMUNICATION PLAN How should we announce this to the community? - Early warning to users about upcoming breaking changes? - Migration guide timing and location? - Coordination with downstream projects? - Docker Hub, Homebrew, packaging updates? ================================================================================ MY RECOMMENDATION ================================================================================ Based on the scope of changes and Apache Geode release documentation, I recommend: 1. TARGET VERSION: 2.0.0 - This is a major version for breaking changes per release process - Clearly signals breaking changes to users - Aligns with semantic versioning 2. BRANCHING TIMELINE: Merge to develop first - Allow 2-4 weeks for community review on develop - Create support/2.0 branch after stabilization period - This follows the pattern in the release documentation 3. SUPPORT POLICY: Maintain 1.x for 12-24 months - Give users time to plan migration - Continue critical fixes on 1.x support branches - Clear end-of-life communication 4. USER GUIDANCE: Comprehensive documentation - Detailed migration guide - Breaking changes clearly documented - Step-by-step upgrade instructions - FAQ for common issues 5. COMMUNICATION: Proactive announcement - Announce to user@ and dev@ lists - Update website with migration timeline - Coordinate with downstream projects early However, I defer to the community's preferences and the PMC's guidance on all decisions above. ================================================================================ DETAILED TECHNICAL INFORMATION ================================================================================ For those interested in the technical details, here is a comprehensive breakdown of all changes: JAKARTA EE 10 MIGRATION - Migrated all javax.* → jakarta.* imports across 173+ files - Updated Servlet API: javax.servlet → jakarta.servlet (Servlet 6.0) - Updated JTA: javax.transaction → jakarta.transaction - Updated JAXB: javax.xml.bind → jakarta.xml.bind - Updated JCA: javax.resource → jakarta.resource - Updated Mail: javax.mail → jakarta.mail - Updated Annotations: javax.annotation → jakarta.annotation - Updated CDI: javax.inject → jakarta.inject SPRING FRAMEWORK 6.X UPGRADE - Spring Framework: 5.3.21 → 6.1.14 - Spring Security: 5.6.5 → 6.3.4 - Spring Boot: 2.6.7 → 3.3.5 - Spring HATEOAS: 1.5.0 → 2.3.3 - Spring LDAP: 2.4.0 → 3.2.7 - SpringDoc OpenAPI: 1.6.8 → 2.6.0 SPRING SECURITY 6.X MIGRATION - Migrated from WebSecurityConfigurerAdapter to SecurityFilterChain pattern - Changed @EnableGlobalMethodSecurity to @EnableMethodSecurity - Updated authorizeRequests() → authorizeHttpRequests() - Updated antMatchers()/mvcMatchers() → requestMatchers() - Fixed XSS protection API and headers configuration - Updated all security configurations with lambda syntax SPRING SHELL 3.X MIGRATION - Migrated from Spring Shell 1.2.0 to 3.3.3 - Updated annotations: @CliCommand → @ShellMethod, @CliOption → @ShellOption - Changed @CliAvailabilityIndicator → @ShellMethodAvailability - Updated 118+ command classes across all modules - Implemented GfshParser for Spring Shell 3.x with multi-word command support - Fixed boolean flags, enum conversion, region path handling - Added completion provider framework for TAB completion JETTY 12 UPGRADE - Upgraded from Jetty 9.4.57 to Jetty 12.0.27 - Migrated to Jetty EE10 namespace (org.eclipse.jetty.ee10.*) - Implemented Server Classes Pattern for webapp classloading - Fixed ServletContext attribute handling with ServletContextListener - Configured proper Jakarta servlet API from container classloader APACHE HTTPCOMPONENTS 5.X MIGRATION - HttpClient: 4.5.13 → 5.3.1 - HttpCore: 4.4.15 → 5.2.4 - Added httpcore5-h2 5.2.4 for HTTP/2 support - Updated all HTTP client code to HttpComponents 5.x APIs - Updated 21 files across geode-management, geode-connectors, geode-pulse TOMCAT 10+ MIGRATION - Removed Tomcat 6/7/8/9 modules (javax.servlet) - Created geode-modules-tomcat10 for Jakarta Servlet 5.0/6.1 - Supports Tomcat 10.1.x (Jakarta Servlet 5.0, Java 11+) - Supports Tomcat 11.x (Jakarta Servlet 6.1, Java 17+) - Implemented SerializablePrincipal (Tomcat removed this class) - Removed 27-year-old deprecated Servlet 2.1 APIs from GemfireHttpSession LUCENE INTEGRATION - Updated Apache Lucene 6.6.6 → 9.12.3 - Fixed artifact names: analyzers-* → analysis-* - Updated all Lucene command classes for Spring Shell 3.x TESTING & VALIDATION - Migrated MockRunner to Spring Test MockMvc for session tests - Fixed 118+ Spring Shell command tests - Fixed 21+ HTTP client tests - Fixed all Jakarta Servlet tests - Fixed all Spring Security 6.x tests - Maintained ~95% test coverage - All 1,360+ active tests passing MODULE STATUS (All Fully Migrated) - geode-core - geode-gfsh - geode-connectors - geode-wan - geode-lucene - geode-management - geode-web-api - geode-web-management - geode-web - geode-pulse - geode-http-service - geode-modules-tomcat10 - geode-modules-session - geode-assembly - geode-dunit - geode-junit PRODUCTION READINESS CHECKLIST ✓ All modules compile successfully ✓ All tests passing (100% active tests) ✓ Build verification successful ✓ API compatibility verified (japicmp) ✓ Spotless formatting applied ✓ RAT license check passed ✓ PMD static analysis passed ✓ Javadoc generation successful ✓ Distribution packaging verified ✓ Assembly contents validated ================================================================================ UPGRADE INSTRUCTIONS FOR USERS ================================================================================ FOR TOMCAT SESSION USERS: 1. Upgrade Tomcat to 10.1+ or 11.x 2. Update dependency: geode-modules-tomcat10 3. Update imports: javax.servlet → jakarta.servlet 4. Update Manager class: Tomcat10DeltaSessionManager 5. Perform big bang upgrade (rolling upgrade not supported) FOR GFSH USERS: - GFSH commands now use Spring Shell 3.x (internal change) - TAB completion enhanced - Command parsing improved - All existing commands work identically FOR APPLICATION DEVELOPERS: - Update all javax.* imports to jakarta.* - Update Spring Security configurations (if using custom security) - Update HTTP client code to 5.x APIs (if using directly) - Review JMX access patterns (Java 9+ module compatibility) ================================================================================ NEXT STEPS ================================================================================ Once we agree on the branching strategy, I will: 1. Update PR description with agreed version target 2. Prepare comprehensive release notes 3. Create detailed migration guide 4. Work with Release Manager on timeline ( I happily volunteer ) 5. Address any review feedback 6. Update JIRA with appropriate fix version 7. Coordinate communication plan I am happy to discuss any concerns, answer questions about the migration work, or provide additional technical details as needed. Please share your thoughts on the questions above, especially: - Target version number (2.0.0 vs 1.16.0) - Branching timeline (now vs after develop merge) - Support policy for 1.x versions - User communication plan Looking forward to the community's feedback and guidance. ================================================================================ REFERENCES ================================================================================ PR: https://github.com/JinwooHwang/geode/pull/new/GEODE-10466 JIRA: https://issues.apache.org/jira/browse/GEODE-10466 Branch: GEODE-10466 Files changed: 603 files (14,339 insertions, 5,106 deletions) Test coverage: 100% of active tests passing (1,360+ tests) Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/>
