Reports won't open

Bug #1802208 reported by Michael Sharman on 2018-11-08
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
LibreOffice
Confirmed
Wishlist
libreoffice (Ubuntu)
High
Olivier Tilloy
Xenial
High
Olivier Tilloy
Bionic
High
Olivier Tilloy

Bug Description

Reports that were working as of June this year (I haven't opened them since then) now are failing with the following error:

Can not activate the factory for org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory

I tried creating a fresh report to see if its some kind of out of date file format but I get the same error:
  1. select "Create Report in Design View..."
  2. select "Save"
  3. Double click report
  4. Same error as above

Of course I'm expecting the report to open without an error.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: libreoffice-report-builder 1:6.0.6-0ubuntu0.18.04.1
ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
Uname: Linux 4.15.0-38-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov 8 12:16:08 2018
InstallationDate: Installed on 2018-02-17 (263 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
PackageArchitecture: all
SourcePackage: libreoffice
UpgradeStatus: Upgraded to bionic on 2018-05-01 (190 days ago)

Michael Sharman (msharman) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libreoffice (Ubuntu):
status: New → Confirmed
Olivier Tilloy (osomon) wrote :

I can reliably reproduce the issue when creating a new report, closing it and double-clicking it to open it again.

Changed in libreoffice (Ubuntu):
importance: Undecided → High
Olivier Tilloy (osomon) wrote :

Neither the debs from libreoffice.org nor the snap package seem to be affected. Only the packages in the ubuntu repositories.

Olivier Tilloy (osomon) wrote :

Libreoffice 5.1.6.2 on xenial (1:5.1.6~rc2-0ubuntu1~xenial4) is also affected.

Libreoffice 4.2.8.2 on trusty (1:4.2.8-0ubuntu5.3) is not affected.

Olivier Tilloy (osomon) wrote :

Copying over reportbuilder.jar AND reportbuilderwizard.jar from the upstream build or from the snap "fixes" the issue.

The obvious difference is that those files were built with OpenJDK 11 in the Ubuntu packages, whereas the upstream build uses version 8.

Changed in libreoffice (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
Olivier Tilloy (osomon) on 2018-11-15
Changed in libreoffice (Ubuntu):
status: Confirmed → In Progress
Olivier Tilloy (osomon) wrote :

cosmic and disco are not (yet) affected, because S8195874 (Improve jar specification adherence) was not backported to openjdk there.

bionic and xenial are affected.

Changed in libreoffice (Ubuntu):
status: In Progress → Invalid
Changed in libreoffice (Ubuntu Xenial):
assignee: nobody → Olivier Tilloy (osomon)
Changed in libreoffice (Ubuntu Bionic):
assignee: nobody → Olivier Tilloy (osomon)
Changed in libreoffice (Ubuntu Xenial):
importance: Undecided → High
Changed in libreoffice (Ubuntu Bionic):
importance: Undecided → High
Changed in libreoffice (Ubuntu Xenial):
status: New → Confirmed
Changed in libreoffice (Ubuntu Bionic):
status: New → Confirmed
Olivier Tilloy (osomon) wrote :

I rebuilt libreoffice 6.0.7 for bionic with the debian patch that sets jdk.net.URLClassPath.disableClassPathURLCheck to true, and verified that this was built against a version of the JDK that has the patch to honour that flag, but this hasn't fixed the issue.

Tony Arnold (tony-arnold) wrote :

This problem affected me after upgrading to Ubuntu 18.10. However, setting the Java version to use to OpenJDK 11 fixed this issue for me.

Olivier Tilloy (osomon) wrote :

That's because OpenJDK 11 in 18.10 doesn't have S8195874 (Improve jar specification adherence) yet.

When OpenJDK tried to enforce stricter class path URL checks without previous announcement, things started to break left and right. This included failing LibreOffice JUnitTest checks, since the dependency classpath in our generated Jars doesn't pass the stricter URL checks and therefore is ignored.

The check was disabled later in http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8513ac27b651, but I still think it's worthwhile to fix our Jars and then disable jdk.net.URLClassPath.disableClassPathURLCheck when running the tests.

More info is also in https://gerrit.libreoffice.org/#/c/63118/2

quoting my 2018-11-12 10:34 comment at <https://gerrit.libreoffice.org/#/c/63118> "Simplify and fix Java UNO API test makefiles":

"With Java moving away from supporting absolute file URLs in jar manifest Class-Paths, we need a new solution for what we currently do with gb_Jar_add_manifest_classpath/gb_Helper_make_url. We use that in unotest/Jar_test.mk (which is the subject of this change), but also in gb_Jar_use_system_jar as used in various places in RepositoryExternal.mk. (Note how we already have issues with file URLs in all of these places with recent Java on Windows, see <https://lists.freedesktop.org/archives/libreoffice/2018-September/080884.html> 'Re: make check fails in [build JCS]'.)

"However, from <https://docs.oracle.com/cd/E15289_01/JRRLN/newchanged.htm#GUID-CDE1F31D-EDEA-4FBF-B8CB-F555D09C084C> and the details of <http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1c1392d7c546> '8195874: Improve jar specification adherence', it looks like support for relative paths starting with '..' in jar manifest Class-Paths is also going away. We currently use such at least in bridges/Jar_java_uno.mk, connectivity/Jar_sdbc_hsqldb.mk, and javaunohelper/Jar_juh.mk."

From reading the current URLClassPath.java code, it seem you can set "jdk.net.URLClassPath.disableClassPathURLCheck" to "debug", and the loader will print the ignored class path entries, which can help debugging.

But it doesn't look like there is a way to get the default value, which could be checked by configure or even our jars to want people of failures.

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/905c107cde4a0a7059b1e11b5f23a0a59188cb0c%5E%21

tdf#121925 test for URLClassPath.ClassPathURLCheck

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/c9de94c65b8ab8bf6073400eda5ba848ba22af47%5E%21

tdf#121925 test for URLClassPath.ClassPathURLCheck

It will be available in 6.2.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

These patches are no fixes, but will detect the failing JDK setup during configure as an early warning! They should be reverted after a real fix is merged.

Olivier Tilloy (osomon) wrote :

This appears to have been fixed in an OpenJDK update.
Successfully tested on xenial, bionic and disco.

Changed in libreoffice (Ubuntu Xenial):
status: Confirmed → Fix Released
Changed in libreoffice (Ubuntu Bionic):
status: Confirmed → Fix Released
Changed in df-libreoffice:
importance: Unknown → Wishlist
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.