Deprecate on-prem Exchange, migrate non-Exchange HTTP from commons-httpclient 3.x → 4.x (Calendar 3.0.0)

[bjagg]

Tracking issue for a planned Calendar 3.0.0 major release.

Background

CalendarPortlet pins commons-httpclient:3.1-osgi to support on-premise Microsoft Exchange via NTLM auth. The pom carries an explicit comment:

Do not upgrade httpclient to 4.2.5. It errors to on-premise Exchange with NtlmAuthHttpClient Malformed challenge / Unauthorized [401].

This pins the repo to a CVE-affected library: CVE-2012-5783 (commons-httpclient SSL hostname verification disabled) — currently dismissed across the rest of the fleet because the dep is dead weight there, but here it's load-bearing.

The fleet survey ahead of the v50/v51 cycle confirmed Calendar is the only repo with non-trivial commons-httpclient usage, and the only one with NTLM/Exchange entanglement.

Decision

Drop on-prem Exchange support and migrate everything else to org.apache.httpcomponents:httpclient:4.5.14 (already provisioned by uportal-portlet-parent).

Per maintainer judgment, Calendar's on-prem Exchange usage is too thinly deployed to justify the cost of preserving NTLM compat through a full httpclient 4.x rewrite. Customers still on on-prem Exchange will need to either stay on Calendar 2.7.x or migrate to OAuth/modern auth before upgrading to 3.0.0.

Scope

Removed

• adapter/ExchangeCalendarAdapter.java
• adapter/exchange/ (7 files): AutodiscoverRedirectStrategy, ExchangeCredentialsInitializationService, ExchangeWebServiceCallBack, ExchangeWsCredentialsProvider, IExchangeCredentialsInitializationService, JCIFSEngine, NtlmAuthHttpClient
• Spring wiring: src/main/resources/context/calendarContext.xml and portlet/calendar.xml Exchange-related beans
• WSDL: src/main/resources/com/microsoft/exchange/Services.wsdl
• i18n entries referencing Exchange
• commons-httpclient transitive of spring-ws-security if any (verify)

Migrated to httpclient 4.x

• adapter/CalDavCalendarAdapter.java (CalDAV — production relevance: Apple iCloud, Google, Nextcloud)
• adapter/ConfigurableHttpCalendarAdapter.java (generic HTTP iCal feeds)
• credentials/ICredentialsExtractor.java interface + 4 implementations — note that AuthScope/Credentials/UsernamePasswordCredentials from org.apache.commons.httpclient.* map to different shapes in org.apache.http.auth.*; the public ICredentialsExtractor signature changes, which is the breaking change driving the major version bump

Pom

• Drop commons-httpclient:3.1-osgi direct dep
• Drop the <dependencyManagement> xerces/spring-ws-security override pieces tied to commons-httpclient
• Bump <version>2.7.x-SNAPSHOT</version> → <version>3.0.0-SNAPSHOT</version>

Test plan

• CalDAV verified against ≥1 real server (Apple iCloud, Google Calendar, or Nextcloud)
• Generic HTTP iCal feed verified (any public university calendar)
• mvn clean install green on Java 11 matrix
• Existing tests pass after API migration
• One deployer's custom ICredentialsExtractor implementation migration tested (or at least a documented API-change recipe)

Release notes for 3.0.0

• BREAKING: dropped on-prem Microsoft Exchange / NTLM support. Exchange Online / OAuth wasn't supported; deployers depending on on-prem Exchange should remain on Calendar 2.7.x or migrate to a modern calendar protocol (CalDAV/iCal feed).
• ICredentialsExtractor interface: API change from org.apache.commons.httpclient.* types to org.apache.http.auth.* types. Custom implementations need migration.
• Closes CVE-2012-5783 by removing the commons-httpclient dependency entirely.

Out of scope

• Spring 6 / Jakarta EE migration (gated on parent + fleet-wide effort)
• Hibernate 5 → 6 migration (same)
• Major UI refactor

---

Tagged as a planned 3.0.0 release. No timeline commitment — picked up when there's bandwidth and a CalDAV test environment available.