Zip64 format not supported in Springboot fat executable jar

GroupDocs.Conversion Product Family
,
1

Dear Groupdocs Team,

Not sure if the issue of “zip64 format not supported” in Springboot fat executable jar is resolved or not.
We found Groupdocs.Coversion product to be suitable for our business requirement and we have tested its capabilities with evaluation copy of version 17.12.
We are in the process of procurement, however we found the same issue while moving further with our deployments. Currently we are using Springboot version 2.1.8.RELEASE.
Can you please confirm if this issue is fixed in the latest available version 21.7? If yes, which Springboot version is compatible to work with the latest Groupdocs.Conversion module.?

Thanks

1 Like
2

@ChourasiyaRajesh

We are looking into this scenario. Your investigation ticket ID is CONVERSIONJAVA-1486. We’ll notify you in case of any update.

3

Dear Team,
We found that SpringBoot version >= 2.2.0.RELEASE supports zip64 format and tested Groupdocs version 21.10 is successfully deployable without error.
However, going forward with this version when we try to convert any document (example docx file) with images within the document, unfortunately, the conversion fails with the error mentioned below:

Caused by: java.lang.IllegalArgumentException: vendorName == null!
at javax.imageio.spi.IIOServiceProvider.(IIOServiceProvider.java:76)
at javax.imageio.spi.ImageOutputStreamSpi.(ImageOutputStreamSpi.java:91)
at com.sun.media.imageioimpl.stream.ChannelImageOutputStreamSpi.(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
… 155 more

We tried different approaches to set the values in manifest.mf file however, didn’t find any solution to this case. Also, we observed that this works well on Windows system and the issue occurs only in Linux environment.

Please let us know any other reference/thread which we can look upon and proceed with Groupdocs.Conversion 21.10.

Thanks.

4

@ChourasiyaRajesh

We’re still investigating this scenario. You’ll be notified in case of any update.

5

Hi @Atir_Tahir
Do you mean investigation related to " java.lang.IllegalArgumentException: vendorName == null!" ?

6

@ChourasiyaRajesh

Yes. Could you please also share the sample project/application using that issue could be reproduced?

7

@Atir_Tahir Thanks for your reply. Not sure I would be able to provide you the sample application as I mentioned that this issue we have encountered on our Linux integration environment however, this works fine while running locally on windows with IntelliJ IDE.

Perhaps it would be similar to the one which we found over the below link

Currently we are using Groupdocs.Conversion version 21.10 with SpringBoot version 2.3.11.
Request you to let us know if there is any solution to the problem as we are in the process of procurement.

Thanks

1 Like
8

@ChourasiyaRajesh

If you can share the sample application. We’ll investigate it on the same environment. Or could you please share a screencast/video of this issue?

9

@ChourasiyaRajesh

You can can try one of these workarounds:

  1. Do not include GroupDocs Conversion jar in your project jar, use as external jar
  2. Include the following lines in your MANIFEST.MF file:
Specification-Title: Java Advanced Imaging Image I/O Tools
Specification-Version: 1.1
Specification-Vendor: Sun Microsystems, Inc.
Implementation-Title: com.sun.media.imageio
Implementation-Version: 1.1
Implementation-Vendor: Sun Microsystems, Inc.

You can use your own values for these properties. But it’s important to add the properties.

10

Hi @Atir_Tahir

The manifest entries didn’t helped.
We tried different ways to provide the jar separately, however, in that case the System throws NoClassDefinitionFound error for the obvious reason as the jar is not included in the BOOT-INF/lib path of the Spring Boot fat jar.

When we include it from System Scope (through “includeSystemScope”), the jar gets included in the BOOT-INF/lib path, the System shows the same vendorName==null error.

Let us know for any alternative solution.

Thank you
Rajesh Chourasiya

11

@ChourasiyaRajesh

Please share a screencast/video of this issue. We’ll then further look into it.

12

Hi @Atir_Tahir

Thanks for your help. It worked while using it as an unpacked jar.

1 Like
13

@ChourasiyaRajesh

Glad to know that the issue is fixed.

14

Hello @Atir_Tahir

In continuation to this topic, we would like to let you know that the real cause of this issue was jar within a a jar:

Analysis: When we build our SpringBoot application, it creates an executable fat jar where the GroupDocs-conversion jar resides inside SpringBoot fat jar as a dependency. While third party Service Provider registrations during document conversion, the Java API encounters a IllegalArguentException as it was unable to read the manifest file entries and get the VendorName value from manifest to set in API.

Solution Approach: We tried different approaches for Manifest entries however hard luck. The issue has a probable solution if the jar is provided as external dependencies which works well while using IDEs, however within the same OS environment if the fat jar is executed (say with command “java -jar <jar_name>”) the issue can be replicated.
As a solution SpringBoot’s Maven plugin provides a tag during fat jar creation where the provided jar’s can be marked for unpacking during runtime. This is shown as below:

image.png (2.5 KB)

The main issue at this point is Spring Boot unpacks it in OS temporary directory. So, in different deployment environments, this raise a risk of temp file getting deleted at any point of time by any unknown separate scheduled running script.

It would be great if we can have a solution to this case. Can’t we use the groupdocs jar within the executable jar without unpack?

Please let us know for more information.

Thank you
Rajesh Chourasiya

1 Like
15

We are further investigating this scenario (CONVERSIONJAVA-1486). You’ll be notified in case of any update.

16

Hello @Atir_Tahir,

Do we have any update on this issue?

Thank you
Rajesh Chourasiya

17

@ChourasiyaRajesh

This issue is still under investigation.

18

Thanks @Atir_Tahir for your response.
Actually, this may create an issue for us if at some specific restricted environments, System (here Spring process) don’t have permission to create files in /tmp directory. In that case, either the deployment or the PDF Conversion process would fail.

19

@ChourasiyaRajesh

We are investigating this scenario and looking for a possible solution. You’ll be notified in case of any progress.

20

A post was split to a new topic: SpringBoot’s Maven plugin