Examining Clarity's Custom Modules

Successful upgrades begin with a thorough code audit. Clarity’s insurance plan application relies on a mix of custom portlets, REST APIs, and persistence layers. To ensure a predictable upgrade to Liferay DXP 2026.Q1 LTS, the team must first inventory all direct and transitive dependencies on the legacy javax.* namespace.

In this exercise, you’ll perform a comprehensive scan of Clarity’s custom modules to identify code patterns and libraries that require migration to Jakarta EE.

Exercise: Performing a Pre-Upgrade Inventory

Upgrading to a Jakarta-based environment involves a fundamental namespace shift. Here, you’ll audit Clarity’s codebase for javax usage, service builder configurations, and third-party library compatibility.

Open a terminal in the course workspace’s root folder and navigate to the modules/ folder.
Confirm these modules are present in the folder:
- clarity-insurance-benefits-tracker
- clarity-template-context-contributor
- sleeping-context-contributor
These are the project folders you’ll search for dependencies that require upgrading.
Run this command to find the configuration files for REST builder modules:
```
find . -name rest-config.yaml -o -name rest-openapi.yaml
```
Run this command to find the configuration file for service builder modules:
```
find . -name service.xml
```
Note the location of each file.

You’ll upgrade these files in a future exercise. For now, search for all Java API references across the modules.
Use your preferred IDE or tool to identify direct references to the javax namespace within each module.
Common examples include:
- javax.ws.rs.* (REST APIs)
- javax.portlet.* (MVC portlets)
- javax.servlet.* (filters or servlet interactions)
- javax.annotation.*
- Other javax.* imports
NOTE
Alternatively, run this command from within the modules/ folder to find all references of the javax namespace:
```
grep -r "import javax." .
```
While some modules may not declare javax imports directly, they may rely on Java-based transitive dependencies. To find these references, you’ll use the dependencies Gradle command.
Execute this command to run a dependency report for the clarity-insurance-benefits-tracker-rest-client module:
```
blade gw :modules:clarity-insurance-benefits-tracker:clarity-insurance-benefits-tracker-rest-client:dependencies | grep "javax"
```
This Gradle task scans your build.gradle code for transitive Java EE dependencies, then uses the grep tool to print only the lines containing the javax expression.

NOTE
While a specific module was used, this command works for all Gradle-based modules in your project.
Note down all javax references and categorize them into groups (e.g., MVC portlets, transitive) for your migration checklist.
Next, you’ll locate specific tag libraries that use legacy Java APIs.
Search for Java-based taglib URIs (e.g., java.sun.com) across the modules using this command:
```
grep -r "java.sun.com" .
```
These URIs indicate a pre-Jakarta JSTL or Portlet taglib. While Liferay typically updates them automatically, they should be noted for future validation.

NOTE
You may need to manually upgrade custom or external tag libraries to a newer, Jakarta-compliant version to ensure JSP compatibility.
Run this command to locate all build.gradle files across the modules:
```
find . -name build.gradle
```
Open each file, analyze the dependencies section, and record all external libraries that might not yet support Jakarta. Specifically, look for:
- Non-Liferay dependencies
- Older or unmaintained libraries
- Explicit references to javax.*
This list will be useful for updating, replacing, or refactoring third-party libraries.

Great! You’ve searched Clarity’s REST and service builder modules for legacy Java APIs and created a comprehensive inventory of:

Java EE-based modules
Transitive javax.* dependencies
Third-party dependencies

This list ensures that every area requiring investigation, validation, or refactoring is tracked for the Jakarta upgrade.

Conclusion

Scanning your codebase and planning for module-level upgrades is a crucial step to successful Jakarta upgrades. By identifying javax usage and dependency risks in advance, you reduce the risk of incompatible code and runtime errors in the new Jakarta-based environment.

Next, you’ll consider how to protect critical components before beginning your upgrade.