Hmm,
I should have said constraints shouldn't be part of LookupLocator
identity below, my bad. Perhaps if ConstrainableLookupLocator used
decoration, rather than inheritance, the design intent would have been
clearer. I don't like the fact that a ConstrainableLookupLocator can be
considered equal to a LookupLocator, but it breaks the following tests.
So I'm going to lodge an issue and back it out. I think the design
intent is like decorating a LookupLocator with constraints, it's was
never intended to change it's identity.
org/apache/river/test/impl/mahalo/AdminIFTest.td
org/apache/river/test/impl/mahalo/AdminIFShutdownTest.td
N.B. This only affects people using secure services.
Regards,
Peter.
On 18/10/2018 6:40 AM, Bryan Thompson wrote:
I've never used that aspect. Nothing to offer.
B
On Wed, Oct 17, 2018 at 3:57 AM Peter Firmstone
wrote:
LookupLocator's identity contract:
/**
* Two locators are equal if they have the samehost and
*port fields. The case of thehost is
ignored.
* Alternative forms of the same IPv6 addresses for the
host
* value are treated as being unequal.
*/
At some point in history, here,
http://svn.apache.org/viewvc/river/jtsk/trunk/src/net/jini/discovery/ConstrainableLookupLocator.java?r1=1034266=1034267;
FindBug's identified the ConstrainableLookupLocator didn't override
equals, so I implemented it, however while it seemed to make sense at
the time to include constraints, I'm finding that it's causing problems
for discovery magement and now I'm thinking that the constraints,
probably shouldn't be part of constraints.
What are your thoughts?
Regards,
Peter.