On 14/11/2012 10:36 PM, Simon IJskes - QCG wrote:
Whereever a Socket or ServerSocket is created i want to have the
option of intercepting this call. Based on this, and this seems like
the simplest option, and the code was already there, i was against.
I havent looked at in depth. I believe you, if you say this intercept
can be done with an extended class. But why remove working code?
It was a recent addition, removing it didn't break any tests and it
simplifies LookupLocator.
As to security, nothing is less secure as a TCP connection, so i view
unicast (tcp based) discovery as a unsecure process anyway. The proof
is in the TLS between endpoints.
Discovery V2 offers security with the use of Constraints, allowing you
to have a secure connection, which is why Disco V1 was replaced.
I don't need it right now, but i will be very unhappy, when i need a
lot of extra work, the moment i need it.
I'm familiar with the ConstrainableLookupLocator code, I could knock it
up for you in about 10 min, I actually did this when I realised the
SocketFactory in LookupLocator wasn't being used by
LookupLocatorDiscovery or ConstrainableLookupLocator, then I looked at
it again and thought this looks wrong because it couldn't be
instantiated during multicast discovery, I could see what the intent was
though, hence the list questions.
I'd recommend against using disco v1 in LookupLocator because your
code's then locked into disco v1, whereas if you use
ConstrainableLookupLocator, you can change to disco v2 any time.
So if it doesnt harm, can we leave it in (the factory, not the rest)?
Gr. Simon
On 14-11-12 13:24, Peter Firmstone wrote:
Is it possible for you to subclass LookupLocator and override the
getRegistrar method?
Alternatively you could subclass ConstrainableLookupLocator and subclass
com.sun.jini.discovery.internal.MultiIPDiscovery, this is far simpler to
implement and would allow you to inject a socket into
ConstrainabledLookupLocator and use Discovery V2 or V1.
This could be done cleanly without making LookupLocator more a cludge
than it is already.
Discovery V1 used by LookupLocator was upgraded in Jini 2.0 with
Discovery V2 in LookupLocatorDiscovery and ConstrainableLookupLocator.
How badly do you need it?
Regards,
Peter.
On 14/11/2012 9:45 PM, Simon IJskes - QCG wrote:
On 14-11-12 11:50, Peter Firmstone wrote:
Reading over the comments, we all appear to be agreeing on Gregg's
approach, in that case I'll clean up LookupLocator before release,
then
we can look at how we can implement a configurable deployment
mechanism.
I was against removing the SocketFactory. Please revert.
