Hi,

Depends on what you count, we do also have the way we had before Codegen, see MyMethodManagerListener in the sampleconsoleserver, but it is a bit more pain to use.

Also, the documentation could be better. You can push the implementations via the setXXXMethodImplementation also before loading the model.

In general this is a complicated topic. There is no best way, because it depends on what you want to do and how. Personally nowadays I would prefer to avoid changing generated files manually (too bad java doesn’t have partial classes the same way as C# has, we sort of emulate this with the 2 outputs per type, but it is not the same), thus the setXXXMethodImplementation way. This way you can also add an implementation to the core namespace types, as we have already generated and use that as part of the SDK (i.e. the code is already compiled). Though, if you would need any extra info you cannot like store it as a field in the class this way.

In a generic case I believe just having the signature is basically almost the best we can do in the generation, because we cannot know anything what the method would do (if we would there would be no need to write the implementation manually). But we could probably add some more in-depth example of using the SampleTypes.xml generation outputs, it currently serves more like this is how to use Codegen -sample, not exactly using the generated sources after that.

(I think this is missing from the manual, should probably be added..)

If you would happen to use a dependency injection framework that allows injecting to static setters (e.g. like with Google Guice, https://github.com/google/guice), you can add:

in the Codegen configuration. Then those method handler setters would be annotated with the given annotations.
(or I guess nowadays the more standard JSR-330 annotation would be used instead)

and have

(the the Guice module configure method; you would also bind the method implementation interface to an implementation etc.)

The methods handlers are in the XXXTypeNodeBase, which XXXTypeNode extends. We tried to emulate C# partial classes such as that the TypeNodeBase contains all logic and can be easily regenerated. Doesn’t matter here, but might be important (not sure does the requestStaticInjection work via XXXTypeNode in this case or only via XXXTypeNodeBase, though technically static methods are visible in subclasses, that is why the interface names are XXXTypeNameYYYMethodNameMethod).

This may or may not be useful, but one of our own app does it like that.