Ortools deployed within Wildfly 29 ear

[HY]

Hello. 

I have a Java project in which I have to solve an optimization problem using ortools. I have included mvn dependency as instructed and created an ear file which is subsequently deployed within Wildfly 29 in turn using jdk 17.

https://developers.google.com/optimization/install/java/pkg_linux

<dependency>

<groupId>com.google.ortools</groupId>

<artifactId>ortools-java</artifactId>

<version>9.11.4210</version> 

</dependency>

The ear file deploys with no problem on a Win11 dev machine and calls to ortools are executed with no problem. We will then fully copy Wildfly 29 distro including the ear file to other Win11 and Ubuntu20.04 test machines. All installed software components and dependencies are identical on all machines except that the test machines do not include the project source. When we deploy the ear file on test machines (both Win11 & Ubuntu20.04, we consistently get the error messages below. It is curious that standlaone ortools installations for Java work fine on test machines.

17:18:17,177 ERROR [stderr] (MSC service thread 1-8) java.nio.file.ProviderNotFoundException: Provider "vfs" not found
17:18:17,177 ERROR [stderr] (MSC service thread 1-8)     at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:359)
17:18:17,178 ERROR [stderr] (MSC service thread 1-8)     at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:288)
17:18:17,178 ERROR [stderr] (MSC service thread 1-8)     at deployment.example.ear.ejb.jar//com.example.service.Scheduler.<clinit>(Scheduler.java:63)
17:18:17,178 ERROR [stderr] (MSC service thread 1-8)     at java.base/java.lang.Class.forName0(Native Method)
17:18:17,178 ERROR [stderr] (MSC service thread 1-8)     at java.base/java.lang.Class.forName(Class.java:467)
17:18:17,178 ERROR [stderr] (MSC service thread 1-8)     at org.jboss....@2.0.0.Final//org.jboss.invocation.proxy.AbstractProxyFactory.afterClassLoad(AbstractProxyFactory.java:107)
17:18:17,178 ERROR [stderr] (MSC service thread 1-8)     at org.jboss....@2.0.0.Final//org.jboss.invocation.proxy.AbstractClassFactory.defineClass(AbstractClassFactory.java:204)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jboss....@2.0.0.Final//org.jboss.invocation.proxy.AbstractProxyFactory.getCachedMethods(AbstractProxyFactory.java:162)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jbos...@29.0.1.Final//org.jboss.as.ejb3.component.singleton.SingletonComponentDescription$6.configure(SingletonComponentDescription.java:219)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jbo...@29.0.1.Final//org.jboss.as.ee.component.DefaultComponentViewConfigurator.configure(DefaultComponentViewConfigurator.java:109)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jbo...@29.0.1.Final//org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:82)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jboss...@21.1.1.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jb...@1.5.1.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1617)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jb...@1.5.1.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1580)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jb...@1.5.1.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1438)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jbos...@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
17:18:17,179 ERROR [stderr] (MSC service thread 1-8)     at java.base/java.lang.Thread.run(Thread.java:840)

The error happens at the line below.

Loader.loadNativeLibraries();

And we have added code snippet below which works fine on dev machine but is no help for test machines.

static {
//Loader.loadNativeLibraries();

try {
FileSystems.newFileSystem(URI.create("vfs:/"), Collections.emptyMap());
} catch (Exception e) {
e.printStackTrace();
}

}

We have also added modules under Wildfly module folder to account for all jars but nothing is resolving the problem. 

Can a kind soul shed some light as to what might be triggering this problem and how we can resolve it?

-- Regards, HY

[Richard Opalka]

Hello HY,

   Unfortunately JBoss VFS library doesn't implement file system provider SPI.

Rio

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/edb9a8cd-29d4-438c-be8e-e996a36494ccn%40googlegroups.com.

[HY]

Thank you for the reply Rio but with due respect I have evidence to the contrary. I have a curious situation in the sense that everything works fine in my win11 dev machine. We observe the issue when deploying the app in other win11 and Ubuntu test machines. Any thought as to why that is? 

Regards,

HY

[Richard Opalka]

Hello HY,

   Below you can see there's no java.nio.file.FileSystem implementation:

jboss-vfs$ git branch
* main

boss-vfs$ git log -1 --pretty=oneline
e7af730eb145b9a717db8b3d3831742dd07277c1 (HEAD -> main, upstream/main, upstream/HEAD, origin/main) Merge pull request #68 from jbossas/dependabot/maven/version.org.jboss.logging.jboss-logging-tools-3.0.3.Final

jboss-vfs$ grep -r "java.nio" *
src/test/java/org/jboss/test/vfs/VirtualJarInputStreamTestCase.java:import java.nio.file.Files;
src/test/java/org/jboss/test/vfs/VirtualJarInputStreamTestCase.java:import java.nio.file.Path;
src/test/java/org/jboss/test/vfs/VirtualJarInputStreamTestCase.java:import java.nio.file.StandardCopyOption;
src/test/java/org/jboss/test/vfs/FileVFSCaseSensitiveTestCase.java:import java.nio.file.Files;
src/test/java/org/jboss/test/vfs/URLConnectionUnitTestCase.java:import java.nio.file.Files;
src/test/java/org/jboss/test/vfs/FileVFSUnitTestCase.java:import java.nio.file.Files;
src/main/java/org/jboss/vfs/VFS.java:import java.nio.file.Files;

Rio

To view this discussion visit https://groups.google.com/d/msgid/wildfly/347154a8-168c-40a4-8b9d-4cfc707308b0n%40googlegroups.com.

[HY]

Thank you. Considering what you provided, I am still looking for an answer as to why the integration works fine on my dev machine. Are there alternative vfs implementations that are being utilized (albeit I don't know of any action that I have explicitly taken)? Can you think of an alternative approach to address the issue?

Below are a few related Wildfly log messages extracted from my dev machine.

2024-12-11 15:46:13,159 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-7) WFLYSRV0018: Deployment "deployment.example.ear" is using a private module ("org.jboss.vfs") which may be changed or removed in future versions without notice.

2024-12-11 15:46:14,773 INFO  [org.jboss.weld.Version] (MSC service thread 1-3) WELD-000900: 5.1.1 (SP1)

2024-12-11 15:46:15,008 ERROR [stderr] (MSC service thread 1-4) java.nio.file.ProviderNotFoundException: Provider "vfs" not found
2024-12-11 15:46:15,009 ERROR [stderr] (MSC service thread 1-4) at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:359)

2024-12-11 15:46:15,009 ERROR [stderr] (MSC service thread 1-4) at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:288)

Your help is much appreciated.

[Richard Opalka]

Hello HY,

   You shuld focus on deployment.example.ear.ejb.jar//com.example.service.Scheduler.<clinit>(Scheduler.java:63) line.

Since the issue is reproducible on test machines it would make sense to debug that line of code there. You should

investigate what current context class loader is being used and for which scheme the file system provider is being looked for.

Rio

To view this discussion visit https://groups.google.com/d/msgid/wildfly/8870ef44-d209-49fe-a45c-a99c59097a37n%40googlegroups.com.