Community
Participate
Working Groups
Build Identifier: 3.7.1 When embedding BIRT into another java application ,we are using the new pojo runtime method, dropping the jars into the WEB-INF/lib directory. The org.apache.batik.pdf_1.6.0.v201105071520.jar file contains 5 classed from the org.apache.commons.io project (not the entire commons io project). It is unclear what version of commons io these files came with. Our application used commons-io 1.4, and in particular a number of files not present in the batik.pdf jar. Therefore we need to be able to include commons-io-1.4.jar in our classpath. If we run the application in that configuration, we get errors such as: SEVERE: Servlet.service() for servlet default threw exception java.lang.SecurityException: class "org.apache.commons.io.output.DeferredFileOutputStream"'s signer information does not match signer information of other classes in the same package at java.lang.ClassLoader.checkCerts(ClassLoader.java:807) at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:626) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1141) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1612) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491) at org.apache.commons.fileupload.disk.DiskFileItemFactory.createItem(DiskFileItemFactory.java:191) at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:350) at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.parse(JakartaMultiPartRequest.java:90) at org.apache.struts2.dispatcher.multipart.MultiPartRequestWrapper.<init>(MultiPartRequestWrapper.java:73) at org.apache.struts2.dispatcher.Dispatcher.wrapRequest(Dispatcher.java:698) at org.apache.struts2.dispatcher.FilterDispatcher.prepareDispatcherAndWrapRequest(FilterDispatcher.java:330) at org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:390) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) .... Our current solution is to strip the commons-io classes out of the batik.pdf jar, this solves the security exception. If batik.pdf requires commons-io, it should be included in the runtime distribution of BIRT in its entirety and separate from the batik.pdf jar file. Reproducible: Always
Hi, I have exactly the same problem ! I had to strip the commons-io classes out of the batik.pdf jar, because I'm using commons-io in all my projects. In the org.apache.batik.pdf_1.6.0.v201105071520.jar file, there are also some classes related to commons-logging, but I had no problem with this inclusion (yet).
See if we can get a split version of Batik pdf, or we need to separate the batik.pdf by ourselves if there are many requirements.
I've opened a bug in Batik's tracker https://issues.apache.org/jira/browse/BATIK-1048 They shouldn't be partially embedding commons-io without changing the package name. That way lies madness.
Just started using the birt runtime in a project and stumbled upon this. Is there anything that can be done on the BIRT side? Its a fairly old ticket and with the recent BIRT releases including 4.5.0 I thought perhaps this could be addressed some other way
