Log In
Register
Topic RSS
19:13, EEST
February 21, 2014
Offline
Good afternoon,
I would like to generate code from the MDIS Companion standard, v1.3. The code generation itself succeeds without warnings or errors. The code does not compile, though, because some method declarations occur twice within the same class or interface.
Is this a problem with/of the companion standard or does the code generator need to be configured in a custom way?
As an example:
public interface MDISChokeObjectType extends MDISBaseObjectType {
…
line 100:
@Mandatory
void setCalculatedPosition(Float value) throws StatusException;
…
line 189: void setCalculatedPosition(Float f_position) throws StatusException, ServiceException;
…
Edit: Taking a closer look at the nodeset / companion standard, there is a read-only variable for each method, reflecting the value, which the method is expected to set. It looks like the code generator creates a setter method for those variables nonetheless. Another indicator for this are the declared exception types.
Is there any way to configure the code generator to NOT generate setters for any variable at all?
11:47, EEST
April 3, 2012
Offline
Hi,
It is a known issue: https://documentation.prosysop…..own-issues
The model https://reference.opcfoundatio…..0020/6.6.3 defines both a CalculatedPosition component and a SetCalculatedPosition Method. Thus it will conflict when we create the setter for the CalculatedPosition component and then the actual method for calling the Method. Codegen is not yet smart enough that it would detect and report this as an error directly. (There are also few other types in this model that do the same); we can hopefully do this at some point.
You must exclude one of them via https://documentation.prosysop…..generation. I would recommend excluding the CalculatedPosition component, as it is easier to get via the generic UaNode.getComponent(QualifiedName) than implementing the Method call via https://documentation.prosysop…..tener.html style.
Thus, something like this in the Codegen configuration should do it:
<instanceDeclarations>
<instanceDeclaration>http://opcfoundation.org/UA/MD…..on>
</instanceDeclarations>
</excludes>
(…some day better code-snippet way…. but anyway have “http://opcfoundation.org/UA/MDIS:CalculatedPosition” without quotes as the ‘instanceDeclaration’ tag data)
Note that it does exclude the CalculatedPosition node from all types of http://opcfoundation.org/UA/MDIS. This was originally designed to avoid conflicts with the SDK API itself.
P.S.
Personally I would say it is a bit of an odd choice in the model that there seems to be Methods that just serves the same role as what a simple Write operation could do. There is maybe a bit of nuances regarding the async clause https://reference.opcfoundatio…..0020/6.6.7 though Write does have that as well https://reference.opcfoundatio…..4/5.11.4.4. (though only in the presence of an “intermediate system”, though an UA Client doesn’t anyway know nothing of that so.. why does it matter). However, this is not the first time we see such models, so it is probably too late anyway to try to change them. Also, there could be valid cases, if more parameters would be involved the very least. (Or there could be something I miss here).
P.S.2.
It is possible we some day do something for this. Though it is .. somewhat complicated to find a good solution that doesn’t involve excluding. We could e.g. start to use prefixes for methods i.e. ‘callXXX’ instead of ‘xXX’ where XXX is the method name (though this would change all existing ones). It could maybe be a flag in the Codegen configuration, though then it gets tricky with overriding of methods (even more if doing so from the core model that is already generated in the SDK). We could try doing that only for methods starting with ‘set’/’get’, but then it is different based on the name (and could still maybe theoretically conflict). We could add a unused parameter as the first java-parameter in the method, but that too is a bit clunky solution.
12:12, EEST
February 21, 2014
Offline
Thank you very much for looking into this.
I am reluctant to exclude anything from code generation because most of the variables/components/methods are indeed important and required.
While the nodeset design is a bit unfortunate from a code generation perspective, it is still quite common to use explicit UA methods as setters and have likewise named read-only variables. It would be “cool” if some time in the future the code generator could consider the accesslevel of a variable.as well. if it is “CurrentRead”, then not generate a setter, if it is CurrentWrite and a setter method exists as well, then emit a warning.
I created (or rather Github Copilot) a gradle task to analyze the generated code, looking for setter and method definitions with conflicting signatures and remove just the duplicate setters. This way I don’t need to exclude any components and the code is compiling okay.
Once again, many thanks for looking into this.
14:28, EEST
April 3, 2012
Offline
Codegen-InstanceDeclaration-excluded nodes do still exist in the node-graph at runtime and are accessible via UaNode.getComponent(QualifiedName). Though, excluded Methods cannot be implemented in the generated XXXTypeNode (and the XXXTypeNodeBase will not have the routing logic to it either). I do recognize that in a development flow e.g. checking via autocomplete has every component been set could miss the excluded one as there is no individual method so it is easier to forget.
As far as I’m aware, AccessLevel in the InstanceDeclarations is more like a “default value”, not a “contract”. At least based on the base spec I mean. A companion spec might be able to limit this (in the text, not in a way for Codegen to know). Some Attributes have limits, https://reference.opcfoundatio…..00-3/6.2.7 + https://reference.opcfoundatio…..00-3/6.2.8, but to my knowledge nothing is said for AccessLevel. Also, the generated setters are mostly for server side, but there it is usable always for setting the value, even if it would be read-only from a client’s point of view.
Just be careful to remove the component-setter version from all of the generated files (i.e. not accidentally removing the method one in e.g. one file). The method one does also have ServiceException in addition to the StatusException. Note that the only difference to the Codegen-InstanceDeclaration-exclusion-way is that the getter and “node-getter” generated methods exist still (but this could be important).
P.S.
This of course causes me to think could we have some day an option to exclude “any generated method”. We do have class-level exclusions https://documentation.prosysop…..ut-classes, basically to avoid generating XXXTypeNodes that are in version control due to implemented methods.
Though it would still be more of a workaround than an actual solution.
14:48, EEST
February 21, 2014
Offline
The gradle script distinguishes between method calls and setters using the presence of the ServiceException clause. This should leave all method declarations and implementation untouched.
Let me reformulate my “wish” for an ideal code generator:
Assuming a / any valid nodeset.xml as an input, the generated code should be compileable without errors and expose all features of the nodeset design. I am very aware that this presents a real challenge and that this is hardly – if at all- ever accomplishable. So this is not any criticism – just a Christmas wish 🙂
1 Guest(s)
