1. Testing
1.1. Ensured all existing unit tests work
1.2. Dedicated manual QA to compare against older version of the app
1.3. Added unit tests for all new code or refactoring
2. Describe the process and challenges of upgrading a legacy Java EE App in 2022.
3. Build
3.1. Before
3.1.1. Builds and deployments via simple Jenkins jobs
3.1.1.1. Ant scripts, custom Java code, Jython scripts, running on a Windows box
3.1.1.1.1. Build scripts not managed in version control
3.1.2. Everyone built the app locally with RAD
3.1.2.1. Used proprietary Ant-based JAX-RPC code generation tools
3.1.3. 3 EARs
3.2. After
3.2.1. Builds and deployments using Jenkins pipelines
3.2.1.1. Used multi-branch Bitbucket plugin for automatically building branches and PRs
3.2.1.2. Builds running on a Docker container using RHEL
3.2.2. Multi-module Maven project
3.2.2.1. Delegates to some IBM Ant tasks (not available via Maven) used by the original build for deployment
3.2.2.2. Used was-maven-plugin for deployment
3.2.2.3. Included hacks to get Eclipse WebSphere plugin to recognize WAR files
3.2.3. 4 WARs
3.3. Pain points
3.3.1. Several JARs weren't in Maven Central
3.3.1.1. - IBM JWL - IBM ILog Jrules - IBM JAX-RPC - IBM WS admin libraries - Infagistics NetAdvantage for JSF
3.3.2. No internal Maven repo
3.3.2.1. Created local repo and stored in git
3.3.3. Character encoding in source code
3.3.4. Some libraries require the IBM JDK
3.3.5. Integrating Ant tasks with Maven and ensuring code generation was done properly
4. Version control
4.1. Before
4.1.1. Legacy version control system (MKS Integrity) used only for this application
4.2. After
4.2.1. Copied all of the code into a new bitbucket git repo
4.2.2. No history retained
4.3. Pain points
4.3.1. Code we received wasn't the latest
4.3.2. Team not familiar with git (using SVN for other projects)
5. Documentation
5.1. Before
5.1.1. Scattered, outdated, some in SharePoint (maybe?)
5.2. After
5.2.1. Added extensive documentation using markdown in README files, some on Confluence
6. Takeaways
6.1. Java/Jakarta EE and Java are extremely backwards compatible
6.2. For upgrade projects, upgrading the legacy Java code may not be most complex or time-consuming task
6.2.1. Builds / CI / CD
6.2.2. New Features (Okta integration)
6.2.3. Version Control
6.2.4. Documentation
6.3. Change as little as possible
6.4. Having QA resources that can compare to the existing app is key
6.5. Try to make things easier for those who come after you
7. First version released 12 years ago
7.1. Over 550,000 lines of Java code
7.2. Over 550 web pages and includes (only 1/2 in use)
7.3. 4 apps sharing some core business logic and services
7.3.1. Backoffice internal web app
7.3.2. 2 public facing web apps
7.3.3. SOAP web services
8. Project goal: upgrade legacy app to work with a recent, supported version of WebSphere
8.1. Had pleasure of working with BalusC (Bauke Scholtz) of OmniFaces / The Definitive Guide to JSF / Stackoverflow fame
8.2. Move to a supported Java or JakartaEE application server
8.3. Integrate with new cloud-based version of the app
8.4. Will be replaced in 2-3 years
8.5. Replace existing security with Okta
9. Code
9.1. Before
9.1.1. WebSphere Application Server (WAS) 7
9.2. Before
9.2.1. IBM JDK 6
9.2.2. Java EE 5
9.2.2.1. Servlet 2.5
9.2.2.2. JSP 2.1
9.2.2.3. JSF 1.2 (Apache MyFaces)
9.2.2.4. JAX-RPC 1.1
9.2.3. Infragistics NetAdvantage for JSF 2009 Volume 2 (9.2) (UI Components)
9.2.3.1. Latest version was released November 2009, shortly before Java EE 6 / JSF 2.0 release at December 2009
9.2.4. IBM JavaServer Faces widget library (JWL)
9.2.4.1. Ships with RAD / IBM WAS
9.2.5. Apache MyFaces Tomahawk 1.1.14 for JSF 1.2
9.3. After
9.3.1. IBM JDK 8
9.3.1.1. Max supported by WAS 9
9.3.2. Java EE 7
9.3.2.1. JAX-RPC 1.1
9.3.2.2. JSF 2.2 (Apache MyFaces 2.2.8)
9.3.2.3. Servlet 3
9.3.3. Infragistics NetAdvantage for JSF 2009 Volume 2 (9.2) (UI Components)
9.3.3.1. Latest version was released November 2009, shortly before Java EE 6 / JSF 2.0 release at December 2009
9.3.4. IBM JavaServer Faces widget library (JWL)
9.3.4.1. Ships with RAD / IBM WAS
9.3.5. Apache MyFaces Tomahawk 1.1.14 for JSF 2.0
9.4. Pain points
9.4.1. JSF changes
9.4.1.1. Infragistics components for JSF 1.2 worked with minimal changes
9.4.1.2. IBM JWL were deprecated/removed in favor of JSF 2.x and/or plain vanilla JS
9.4.1.2.1. Required minor changes to quite a few pages
9.4.2. Web Services
9.4.2.1. Obfuscated errors
9.4.2.2. Understanding how code generation interacts with hand-coded artifacts
9.4.3. Poor error handling
10. App Server
10.1. After
10.1.1. WebSphere Application Server (WAS) 9 Full Profile
10.1.1.1. Evaluated Liberty and other options, but we needed support for JAX-RPC
11. Security
11.1. Web Services
11.1.1. Before
11.1.1.1. All apps on-premise in same network; no security
11.1.2. After
11.1.2.1. New apps in cloud, legacy app on-premise
11.1.2.1.1. Added machine-to-machine OAuth 2 Client Credentials grant type
11.2. Public JSF Apps
11.2.1. Before
11.2.1.1. IBM WebSeal with IBM Security Access Manager (ISAM)
11.2.1.2. Custom database authorization using JDBC and DB2
11.2.1.3. Used for both legacy app and new app
11.2.2. After
11.2.2.1. Integration with Okta through OAuth2 Authorization Code grant type
11.2.2.1.1. Custom Servlet Filter
11.2.2.1.2. Custom Servlet
11.2.2.2. Okta provides auth for both legacy and new apps
11.3. Internal JSF App
11.3.1. No security changes
11.4. Pain points
11.4.1. Okta docs not so great
11.4.2. Primary Java examples are for Spring Boot