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
<peter.firmst...@zeus.net.au> wrote:
LookupLocator's identity contract:
/**
* Two locators are equal if they have the same<code>host</code> and
*<code>port</code> fields. The case of the<code>host</code> is
ignored.
* Alternative forms of the same IPv6 addresses for the
<code>host</code>
* 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&r2=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.
