Hi,

Normally that error happens when the models are not registered to the SDK. Since you said you did that, is it possible to show that part of the code? Like, it could be a bug, but 99% of the time that error means incorrect (or no) registration. In SDK 4.x if the server_model_provider target is used in codegen, and the output resource files are in the classpath, SDK would by default register the model itself internally via java ServiceLoader (basically as-if you would have called registerModel for the UaServer object).

I assume you are using SDK 4.x, but could you please specify the exact version. Also, it would be a good practice to end all type names in “Type”. Most information models do this, thus we use the type name by default for the interface name, and append “Node/NodeBase/Impl/ImplBase” for the implementation parts. I assume that the “Test1Node” class is output of the codegen.

What happens behind the scenes is that SDK will only read the @TypeDefinitionId annotation from the classfile to obtain the ExpandedNodeId of the type. Then it will delegate to those versions of the instatiation (class info is lost at this point). Then during the instantiation, SDK checks if there is a class registered for a TypeDefinition and it will instantiate that. Then when the call is back in the Class parameter version, we will cast the UaNode output to that class, which should be the same you initially gave (due to the registration).

In general, it works like this to allow instantiation to work without codegen. Basically you could say all codegen does is add syntactic sugar for making it easier to operate on the nodes (plus, in some major versions in the past, it was needed for custom Structures, and there are still one or two edge cases where it is still needed).

Ok, great that it was resolved 🙂

We added at some point a feature to help with this:
IF you can come up with an “alias” to your namespace, such as we typically use “DI” for http://opcfoundation.org/UA/DI/, you can add ‘prefix’ element in the ‘namespaceMapping’ xml block of the codegen configuration. Then the output e.g. would be “DiServerInformationModel.java” (though, note that we configured it as “Di” to have more java-like name), which makes it easier to avoid making that mistake. In the “codegen/commandline/configexamples/di_adi_plcopen.xml” you can see an example of that, though, it should be mentioned that for those the codegen internally defaults to those aliases, but they are listed also as a commented out xml block in that configuration.

That is also useful for the “Ids” output, since it allows you to use those from more than one model in the same class (otherwise you would need the fully qualified form).

We do not have a prefix for the standard, base namespace (http://opcfoundation.org/UA/), thus that is always “ServerInformationModel” (like, at least in SDK 4.x scope, since it would be somewhat major change).

P.S.
IF you use the server_model output target in addition to server_model_provider target (or the ALL forms which include those), and added the resource folder output to be in the classpath (typically this happens with maven build-helper plugin in Maven projects), then you can use the ServerInformationModel.getLocationURI(). Codegen will copy the nodeset xml that contained the model to the resources output to package next to the ServerInformationModel.java (that is in code output, but the package is the same, so “classpath-next-to”), thus that should work. This way your modelling project can be basically anywhere codegen can access it and you do not need to copy the model manually (avoids model out of sync -type scenarios).