I’m trying to convert a legacy Driver from v7.9 to v8 and im getting the following Java error after installing the driver in Ignition v8 Gateway.

I realize that the class “com.inductiveautomation.xopc.driver.api.configuration.DriverType” cannot be loaded due to the changes made with the newer version however I don’t know how to get around this without rewriting my entire driver. i’m hoping there’s a 1:1 class that i can remap to but i’m sure its not that easy.

I’ve hunted trough the new programming guide supplied for v8 but haven’t had any luck yet.
Any help would be greatly appreciated!!

com.inductiveautomation.ignition.common.modules.ModuleLoadException: Unable to load hook class “”.
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl$LoadedModule.loadHook(
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl$LoadedModule.load(
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl.startupModule(
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl$
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl.executeModuleOperation(
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl.installModuleInternal(
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl$InstallCommand.execute(
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl$Receiver.receiveCall(
at com.inductiveautomation.ignition.gateway.redundancy.QueueableMessageReceiver.receiveCall(
at com.inductiveautomation.ignition.gateway.redundancy.RedundancyManagerImpl.dispatchMessage(
at com.inductiveautomation.ignition.gateway.redundancy.RedundancyManagerImpl$
at com.inductiveautomation.ignition.common.execution.impl.BasicExecutionEngine$
at java.base/java.util.concurrent.Executors$ Source)
at java.base/ Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$ Source)
at java.base/ Source)
Caused by: java.lang.NoClassDefFoundError: com/inductiveautomation/xopc/driver/api/configuration/DriverType
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
at java.base/ Source)
at java.base/ Source)
at java.base/$ Source)
at java.base/$ Source)
at java.base/ Method)
at java.base/ Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at driver.GatewayHook.(
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.base/java.lang.Class.newInstance(Unknown Source)
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl$LoadedModule.loadHook(
… 17 more
Caused by: java.lang.ClassNotFoundException: com.inductiveautomation.xopc.driver.api.configuration.DriverType
at java.base/ Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
… 34 more

8.0.2 (b2019060511)
Azul Systems, Inc. 11.0.3

That DriverType class does exist in v8. However, the OPC/UA server module name changed from xopc to com.inductiveautomation.opcua. Make sure you’ve made that adjustment in your build, or your module won’t be pulled into the classloader that has access to DriverType and all the other stuff you will need.

However, you are going to have a significant rewrite. All of the classes under com.inductiveautomation.opcua.* in v7.9 are gone. Most have replacements under org.eclipse.milo.opcua.stack.* or org.eclipse.milo.opcua.sdk.* in v8.0. There are semantic changes, too.

@Kevin.Herron, do you have a porting guide? I recall some suffering when doing this for my Ethernet/IP driver.

DriverType still exists and is defined at that location.

My guess is that your module isn’t being loaded underneath the OPC UA module’s ClassLoader any more because the module id changed from “xopc” to “com.inductiveautomation.opcua” but your module.xml is still referencing “xopc” as its dependency.

edit: lol, I just realized you already said this @pturmel. I didn’t read your post close enough :slight_smile:

As far as porting goes, there’s definitely some work that needs to be done. You can still use your existing driver written against the Driver interface because of the adapter/bridge I wrote, but as @pturmel mentioned there’s a lot of OPC UA related imports that need updating.

Get your module compiling against the 8.0 SDK APIs, start deleting broken imports, and let your IDE help you start importing the new classes. Post here when you have questions.

Fantastic! That worked.
OK, now after successfully loading the module into my gateway i am not able to see the driver in the driver list when adding a new device. Could this be a class mismatch issue as well?

Check to see if the module is faulted and if there’s a bunch of errors in your gateway logs or not.

The module is not faulted and there are no errors in the gateway log.

Guess you just need to start debugging/troubleshooting then. Maybe add some logging to your module hook and ensure that getDriverTypes() is being called for starters.