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?
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.
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.
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.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
