[NEUTRON-199] class NeutronID should be abstract and cannot be used as for List<NeutronID> properties Created: 08/Oct/18  Updated: 29/Aug/19

Status: Confirmed
Project: neutron
Component/s: northbound-api
Affects Version/s: None
Fix Version/s: Neon

Type: Improvement Priority: Medium
Reporter: Michael Vorburger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While upgrading the version of Jersey used in Neutron in NEUTRON-197 during the big Neon-MRI bump, and having to change how it uses Moxy for working with JSON, I have stumbled upon something in the Neutron code (as it is right now) which seems to have been modelled wrong originally:

Classes NeutronLoadBalancerHealthMonitor, NeutronLoadBalancerListener and NeutronLoadBalancerPool use List<NeutronID> ... and NeutronID is the base class of for (almost all) Neutron object clases. (Via NeutronObject which everything else extends; except NeutronL2gatewayDevice, which seems a bit weird?).

Now this would mean that e.g. a NeutronLoadBalancerHealthMonitor's loadBalancerHealthMonitorPools field, in JSON, could contain not only e.g. "listeners" : [ { "id": "39de4d56-d663-46e5-85a1-5b9d5fa17829" } ] (a NeutronID) but really any other full Neutron object. I highly doubt that was the intention, as that surely would not make any sense?

What whoever wrote that load balancer code in Neutron probably meant was that these fields should contain (a list of) String UUIDs referring to other Neutron objects - but only that, and not full other objects.

 Comments   
Comment by Michael Vorburger [ 08/Oct/18 ]

WIP in (Draft) https://git.opendaylight.org/gerrit/#/c/76770/ ...

Comment by Michael Vorburger [ 08/Oct/18 ]

The reason why I think it would be useful to clean this up isn't just "modeling purity"  but because as per one of the (too many, buried) comments on NEUTRON-197 it seems Moxy can get confused about which is the "class type indicator field" (there is none).

This is seen when using the jersey-media-moxy (it's mere presence on the classpath by way of a dependency in northbound-api), which causes the following issue, the idea would be to see if doing above prevents this (without suggesting to actually switch to jersey-media-moxy at this point, there is no reason; but it would still be good to clean this up for the future):

Exception [EclipseLink-43] (Eclipse Persistence Services - 2.7.3.v20180807-4be1041): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: Missing class for indicator field value [HTTP] of type [class java.lang.String].
Descriptor: XMLDescriptor(org.opendaylight.neutron.spi.NeutronLoadBalancerHealthMonitor --> [DatabaseTable(neutronLoadBalancerHealthMonitor), DatabaseTable(neutronObject), DatabaseTable(neutronID)])
Generated at Wed Feb 07 20:25:49 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.