Hi Andrew: Sorry for late, but as this solution does not resolve I18N (working aound for 815 only?) , I guess we may have another way. If I understand correctly, this solution try to analysis error code in native code, throws ErrorCodeException; and java code catch this exception, get error code, and throw another exception. If so, why not just return the error code directly instead? :)
2006/7/14, Mikhail Loenko <[EMAIL PROTECTED]>:
Hi Andrew this seems reasonable Thanks, Mikhail 2006/7/14, Andrew Zhang <[EMAIL PROTECTED]>: > Hi folks, > > I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids message > comparison while keeps current luni native architecture. > > Before I upload a new patch to JIRA, I want to hear more voices from > the community. Any better suggestions? Any comments? > > Mikhail, what's your opnion? Do you think it makes sense? > > Thanks in advance! > > Best regards, > Andrew > > > On 7/14/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > Andrew Zhang wrote: > > > How about design a subclass which extends from SocketException, looks > > like: > > > > If you want to preserve the throwable type you could create a > > o.a.h.luni.ErrorCodeException that has a errorCode field set by the > > native, and then make that the cause of the SocketException. > > > > The calling code would then do something like: > > ((ErrorCodeException)ex.getCause()).getErrorCode() > > > > Just a thought. > > > > Regards, > > Tim > > > > > > > class SocketWithErrorCodeException extends SocketException { > > > > > > SocketWithErrorCodeException (String message, int errorCode) { > > > super(message); this.errorCode = errorCode; } > > > > > > private int errorCode; > > > > > > public void get/setErrorCode() ; > > > > > > } > > > > > > Native code throws SocketWithErrorCodeException instead of > > SocketException > > > so that java code could process different error by invoking > > e.getErrorCode > > > (). > > > > > > Does that make sense? > > > > > > Thanks! > > > > > > On 7/13/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > >> > > >> I agree with the reason why (I think I understand it - you don't want > > to > > >> rely on the result of getMessage() to determine the problem...) > > >> > > >> Could you wrap the socket exception to carry a simple integer error > > code? > > >> > > >> geir > > >> > > >> > > >> Mikhail Loenko wrote: > > >> > -1 for applying the patch > > >> > > > >> > Applying this patch means creating a hidden problem > > >> > > > >> > Thanks, > > >> > Mikhail > > >> > > > >> > 2006/7/12, Jimmy, Jing Lv <[EMAIL PROTECTED]>: > > >> >> Andrew Zhang wrote: > > >> >> > Hello Mikhail, > > >> >> > > > >> >> > Please see my comments inline. > > >> >> > > > >> >> > Thanks! > > >> >> > > > >> >> > > > >> >> > On 7/12/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > >> >> >> > > >> >> >> 2006/7/12, Andrew Zhang <[EMAIL PROTECTED]>: > > >> >> >> > Hi Mikhail, > > >> >> >> > > > >> >> >> > It's a NON-NLS message. > > >> >> >> > > > >> >> >> > Native code is designed in this way. Currently, Harmony socket > > >> >> native > > >> >> >> code > > >> >> >> > uses messages in SocketException to identify error type. > > >> >> >> > > > >> >> >> > To avoid the confusion, two alternatives way I could image are: > > >> >> >> > > > >> >> >> > 1. Native code returns platform-independent error code. > > >> >> >> > > > >> >> >> > 2. Native code throws different exceptions, which are all > > >> >> extended from > > >> >> >> > SocketException. > > >> >> >> > > > >> >> >> > Anyway, as current Harmony native design, the message in > > >> >> >> SocketException > > >> >> >> > thrown by native code is a NON-NLS string, that is to say, like > > >> >> >> "GET","POST" > > >> >> >> > in http protocol. Unless we take a big change on native code > > >> >> design, I > > >> >> >> > don't think the code is dangerous. > > >> >> >> > > > >> >> >> > What's your opnion? > > >> >> >> > > >> >> >> I like option #2. > > >> >> > > > >> >> > > > >> >> > I also prefer option1 and 2 to current native solution. > > >> >> > > > >> >> > I don't think exception messages are the same as "GET" and > > >> "POST", we > > >> >> > agreed > > >> >> >> that the messages are to be internationalized. I see that > > currently > > >> >> not > > >> >> >> all > > >> >> >> the messages are internationalized but I think they will in the > > >> >> future. > > >> >> > > > >> >> > > > >> >> > NO. Currently, exception message thrown by native code are used as > > >> >> if error > > >> >> > code [1]. Please pay attention to netLookupErrorString function. > > >> >> > > > >> >> > Harmony-815 patch is based on current Harmony native > > implemenation, > > >> >> > therefore, it should work well if design is not changed. > > >> >> > > > >> >> > If we decide to adopt option 1, or 2, we have to re-design native > > >> >> and java > > >> >> > interface, > > >> >> > > > >> >> > and there are lots of native and java code to be changed. > > >> >> > > > >> >> > How to design native interface is out of scope to this patch, > > >> >> therefore, I > > >> >> > think a seperate JIRA or thread for socket native interface design > > >> >> is more > > >> >> > suitable. > > >> >> > > > >> >> > Of course, once decision is made, I'll volunteer to revise native > > >> >> and java > > >> >> > code. > > >> >> > > > >> >> > > >> >> Yep, I also find this strange style of return value, I doubt if the > > >> >> exception thrown in native may be an enhancement to code efficiency? > > >> >> However to refactor this may be a heavy work, as much code follows > > >> this > > >> >> style, affects both luni and nio. I suggest apply this patch, and > > >> leave > > >> >> this work until Harmony begins i18n. > > >> >> > > >> >> > Does it make sense? > > >> >> > > > >> >> > Thanks! > > >> >> > > > >> >> > [1] native-src (nethelp.c) > > >> >> > > > >> >> > > > >> >> > void > > >> >> > throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber) > > >> >> > { > > >> >> > jclass aClass; > > >> >> > /* the error message lookup should be done before the FindClass > > >> call, > > >> >> > because the FindClass call > > >> >> > * may reset the error number that is used in > > hysock_error_message > > >> */ > > >> >> > > > >> >> > // !!! Here, error code is mapped to NON-NLS mesage. > > >> >> > char *errorMessage = netLookupErrorString (env, errorNumber); > > >> >> > aClass = (*env)->FindClass (env, "java/net/SocketException"); > > >> >> > if (0 == aClass) > > >> >> > { > > >> >> > return; > > >> >> > } > > >> >> > (*env)->ThrowNew (env, aClass, errorMessage); > > >> >> > > > >> >> > } > > >> >> > > > >> >> > char * > > >> >> > netLookupErrorString (JNIEnv * env, I_32 anErrorNum) > > >> >> > { > > >> >> > PORT_ACCESS_FROM_ENV (env); > > >> >> > switch (anErrorNum) > > >> >> > { > > >> >> > case HYPORT_ERROR_SOCKET_BADSOCKET: > > >> >> > return "Bad socket"; > > >> >> > case HYPORT_ERROR_SOCKET_NOTINITIALIZED: > > >> >> > return "Socket library uninitialized"; > > >> >> > case HYPORT_ERROR_SOCKET_BADAF: > > >> >> > return "Bad address family"; > > >> >> > case HYPORT_ERROR_SOCKET_BADPROTO: > > >> >> > return "Bad protocol"; > > >> >> > case HYPORT_ERROR_SOCKET_BADTYPE: > > >> >> > return "Bad type"; > > >> >> > case HYPORT_ERROR_SOCKET_SYSTEMBUSY: > > >> >> > return "System busy handling requests"; > > >> >> > case HYPORT_ERROR_SOCKET_SYSTEMFULL: > > >> >> > return "Too many sockets allocated"; > > >> >> > case HYPORT_ERROR_SOCKET_NOTCONNECTED: > > >> >> > return "Socket is not connected"; > > >> >> > case HYPORT_ERROR_SOCKET_INTERRUPTED: > > >> >> > return "The call was cancelled"; > > >> >> > case HYPORT_ERROR_SOCKET_TIMEOUT: > > >> >> > return "The operation timed out"; > > >> >> > case HYPORT_ERROR_SOCKET_CONNRESET: > > >> >> > return "The connection was reset"; > > >> >> > case HYPORT_ERROR_SOCKET_WOULDBLOCK: > > >> >> > return "The socket is marked as nonblocking operation would > > >> >> block"; > > >> >> > case HYPORT_ERROR_SOCKET_ADDRNOTAVAIL: > > >> >> > return "The address is not available"; > > >> >> > case HYPORT_ERROR_SOCKET_ADDRINUSE: > > >> >> > return "The address is already in use"; > > >> >> > case HYPORT_ERROR_SOCKET_NOTBOUND: > > >> >> > return "The socket is not bound"; > > >> >> > case HYPORT_ERROR_SOCKET_UNKNOWNSOCKET: > > >> >> > return "Resolution of the FileDescriptor to socket failed"; > > >> >> > case HYPORT_ERROR_SOCKET_INVALIDTIMEOUT: > > >> >> > return "The specified timeout is invalid"; > > >> >> > case HYPORT_ERROR_SOCKET_FDSETFULL: > > >> >> > return "Unable to create an FDSET"; > > >> >> > case HYPORT_ERROR_SOCKET_TIMEVALFULL: > > >> >> > return "Unable to create a TIMEVAL"; > > >> >> > case HYPORT_ERROR_SOCKET_REMSOCKSHUTDOWN: > > >> >> > return "The remote socket has shutdown gracefully"; > > >> >> > case HYPORT_ERROR_SOCKET_NOTLISTENING: > > >> >> > return "Listen() was not invoked prior to accept()"; > > >> >> > case HYPORT_ERROR_SOCKET_NOTSTREAMSOCK: > > >> >> > return "The socket does not support connection-oriented > > >> service"; > > >> >> > case HYPORT_ERROR_SOCKET_ALREADYBOUND: > > >> >> > return "The socket is already bound to an address"; > > >> >> > case HYPORT_ERROR_SOCKET_NBWITHLINGER: > > >> >> > return "The socket is marked non-blocking & SO_LINGER is > > >> >> non-zero"; > > >> >> > case HYPORT_ERROR_SOCKET_ISCONNECTED: > > >> >> > return "The socket is already connected"; > > >> >> > case HYPORT_ERROR_SOCKET_NOBUFFERS: > > >> >> > return "No buffer space is available"; > > >> >> > case HYPORT_ERROR_SOCKET_HOSTNOTFOUND: > > >> >> > return "Authoritative Answer Host not found"; > > >> >> > case HYPORT_ERROR_SOCKET_NODATA: > > >> >> > return "Valid name, no data record of requested type"; > > >> >> > case HYPORT_ERROR_SOCKET_BOUNDORCONN: > > >> >> > return "The socket has not been bound or is already > > connected"; > > >> >> > case HYPORT_ERROR_SOCKET_OPNOTSUPP: > > >> >> > return "The socket does not support the operation"; > > >> >> > case HYPORT_ERROR_SOCKET_OPTUNSUPP: > > >> >> > return "The socket option is not supported"; > > >> >> > case HYPORT_ERROR_SOCKET_OPTARGSINVALID: > > >> >> > return "The socket option arguments are invalid"; > > >> >> > case HYPORT_ERROR_SOCKET_SOCKLEVELINVALID: > > >> >> > return "The socket level is invalid"; > > >> >> > case HYPORT_ERROR_SOCKET_TIMEOUTFAILURE: > > >> >> > return "The timeout operation failed"; > > >> >> > case HYPORT_ERROR_SOCKET_SOCKADDRALLOCFAIL: > > >> >> > return "Failed to allocate address structure"; > > >> >> > case HYPORT_ERROR_SOCKET_FDSET_SIZEBAD: > > >> >> > return "The calculated maximum size of the file descriptor > > set > > >> is > > >> >> > bad"; > > >> >> > case HYPORT_ERROR_SOCKET_UNKNOWNFLAG: > > >> >> > return "The flag is unknown"; > > >> >> > case HYPORT_ERROR_SOCKET_MSGSIZE: > > >> >> > return > > >> >> > "The datagram was too big to fit the specified buffer, so > > >> truncated"; > > >> >> > case HYPORT_ERROR_SOCKET_NORECOVERY: > > >> >> > return "The operation failed with no recovery possible"; > > >> >> > case HYPORT_ERROR_SOCKET_ARGSINVALID: > > >> >> > return "The arguments are invalid"; > > >> >> > case HYPORT_ERROR_SOCKET_BADDESC: > > >> >> > return "The socket argument is not a valid file descriptor"; > > >> >> > case HYPORT_ERROR_SOCKET_NOTSOCK: > > >> >> > return "The socket argument is not a socket"; > > >> >> > case HYPORT_ERROR_SOCKET_HOSTENTALLOCFAIL: > > >> >> > return "Unable to allocate the hostent structure"; > > >> >> > case HYPORT_ERROR_SOCKET_TIMEVALALLOCFAIL: > > >> >> > return "Unable to allocate the timeval structure"; > > >> >> > case HYPORT_ERROR_SOCKET_LINGERALLOCFAIL: > > >> >> > return "Unable to allocate the linger structure"; > > >> >> > case HYPORT_ERROR_SOCKET_IPMREQALLOCFAIL: > > >> >> > return "Unable to allocate the ipmreq structure"; > > >> >> > case HYPORT_ERROR_SOCKET_FDSETALLOCFAIL: > > >> >> > return "Unable to allocate the fdset structure"; > > >> >> > case HYPORT_ERROR_SOCKET_CONNECTION_REFUSED: > > >> >> > return "Connection refused"; > > >> >> > > > >> >> > default: > > >> >> > return (char *) hysock_error_message (); > > >> >> > } > > >> >> > } > > >> >> > > > >> >> > > > >> >> > Thanks, > > >> >> >> Mikhail > > >> >> >> > > >> >> >> > > >> >> >> > > > >> >> >> > Best regards, > > >> >> >> > Andrew > > >> >> >> > > > >> >> >> > > > >> >> >> > On 7/11/06, Mikhail Loenko (JIRA) <[EMAIL PROTECTED]> wrote: > > >> >> >> > > > > >> >> >> > > [ > > >> >> >> > > > > >> >> >> > > >> >> > > >> > > http://issues.apache.org/jira/browse/HARMONY-815?page=comments#action_12420281 > > >> > > >> >> > > >> >> >> > > >> >> >> ] > > >> >> >> > > > > >> >> >> > > Mikhail Loenko commented on HARMONY-815: > > >> >> >> > > ---------------------------------------- > > >> >> >> > > > > >> >> >> > > Hi Andrew > > >> >> >> > > > > >> >> >> > > I think it's rather dangerous: > > >> >> >> > > > > >> >> >> > > } catch (SocketException e) { > > >> >> >> > > if (ERRMSG_NONBLOKING_OUT.equals(e.getMessage ())) > > { > > >> >> >> > > return sendCount; > > >> >> >> > > } > > >> >> >> > > throw e; > > >> >> >> > > > > >> >> >> > > Once we internationilize our code that won't work > > >> >> >> > > > > >> >> >> > > > [classlib][nio] Refine implConfigureBlocking(boolean) > > method > > >> of > > >> >> >> > > DatagramChannel and SocketChannel. > > >> >> >> > > > > > >> >> >> > > > > >> >> >> > > >> >> > > >> > > -------------------------------------------------------------------------------------------------- > > >> > > >> >> > > >> >> >> > > >> >> >> > > > > > >> >> >> > > > Key: HARMONY-815 > > >> >> >> > > > URL: > > >> http://issues.apache.org/jira/browse/HARMONY-815 > > >> >> >> > > > Project: Harmony > > >> >> >> > > > Type: Improvement > > >> >> >> > > > > >> >> >> > > > Components: Classlib > > >> >> >> > > > Reporter: Andrew Zhang > > >> >> >> > > > Assignee: Mikhail Loenko > > >> >> >> > > > Attachments: nio.diff > > >> >> >> > > > > > >> >> >> > > > Currently, Harmony > > >> >> DatagramChannel.implConfigureBlocking(boolean) > > >> >> >> does > > >> >> >> > > nothing. > > >> >> >> > > > It doesn't cause any problem of read operation because > > >> >> Harmony uses > > >> >> >> > > select+blocking read to ensure nonblocking reading. > > >> >> >> > > > But it affects write operations, although it is difficult > > to > > >> >> test > > >> >> >> the > > >> >> >> > > difference between blocking write and blocking write. > > >> >> >> > > > Another defect is introduced by portlib bug. As discussed > > on > > >> >> >> mailing > > >> >> >> > > list[1], connect_with_timeout always changes the fd to > > blocking > > >> >> mode > > >> >> >> after > > >> >> >> > > invocation. > > >> >> >> > > > I'll upload a patch to fix these problems. > > >> >> >> > > > Thanks! > > >> >> >> > > > Best regards, > > >> >> >> > > > Andrew > > >> >> >> > > > > >> >> >> > > -- > > >> >> >> > > This message is automatically generated by JIRA. > > >> >> >> > > - > > >> >> >> > > If you think it was sent incorrectly contact one of the > > >> >> >> administrators: > > >> >> >> > > http://issues.apache.org/jira/secure/Administrators.jspa > > >> >> >> > > - > > >> >> >> > > For more information on JIRA, see: > > >> >> >> > > http://www.atlassian.com/software/jira > > >> >> >> > > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > >> >> >> > -- > > >> >> >> > Andrew Zhang > > >> >> >> > China Software Development Lab, IBM > > >> >> >> > > > >> >> >> > > > >> >> >> > > >> >> >> > > >> --------------------------------------------------------------------- > > >> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> >> >> To unsubscribe, e-mail: > > >> [EMAIL PROTECTED] > > >> >> >> For additional commands, e-mail: > > >> [EMAIL PROTECTED] > > >> >> >> > > >> >> >> > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> -- > > >> >> > > >> >> Best Regards! > > >> >> > > >> >> Jimmy, Jing Lv > > >> >> China Software Development Lab, IBM > > >> >> > > >> >> > > --------------------------------------------------------------------- > > >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> >> For additional commands, e-mail: > > [EMAIL PROTECTED] > > >> >> > > >> >> > > >> > > > >> > --------------------------------------------------------------------- > > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> > For additional commands, e-mail: > > [EMAIL PROTECTED] > > >> > > > >> > > > >> > > > >> > > >> --------------------------------------------------------------------- > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > -- > > > > Tim Ellison ([EMAIL PROTECTED]) > > IBM Java technology centre, UK. > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Andrew Zhang > China Software Development Lab, IBM > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM