-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]
