Multiple metadata entries in properties

[jmachowinski]

Hey,
there seems to be a bug in the latest orogen. If I run
task.each_property I get the entry for metadata of
type metadata::TaskContext 2 times. Any ideas
what might be the source ?
Janosch

[goldhoorn]

The problem is related how orogen handles subclassing.

the metadata creating on each parent and child class a property "metadata".
This yields into the problem, that the parent and child itself have the metadata property, this internally and externally.

The same is truth for input/output ports either. I see currently no easy was to solve this. It might be the best solution if a port with the same name and type is generated on a superclass to not generate the respective member on the child. But i don't know if this would have other side-effects within the framework.

The current solution is not good either, because a superclass might call metadata.set('something') but the metadata object on the parent is another instance and would not updated here.

[goldhoorn]

It seems the complete orogen loading mechanism is partwise broken which makes this bug even harder.

the metadata plugin checks if it's already registered and skipts the generation otherwise.

 10                 if !find_extension("MetaDataPlugin")

the find_extension should check the superclasses too, but the problem is that this does not work. on this step of loading the @superclass is either empty or only the RTT::TaskContext therefore the check fails.

Even is the check would be there. the c++ code generation should be done on the child to build up the port-model for the child too. This starts to get tricky for the same reasons than in my previous post...

[doudou]

👍 on the general analysis, in addition:

(1) the Spec's each_ methods should never yield two interface objects that have the same name, as a matter of rule
(2) the extension should register itself as each level of the hierarchy (same than e.g. the stream aligner), as it stores information that is specific to that specific level of the hierarchy (metadata set on the subclass should not "appear" on the superclass)
(3) the subclass issue you fished is indeed a problem. We'll have to move to having the superclass as a parameter of #task_context in order to fix that problem (e.g. having the superclass "fixed" at construction, which is obvious in hindsight). Calling #superclass would be deprecated.
(4) until we get (3) widely deployed, we should simply "ignore" duplicate properties that have same name and type.