river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Johnson - Sun Microsystems <Thomas.John...@Sun.COM>
Subject Re: Integrity.NO constraint results in selection of X500Provider instances
Date Tue, 27 Mar 2007 19:41:34 GMT
Mark Brouwer wrote:
> When I configure Integrity.NO for discovery the logging (see below)
> reveals that the SHA1withDSA client provider is used while according to
> DJ.3.2 this provider supports "integrity protection of multicast request
> and announcement packet contents, and sender authentication".
> 27-Mar-2007 11:40:17 com.sun.jini.discovery.DiscoveryV2
>     decodeMulticastAnnouncement (oid=,
>                                  instance=master)
> FINEST: decoded MulticastAnnouncement[0, polaris:8888, [],
>         0bae0e43-cb40-4d98-81aa-9b61d45c038d] using
>         com.sun.jini.discovery.x500.sha1withdsa.Client@1ffccd6,
>         InvocationConstraints[reqs: {Integrity.NO}, prefs: {}]
> To me it seems that Integrity.NO as constraint can't be fulfilled by
> this provider and therefore should have failed. Is my reasoning correct
> or is there language that allows the above to happen.
This may just be a logging bug. If you happen to be invoking 
DiscvoeryV2.decodeMulticastAnnouncement with delayConstraintCheck set to 
true, this enables you to delay constraint checking until a more 
opportune time. This feature is currently used in LookupDiscovery (see 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4867820 for more 
information on this). It looks like when this feature was added, the 
logging message was not updated to reflect the fact that constraint 
checking has been delayed.

If you happen to be using LookupDiscovery, you should see a later 
logging message from LookupDiscovery (at HANDLED level) - "exception 
decoding multicast announcement", with the associated exception. This is 
the point at which the constraint check is actually done.
- vinod

View raw message