search

kazurayam / inspectus4katalon-sample-project

A sample Katalon Studio project that performs Visual Inspection
Apache License 2.0
0 stars 0 forks source link

java.lang.Error: Circular loading of installed providers detected at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(FileSystemProvider.java:198) #49

Open kazurayam opened 1 year ago

kazurayam commented 1 year ago

Using the Katalon Studio Arm64.app (v9.0.0), I executed

then I got the following error:

java.lang.reflect.InvocationTargetException
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:568)
    at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:117)
    at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:39)
Caused by: java.lang.Error: Circular loading of installed providers detected
    at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(FileSystemProvider.java:198)
    at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:336)
    at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:288)
    at org.codehaus.groovy.vmplugin.v9.ClassFinder.maybeNewFileSystem(ClassFinder.java:177)
    at org.codehaus.groovy.vmplugin.v9.ClassFinder.find(ClassFinder.java:122)
    at org.codehaus.groovy.vmplugin.v9.ClassFinder.find(ClassFinder.java:109)
    at org.codehaus.groovy.vmplugin.v9.Java9.doFindClasses(Java9.java:116)
    at org.codehaus.groovy.vmplugin.v9.Java9.getDefaultImportClasses(Java9.java:103)
    at org.codehaus.groovy.control.ResolveVisitor.<clinit>(ResolveVisitor.java:647)
    at org.codehaus.groovy.runtime.InvokerHelper.<clinit>(InvokerHelper.java:816)
    at groovy.lang.GroovyObjectSupport.getDefaultMetaClass(GroovyObjectSupport.java:46)
    at groovy.lang.GroovyObjectSupport.<init>(GroovyObjectSupport.java:32)
    at groovy.lang.Closure.<init>(Closure.java:211)
    at groovy.lang.Closure.<init>(Closure.java:228)
    at groovy.lang.Closure$1.<init>(Closure.java:193)
    at groovy.lang.Closure.<clinit>(Closure.java:193)
    at java.base/java.lang.Class.forName0(Native Method)
    at java.base/java.lang.Class.forName(Class.java:375)
    at groovyjarjarpicocli.CommandLine$DefaultFactory.loadClosureClass(CommandLine.java:5477)
    at groovyjarjarpicocli.CommandLine$DefaultFactory.<clinit>(CommandLine.java:5475)
    at groovyjarjarpicocli.CommandLine.<init>(CommandLine.java:196)
    at groovy.ui.GroovyMain.processArgs(GroovyMain.java:128)
    at groovy.ui.GroovyMain.main(GroovyMain.java:115)
    ... 6 more
kazurayam commented 1 year ago 
    at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(FileSystemProvider.java:198)

this line reminds me that the materialstore library supports AWS S3 as filesystem. See

kazurayam commented 1 year ago

I tried to run the same Test Case on Katalon Studio v8.6.8, an older version.

...

The Test Case worked fine on the v8.6.8.

The v9.0.0 runs on Java 17, v8.6.8 runs on Java1.8. This difference might be the case of "Curcular loading of installed provider".

The following lines in the stacktrace would prove that it has something to do with Java version.

    at org.codehaus.groovy.vmplugin.v9.Java9.doFindClasses(Java9.java:116)
    at org.codehaus.groovy.vmplugin.v9.Java9.getDefaultImportClasses(Java9.java:103)

So what to do next?

kazurayam commented 1 year ago

Quoting a javadoc from java.nio.file.FileSystems

Factory methods for file systems. This class defines the getDefault method to get the default file system and factory methods to construct other types of file systems. The first invocation of any of the methods defined by this class causes the default provider to be loaded. The default provider, identified by the URI scheme "file", creates the FileSystem that provides access to the file systems accessible to the Java virtual machine. If the process of loading or initializing the default provider fails then an unspecified error is thrown.

The first invocation of the installedProviders method, by way of invoking any of the newFileSystem methods defined by this class, locates and loads all installed file system providers. Installed providers are loaded using the service-provider loading facility defined by the ServiceLoader class. Installed providers are loaded using the system class loader. If the system class loader cannot be found then the extension class loader is used; if there is no extension class loader then the bootstrap class loader is used. Providers are typically installed by placing them in a JAR file on the application class path or in the extension directory, the JAR file contains a provider-configuration file named java.nio.file.spi.FileSystemProvider in the resource directory META-INF/services, and the file lists one or more fully-qualified names of concrete subclass of FileSystemProvider that have a zero argument constructor. The ordering that installed providers are located is implementation specific. If a provider is instantiated and its getScheme returns the same URI scheme of a provider that was previously instantiated then the most recently instantiated duplicate is discarded. URI schemes are compared without regard to case. During construction a provider may safely access files associated with the default provider but care needs to be taken to avoid circular loading of other installed providers. If circular loading of installed providers is detected then an unspecified error is thrown.

This class also defines factory methods that allow a ClassLoader to be specified when locating a provider. As with installed providers, the provider classes are identified by placing the provider configuration file in the resource directory META-INF/services.

If a thread initiates the loading of the installed file system providers and another thread invokes a method that also attempts to load the providers then the method will block until the loading completes.

kazurayam commented 1 year ago

Quoting from https://github.com/freelunchcap/ParallelGit/issues/9

Calling FileSystemProvider.installedProviders(); by anyone before a single GitFileSystem has been instantiated causes a circular dependency. This also happens when trying to run under GraalVM with node starting jvm. The node process tries to get all the installedProviders causing circular dependency exception.

kazurayam commented 1 year ago

In the stack trace I noticed

org.codehaus.groovy.vmplugin.v9.ClassFinder.find(

I checked the javadoc of ClassFinder class:

https://docs.groovy-lang.org/latest/html/gapi/org/codehaus/groovy/vmplugin/v9/ClassFinder.html#find(java.net.URI,%20java.lang.String)

since 3.0.2

Well, I know, Katalon Studio v9.0.0 migrated to Grovvy 3.0.17, which is newer than 3.0.2.

Coincidence!

kazurayam commented 1 year ago

I found the source code of Groovy 3.0.17, org.codehaus.groovy.vmplugin.v9 package

kazurayam commented 1 year ago

I found an interesting stuff in https://github.com/apache/groovy/blob/GROOVY_3_0_17/src/main/java/org/codehaus/groovy/vmplugin/v9/Java9.java

                result.putAll(doFindClasses(URI.create("jrt:/modules/java.base/"), "java", javaPns));

What is the jrt:/modules/java.base/ stuff?

The term module is Java9 specific thing. Java8 does not have module. So I need to look at this in more detail.