After moving to POI 5.0.0 I get this error:
java.lang.NoSuchMethodError: org.openxmlformats.schemas.wordprocessingml.x2006.main.CTPPrDefault.getPPr()Lorg/openxmlformats/schemas/wordprocessingml/x2006/main/CTPPrGeneral;
at org.apache.poi.xwpf.usermodel.XWPFStyles.setStyles(XWPFStyles.java:145)
at org.apache.poi.xwpf.usermodel.XWPFStyles.onDocumentRead(XWPFStyles.java:84)
at org.apache.poi.xwpf.usermodel.XWPFDocument.onDocumentRead(XWPFDocument.java:207)
at org.apache.poi.ooxml.POIXMLDocument.load(POIXMLDocument.java:169)
at org.apache.poi.xwpf.usermodel.XWPFDocument.<init>(XWPFDocument.java:126)
Where is this CTPPrGeneral class placed?
I tried poi-ooxml-full 5.0.0, poi-ooxml-lite 5.0.0, poi-ooxml-schemas 4.1.2 - There is no CTPPrGeneral class.
Searching in Google does not help. It looks like it mentioned only in XWPFDefaultParagraphStyle class.
The new apache poi 5.0.0 needs poi-ooxml-lite-5.0.0.jar or poi-ooxml-full-5.0.0.jar. Both contain org/openxmlformats/schemas/wordprocessingml/x2006/main/CTPPrGeneral and org.openxmlformats.schemas.wordprocessingml.x2006.main.CTPPrDefault has a method getPPr() which returns CTPPrGeneral.
Your problem results from the fact that there is ooxml-schemas-1.4.jar or older also in class path. And there org.openxmlformats.schemas.wordprocessingml.x2006.main.CTPPrDefault has a method getPPr() which returns CTPPr and not CTPPrGeneral. That's why java.lang.NoSuchMethodError. The apache poi 5.0.0 code calls CTPPrDefault.getPPr and expects a CTPPrGeneral but the old ooxml-schemas-1.4.jar exports CTPPrDefault which has getPPr not returning that type.
Make sure your classpath only contains poi-ooxml-lite-5.0.0.jar or poi-ooxml-full-5.0.0.jar but not ooxml-schemas-1.4.jar or even older versions of ooxml-schemas when apache poi 5.0.0 is used.
Related
I tried answering on the following post, but I don't have the "reputation" and really do not have time to hunt down 10 questions to answer.
Runtime Exception - POI 5 and xmlbeans
With POI 5 and XMLBeans 4 (or 5) in WebLogic server there is a classloader issue where it will try to use the underlying XMLBeans jar in the WebLogic server modules directory.
When packaging in an EAR you can use the weblogic-application.xml descriptor to override class loading with .
However, listing the POI and dependencies packages here will result in further errors.
The class SchemaTypeLoaderImpl is looking in the new (org.apache.xmlbeans.metadata) AND old (schemaorg_apache_xmlbeans) packages.
So you should also include the old package in the override list.
Now SchemaTypeLoaderImpl also tries to load the TypeSystemHolder classes using ClassLoader.getResource before it tries to look it up with Class.forName.
To fix this issue you need to prevent it from finding the old classes, as the previous package override is only giving your application bundled library priority over the underlying server libraries. It is not preventing it from finding these out of date classes and trying to load them as well.
This can be done by using for these resources.
NOTE that I am only using basic XSSFWorkbook XLS functionality!
You may need to track down other resources if you use other POI functionality.
For example the following weblogic-application.xml descriptor allows your application to use bundled POI/XMLBeans libraries and ignore the old resources.
<prefer-application-packages>
<package-name>org.apache.commons.collections4.*</package-name>
<package-name>org.apache.commons.compress.*</package-name>
<package-name>org.apache.poi.*</package-name>
<package-name>org.apache.xmlbeans.*</package-name>
<package-name>org.openxmlformats.*</package-name>
<package-name>schemaorg_apache_xmlbeans.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>schemaorg_apache_xmlbeans/system/sXMLCONFIG/TypeSystemHolder.class</resource-name>
<resource-name>schemaorg_apache_xmlbeans/system/sXMLLANG/TypeSystemHolder.class</resource-name>
<resource-name>schemaorg_apache_xmlbeans/system/sXMLSCHEMA/TypeSystemHolder.class</resource-name>
<resource-name>schemaorg_apache_xmlbeans/system/sXMLTOOLS/TypeSystemHolder.class</resource-name>
</prefer-application-resources>
I am getting this compilation error
HSSFWorkbook cannot be resolved to a type
when i am using this class in Selenium webdriver.I have added the respective jar, poi 3.9 jar, but still unable to resolve this compilation error.
Hi please update your apache poi to The latest stable release is Apache POI 3.14 from https://poi.apache.org/download.html and then import the Apache POI jars form
jars inside poi-3.14
jars inside lib
Look for "poi-3.17.jar"!!!
Download from "https://poi.apache.org/download.html".
Click the one Binary Distribution -> poi-bin-3.17-20170915.tar.gz
Unzip the file download and look for this "poi-3.17.jar".
Problem solved and errors disappeared.
Hope this answer your question!!!
The message indicates that the class could not be found on the classpath of your application. Did you make sure that the POI jar is added?
To insert image to excel using POI:XSSF
I am using maven poi dependency:
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>3.8</version>
</dependency>
AND code as :
InputStream my_banner_image = new FileInputStream("input.png");
byte[] bytes = IOUtils.toByteArray(my_banner_image);
int my_picture_id = wb.addPicture(bytes, Workbook.PICTURE_TYPE_PNG);
I am getting these errors:
1) The method toByteArray(InputStream) is undefined for the type IOUtils
2) PICTURE_TYPE_PNG cannot be resolved or is not a field
Any help would be appriciated. Thanks.
Promoting a comment to an answer:
The method you want to use is very much present in Apache POI 3.11, and you can see full details about it in the POI Javadocs.
As detailed on the POI Components page, defining a Maven dependency on poi-ooxml will pull in the main poi component jar, which is where the IOUtils class lives, so that bit is fine
What you have in this case (based on comments) is a second, older copy of POI on your classpath. You need to remove this older POI jar (or POI jars), in common with most Java projects Apache POI will only work properly if all of the POI jars are from the same version, and no old ones are present.
Because it's a fairly common problem - lots of frameworks ship old copies of POI for example - there's a POI FAQ entry on this very thing. If you can't find the old jar by hand, you can use the code given there to work out where the old jar is to remove it.
Also, one other thing to bear in mind - many many projects provide a class called IOUtils - make sure the one you have imported into your code is org.apache.poi.util.IOUtils and not something else!
I am trying to generate Excel using Xssf API because its memory footprint is small.
It is working fine in my local machine which is having jdk1.7.
But when I try to run it on UNIX where java version is 1.6.0_75 it gives me the following error.
java.lang.NoClassDefFoundError: Could not initialize class org.apache.poi.openxml4j.opc.internal.marshallers.ZipPackagePropertiesMarshaller
I have following jars in my classpath
poi-3.11-20141221.jar
poi-excelant-3.11-20141221.jar
poi-ooxml-3.11-20141221.jar
poi-ooxml-schemas-3.11-20141221.jar
xmlbeans-2.6.0.jar
xercesImpl.jar
I have verified that poi-3.11-20141221.jar has the ZipPackagePropertiesMarshaller class.
Seems that some jar is missing.
Am I missing something?
I have found a solution to my own problem.
I replaced poi-3.11-20141221.jar with poi-ooxml-3.9.jar. That worked.
Java version 1.6.0_75 does not exists, I suppose you make a typo. The last update of Java 6 is the update 45 (6u45).
The class ZipPackagePropertiesMarshaller is loaded at run-time for sure. The exception NoClassDefFoundError occurs during the initialization phase; if the exception had been ClassNotFoundException, it would have been different...
The class ZipPackagePropertiesMarshaller is unaltered between the versions 3.11 and 3.9, but the class PackagePropertiesMarshaller extended by ZipPackagePropertiesMarshaller is changed: the main change regards the use of StAX in the newer version.
The distribution of StAX coming with Java 6, but the version of Java 6 update 18 (http://www.oracle.com/technetwork/java/javase/6u18-142093.html) introduces the StAX 1.2 API version.
Consider to use Java 6u18 or newer. This should solve your problem.
In the official FAQ there are some indications about a similar problem: https://poi.apache.org/faq.html#faq-N1017E.
Moreover, the workaround you found is not the best one, see the last FAQ of POI.
I'm on Windows 7 64-bit, using JDK 1.6.0_29, groovy 1.8.1, and JasperReports/iReport 4.1.3.
I have the following jars from the JasperReports distribution in my CLASSPATH:
commons-beanutils-1.8.0.jar, commons-collections-2.1.1.jar, commons-digester-1.7.jar, commons-logging-1.0.4.jar, jasperreports-4.1.3.jar, poi-3.7-20101029.jar
I have also tried adding all the jars in the ${JASPER_HOME}/lib distribution in case I was missing some important jar.
The jasper report is to be generated by a groovy script. I have created a very simple report with iReport that contains only some static text in the title. I am able to compile and view the report from within iReport.
When I try and compile the report from the script:
def jasperReport = JasperCompileManager.compileReport("filename")
I get the following error:
Caught: java.lang.AbstractMethodError
java.lang.AbstractMethodError
at net.sf.jasperreports.compilers.JRGroovyCompiler.compileUnits(JRGroovyCompiler.java:96)
at net.sf.jasperreports.engine.design.JRAbstractCompiler.compileReport(JRAbstractCompiler.java:188)
at net.sf.jasperreports.engine.JasperCompileManager.compileReport(JasperCompileManager.java:212)
at net.sf.jasperreports.engine.JasperCompileManager.compileReport(JasperCompileManager.java:145)
at net.sf.jasperreports.engine.JasperCompileManager$compileReport.call(Unknown Source)
at wis_validate_environment.run(wis_validate_environment.groovy:58)
Is there possibly some conflict between the groovy that JasperReports is using (JRGroovyCompiler? from the stacktrace) and the groovy that I am using to compile the report?
There were a couple of things I had to change in order to resolve this issue.
Creating a report using the Report Wizard and the default settings creates the language="groovy" parameter in the jasperReport tag. When I remove language parameter, I no longer get the AbstractMethodError mentioned above.
I also needed to add the jdt-compiler-3.1.1.jar in my classpath.
I found the problem was explained here:
http://www.mail-archive.com/user#ofbiz.apache.org/msg23404.html
There seems to be a problem with the versions of one of the dependent libraries that our project uses that conflicts with groovy's.
In short use groovy-all.jar or make sure are your dependancies match those of the version of groovy you are using.