> On 29 Dec 2017, at 00:33, Steven Schlansker <stevenschlans...@gmail.com> > wrote: > > Thanks for the discussion! > > So, it sounds like amending the message by default is going to be a > non-starter -- but at least adding the information otherwise might be > possible. > > One possibility would be to add new fields to SocketException, for example an > InetSocketAddress representing both the local and remote (if available).
You would need to careful to not disclose resolved addresses to untrusted code. SocketException, since a subtype of IOException, can wind up in many places. Would you be proposing to add these new fields to the serial-form of SocketException? What behaviour do you envisage for deserializing instances from previous releases? This will have an impact of any potential API. > This would not be rendered by default, but could be retrieved by a > cooperating application or library. Or maybe a second step could be a > '-Djavax.net.debug=exceptions' that then appends this information by default, > but that sounds more controversial. Logging seems like a better alternative than a system property, to me. > Then at least libraries and applications have the ability to get these > diagnostics, even if they choose not to. > Is this an acceptable approach? Would it be accepted as a patch? I suspect that a webrev/patch would help drive the discussion, rather than a commitment to accepting it into the JDK. -Chris. >> On Dec 22, 2017, at 8:42 AM, Bernd Eckenfels <e...@zusammenkunft.net> wrote: >> >> Hello, >> >> I also dearly miss Socket addresses in connection exceptions, however it >> looks like it is not going to make it. However if we add a getter for the >> Peer address (not included in toString) then logging frameworks could detect >> instances of ConnectException and process them accordingly. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ________________________________ >> From: net-dev <net-dev-boun...@openjdk.java.net> on behalf of Chris Hegarty >> <chris.hega...@oracle.com> >> Sent: Friday, December 22, 2017 4:17:31 PM >> To: Seán Coffey; David Holmes; Steven Schlansker >> Cc: core-libs-dev; net-dev@openjdk.java.net >> Subject: Re: Adding SocketChannel toString to connection exception messages >> >> >>> On 22/12/17 14:59, Seán Coffey wrote: >>> As someone who works with alot of log files, I'd like to chime in and >>> support Steven's end goal. Looking at a "Connection refused" error in >>> the middle of a log file that possibly extends to millions of lines is >>> near useless. In the era of cloud compute, diagnosing network issues is >>> sure to become a more common task. >>> >>> While we may not be able to put the sensitive information in an >>> exception message, I think we could put it behind a (new?) system >>> property which might be able to log this information. Logs contain all >>> sorts of sensitive data. Take javax.net.debug=ssl output for example. >> >> I have some sympathy for (capital-L)ogging such detail messages >> ( given the reasonable restriction on access to log files ), but >> a system property that effectively amends exception detail >> messages, or prints to stdout/stderr is not a runner in my >> opinion. >> >> Maybe we should be looking at instrumentation with JFR events, or >> similar. My point being, if someone has time and energy enough >> to spend on this, then we can do better than javax.net.debug=ssl. >> Also, someone should check that divulging such sensitive information, >> even in log files, is acceptable from a security perspective. I'm >> personally still dubious. >> >> -Chris. >
