On Sun, Apr 22, 2018 at 11:18 AM, Robert Varga <[email protected]> wrote:

> On 22/04/18 10:01, Anil Vishnoi wrote:
> >
> >     To drive the argument to conclusion, though, is the analysis why
> things
> >     broke -- which is because Ipv4Address.equals() uses getClass() to
> >     determine equality. Ipv4AddressNoZone inherits that -- it's not what
> >     Ipv4AddressNoZone type or MD-SAL's treatment of it has done. It is
> what
> >     Ipv4Address as an MD-SAL-generated type does.
> >
> > ​I think you got my question finally. This is what basically broke the
> > backward compatibility ​for ipv4address. derive type.
>
> Thank you for clearly stating your question, I finally understand it.
>
> Thanks,
> Robert, rejoicing in understanding.
>
​Sorry for putting you though the pain, but if ​you would have read my very
initial response to this mail carefully, you would have been rejoining very
early on ;-)

*" This seems like regression. ietf-type (2013-07-15) supports both the
version and this revision seems to be backward compatible."*

*"This is not correct behavior in my opinion, because ietf clearly says
that user "may" add zone, so the equals should not fail if two ipv4-address
(without zone) is compared."*



-- 
Thanks
Anil
_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to