[
https://issues.apache.org/jira/browse/GEODE-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinwoo Hwang updated GEODE-10466:
---------------------------------
Description:
h3. Background
With the transition from Java EE to Jakarta EE (starting with Jakarta EE 9),
the namespace for enterprise Java APIs changed from {{javax.*. }}*to
{{jakarta.*.}}* This migration is necessary to:
* Maintain compatibility with modern application servers (Tomcat 10+, Jetty
11+, etc.)
* Support latest Spring Framework versions (6.0+)
* Ensure long-term sustainability and vendor support
* Align with industry standards and best practices
h3. Current State
Apache Geode currently uses {{javax.*}} packages in several modules, primarily:
* *Servlet APIs* in web-related modules
* *Annotation APIs* for dependency injection and validation
* *HTTP session management* components
* *REST API endpoints* and web controllers
h3. Scope of Work
h4. Affected Modules
* geode-web - Core web functionality and servlet integration
* geode-web-api - REST API interfaces and controllers
* geode-web-management - Management REST endpoints
* geode-core - Limited javax usage (primarily annotations)
* geode-assembly - Web container integration and packaging
h4. Key Changes Required
* *Dependency Updates*
** Replace {{javax.servlet:javax.servlet-api}} with
{{jakarta.servlet:jakarta.servlet-api}}
** Replace {{javax.annotation:javax.annotation-api}} with
{{jakarta.annotation:jakarta.annotation-api}}
** Update Spring Framework to Jakarta EE compatible versions (6.0+)
* *Package Name Migration*
// Before
import javax.servlet.http.HttpServletRequest;
import javax.annotation.PostConstruct;
// After
import jakarta.servlet.http.HttpServletRequest;
import jakarta.annotation.PostConstruct;
* *Build Configuration Updates*
** Update Gradle dependencies in affected modules
** Ensure compatibility with Jakarta EE 9+ specifications
** Update version constraints and BOM files
h3. Acceptance Criteria
h4. Functional Requirements
* All {{{}javax.* *imports replaced with corresponding jakarta.*{}}}* imports
* All build dependencies updated to Jakarta EE compatible versions
* REST API endpoints function identically to current implementation
* Web management interfaces remain fully operational
* HTTP session management continues to work as expected
h4. Technical Requirements
* All unit tests pass without modification
* Integration tests pass
* No performance regression compared to current implementation
* Backward compatibility maintained where possible
* CI/CD pipeline updated to test against Jakarta EE environments
h3. Implementation Plan
h4. Phase 1: Assessment and Preparation (1-2 weeks)
* Complete comprehensive audit of all {{javax.*}} usage
* Identify third-party dependencies requiring updates
* Create automated migration scripts for package name changes
* Set up test environments with Jakarta EE compatible containers
h4. Phase 2: Core Migration (2-3 weeks)
* Update build dependencies and version constraints
* Execute automated package name migration
* Update web module implementations
* Resolve compilation and runtime issues
h4. Phase 3: Testing and Validation (2 weeks)
* Execute full test suite against Jakarta EE environment
* Perform integration testing with supported application servers
* Validate REST API functionality and performance
* Test web management interface compatibility
h4. Phase 4: Documentation and Release (1 week)
* Update user documentation and migration guides
* Create compatibility matrix for supported containers
* Update examples and sample applications
* Prepare release notes with breaking changes
h3. Risks and Mitigation
h4. Technical Risks
* {*}Third-party library compatibility{*}: Some dependencies may not support
Jakarta EE
** {_}Mitigation{_}: Identify alternatives or request vendor updates early
* {*}Application server compatibility{*}: Older containers may not support
Jakarta EE
** {_}Mitigation{_}: Document minimum supported versions clearly
* {*}Performance impact{*}: Package changes may affect performance
** {_}Mitigation{_}: Comprehensive performance testing and benchmarking
h4. Project Risks
* {*}Breaking changes for users{*}: Applications using Geode web features may
require updates
** {_}Mitigation{_}: Provide detailed migration guide and deprecation notices
* {*}Timeline dependencies{*}: Spring Framework and other dependencies must be
updated first
** {_}Mitigation{_}: Coordinate with dependency update schedules
h3. Success Metrics
* 100% of {{{}javax.* *references migrated to jakarta.*{}}}*
* All existing functionality preserved
* CI/CD pipeline fully operational with Jakarta EE
* Zero performance regression
* Complete documentation coverage
h3. Additional Notes
* This migration aligns Apache Geode with modern Java enterprise standards and
ensures long-term compatibility with evolving Java ecosystem.
* The work should be coordinated with any planned Spring Framework upgrades.
was:
h3. Background
With the transition from Java EE to Jakarta EE (starting with Jakarta EE 9),
the namespace for enterprise Java APIs changed from {{{}javax.{*}{{*}{}}}}
{*}to {{jakarta.}}{*}. This migration is necessary to:
* Maintain compatibility with modern application servers (Tomcat 10+, Jetty
11+, etc.)
* Support latest Spring Framework versions (6.0+)
* Ensure long-term sustainability and vendor support
* Align with industry standards and best practices
h3. Current State
Apache Geode currently uses {{javax.*}} packages in several modules, primarily:
* *Servlet APIs* in web-related modules
* *Annotation APIs* for dependency injection and validation
* *HTTP session management* components
* *REST API endpoints* and web controllers
h3. Scope of Work
h4. Affected Modules
* geode-web - Core web functionality and servlet integration
* geode-web-api - REST API interfaces and controllers
* geode-web-management - Management REST endpoints
* geode-core - Limited javax usage (primarily annotations)
* geode-assembly - Web container integration and packaging
h4. Key Changes Required
* *Dependency Updates*
** Replace {{javax.servlet:javax.servlet-api}} with
{{jakarta.servlet:jakarta.servlet-api}}
** Replace {{javax.annotation:javax.annotation-api}} with
{{jakarta.annotation:jakarta.annotation-api}}
** Update Spring Framework to Jakarta EE compatible versions (6.0+)
* *Package Name Migration*
// Before
import javax.servlet.http.HttpServletRequest;
import javax.annotation.PostConstruct;
// After
import jakarta.servlet.http.HttpServletRequest;
import jakarta.annotation.PostConstruct;
* *Build Configuration Updates*
** Update Gradle dependencies in affected modules
** Ensure compatibility with Jakarta EE 9+ specifications
** Update version constraints and BOM files
h3. Acceptance Criteria
h4. Functional Requirements
* All {{{}javax.* *imports replaced with corresponding jakarta.*{}}}* imports
* All build dependencies updated to Jakarta EE compatible versions
* REST API endpoints function identically to current implementation
* Web management interfaces remain fully operational
* HTTP session management continues to work as expected
h4. Technical Requirements
* All unit tests pass without modification
* Integration tests pass
* No performance regression compared to current implementation
* Backward compatibility maintained where possible
* CI/CD pipeline updated to test against Jakarta EE environments
h3. Implementation Plan
h4. Phase 1: Assessment and Preparation (1-2 weeks)
* Complete comprehensive audit of all {{javax.*}} usage
* Identify third-party dependencies requiring updates
* Create automated migration scripts for package name changes
* Set up test environments with Jakarta EE compatible containers
h4. Phase 2: Core Migration (2-3 weeks)
* Update build dependencies and version constraints
* Execute automated package name migration
* Update web module implementations
* Resolve compilation and runtime issues
h4. Phase 3: Testing and Validation (2 weeks)
* Execute full test suite against Jakarta EE environment
* Perform integration testing with supported application servers
* Validate REST API functionality and performance
* Test web management interface compatibility
h4. Phase 4: Documentation and Release (1 week)
* Update user documentation and migration guides
* Create compatibility matrix for supported containers
* Update examples and sample applications
* Prepare release notes with breaking changes
h3. Risks and Mitigation
h4. Technical Risks
* {*}Third-party library compatibility{*}: Some dependencies may not support
Jakarta EE
** {_}Mitigation{_}: Identify alternatives or request vendor updates early
* {*}Application server compatibility{*}: Older containers may not support
Jakarta EE
** {_}Mitigation{_}: Document minimum supported versions clearly
* {*}Performance impact{*}: Package changes may affect performance
** {_}Mitigation{_}: Comprehensive performance testing and benchmarking
h4. Project Risks
* {*}Breaking changes for users{*}: Applications using Geode web features may
require updates
** {_}Mitigation{_}: Provide detailed migration guide and deprecation notices
* {*}Timeline dependencies{*}: Spring Framework and other dependencies must be
updated first
** {_}Mitigation{_}: Coordinate with dependency update schedules
h3. Success Metrics
* 100% of {{{}javax.* *references migrated to jakarta.*{}}}*
* All existing functionality preserved
* CI/CD pipeline fully operational with Jakarta EE
* Zero performance regression
* Complete documentation coverage
h3. Additional Notes
* This migration aligns Apache Geode with modern Java enterprise standards and
ensures long-term compatibility with evolving Java ecosystem.
* The work should be coordinated with any planned Spring Framework upgrades.
> Migrate Apache Geode from Java EE to Jakarta EE
> -----------------------------------------------
>
> Key: GEODE-10466
> URL: https://issues.apache.org/jira/browse/GEODE-10466
> Project: Geode
> Issue Type: Improvement
> Reporter: Jinwoo Hwang
> Assignee: Jinwoo Hwang
> Priority: Major
>
> h3. Background
> With the transition from Java EE to Jakarta EE (starting with Jakarta EE 9),
> the namespace for enterprise Java APIs changed from {{javax.*. }}*to
> {{jakarta.*.}}* This migration is necessary to:
> * Maintain compatibility with modern application servers (Tomcat 10+, Jetty
> 11+, etc.)
> * Support latest Spring Framework versions (6.0+)
> * Ensure long-term sustainability and vendor support
> * Align with industry standards and best practices
> h3. Current State
> Apache Geode currently uses {{javax.*}} packages in several modules,
> primarily:
> * *Servlet APIs* in web-related modules
> * *Annotation APIs* for dependency injection and validation
> * *HTTP session management* components
> * *REST API endpoints* and web controllers
> h3. Scope of Work
> h4. Affected Modules
> * geode-web - Core web functionality and servlet integration
> * geode-web-api - REST API interfaces and controllers
> * geode-web-management - Management REST endpoints
> * geode-core - Limited javax usage (primarily annotations)
> * geode-assembly - Web container integration and packaging
> h4. Key Changes Required
> * *Dependency Updates*
> ** Replace {{javax.servlet:javax.servlet-api}} with
> {{jakarta.servlet:jakarta.servlet-api}}
> ** Replace {{javax.annotation:javax.annotation-api}} with
> {{jakarta.annotation:jakarta.annotation-api}}
> ** Update Spring Framework to Jakarta EE compatible versions (6.0+)
> * *Package Name Migration*
>
> // Before
> import javax.servlet.http.HttpServletRequest;
> import javax.annotation.PostConstruct;
> // After
> import jakarta.servlet.http.HttpServletRequest;
> import jakarta.annotation.PostConstruct;
>
> * *Build Configuration Updates*
> ** Update Gradle dependencies in affected modules
> ** Ensure compatibility with Jakarta EE 9+ specifications
> ** Update version constraints and BOM files
> h3. Acceptance Criteria
> h4. Functional Requirements
> * All {{{}javax.* *imports replaced with corresponding jakarta.*{}}}*
> imports
> * All build dependencies updated to Jakarta EE compatible versions
> * REST API endpoints function identically to current implementation
> * Web management interfaces remain fully operational
> * HTTP session management continues to work as expected
> h4. Technical Requirements
> * All unit tests pass without modification
> * Integration tests pass
> * No performance regression compared to current implementation
> * Backward compatibility maintained where possible
> * CI/CD pipeline updated to test against Jakarta EE environments
> h3. Implementation Plan
> h4. Phase 1: Assessment and Preparation (1-2 weeks)
> * Complete comprehensive audit of all {{javax.*}} usage
> * Identify third-party dependencies requiring updates
> * Create automated migration scripts for package name changes
> * Set up test environments with Jakarta EE compatible containers
> h4. Phase 2: Core Migration (2-3 weeks)
> * Update build dependencies and version constraints
> * Execute automated package name migration
> * Update web module implementations
> * Resolve compilation and runtime issues
> h4. Phase 3: Testing and Validation (2 weeks)
> * Execute full test suite against Jakarta EE environment
> * Perform integration testing with supported application servers
> * Validate REST API functionality and performance
> * Test web management interface compatibility
> h4. Phase 4: Documentation and Release (1 week)
> * Update user documentation and migration guides
> * Create compatibility matrix for supported containers
> * Update examples and sample applications
> * Prepare release notes with breaking changes
> h3. Risks and Mitigation
> h4. Technical Risks
> * {*}Third-party library compatibility{*}: Some dependencies may not support
> Jakarta EE
> ** {_}Mitigation{_}: Identify alternatives or request vendor updates early
> * {*}Application server compatibility{*}: Older containers may not support
> Jakarta EE
> ** {_}Mitigation{_}: Document minimum supported versions clearly
> * {*}Performance impact{*}: Package changes may affect performance
> ** {_}Mitigation{_}: Comprehensive performance testing and benchmarking
> h4. Project Risks
> * {*}Breaking changes for users{*}: Applications using Geode web features
> may require updates
> ** {_}Mitigation{_}: Provide detailed migration guide and deprecation notices
> * {*}Timeline dependencies{*}: Spring Framework and other dependencies must
> be updated first
> ** {_}Mitigation{_}: Coordinate with dependency update schedules
> h3. Success Metrics
> * 100% of {{{}javax.* *references migrated to jakarta.*{}}}*
> * All existing functionality preserved
> * CI/CD pipeline fully operational with Jakarta EE
> * Zero performance regression
> * Complete documentation coverage
> h3. Additional Notes
> * This migration aligns Apache Geode with modern Java enterprise standards
> and ensures long-term compatibility with evolving Java ecosystem.
> * The work should be coordinated with any planned Spring Framework upgrades.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
