db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1178) NetworkServer doesn't handle new subclasses of SQLException correctly
Date Tue, 04 Apr 2006 07:33:45 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1178?page=all ]

Dyre Tjeldvoll updated DERBY-1178:
----------------------------------

      Component: JDBC
                 Localization
                 Network Server
                 Regression Test Failure
    Fix Version: 10.2.0.0
        Version: 10.2.0.0
    Description: 
I observe a strange diff when running metadata.java under 1.6 and
NetworkServer.

Some expected SQLExceptions that are printed in the output have ' : '
appended to them, and this causes a diff.

After some debugging and poking around I discovered that this is
because

DRDAConnThread::buildSqlerrmc(SQLException se) 

assumes that if 'se' is NOT an EmbedSQLException it should not build a
tokenized sqlerrmc:

		if (se instanceof EmbedSQLException  && ! severe)
			sqlerrmc = buildTokenizedSqlerrmc((EmbedSQLException) se);
		else {
		    System.out.println("using preformatted..."); 
			// If this is not an EmbedSQLException or is a severe excecption where
			// we have no hope of succussfully calling the SYSIBM.SQLCAMESSAGE send
			// preformatted message using the server locale
			sqlerrmc = buildPreformattedSqlerrmc(se);
			}

But in Java 1.6 'se' can indeed be something else, e.g.
java.sql.SQLSyntaxErrorException

in this case the NetworkServer will build a preformatted message, and
SYSIBM.SQLCAMESSAGE will be called on this. Unfortunately  the input
is not checked very well so it ends up trying to use the preformatted
message as a real messageId and try to look up a localized version of
the message. This obviously doesn't work and in the bail-out process we end up
with the preformatted message with ' : ' appended to it...

So I think DRDAConnThread::buildSqlerrmc(SQLException se) must be able
to handle all the new SQLException types.
       Priority: Critical  (was: Major)
     Derby Info: [Regression]

> NetworkServer doesn't handle new subclasses of SQLException correctly
> ---------------------------------------------------------------------
>
>          Key: DERBY-1178
>          URL: http://issues.apache.org/jira/browse/DERBY-1178
>      Project: Derby
>         Type: Sub-task

>   Components: JDBC, Localization, Network Server, Regression Test Failure
>     Versions: 10.2.0.0
>     Reporter: Dyre Tjeldvoll
>     Priority: Critical
>      Fix For: 10.2.0.0

>
> I observe a strange diff when running metadata.java under 1.6 and
> NetworkServer.
> Some expected SQLExceptions that are printed in the output have ' : '
> appended to them, and this causes a diff.
> After some debugging and poking around I discovered that this is
> because
> DRDAConnThread::buildSqlerrmc(SQLException se) 
> assumes that if 'se' is NOT an EmbedSQLException it should not build a
> tokenized sqlerrmc:
> 		if (se instanceof EmbedSQLException  && ! severe)
> 			sqlerrmc = buildTokenizedSqlerrmc((EmbedSQLException) se);
> 		else {
> 		    System.out.println("using preformatted..."); 
> 			// If this is not an EmbedSQLException or is a severe excecption where
> 			// we have no hope of succussfully calling the SYSIBM.SQLCAMESSAGE send
> 			// preformatted message using the server locale
> 			sqlerrmc = buildPreformattedSqlerrmc(se);
> 			}
> But in Java 1.6 'se' can indeed be something else, e.g.
> java.sql.SQLSyntaxErrorException
> in this case the NetworkServer will build a preformatted message, and
> SYSIBM.SQLCAMESSAGE will be called on this. Unfortunately  the input
> is not checked very well so it ends up trying to use the preformatted
> message as a real messageId and try to look up a localized version of
> the message. This obviously doesn't work and in the bail-out process we end up
> with the preformatted message with ' : ' appended to it...
> So I think DRDAConnThread::buildSqlerrmc(SQLException se) must be able
> to handle all the new SQLException types.

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


Mime
View raw message