When doing:
new MiniDFSCluster.Builder(config).build()
I get this exception:
java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio.NativeIO$Windows.access0(Ljava/lang/String;I)Z
at org.apache.hadoop.io.nativeio.NativeIO$Windows.access0(Native Method)
at org.apache.hadoop.io.nativeio.NativeIO$Windows.access(NativeIO.java:557)
at org.apache.hadoop.fs.FileUtil.canWrite(FileUtil.java:996)
at org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.analyzeStorage(Storage.java:490)
at org.apache.hadoop.hdfs.server.namenode.FSImage.recoverStorageDirs(FSImage.java:308)
at org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:202)
at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1020)
at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:739)
at org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:536)
at org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:595)
at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:762)
at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:746)
at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1438)
at org.apache.hadoop.hdfs.MiniDFSCluster.createNameNode(MiniDFSCluster.java:1107)
at org.apache.hadoop.hdfs.MiniDFSCluster.createNameNodesAndSetConf(MiniDFSCluster.java:978)
at org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:807)
at org.apache.hadoop.hdfs.MiniDFSCluster.<init>(MiniDFSCluster.java:467)
at org.apache.hadoop.hdfs.MiniDFSCluster$Builder.build(MiniDFSCluster.java:426)
I want to use the Hadoop Minicluster to test my Hadoop HDFS (which does not throw this exception, see java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio.NativeIO$Windows.createDirectoryWithMode0).
In my Maven pom.xml I have these dependencies:
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-common</artifactId>
<version>2.6.0</version>
</dependency>
<!-- for unit testing -->
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-common</artifactId>
<version>2.6.0</version>
<type>test-jar</type>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-hdfs</artifactId>
<version>2.6.0</version>
</dependency>
<!-- for unit testing -->
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-hdfs</artifactId>
<version>2.6.0</version>
<scope>test</scope>
<classifier>tests</classifier>
</dependency>
I understood, I do not need to the specific 'hadoop-minicluster' dependency as it already comes with the above included hadoop-hdfs.
I am trying to build the MiniDFSCluster in my #BeforeAll.
I have used different configs for the builder:
config = new HdfsConfiguration(); / config = new Configuration();
And different ways to create a path for the baseDir:
config.set(miniDfsClusterHD.HDFS_MINIDFS_BASEDIR, baseDir);
Also, I downloaded the hadoop.dll and hdfs.dll and winuntils.exe in v2.6.0 and added the path to those in my environment variables.
I studied all the related issues I could find in stackoverflow (without success, obviously) and all guides and code examples I could find in the internet (there are a few and they all do it differently.)
Can somehow please help me, I am out of ideas.
UPDATE:
I am running the test with the following VM options (which should not be necessary, I think):
-Dhadoop.home.dir=C:/Temp/hadoop
-Djava.library.path=C:/Temp/hadoop/bin
I also tried to set the environment variables directly (which should not be necessary when using the VM options):
System.setProperty("hadoop.home.dir", "C:\\Temp\\hadoop-2.6.0");
System.setProperty("java.library.path", "C:\\Temp\\hadoop-2.6.0\\bin");
I have resolved this issue by downloading the source file (org.apache.hadoop.io.nativeio.NativeIO.java) and modifying line in
function access (in your case 557) from:
return access0(path, desiredAccess.accessRight());
to
return true;
Related
I made a program that parses turtle files with Jena library. These are the dependencies i use:
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-iri</artifactId>
<version>3.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-core</artifactId>
<version>3.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-arq</artifactId>
<version>3.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-tdb</artifactId>
<version>3.10.0</version>
</dependency>
So the parsing is working well on my java program but when i create my jar and try to run it, i have these kind of errors :
ERROR JenaService:146 - org.apache.jena.n3.turtle.TurtleParseException: Line 28015, column 79: org.apache.jena.iri.impl.IRIImplException:
<http://www.reussir.fr,> Code: 28/NOT_DNS_NAME in HOST: The host component did not meet the restrictions on DNS names.
Any ideas ?
EDIT
I have a warning for the invalid IRI problem by running my program with the IDE, but still giving me errors with the generated jar.
<http://www.reussir.fr,>
There is a comma in the URI in a place where commas are not allowed.
It is better to find and fix the data problem because it can lead to other problems later if not fixed.
I found the problem, the only dependency i really needed was jena-arq, so i removed others dependencies (especially jena-iri which was throwing the TurtleParseException) and the bad-iri errors became warnings like in the IDE execution logs.
We are using a library called logback-ext-cloudwatch-appender to send our logback-based logs to AWS Cloudwatch. This is what the dependency looks like in our pom.xml file.
<dependency>
<groupId>org.eluder.logback</groupId>
<artifactId>logback-ext-cloudwatch-appender</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
A few days ago these errors started appearing in our logs.
java.lang.NoSuchMethodError: com.amazonaws.transform.JsonErrorUnmarshaller: method <init>(Ljava/lang/Class;)V not found
at com.amazonaws.services.logs.model.transform.InvalidParameterExceptionUnmarshaller.<init>(InvalidParameterExceptionUnmarshaller.java:26)
at com.amazonaws.services.logs.AWSLogsClient.init(AWSLogsClient.java:280)
at com.amazonaws.services.logs.AWSLogsClient.<init>(AWSLogsClient.java:275)
at com.amazonaws.services.logs.AWSLogsClient.<init>(AWSLogsClient.java:248)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.doStart(AbstractCloudWatchAppender.java:100)
at org.eluder.logback.ext.aws.core.AbstractAwsEncodingStringAppender.start(AbstractAwsEncodingStringAppender.java:123)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.start(AbstractCloudWatchAppender.java:95)
at ch.qos.logback.ext.spring.DelegatingLogbackAppender.getDelegate(Unknown Source)
at ch.qos.logback.ext.spring.DelegatingLogbackAppender.append(Unknown Source)
at ch.qos.logback.ext.spring.DelegatingLogbackAppender.append(Unknown Source)
at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84)
at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48)
at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383)
at ch.qos.logback.classic.Logger.info(Logger.java:579)
(truncated)
I found out that we had upgraded to AWS 1.11.5, but I couldn't find any evidence of such a bug in that release.
It turns out that the current version of logback-ext-cloudwatch-appender has a transitive dependency on a specific version of aws-java-sdk-logs 1.10.2, which is not compatible with other aws-java-sdk libraries 1.11.0 and above. We do use a number of other aws-java-sdk libraries. We excluded the dependency like this.
<dependency>
<groupId>org.eluder.logback</groupId>
<artifactId>logback-ext-cloudwatch-appender</artifactId>
<version>1.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-logs</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-core</artifactId>
<version>1.11.5</version>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-logs</artifactId>
<version>1.11.5</version>
</dependency>
At that point we started getting another error.
Exception in thread "org.myorg.task.MyTask working" java.lang.NoSuchMethodError: com.amazonaws.services.logs.AWSLogsClient.createLogGroup(Lcom/amazonaws/services/logs/model/CreateLogGroupRequest;)V
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.createLogGroup(AbstractCloudWatchAppender.java:171)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.doStart(AbstractCloudWatchAppender.java:107)
at org.eluder.logback.ext.aws.core.AbstractAwsEncodingStringAppender.start(AbstractAwsEncodingStringAppender.java:123)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.start(AbstractCloudWatchAppender.java:95)
at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:90)
at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179)
at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:155)
at ch.qos.logback.core.sift.SiftingJoranConfiguratorBase.doConfigure(SiftingJoranConfiguratorBase.java:82)
at ch.qos.logback.core.sift.AbstractAppenderFactoryUsingJoran.buildAppender(AbstractAppenderFactoryUsingJoran.java:51)
at ch.qos.logback.core.sift.AppenderTracker.buildComponent(AppenderTracker.java:56)
at ch.qos.logback.core.sift.AppenderTracker.buildComponent(AppenderTracker.java:32)
at ch.qos.logback.core.spi.AbstractComponentTracker.getOrCreate(AbstractComponentTracker.java:124)
at ch.qos.logback.core.sift.SiftingAppenderBase.append(SiftingAppenderBase.java:104)
at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:82)
at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48)
at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383)
at ch.qos.logback.classic.Logger.info(Logger.java:579)
Merely excluding the dependencies did not work. I had to fork and rebuild the logback-ext-cloudwatch-appender jar with a dependency on the current 1.11.5 aws-java-sdk libraries. Trying to use the new AWS dependencies with the logback-ext-cloudwatch-appender jar which had been built against the old libraries caused a mismatch in the method signature (return type) of createLogGroup which caused a runtime error. To get this to run, I only had to change the pom.xml files, not the source code, in my forked version.
I have done previous searches trying to find an answer to this however my attempts failed so far. I think the error is quite simple its just not loading the classes.
I am running MacOSX 10 with intellij. I am using it with Junit Spring and Maven & Junit.
I followed the maven dependencies found mvnrepository.com - sikuli-api 1.2.0 so I was thinking that if the dependencies are added to the pom then all files should be in my class path? So I don't understand why its not working?
This previous answer looks close to mine - but its for windows im on a mac. However by using maven I should not need to add it to the class path?? or am I missing something. This similar unanswered question also looks similar uses mac like mine
POM Dependencies added
<dependency>
<groupId>org.sikuli</groupId>
<artifactId>sikuli-api</artifactId>
<version>1.2.0</version>
</dependency>
<dependency>
<groupId>org.sikuli</groupId>
<artifactId>sikuli-core</artifactId>
<version>1.2.2</version>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>14.0.1</version>
</dependency>
<dependency>
<groupId>org.bytedeco</groupId>
<artifactId>javacpp</artifactId>
<version>0.9</version>
</dependency>
<dependency>
<groupId>org.bytedeco.javacpp-presets</groupId>
<artifactId>opencv</artifactId>
<version>2.4.9-0.9</version>
<classifier>macosx-x86_64</classifier>
</dependency>
<dependency>
<groupId>org.piccolo2d</groupId>
<artifactId>piccolo2d-core</artifactId>
<version>1.3.1</version>
</dependency>
<dependency>
<groupId>org.piccolo2d</groupId>
<artifactId>piccolo2d-extras</artifactId>
<version>1.3.1</version>
</dependency>
My test
static {
System.setProperty("platform.dependency", "macosx-x86_64");
//System.setProperty("platform.dependency", "1"); // tried this also
}
#Test
public void testOne() throws Exception {
File file = new File(getClass().getClassLoader().getResource("camera_icon.png").getFile());
browse(new URL("http://code.google.com"));
ScreenRegion s = new DesktopScreenRegion();
Target target = new ColorImageTarget(file);
// ** Fails here **
ScreenRegion r = s.find(target);
....
The Error - ClassLoader
I followed the debugger and it fails on the class loader for open_core -- see screenshot
Update
I added the POM classifier per Samuel answer below. I also tried setting the system property. still getting the same error.
Also noticed the following error - I have tried to cut it down as much as possible.
Caused by: java.lang.UnsatisfiedLinkError: /private/var/folders/qp/.../libjniopencv_core.dylib: dlopen(/private/var/....../libjniopencv_core.dylib, 1): Library not loaded: #rpath/libopencv_core.2.4.dylib
Referenced from: /private/var/.......libjniopencv_core.dylib
Reason: no suitable image found. Did find:
/private/va.....77/./libopencv_core.2.4.dylib: malformed mach-o image: load command #12 length (0) too small in /private/var/fo......./libopencv_core.2.4.dylib t java.lang.ClassLoader$NativeLibrary.load(Native Method)
The answer is basically in the README.md file, but I'll spell it out here. You will need to set either the platform.dependency system property to the desired platform, for example, macosx-x86_64, or to true the platform.dependencies one, to get dependencies for all platforms. I'm not sure how we're supposed to set that with JUnit Spring (it should be in the docs), but even that doesn't work with SBT anyway, so to work around these cases we can add the platform-specific dependencies manually. Since you're running on Mac OS X and interested in using OpenCV 2.4.9, adding this additional dependency to your pom.xml file should work:
<dependency>
<groupId>org.bytedeco.javacpp-presets</groupId>
<artifactId>opencv</artifactId>
<version>2.4.9-0.9</version>
<classifier>macosx-x86_64</classifier>
</dependency>
For my work around I install opencv via homebrew. Open terminal and type the following.
brew tap homebrew/science
brew info opencv
brew install opencv
This allowed my POM to be much smaller
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>sikuliTest</groupId>
<artifactId>sikuliTest</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.sikuli</groupId>
<artifactId>sikuli-api</artifactId>
<version>1.2.0</version>
</dependency>
</dependencies>
</project>
The test
#Test
public void testOne() throws IOException {
File file = new File(getClass().getClassLoader().getResource("image_to_click.jpeg").getFile());
browse(new URL("http://code.google.com"));
// click image that looks like image_to_click.jpeg
ScreenRegion s = new DesktopScreenRegion(1);
ScreenRegion s1 = s.find(new ImageTarget(file));
Mouse mouse = new DesktopMouse();
mouse.click(s1.getCenter());
// take a screenshot and save it
BufferedImage img = s.capture();
File outputfile = new File("screenshot_image.jpg");
ImageIO.write(img, "jpg", outputfile);
}
I'm trying to build a mule project in maven which uses a library that in turn uses apache-commons-codec-1.8 . Mule 3.5 currently supports only v 1.3
In order to get around this Ive implemented classloader control in mule and blocked mule from loading its version of the library by doing the following in mule-deploy.properties.
loader.override=-org.apache.commons.codec
In addition I've updated my pom.xml to include the 1.9 version of the library . Here is a snapshot of running mvn:dependency tree on the project.
However, when I run my test method I get a runtime exception
java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.encodeBase64URLSafeString([B)Ljava/lang/String;
at com.nimbusds.jose.util.Base64URL.encode(Base64URL.java:64)
at com.nimbusds.jose.util.Base64URL.encode(Base64URL.java:91)
at com.nimbusds.jose.Header.toBase64URL(Header.java:238)
at com.nimbusds.jose.JWSObject.<init>(JWSObject.java:101)
at com.package.components.lastmile.originator.TokenSignerTemplate.sign(TokenSignerTemplate.java:109)
at com.package.components.lastmile.originator.TokenSignerTemplate.signClaim(TokenSignerTemplate.java:122)
at com.package.orchestration.LMSFakeClaimsHandler.testSignParse_Positive(LMSFakeClaimsHandler.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
which is clearly because it's referencing the older version of apache-commons. How do I make sure that it references only the latest version and not the older version?
mule-deploy.properties
#Fri Dec 12 09:58:12 PST 2014
loader.override=-org.apache.commons.codec
redeployment.enabled=true
encoding=UTF-8
domain=default
config.resources=..flows.
.
Relevant positions of pom.xml
<dependencies>
....
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.9</version>
</dependency>
....
<!-- Test to check commons-codec works -->
<dependency>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transport-http</artifactId>
<version>${mule.version}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
P.S: The same snippet seems to work fine on a non mule project, indicating this is a mule related issue.
If you are running the Mule app in Mule server, excluding the lib from the pom will not work, since the codec lib is present in the server itself.
Try to insert the newest codec lib version in the server lib shared folder (maintaining the property loader.override=-org.apache.commons.codec)
Add the following exclusion to your pom.
<dependency>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transport-http</artifactId>
<version>${mule.version}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
And then add the dependency of Commons Codec 1.9.
Then your override property in mule-deploy.properties will work as expected.
Update: 12/30:
The override property seems to be the problem.
loader.override=-org.apache.commons.codec is not correct.
Try the following
loader.override=org.apache.commons.codec
Hope this helps.
I have a similar issue with the jackson-xc. I don't know why Mule 3.5 comes with a mix of jackson 1 and 2 libraries
jackson-annotations-2.1.1.jar
jackson-core-2.1.1.jar
jackson-databind-2.1.1.jar
jackson-core-asl-1.9.11.jar
jackson-jaxrs-1.9.11.jar
jackson-mapper-asl-1.9.11.jar
jackson-xc-1.7.1.jar
And with jackson-xc-1.7.1 instead of jackson-xc-1.9.11 that would be aligned to the version of the other jackson 1 libraries.
In my application it is producing the "classic" library issue exception:
Caused by: java.lang.AbstractMethodError
at org.codehaus.jackson.map.AnnotationIntrospector$Pair.findDeserializer(AnnotationIntrospector.java:1335)
Since using
loader.override=...
into the mule-deploy.properties didn't work (with either override and/or blocking on the package org.codehaus.jackson.xc and on the class org.codehaus.jackson.xc.JaxbAnnotationIntrospector) the only solution I have found goes in the direction of Nuno's answer and is to put the jar we want to use in a lib folder with higher priority than lib/opt
lib/shared has been deprecated but you can use lib/user to override.
I would prefer to use the loader.override (classloader-control-in-mule 3.5) and avoid the modification of all the installation, but for now is the only solution that is working for me.
guys! For long time I can't fix the exception: java.lang.NoSuchMethodError: com.lowagie.text.pdf.PdfWriter.setRgbTransparencyBlending(Z)V
I've add all need jars into classpath:
commons-beanutils-1.8.0
commons-collections-2.1.1
commons-digester-2.1.0
commons-javaflow-20060411
commons-logging-1.1.1
itext - 2.1.5
jasperreports - 5.1.0
I saw requirements for JasperReports here, so I've all need libraries, but, anyway, I can't fix the bug
My code:
class ForIReport {
public static void main(String[] args) {
// def conn = Sql.newInstance(
// "jdbc:sqlserver://localhost:1433;databaseName=twitter",
// 'sa',
// 'sunrise123',
// 'com.microsoft.sqlserver.jdbc.SQLServerDriver')
// Class.forName("com.microsoft.jdbc.SQLServerDriver").newInstance();
// Connection conn = DriverManager.getConnection("jdbc:microsoft:sqlserver://localhost:1433", 'sa', 'sunrise123');
def fileName = "C:/Users/avalev/Documents/iReport/First.jasper"
def outFileName = "First.pdf"
HashMap hm = new HashMap()
JasperPrint print = JasperFillManager.fillReport(fileName, hm, new JREmptyDataSource())
JRExporter exporter = new JRPdfExporter()
exporter.setParameter(
JRExporterParameter.OUTPUT_FILE_NAME,
outFileName);
exporter.setParameter(JRExporterParameter.JASPER_PRINT, print)
exporter.exportReport()
println("Created file :" + outFileName)
}
}
and description of exception
log4j:WARN No appenders could be found for logger (net.sf.jasperreports.extensions.ExtensionsEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Exception in thread "main" java.lang.NoSuchMethodError: com.lowagie.text.pdf.PdfWriter.setRgbTransparencyBlending(Z)V
at net.sf.jasperreports.engine.export.JRPdfExporter.exportReportToStream(JRPdfExporter.java:596)
at net.sf.jasperreports.engine.export.JRPdfExporter.exportReport(JRPdfExporter.java:419)
at net.sf.jasperreports.engine.JRExporter$exportReport.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
at ForIReport.main(One.groovy:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
I can create the instance of PdfWriter class (for check myself)
Thank you for your help
jasperreports-5.1.0 needs itext-2.1.7.
You can see it in the pom of the jasperreports-5.1.0 project:
<dependency>
<groupId>com.lowagie</groupId>
<artifactId>itext</artifactId>
<version>2.1.7.js2</version>
<scope>compile</scope>
</dependency>
You need to upgrade the version of itext to version 2.1.7 minimum.
I had the same [runtime] error. What I realized was, I had the wrong jars for the "batik" library. I got all version 1.7 jars from the org.apache.xmlgraphics. I'm using jasper in this way:
<dependency>
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>4.0.0</version>
</dependency>
The batik, for example:
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>batik-anim</artifactId>
<version>1.7</version>
</dependency>
Also, I made sure I only had one instance of iText in the pom:
<dependency>
<groupId>com.lowagie</groupId>
<artifactId>iText</artifactId>
<version>2.1.7</version>
</dependency>
Hope that helps.
I had the same issue, when retrieving data from grid and writing to a PDF using
flying-saucer-pdf
The isuue was com.lowagie (itext) and org.xhtmlrenderer (flying-saucer-pdf) versions incompatible,
use following,
<dependency>
<groupId>com.lowagie</groupId>
<artifactId>itext</artifactId>
<version>2.1.7</version>
</dependency>
<dependency>
<groupId>org.xhtmlrenderer</groupId>
<artifactId>flying-saucer-pdf</artifactId>
<version>9.0.7</version>
</dependency>
I have also came across same situation but finally succeeded to resolve it.
If you are using maven then add below dependency
<dependency>
<groupId>org.eclipse.birt.runtime.3_7_1</groupId>
<artifactId>com.lowagie.text</artifactId>
<version>2.1.7</version>
</dependency>
or download jar from below link and add to your buildpath
com.lowagie.text_2.1.7
It will be of no use to add itext-2.1.7.jar , Also the latest version of that is itextpdf-5.5.9.jar
If M. Abbas answer does not work then please use this dependency:
<dependency>
<groupId>com.lowagie</groupId>
<artifactId>itext</artifactId>
<version>2.1.7</version>
</dependency>
It works for me.