Apache POI Jar Conflict

[surendra_Gollapudi (Suren G)]

Hi,

I created a java service to read an excel(.xlsx and .xlx) files (Note: .xls works fine) . For this I loaded Apache POI 5.0 jars under \code\jars\static and updated manifest.v3 of my package and add the following line :

 <value name="classloader">package</value>

I’m getting below error when I execute this service. Not sure which Jar is causing this issue. Can someone please provide some suggestion what might be causing this issue?

org.apache.commons.compress.archivers.zip.ZipArchiveInputStream is not implementing InputStreamStatistics.

[Nagendra_Prasad]

Hi @surendra_Gollapudi ,
There is limited information in the question, but I’ll take a shot.
From a bit of googling , it appears that the apache POI needs a newer version of the commons.compress jar, have you confirmed that the apache poi and commons.compress are compatible?
Could you provide the version of IS that you are using?
Also provide a code sample of how you are trying to read the excel , and the full error stack trace.

You can refer this old thread - Error with get xlsx file if that helps.

-NP

[surendra_Gollapudi (Suren G)]

Hi Nagendra,

Thank you for the response ! We’re using common-compress1.19.jar which is compatible with apache POI version 5.0, also tried with version 1.20 and 1.21 without any luck. We’re using 10.5 and fix level is IS_10.5_Core_Fix13.
readExcel.txt (4.9 KB)
Attached sample code to process simple excel file.

Error: java.lang.IllegalArgumentException: InputStream of class class org.apache.commons.compress.archivers.zip.ZipArchiveInputStream is not implementing InputStreamStatistics.

[reamon]

This doesn’t address the question but I would encourage that if there is any way possible that you avoid the need to read or create Excel files. This a YMMV item for sure but there are many ways that your integration can break due to seemingly innocuous changes in how the Excel file is created/populated. If the creation is via a controlled and automated process, might be okay. But if it has any human editing at all, be afraid.

[Nagendra_Prasad]

Hi @surendra_Gollapudi ,
In the attached code, I only see an import for the classes ZipArchiveInputStream and InputStreamStatistics and they are not directly referred in the code , it is not clear which line is actually throwing this exception, can you please clarify?
Also the error log should have more information about the origin of the error, could you share that too? You can get them from the Admin → Logs->Error (expand stacktrace)

-NP

[surendra_Gollapudi (Suren G)]

Hi Nagendra, It’s failing while calling Workbook wb = new XSSFWorkbook(ExcelFileToRead); line and goes catch block. I don’t see any other error in error logs. I have been working with SoftwareAG support for 2 months to find the root cause, but no luck.

Thanks,
Surendra.

[Nagendra_Prasad]

There is probably another version of ZipArchiveInputStream somewhere in the classpath which is already loaded and it doesn’t implement InputStreamStatistics, You can run the following code in a java service to figure out where this class is loaded from

IDataMap map = new IDataMap(pipeline);
String location = org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.class.getProtectionDomain().getCodeSource().getLocation().toString();
map.put("loc", location);

-NP

[surendra_Gollapudi (Suren G)]

Hi Nagendra, I have already tried that. Path is under /softwareag105/profiles/IS_Dev/configuration/org.eclipse.osgi/465/0/.cp/lib/commons-compress-1.19.jar which is strange since I loaded Jar under \code\jars\static. I deleted the Jar under folder /softwareag105/profiles/IS_Dev/configuration/org.eclipse.osgi/465/0/.cp/lib/, but I still it in same location after server restarted.

It should be working since Jar under /softwareag105/profiles/IS_Dev/configuration/org.eclipse.osgi/465/0/.cp/lib/ is implementing InputStreamStatistics.

Thanks,
Surendra.

[Nagendra_Prasad]

Can you please try moving your jar from package/code/jars/static to just package/code/jars, since jars under code/jars/static are expected to be available to the whole Integration Server and not just the package and therefore the package classloader wouldn’t come into the picture.
From the 10.5 IS Admin guide , page 659

The jar files in code/jars folder are loaded by the Package class loader and jars files in code/jars/static folder are loaded by the Integration Server class loader.

Since the jar in the osgi bundle commons-compress is already loaded, there could be some clashes.
-NP

[surendra_Gollapudi (Suren G)]

Hi Nagendra, Yes I removed Jars from code/jars/static to code/Jar and restarted the server. I get “java.lang.NullPointerException” now and don’t see jars in Integration about page. Is there some parameter that need to be added in order to see jars under Server Classpath in IS about page?

[Holger_von_Thomsen]

Hi Suren,

when the jar is loaded from code/jars, it will not be listed in the about page.

About page only lists jars which are configured in ini.cnf of the IS or loaded from code/jars/static (which is only required when the jars have a native lib part like the SAP JCo jars).

Regards,
Holger

[Nagendra_Prasad]

@surendra_Gollapudi

I get “java.lang.NullPointerException” now

Can you specify which line of the code throws that? Do you see more details in the IS error log or the Designer logs?

-NP

[surendra_Gollapudi (Suren G)]

Hi Nagendra, I get this error at
String path5=org.apache.commons.compress.utils.InputStreamStatistics.class.getProtectionDomain().getCodeSource().getLocation().getPath(); I do not see stack trace error in error logs.

and java.lang.ExceptionInInitializerError at XSSFWorkbook wb = new XSSFWorkbook(ExcelFileToRead);

Hi @Holger_von_Thomsen - Yes you are correct. Files under code/jars are not added to Server classpath.

[Nagendra_Prasad]

Hi @surendra_Gollapudi
You can ignore the Nullpointer for InputStreamStatistics since you are not getting the ZipArchiveInputStream does not implement error anymore.

The ExceptionInInitializerError seems to be particular to certain versions of apache poi and not necessarily caused due to Integration Server, You can try a couple of things here

1. Rule out problems with package classloading by running the same code as a standalone java program with different versions of the jars.
2. Then you can place the same set of jars and try in a java service.

-NP

[surendra_Gollapudi (Suren G)]

Hi @Nagendra_Prasad - Standalone program works fine with same set of jars which I loaded under code/jars folder. I’m stuck at this point.

Is it possible to update OSGI loader not to load common-compress.jar under below locations ?

/profiles/IS_Dev/configuration/org.eclipse.osgi/465/0/.cp/lib/commons-compress-1.19.jar
/profiles/IS_Dev/configuration/org.eclipse.osgi/463/0/.cp/lib/commons-compress-1.19.jar

Thanks,
Surendra.

[Nagendra_Prasad]

Regarding the error ,

@surendra_Gollapudi

java.lang.ExceptionInInitializerError at XSSFWorkbook wb = new XSSFWorkbook(ExcelFileToRead);

there should be more details in the Integration Server Error log, you can check the Admin UI → Logs->Error with stacktrace expanded.

Based on this , you can try to confirm if the classes are loaded from OSGI bundles are interfering with the package classloader using the java code mentioned earlier ( class.getProtectionDomain…), try checking for a class within the commons-compress jar.
If the result points to the osgi bundle location, then you can mention in the support ticket that package classloader is not honored.

Edit: I would also suggest to try with a different installation to rule out problems specific to this installation.

-NP

[surendra_Gollapudi (Suren G)]

Hi @Nagendra_Prasad - Yes, ( class.getProtectionDomain…) returns OSGI bundle location which is causing conflict issue. I mentioned the same to SoftwareAG support, but haven’t heard back from them yet. .I’ll try installing in different location which will take some time, however it doesn’t solve the problem since I have the same issue in test/prod environments. Thank you and appreciate your help on this one.

Thanks,
Surendra.