Registering java extensions fails because java_import syntax

[ktoso]

Hi guys,
a rather surprising problem I bumped into today, seems I'm unable to register extensions implemented in Java (well Scala, but I don't think it matters for the subject at hand) due to a syntax (?) problem with how import_java is being used in JavaExtensionRegistry here: https://github.com/asciidoctor/asciidoctorj/blob/master/asciidoctorj-core/src/main/java/org/asciidoctor/extension/JavaExtensionRegistry.java#L63

I know a bit of JRuby and know that the syntax "should" be valid, yet if fails for me with:

org.jruby.exceptions.RaiseException: (NameError) undefined local variable or method `pl' for main:Object
    at RUBY.(root)(<script>:1)
    at pl.project13.scala.sbt.SbtAsciidoctor$$anonfun$asciidoctorSettings$6$$anonfun$apply$1.applyOrElse(SbtAsciidoctor.scala:81)
    at pl.project13.scala.sbt.SbtAsciidoctor$$anonfun$asciidoctorSettings$6$$anonfun$apply$1.applyOrElse(SbtAsciidoctor.scala:61)
    at scala.runtime.AbstractPartialFunction$mcVL$sp.apply$mcVL$sp(AbstractPartialFunction.scala:33)
    at scala.runtime.AbstractPartialFunction$mcVL$sp.apply(AbstractPartialFunction.scala:33)
    at scala.runtime.AbstractPartialFunction$mcVL$sp.apply(AbstractPartialFunction.scala:25)
    at scala.collection.TraversableLike$$anonfun$collect$1.apply(TraversableLike.scala:278)

The extension being an pl.project13.scala.sbt.extension.HtmlLayoutWrapper.

I found that quoting the imported class solves the problem, so instead of:

          ruby.evalScriptlet(s"java_import ${p.getClass.getCanonicalName}")
          module.postprocessor(p)

doing:

          val rubyRuntimeField = extensionRegistry.getClass.getDeclaredField("rubyRuntime")
          rubyRuntimeField.setAccessible(true)
          val ruby = rubyRuntimeField.get(extensionRegistry).asInstanceOf[Ruby]

          val asciidoctorModuleField = extensionRegistry.getClass.getDeclaredField("asciidoctorModule")
          asciidoctorModuleField.setAccessible(true)
          val module = asciidoctorModuleField.get(extensionRegistry).asInstanceOf[AsciidoctorModule]

          ruby.evalScriptlet(s"java_import '${p.getClass.getCanonicalName}'") // notice the ' here! this works!
          module.postprocessor(p)

This is on asciidoctorj-1.5.2.jar extecuted inside sbt 0.13.7, and I don't think it's a classloader issue (worked around those already).

Anyway, if you'd be happy to accept a PR with the added quotes I'd happily submit one as I could throw out my ugly hacks from the sbt plugin then ;-)

Oh, and merry x-mas guys! 🎄

[mojavelinux]

Konrad,

A pull request would be a most welcomed gift!

You've bumped into one of those really quirky corner cases in JRuby. JRuby
recognizes a few common namespace prefixes like org. and com. and allows
them to be unquoted. However, it doesn't recognize others like pl. or io.
I'd prefer if JRuby was consistent, but alas it is not.

Since we're importing an unknown qualified class, we should definitely be
quoting it.

Happy Holidays to you too!

-Dan
On Dec 23, 2014 12:24 PM, "Konrad Malawski" notifications@github.com
wrote:

Hi guys,
a rather surprising problem I bumped into today, seems I'm unable to
register extensions implemented in Java due to a syntax (?) problem with
how import_java is being used in JavaExtensionRegistry here:
https://github.com/asciidoctor/asciidoctorj/blob/master/asciidoctorj-core/src/main/java/org/asciidoctor/extension/JavaExtensionRegistry.java#L63

I know a bit of JRuby and know that the syntax "should" be valid, yet if
fails for me with:

org.jruby.exceptions.RaiseException: (NameError) undefined local variable or method `pl' for main:Object at RUBY.(root)(<script>:1) at pl.project13.scala.sbt.SbtAsciidoctor$$anonfun$asciidoctorSettings$6$$anonfun$apply$1.applyOrElse(SbtAsciidoctor.scala:81) at pl.project13.scala.sbt.SbtAsciidoctor$$anonfun$asciidoctorSettings$6$$anonfun$apply$1.applyOrElse(SbtAsciidoctor.scala:61) at scala.runtime.AbstractPartialFunction$mcVL$sp.apply$mcVL$sp(AbstractPartialFunction.scala:33) at scala.runtime.AbstractPartialFunction$mcVL$sp.apply(AbstractPartialFunction.scala:33) at scala.runtime.AbstractPartialFunction$mcVL$sp.apply(AbstractPartialFunction.scala:25) at scala.collection.TraversableLike$$anonfun$collect$1.apply(TraversableLike.scala:278)

The extension being an pl.project13.scala.sbt.extension.HtmlLayoutWrapper.

I found that quoting the imported class solves the problem, so instead of:

      ruby.evalScriptlet(s"java_import ${p.getClass.getCanonicalName}")
      module.postprocessor(p)

doing:

      val rubyRuntimeField = extensionRegistry.getClass.getDeclaredField("rubyRuntime")
      rubyRuntimeField.setAccessible(true)
      val ruby = rubyRuntimeField.get(extensionRegistry).asInstanceOf[Ruby]

      val asciidoctorModuleField = extensionRegistry.getClass.getDeclaredField("asciidoctorModule")
      asciidoctorModuleField.setAccessible(true)
      val module = asciidoctorModuleField.get(extensionRegistry).asInstanceOf[AsciidoctorModule]

      ruby.evalScriptlet(s"java_import '${p.getClass.getCanonicalName}'") // notice the ' here! this works!
      module.postprocessor(p)

This is on asciidoctorj-1.5.2.jar extecuted inside sbt 0.13.7, and I
don't think it's a classloader issue (worked around those already).

Anyway, if you'd be happy to accept a PR with the added quotes I'd happily
submit one as I could throw out my ugly hacks from the sbt plugin then ;-)

Oh, and merry x-mas guys! [image: 🎄]

—
Reply to this email directly or view it on GitHub
#250.

[ktoso]

Oh interesting. Indeed, all examples I saw that "just worked" were com... or java....
I'll prep a PR then, and a day or two later the long promised sbt integration ;-)

[mojavelinux]

Oh yeah!!

[mojavelinux]

I was thinking that the fix to this bug might warrant a 1.5.2.1 release. We definitely want to be able to use the proper API in the sbt plugin out of the gate.

[ktoso]

Would be awesome, thanks guys :-) still got my hack in there currently.

Konrad
(sent from mobile)
On 26 Dec 2014 23:04, "Dan Allen" notifications@github.com wrote:

I was thinking that the fix to this bug might warrant a 1.5.2.1 release.
We definitely want to be able to use the proper API in the sbt plugin out
of the gate.

—
Reply to this email directly or view it on GitHub
#250 (comment)
.

[lordofthejars]

I have just read now the latest mesage of @mojavelinux and I have already accepted some PR, the good news are that they are bug fixing, so we can do a 1.5.2.1 release without any problem. Converters part are still no their own branch.

[ktoso]

1.5.2.1 would be very nice - I could throw out my reflection hacks then :)
Let me know when you release

[mojavelinux]

I went ahead and created a milestone for 1.5.2.1 and added this issue to it. We can probably wait a couple of days to make sure we have everything we need covered (including the fix for requiring a Ruby library that is needed for Asciidoclet). Then we can attempt to push out a release. It will certainly be good practice.

[axelschoener]

The problem is still present. I don't find it in the announced 1.5.2.1/1.5.3 milestones.
Will it be possible in the next release?