OpenAM has doubled in size since version 14

I noticed 16 was a lot bigger than it used to be so got Claude to take a look, here's what it came up with - some of these can totally be ignored (like including embedded OpenDJ)

The WAR contains 318 JARs. Here's what stands out as genuinely problematic:

Duplicate/conflicting stacks:

Two Cassandra Java drivers: java-driver-core-4.17.0.jar AND java-driver-core-4.19.2.jar — two different versions of the same DataStax driver coexist. Same story with java-driver-query-builder-4.17.0.jar sitting alongside java-driver-core-4.19.2.jar. That's not a transitive conflict that got mediated — both physically landed in the WAR.
Two shaded Guava copies for Cassandra: java-driver-guava-shaded-4.19.2.jar AND java-driver-shaded-guava-25.1-jre-graal-sub-1.jar — two separately-shaded Guava bundles from the two driver versions.
Two Restlet copies: org.restlet-16.0.6.jar (the Jakarta-transformed version) AND org.restlet-2.4.4.jar (the original) — both are in the WAR simultaneously, along with the Jakarta-transformed ext JARs (org.restlet.ext.jackson-16.0.6.jar etc.) but also org.restlet.ext.freemarker-2.4.4.jar from the original. That's two full Restlet runtimes.
Two aopalliance JARs: aopalliance-1.0.jar and aopalliance-repackaged-3.0.6.jar — different coordinates, same API.
Two javax.activation / jakarta.activation stacks: javax.activation-api-1.2.0.jar alongside jakarta.activation-2.0.1.jar and jakarta.activation-api-2.0.1.jar.
Two JAXB generations: jaxb-api-2.3.1.jar + jaxb-core-2.3.0.1.jar + jaxb-impl-2.3.2.jar (JAXB 2.x) alongside jaxb-core-3.0.2.jar + jaxb-runtime-3.0.2.jar (JAXB 3.x/Jakarta). Both fully present.
Two javax.xml.soap / jakarta.xml.soap stacks: javax.xml.soap-api-1.4.0.jar and jakarta.xml.soap-api-2.0.1.jar.
Two validation-api JARs: validation-api-1.1.0.Final.jar (Bean Validation 1.1, javax) and jakarta.validation-api-3.0.2.jar (Jakarta). Both present.
Two HTTP client generations: Apache HttpClient 4.x (httpclient-4.5.13.jar, httpcore-4.4.14.jar, httpclient-osgi-4.5.13.jar, httpasyncclient-4.1.4.jar, httpcore-nio-4.4.14.jar, httpcore-osgi-4.4.14.jar) alongside HttpClient 5.x (httpclient5-5.3.1.jar, httpcore5-5.2.4.jar, httpcore5-h2-5.2.4.jar). That's two complete Apache HTTP stacks.
Two BouncyCastle families: bc-fips-2.1.2.jar + bcpkix-fips-2.1.10.jar + bctls-fips-2.1.22.jar + bcutil-fips-2.1.5.jar (the FIPS suite) and bcpkix-shaded-16.0.6.jar (the shaded non-FIPS version). So yes, two BC stacks physically present.

Genuinely alarming items:

jruby-9.2.20.1.jar + jruby-core-9.2.20.1.jar + jruby-stdlib-9.2.20.1.jar — a full JRuby runtime is in there. This is almost certainly pulled in by asciidoctorj-2.5.3.jar (AsciidocJ requires JRuby to run). AsciidocJ is a documentation generation tool — it has absolutely no business being in a production server WAR.
asciidoctorj-2.5.3.jar + asciidoctorj-api-2.5.3.jar — confirms above. These are build/doc tools.
mssql-jdbc-12.10.2.jre11.jar + mysql-connector-j-9.2.0.jar + postgresql-42.7.8.jar + ojdbc8-23.7.0.25.01.jar — all four major JDBC drivers bundled. You'll only ever use one (or none, if using LDAP/DJ for everything). Three of these are always dead weight.
groovy-all-2.4.21.jar — the full groovy-all monolith rather than just groovy-core. This includes the Groovy compiler, Swing bindings, SQL module, test framework, etc.
servlet-api-2.4.jar — a 2004-era Servlet 2.4 API JAR sitting in WEB-INF/lib alongside modern Jakarta Servlet. This should be provided scope and never land in the WAR.
batik-* JARs (SVG rendering library from Apache) — batik-constants, batik-css, batik-i18n, batik-util, batik-shared-resources + xmlgraphics-commons, jai-imageio-core. This is a heavyweight SVG/graphics rendering stack used by the legacy console's image generation. Not needed for auth/SSO operations.
nashorn-core-15.4.jar — a Nashorn JavaScript engine polyfill for Java 15+ (Nashorn was removed from the JDK). Since OpenAM also has Rhino (rhino-1.7.14.1.jar), there are now two JavaScript engines in the WAR.
xalan-2.7.3.jar + xercesImpl-2.12.2.jar + xml-apis-1.4.01.jar — the ancient Xalan XSLT and Xerces XML parser stack, both redundant when modern Java has built-in XML support. Xalan in particular has a long CVE history.
neko-htmlunit-3.11.1.jar — an HTML parser, appears to be pulled in by the WebAuthn or scripting module.
jdmkrt-2007-01-10.jar — a 2007 Sun JDMK (Java DMK) runtime for SNMP monitoring. Ancient and large.
isorelax-20030108.jar — a 2003 RELAX NG schema library. Almost certainly dead.
bsh-2.0b6.jar — BeanShell scripting engine, another scripting runtime alongside Groovy, Rhino, JRuby, and Nashorn.

Here's the full picture visually:A few things stand out that are worth calling out beyond what's in the visual:

The JRuby situation is the most egregious. asciidoctorj is a library for rendering AsciiDoc documentation — it has zero runtime function in a running auth server. It likely crept in as a dependency of openam-documentation or something in the audit/reporting modules that generates docs during build but was mistakenly scoped as compile instead of being excluded. The JRuby stdlib alone is roughly 20 MB. Filing this as a bug upstream would be entirely reasonable.

The dual Cassandra driver versions strongly suggest the two Cassandra submodules (openam-cassandra-datastore and openam-cassandra-cts) have diverged and aren't pinned to the same driver version in their own POMs. One is pulling 4.17.0 and the other 4.19.2, and Maven's dependency mediation didn't collapse them because they both physically ended up in the WAR rather than being resolved at the classpath level (since both submodule JARs are included as first-class dependencies).

The dual Restlet situation (2.4.4 + 16.0.6) is a consequence of the Jakarta transform approach — the project creates transformed copies at the project version but didn't add packagingExcludes entries for the original 2.4.4 originals. The org.restlet.ext.freemarker-2.4.4.jar sitting alongside the transformed 16.0.6 versions is a particularly clear sign of this.

On OpenDJ specifically: opendj-ldap-toolkit contains the command-line administration tools (ldapsearch, ldapmodify etc.) — there is no reason these need to be in a production WAR. opendj-rest2ldap is the REST-to-LDAP gateway component, also not needed inside the WAR. Those two alone are probably several MB that serve zero purpose at runtime.

For a practical attack plan in rough effort/reward order: remove AsciidocJ+JRuby (trivial exclusion, massive reward), fix the packagingExcludes to drop the pre-transform Restlet 2.4.4 JARs, align the Cassandra driver versions across the two submodules, add packagingExcludes for the three JDBC drivers you don't use, and add <scope>provided</scope> to servlet-api-2.4.

[OpenIdentityPlatform/OpenAM#980] Resolve duplicate dependencies (#172)

[OpenIdentityPlatform/OpenAM#980] OpenDJ slim maven artifact (#625)

[#980] Remove duplicated and redundant dependencies, use OpenDJ embed…

Whoop, thanks, I'll give this a check once a new release is cut

I downloaded one of the artifacts from your CI to see how things hae improved (30MB smaller, nice)

Again got AI to analyse the libs directory:

Reviewing the WEB-INF/lib directory of an enterprise identity access management system like OpenAM is a great practice. Because this is a 16.0.7-SNAPSHOT build (likely from the Open Identity Platform community fork of ForgeRock's OpenAM), the classpath reflects a mix of modern updates and legacy technical debt.

Based on the directory listing, here are the conflicts, security concerns, and unnecessary inclusions that stand out:

Version Conflicts & Classpath Clashes
These are libraries where multiple versions or competing implementations exist, which can lead to unpredictable NoSuchMethodError, NoClassDefFoundError, or classloader leaks.

Jackson Version Mismatch:

jackson-dataformat-smile-2.17.0.jar

jackson-core-2.18.6.jar (and all other Jackson modules at 2.18.6)

Issue: Jackson modules are tightly coupled. Mixing minor versions (2.17 vs 2.18) is a notorious cause of runtime serialization crashes.

Logging Implementations (The SLF4J / Commons-Logging clash):

jcl-over-slf4j-2.0.17.jar

commons-logging-1.1.3.jar & commons-logging-api-1.1.jar

Issue: jcl-over-slf4j is specifically designed to completely replace commons-logging by intercepting its calls. Shipping both in the same lib folder defeats the purpose and often causes infinite logging loops or duplicate log entries.

Duplicate Rhino (JavaScript Engine) Engines:

rhino-1.7.14.1.jar

org.apache.servicemix.bundles.rhino-1.7.15_1.jar

Issue: Two different versions of Mozilla Rhino are present. The JVM will arbitrarily pick one to load first, potentially breaking whichever script relies on the other's specific bindings.

The javax.* vs jakarta.* Split:

You have both jaxb-api-2.3.1.jar (legacy javax.xml.bind) AND jakarta.xml.bind-api-3.0.1.jar (modern jakarta.xml.bind).

You have both javax.annotation-api-1.3.2.jar AND jakarta.annotation-api-2.0.0.jar.

Issue: While sometimes necessary if legacy OpenAM code hasn't been fully migrated to Jakarta EE, shipping both namespaces bloats memory and increases the risk of ClassCastExceptions when passing XML or servlet objects between modules.

Security & Outdated Dependencies
While many of your core utilities (like SnakeYAML, Guava, and Jackson) are reasonably up to date, a few stand out as potential security or stability risks.

Ancient AWS SDK:

aws-java-sdk-core-1.10.72.jar

Issue: The 1.10.x branch dates back to ~2016. It is missing years of security patches, optimized retry logic, and modern TLS cipher suite support. AWS SDK v1 is officially in maintenance mode; v2 is the standard.

Legacy Apache Commons Lang:

commons-lang-2.5.jar (Alongside modern commons-lang3-3.18.0.jar)

Issue: Version 2.5 was released in 2010. While OpenAM likely retains it because an older transitive dependency requires it, it represents unmaintained code in a security-critical application.

Groovy 2.4:

groovy-all-2.4.21.jar

Issue: The Groovy 2.4.x line is End-of-Life. Older Groovy versions have historically struggled with remote code execution (RCE) vulnerabilities via deserialization (e.g., CVE-2016-6814), though risk depends on how OpenAM handles scripted authentication modules.

Things That "Shouldn't Be There" (Deployment Bloat)
A production .war file should only contain what is required at runtime. Several items here look like build-time or test-time dependencies that "leaked" into the packaging phase.

Test Frameworks:

test-3.1.0.jar

test-utils-3.1.0.jar

Issue: Test libraries should be marked with test in Maven/Gradle and kept out of production builds to reduce attack surface and memory footprint.

Compile-Time Annotations:

checker-qual-3.40.0.jar

error_prone_annotations-2.43.0.jar

jspecify-1.0.0.jar

Issue: These are used by IDEs and compilers (like Google's Error Prone) to check for nullability and threading issues during the build. They do nothing at runtime and just take up space.

CLI Tools:

opendj-cli-5.1.0.jar

openam-cli-impl-16.0.7-SNAPSHOT.jar

openam-license-manager-cli-16.0.7-SNAPSHOT.jar

Issue: Command-line interface logic rarely belongs inside the web application container.

Architectural Notes
Multiple HTTP Clients: You are shipping Apache httpclient-4.5.13 (legacy), httpclient5-5.4.4 (modern), AND httpasyncclient-4.1.4, alongside Jersey and Grizzly HTTP clients. While not strictly a failure, having 4+ different ways to make an HTTP request drastically increases the application's attack surface (e.g., varying susceptibility to HTTP Request Smuggling).

Bouncy Castle FIPS vs. Shaded: You have the strictly regulated FIPS modules (bc-fips-2.1.2.jar) but also a custom shaded version (bcpkix-shaded-16.0.7-SNAPSHOT.jar). Mixing FIPS and non-FIPS cryptography providers in the same JVM requires very careful configuration of the java.security file to ensure secure operations aren't accidentally bypassing the FIPS boundary.

OpenDJ:

The good news is that your OpenDJ build successfully completed! Compared to your OpenAM output, this dependency tree is actually much healthier—many of your core libraries (like Guava 33, Jackson 2.18, the database drivers, and the BouncyCastle FIPS modules) are impressively up-to-date.

However, beneath the BUILD SUCCESS message, there are a few dependency clashes, architectural risks, and Maven configuration issues you should address to keep the project stable.

Here is what stands out:

The Classic Logging Clash
Just like in OpenAM, you have a collision between legacy logging and modern SLF4J logging, specifically within the opendj-rest2ldap and opendj-dsml-servlet modules.

The Conflict:

org.slf4j:jcl-over-slf4j:2.0.17 (Designed to replace Commons Logging)

commons-logging:commons-logging:1.2 (Pulled in transitively by org.apache.httpcomponents:httpclient:4.5.13)

The Issue: Shipping both of these to the classpath defeats the purpose of the SLF4J bridge. It can cause unpredictable logging behavior, duplicate log entries, or classloader confusion at runtime. You should add an for commons-logging on the httpclient dependency.

The Portability Killer: system
If you look closely at the dependencies for the server, you will see these two:

opendmk:jdmkrt:jar:1.0:system

opendmk:jdmktk:jar:1.0:system

The Issue: The system scope is highly discouraged in modern Maven. It means the pom.xml contains hardcoded, absolute file paths on your local machine (e.g., /Users/mlo17/lib/jdmkrt.jar) pointing to these files.

This breaks CI/CD pipelines. If a colleague or a Jenkins server tries to build this project, it will fail unless they have the exact same files at the exact same absolute path.

The Fix: You should upload these to your Sky Artifactory (just like we did for OpenAM) and change their scope from system to compile.

Maven 4 Plugin Incompatibilities
Your build is generating a massive wall of yellow [WARNING] text before it even starts compiling. This is due to bad plugin management in the parent pom.xml.

Version Too High: The project is attempting to use 4.0.0-beta versions of maven-source-plugin, maven-install-plugin, and maven-deploy-plugin. Because you are running Maven 3.9.15, Maven recognizes they are incompatible and gracefully downgrades them (e.g., to 3.4.0 or 3.1.4). Relying on automatic downgrades makes your build unpredictable across different developer machines.

Missing Plugin Versions: You have dozens of warnings about missing plugin versions for cobertura-maven-plugin, clirr-maven-plugin, and maven-source-plugin. Maven 3 allows this, but if you ever upgrade to Maven 4, these warnings will turn into fatal build errors. You need to explicitly define these versions in a block.

Minor Technical Debt
Berkeley DB JE: You are using com.sleepycat:je:18.3.12. This is from 2018. While expected for a ForgeRock/OpenDJ fork (as Oracle changed the licensing model for Berkeley DB after this version, freezing many projects in time), it is unmaintained. Just something to keep in mind for the long-term roadmap.

Testing Frameworks: You are pulling in org.apache-extras.beanshell:bsh:2.0b6 (from 2014) via TestNG. Since it is strictly in the test, it won't impact your production security, but it is ancient code.

I managed to find some of the old dependencies jato, cc*, jdmkrt but I still couldn't get a full mvn dependency:tree due to download failures

Here's the analysis so far:

Based on the provided Maven build log, here is a detailed analysis of the dependency tree, focusing on the build failure, configuration issues, version clashes, and security vulnerabilities.

1. The Root Cause of the Build Failure

The build successfully compiles 106 modules but fails critically at the OpenAM RIA Web UI (openam-ui-ria) module.

The Error:
Maven cannot resolve dozens of frontend dependencies (JavaScript, CSS, LESS files) packaged as Maven artifacts under the group ID org.openidentityplatform.commons.ui.libs.
Examples of missing artifacts: jquery:js:min:3.7.1, react:js:min:15.2.1, bootstrap:js:custom:3.3.5, moment:js:min:2.28.0.

Why is this happening?
At the very beginning of your log, there are hundreds of warnings stating:

[WARNING] 'build.plugins.plugin.version' for org.openidentityplatform.commons:maven-external-dependency-plugin is missing.

This project relies on a custom plugin (maven-external-dependency-plugin) to download raw frontend files (JS/CSS) from the internet and package them as local Maven artifacts. Because the plugin lacks a version declaration in the pom.xml, Maven is likely failing to execute it properly. Consequently, the JS/CSS artifacts are never generated or downloaded, causing the openam-ui-ria module to fail when it looks for them.

2. Dependency Conflicts & Classpath Clashes (The "Javax vs. Jakarta" Split)

The project is undergoing a migration from older Java EE (javax.*) to modern Jakarta EE (jakarta.*), but the transition is incomplete. This split will almost certainly cause ClassNotFoundException or NoSuchMethodError issues at runtime.

Servlet API: You have the modern jakarta.servlet:jakarta.servlet-api:5.0.0 (provided), but older transitive dependencies (like httpunit:1.7) are pulling in javax.servlet:servlet-api:2.3.
JAXB (XML Binding): The tree contains severe fragmentation here:
- jakarta.xml.bind:jakarta.xml.bind-api:4.0.2 (Modern)
- javax.xml.bind:jaxb-api:2.3.1 (Legacy)
- com.sun.xml.bind:jaxb-impl:2.3.2 vs com.sun.xml.bind:jaxb1-impl:2.2.5.1
Mail/Activation: You have both com.sun.mail:jakarta.mail:2.0.2 and the older javax.activation:javax.activation-api:1.2.0.
Woodstox (XML Parsing): You have both the modern com.fasterxml.woodstox:woodstox-core:6.4.0 and the ancient org.codehaus.woodstox:wstx-asl:3.2.6.

3. Vulnerability Analysis (Outdated / Insecure Versions)

While some backend libraries are surprisingly up-to-date (e.g., Jackson 2.18.6, Guava 33.4.8), the frontend libraries and some legacy backend tools are severely outdated and contain known CVEs:

Frontend Vulnerabilities (Once they resolve):

React 15.2.1: Extremely old (2016). Contains XSS vulnerabilities and is entirely unsupported.
Bootstrap 3.3.5: Contains known Cross-Site Scripting (XSS) vulnerabilities (e.g., CVE-2019-8331).
Moment.js 2.28.0: Vulnerable to Path Traversal (CVE-2022-24785). Fixed in 2.29.2.
Handlebars 4.7.7: Has Prototype Pollution vulnerabilities depending on how it's used.

Backend Vulnerabilities:

Log4j 1.x: Found under org.apache.xbean -> log4j:log4j:jar:1.2.12. Log4j 1.x is End-of-Life and contains multiple RCE vulnerabilities. While the project correctly uses log4j-over-slf4j to route logging, the presence of the native log4j artifact on the classpath is a security audit red flag.
Commons Logging: The project imports jcl-over-slf4j to bridge logs, but commons-logging:commons-logging:1.1.3 is still physically present in the tree. This defeats the purpose of the SLF4J bridge.

4. Deprecations & Build Warnings

Deprecated Property: [WARNING] The expression ${build.outputDirectory} is deprecated. Please use ${project.build.outputDirectory} instead.
Missing Site Plugin Version: Warnings state that maven-site-plugin is missing a version definition in the openam-doc-log-message-ref and openam-doc-ssoadm-ref POMs.

Actionable Recommendations

Fix the Build Failure (Immediate Step):
Open the root pom.xml (located at /Users/mlo17/OpenAM/pom.xml) and go to line 1840. You need to define a <version> inside the <plugin> definition for org.openidentityplatform.commons:maven-external-dependency-plugin. Look up what version this project usually uses (often 3.1.0 matching other commons artifacts) and add it to the <pluginManagement> section.
Clean up the "Javax" vs "Jakarta" mess:
Use Maven exclusions to strip out old javax.* dependencies. For example, when declaring the dependency on httpunit, exclude javax.servlet.
```
<exclusion>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
</exclusion>
```
Exclude Log4j 1.x:
Add a global exclusion for log4j:log4j and commons-logging:commons-logging in your root pom.xml dependency management to force all libraries to rely on your SLF4J bridges.
Modernize the Frontend Build:
Relying on Maven to download minified JavaScript files via custom external plugins is highly fragile (as you are experiencing). Modernizing this project to use frontend-maven-plugin (which uses Node/NPM to pull dependencies from the NPM registry via a package.json) is highly recommended to fix both the build stability and the severely outdated React/Bootstrap versions.

[OpenIdentityPlatform/OpenAM#980] import jackson-bom to resolve ambig…

Perhaps related, I noticed that OpenAM 16.0.6 takes a long time (... I know that can be subjective...), to initialize and complete its startup process. Even when deployed in Tomcat on a 4 core machine with lots of ram and heap assigned, it can take 2 minutes or more.

I realize that Tomcat's deployment process is a single thread per app, so more cores won't necessarily help that much.

I have however slowly identified all of the jars that do not have any TLDs, and added them to Tomcat's list of "jarsToSkip" argument in catalina.properties for its TLD scanner, there are many, which helped improve OpenAM startup time.

I have also reviewed the OpenAM performance tuning documentation.

Please share any other additional thoughts or recommendations you may have to further improve OpenAM initialization and startup time.

Thanks.

[#980] Get rid of test and deprecated dependencies (#1010)

Navigation Menu

Repository navigation

OpenAM has doubled in size since version 14 #980

1. The Root Cause of the Build Failure

2. Dependency Conflicts & Classpath Clashes (The "Javax vs. Jakarta" Split)

3. Vulnerability Analysis (Outdated / Insecure Versions)

4. Deprecations & Build Warnings

Actionable Recommendations

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

OpenAM has doubled in size since version 14 #980

Description

Activity

FireBurn commented on Apr 14, 2026

FireBurn commented on Apr 21, 2026

FireBurn commented on Apr 21, 2026

FireBurn commented on Apr 21, 2026

1. The Root Cause of the Build Failure

2. Dependency Conflicts & Classpath Clashes (The "Javax vs. Jakarta" Split)

3. Vulnerability Analysis (Outdated / Insecure Versions)

4. Deprecations & Build Warnings

Actionable Recommendations

joelcharlebois commented on Apr 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions