asciidoctorj-pdf jruby NoMethodError when attempting to execute #402
Comments
|
This may be related to the Asciidoctor Diagram issue (since I see the same io/console warning). Can you verify which jars you are using in your adt.jar bundle? |
|
Im using the following: Here's Granted, I have made the jar into a fat-jar using the jar-with-dependencies via the assembly plugin. |
|
I'll take a look at it tomorrow. The error seems to be a little bit different than what we've seen with asciidoctorj-diagram where require_relative does not find the resource. (And it was Windows only)
|
|
Downgrading exposed a different error... here's what I'm getting now: |
|
That's crazy that it's failing on fstat. Wow. Which JVM are you using? |
|
JRE 1.7.0_67 64 bit. |
|
Just built a fat jar of asciidoctorj 1.5.3.1 and asciidoctorj-pdf 1.5.0-alpha.10 myself and it works:
This is the pom that I used: (Remove the jruby dep for Linux) <?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>foo.bar</groupId>
<artifactId>fatjartest</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj</artifactId>
<version>1.5.3.1</version>
</dependency>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj-pdf</artifactId>
<version>1.5.0-alpha.10</version>
</dependency>
<dependency>
<groupId>org.jruby</groupId>
<artifactId>jruby-complete</artifactId>
<version>1.7.21</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project> |
|
Excellent! I didn't get a chance to test it today because I've been super heads down preparing my talk for Devoxx. But I'm going to try to test asap. |
|
I can confirm that AsciidoctorJ 1.5.3.2 + AsciidoctorJ PDF 1.5.0.alpha.10.1 (when I build them from source) work on Windows without specifying the JRuby version, whereas AsciidoctorJ 1.5.3.1 + AsciidoctorJ 1.5.0.alpha.10 (from the repositories) does not. I tried with both Java 7 and Java 8 (Oracle versions). I think we're stuck with the So I give it a thumbs up! Interestingly, when I used AsciidoctorJ PDF 1.5.0.alpha.10, I got an error on a completely different line than what was reported. It seems to me that JRuby 1.7.22 is a dud release, or at least a dud for us. |
|
Btw, I checked the icons in PDF and they are working as well. |
|
Oh, and I also tested AsciidoctorJ Diagram and that worked too (I just tested a ditaa diagram since I don't have dot installed on the Windows box). |
|
But let's update rouge to 1.10.1. |
|
👍 I will update the version, test again and then go for releasing 1.5.3.2. |
|
What I can't figure out is how John is getting errors on Linux though. No matter what I try, Linux always works. Granted, there were a number of resources missing from the jars in the 1.5.3.1 cut, so it could have traced back to a missing resource somewhere. What I do know is that on Windows I'm able to see errors with 1.5.3.1 but everything works with 1.5.3.2. |
|
There are two things I'm thinking are a possibility:
What's in test.adoc? What's the result of I'm asking because I want to see if there's something we're not thinking about. But honestly, 1.5.3.2 looks as stable as any AsciidoctorJ version that preceded it. |
|
One thing that should come out of this is a test project that we stick on GitHub for doing manual testing scenarios. Even better if we figure out how to turn those into integration tests, but sometimes, it's nice to have a project to fiddle with, so it may still be useful in addition to an integration test suite. It would save a lot of time instead of having to bootstrap a project. I can certainly contribute scripts from my end. We can call it something like asciidoctorj-manual-tests or something. |
|
Here's a little more information:
I'm not sure how my administrators installed Ruby. Here's the contents of test.adoc: Here's another wrinkle to this issue. I tried to run this same code via our application server, to exercise the non-fat-jar approach. I got this error: Could the problem be that JRuby is using the system install Ruby? Is there a way to configure this? |
|
I cannot imagine that JRuby uses an implementation from a C Ruby except for sth like gems. The field org.jruby.CompatVersion.RUBY_2_0 exists since JRuby 1.7.0! Could you start the Java VM with the option -verbose:class ?
|
|
working on it... |
|
Hmmm, it's loading it out of the correct jar: |
|
I tried moving jruby out of the war and into an ejb to see if that made a difference. It did!... but it eventually errored. Now the current error is: Im running this app server on Oracle Java: I feel like this is closer. |
|
That's unfortunately not correct. It would be good to get JRuby 1.6 completely out of the way.
|
|
Oh, that's odd... I'm including 1.7.21 explicitly... I'll try to upgrade. |
|
FYI, I did upgrade, which resulted in this and ended up erroring with the |
|
Wow, I'm completely clueless. Just a wild guess, but are there maybe some jnr-* jars on the classpath that hide the classes from JRuby?
|
By default, AsciiidoctorJ is now isolated from the system Ruby by default...I was just trying to think outside the box. After seeing the most recent traces I'm convinced that the problem is visibility within the deployment (not a system issue).
This seems to be where we need to focus. In what case is JRuby not able to load a native function. I know JRuby has been making changes to the FFI (native bridge) and this could be biting you. It would be very interesting for the JRuby devs. |
|
I think I'll try downgrading JRuby a bit... maybe that will expose changes made along the way to this FFI component. |
|
FYI, it seems older versions of jruby show this error as well... I tired 1.7.5, 1.7.10, 1.7.15 and 1.7.21. What would you suggest to try? |
|
Ok, we got to the bottom of it... seems that this was caused by the /tmp directory "noexec" option... we removed this and then we were able to generate pdfs! Very strange issues. |
|
That's fantastic news! This seems like pretty critical information to know. Perhaps we should add it to the troubleshooting section (assuming there is one) in the README. Thanks for tracking this down! |
|
Thanks for the help along the way. Yeah, it may make sense to add this to the README, although I wonder if it could be fixed in a more global way across JRuby. Do you have any contacts with the project that would be effective with this fix information? |
We have a great relationship with the JRuby leadership, so definitely. |
|
We just got bitten by the very same error, in our case it was because we are using a tempfs filesystem (instead of ext4/ HFS+/ zfs in /tmp). |
|
You can control which directory is used for temporary files by setting the |
I'm receiving the following error when trying to run this code to create a pdf:
Error:
I am using asiidoctorj 1.5.3.1, asciidoctorj-pdf 1.5.0-alpha.10 on a linux system.
Any help is appreciated.
The text was updated successfully, but these errors were encountered: