https://bugs.documentfoundation.org/show_bug.cgi?id=171215
Bug ID: 171215
Summary: Problem of MANIFEST.MF for the libreoffice Core-Lib
Product: LibreOffice
Version: 24.8.4.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: sdk
Assignee: [email protected]
Reporter: [email protected]
libreoffice.jar MANIFEST.MF contains "Class-Path: ../" entry that causes
Jakarta EE / EJB application deployment failures
Description:
The libreoffice.jar (module org.libreoffice.uno) version 24.8.4 ships with the
following entry in META-INF/MANIFEST.MF:
Class-Path: java_websocket.jar unoloader.jar ../
The "../" entry is a critical defect. Per the JAR specification
(https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html),
Class-Path entries are resolved relative to the JAR's location. This means the
parent directory of libreoffice.jar is unconditionally added to the
application's classpath at runtime.
Impact on Jakarta EE applications:
When libreoffice.jar is included as a dependency in a Jakarta EE application
(e.g., via Maven coordinates or direct inclusion), the "../" classpath entry
causes severe classpath pollution:
1. EAR deployments: If libreoffice.jar is placed in the EAR's lib/ directory
(the standard location for shared libraries), "../" resolves to the EAR root.
This causes all EJB module JARs at the EAR root to be loaded a second time by
the library classloader, in addition to the EJB classloader. The application
server (WildFly, GlassFish, Payara, OpenLiberty, TomEE, etc.) then discovers
duplicate @Stateless, @Stateful, @Singleton, and @MessageDriven bean
definitions, causing deployment to fail with errors such as:
- "Duplicate EJB bean definition"
- ClassCastException (same class loaded by two classloaders)
- CDI AmbiguousResolutionException (duplicate bean candidates)
2. WAR deployments: If libreoffice.jar is in WEB-INF/lib/, the "../" resolves
to WEB-INF/, pulling the classes/ directory into the classpath a second time,
causing potential duplicate class issues.
3. The java_websocket.jar and unoloader.jar entries reference JARs that are
specific to the LibreOffice runtime environment and do not exist in standard
application server deployments, generating classloader warnings/errors.
Steps to reproduce:
1. Create a Jakarta EE application (EAR) with at least one EJB module.
2. Add libreoffice.jar 24.8.4 to the EAR's lib/ directory.
3. Deploy to any Jakarta EE compliant application server (e.g., WildFly 30+,
Payara 6, GlassFish 7, TomEE 10).
4. Deployment fails with duplicate EJB / classpath conflict errors.
Expected behavior:
libreoffice.jar should not contain a Class-Path entry in its MANIFEST.MF, or at
the very minimum should not contain the "../" entry. The Class-Path header is
intended for the LibreOffice internal runtime environment and should not leak
into the JAR that is distributed for external use.
Proposed fix:
Remove the Class-Path line entirely from META-INF/MANIFEST.MF:
Manifest-Version: 1.0
Sealed: false
Solar-Version: 24.8.4.2
- Class-Path: java_websocket.jar unoloader.jar ../
Created-By: 1.8.0_432 (Red Hat, Inc.)
This fix has been manually verified to resolve the issue. The LibreOffice UNO
API classes function correctly without this manifest entry when used as a
library dependency, since java_websocket.jar and unoloader.jar are only needed
within the LibreOffice runtime, not by external consumers of the API.
Affected versions: 24.8.4 (confirmed). Possibly other versions if the same
build script generates the Class-Path entry.
Workaround:
Manually repackage the JAR with the Class-Path line removed from the manifest:
mkdir tmp && cd tmp
jar xf libreoffice-24.8.4.jar
# Edit META-INF/MANIFEST.MF to remove the Class-Path line
jar cfm libreoffice-24.8.4-fixed.jar META-INF/MANIFEST.MF -C . .
--
You are receiving this mail because:
You are the assignee for the bug.
