You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <pe...@zeus.net.au> on 2018/10/17 10:57:57 UTC
ConstrainableLookupLocator identity
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.
Re: ConstrainableLookupLocator identity
Posted by Peter Firmstone <pe...@zeus.net.au>.
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
> <pe...@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.
Re: ConstrainableLookupLocator identity
Posted by Bryan Thompson <br...@blazegraph.com>.
I've never used that aspect. Nothing to offer.
B
On Wed, Oct 17, 2018 at 3:57 AM Peter Firmstone
<pe...@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.