JRuby Jar comuptation fails in OSGi environment

[glatuske]

Environment Information

Provide at least:

• JRuby version: 9.4.7.0
• Operating system and platform: Windows 10 64 Bit, OSGi with Equinox

Expected Behavior

• JRuby should run in OSGi environment
• Any kind of access to the classpath need to take OSGi into consideration

Actual Behavior

• ClasspathLauncher expects a JAR classpath entry. In OSGi case this is a bundleresource (e.g. bundleresource://344.fwk257265217/org/jruby/Main.class).
• Path.of fails with java.nio.file.FileSystemNotFoundException: Provider "bundleresource" not installed
• Catching this exception and return null would be sufficient in our scenario.

[enebo]

Ah whoops. Different fish different recipe I guess (this change was so some things would continue to run within jruby-complete.jar) For some reason I thought we had some OSGi test.

@glatuske Since you localized this would there be any chance you can make a PR since you also can test it? It sounds like you have an idea on a fix.

[glatuske]

@enebo I can try ;-) Just to get it right the idea of getJRubyJar() is to retrieve the location of the JAR file it self (e.g. /path/to/jruby.jar)?

[enebo]

@glatuske yeah. In the comment I thought that this was only used with jruby-complete.jar. Looking a little more this is only used by jrubyCommand but that is used for classpath_launcher ... which I think is where you are calling this from?

I feel like I am missing the path where OSGi requests this. Do you think the uri stripping is the main issue?

The original fix was because on newer Java's our code for determining where jruby-complete.jar (and I guess for the OSGi case) stopped working.

[glatuske]

@enebo I have checked debugged new and old behaviour. The old code was also not working with OSGi, but did not throw an exception.

The best way to get the JAR location in an OSGi environment would be:
org.osgi.framework.FrameworkUtil.getBundle(Main.class).getLocation()

In my case that returns: reference:file:/C:/Users/<user>/.m2/repository/org/jruby/jruby-base/9.4.7.0/bnd-9a09156e6d5f59f62209e4c29daf86be/jruby-base-9.4.7.0.jar

The question is, if you are ok to add some OSGi specific code. As a quick fix for us would be sufficient to fix the java.nio.file.FileSystemNotFoundException, as we are not using JRuby command at all.

Call Stacktrace from 9.4.7.0

	ClasspathLauncher.getJRubyJar() line: 32	
	ClasspathLauncher.jrubyCommand(ClassLoader) line: 48	
	RubyInstanceConfig.getEnvironment() line: 679	
	OSEnvironment.environmentVariableMap(Ruby) line: 51	
	RubyGlobal.defineGlobalEnvConstants(Ruby) line: 395	
	RubyGlobal.createGlobals(Ruby) line: 234	
	Ruby.<init>(RubyInstanceConfig) line: 520	
	Ruby.newInstance(RubyInstanceConfig) line: 723	
	JavaEmbedUtils.initialize(List<String>, RubyInstanceConfig) line: 85	
	JRubyAsciidoctor.createRubyRuntime(Map<String,String>, List<String>, ClassLoader) line: 145	
	JRubyAsciidoctor.createJRubyAsciidoctorInstance(Map<String,String>, List<String>, ClassLoader) line: 132	
	JRubyAsciidoctor.create(ClassLoader) line: 93	
	AsciidoctorJRuby$Factory.create(ClassLoader) line: 72

[enebo]

@glatuske I think it is ok. I can see we compile against org.osgi already in org.jruby.embed.osgi which ends up in jruby.jar.

So your change would be just recognize you are in an OSGi env and then use getBundle() as the replacement to determine the location. All the rest would just be the same more or less? If so I think that is fine. If not then you may be finding a rich vein of new problems.

My wonderment at this point is this is for exec'ing a new JRuby process for executing a sub-Ruby command. OSGi I would wonder if this ever worked or is even something OSGi would want. It seems like the OSGi way would be to get another instance of the service which does Ruby and run that in there (It has been ~20 years since I used OSGi so I am rusty :) ). If this was not raising but giving a bad value for the location of the jar then it is possible no one has ever used the value being produced because they are not performing subspawns of Ruby....or this entire paragraph is wrong :) It is possible this is how it works for us (not that the service idea wouldn't also be some option for OSGi).

[glatuske]

@enebo I would recommend to just fetch the FileSystemNotFoundException and do nothing more on that. As you said, the OSGi way would be to use OSGi services; but I guess that's to realistic to change this easily.

[laumacirule]

It seems I am running into this same issue when I run a compiled JRuby app as an Atlassian Jira OSGi plugin (Jruby 9.4.7.0, MacOS). Here is the stacktrace:

Caused by: java.nio.file.FileSystemNotFoundException: Provider "bundle" not installed
	at java.base/java.nio.file.Path.of(Path.java:212)
	at java.base/java.nio.file.Paths.get(Paths.java:97)
	at org.jruby.util.ClasspathLauncher.getJRubyJar(ClasspathLauncher.java:40)
	at org.jruby.util.ClasspathLauncher.jrubyCommand(ClasspathLauncher.java:48)
	at org.jruby.RubyInstanceConfig.getEnvironment(RubyInstanceConfig.java:679)
	at org.jruby.util.OSEnvironment.environmentVariableMap(OSEnvironment.java:51)
	at org.jruby.RubyGlobal.defineGlobalEnvConstants(RubyGlobal.java:395)
	at org.jruby.RubyGlobal.createGlobals(RubyGlobal.java:234)
	at org.jruby.Ruby.<init>(Ruby.java:520)
	at org.jruby.Ruby.newInstance(Ruby.java:723)

And as @glatuske mentioned, just fetching the FileSystemNotFoundException would be enough to proceed.