You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Dy...@Sun.COM on 2006/04/03 21:01:30 UTC
Problem with new SQLException hierarchy in 1.6
Hi.
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. Should I log a JIRA?
Also, I think it would be good to clean up the localization/message
formatting code so that it becomes more robust and fail-fast.
David, will this will be addressed by the ongoing internationalization work?
--
dt
Re: Problem with new SQLException hierarchy in 1.6
Posted by Dy...@Sun.COM.
"David W. Van Couvering" <Da...@Sun.COM> writes:
> Sorry, it's very hard to know which threads to pay attention to. Let
> me go look at the whole thread and I'll try to respond.
No problem, the issue is there now, so you can just assign it to
yourself if it is your itch.
--
dt
Re: Problem with new SQLException hierarchy in 1.6
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Sorry, it's very hard to know which threads to pay attention to. Let me
go look at the whole thread and I'll try to respond.
David
Dyre.Tjeldvoll@Sun.COM wrote:
> Dyre.Tjeldvoll@Sun.COM writes:
>
>> Bryan Pendleton <bp...@amberpoint.com> writes:
>>
>>>>> Thank you for digging into this. I noticed this cruft (but didn't
>>>>> go hunting for the problem) while cleaning up some other diffs in
>>>>> the 1.6 derbyall. Yes, please log a JIRA on this and link it to
>>>>> DERBY-955, the master JIRA for 1.6 derbyall problems.
>>>> Logged as DERBY-1178
>>> It seemed like there was a second bug that you discovered here, too: you
>>> noticed that, due to poor input validation:
>>>
>>> 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
>>>
>>> Are we going to address *both* problems as part of 1178? Or do you think
>>> we need to have two different bug reports?
>> Well, the way I see it, the first problem is definitely a bug, but the
>> latter is more of a "quality of implementation" issue. That said, I
>> think it should be fixed and I can create a JIRA for it. I just wanted
>> to give David a chance to "claim" this, as part of his work on
>> internationalization...
>
> I have not heard anything from David, so I have logged DERBY-1232 for this.
>
Re: Problem with new SQLException hierarchy in 1.6
Posted by Dy...@Sun.COM.
Dyre.Tjeldvoll@Sun.COM writes:
> Bryan Pendleton <bp...@amberpoint.com> writes:
>
>>>> Thank you for digging into this. I noticed this cruft (but didn't
>>>> go hunting for the problem) while cleaning up some other diffs in
>>>> the 1.6 derbyall. Yes, please log a JIRA on this and link it to
>>>> DERBY-955, the master JIRA for 1.6 derbyall problems.
>>> Logged as DERBY-1178
>>
>> It seemed like there was a second bug that you discovered here, too: you
>> noticed that, due to poor input validation:
>>
>> 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
>>
>> Are we going to address *both* problems as part of 1178? Or do you think
>> we need to have two different bug reports?
>
> Well, the way I see it, the first problem is definitely a bug, but the
> latter is more of a "quality of implementation" issue. That said, I
> think it should be fixed and I can create a JIRA for it. I just wanted
> to give David a chance to "claim" this, as part of his work on
> internationalization...
I have not heard anything from David, so I have logged DERBY-1232 for this.
--
dt
Re: Problem with new SQLException hierarchy in 1.6
Posted by Dy...@Sun.COM.
Bryan Pendleton <bp...@amberpoint.com> writes:
>>> Thank you for digging into this. I noticed this cruft (but didn't
>>> go hunting for the problem) while cleaning up some other diffs in
>>> the 1.6 derbyall. Yes, please log a JIRA on this and link it to
>>> DERBY-955, the master JIRA for 1.6 derbyall problems.
>> Logged as DERBY-1178
>
> It seemed like there was a second bug that you discovered here, too: you
> noticed that, due to poor input validation:
>
> 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
>
> Are we going to address *both* problems as part of 1178? Or do you think
> we need to have two different bug reports?
Well, the way I see it, the first problem is definitely a bug, but the
latter is more of a "quality of implementation" issue. That said, I
think it should be fixed and I can create a JIRA for it. I just wanted
to give David a chance to "claim" this, as part of his work on
internationalization...
--
dt
Re: Problem with new SQLException hierarchy in 1.6
Posted by Bryan Pendleton <bp...@amberpoint.com>.
>> Thank you for digging into this. I noticed this cruft (but didn't go
>> hunting for the problem) while cleaning up some other diffs in the 1.6
>> derbyall. Yes, please log a JIRA on this and link it to DERBY-955, the
>> master JIRA for 1.6 derbyall problems.
>
> Logged as DERBY-1178
It seemed like there was a second bug that you discovered here, too: you
noticed that, due to poor input validation:
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
Are we going to address *both* problems as part of 1178? Or do you think
we need to have two different bug reports?
thanks,
bryan
Re: Problem with new SQLException hierarchy in 1.6
Posted by Dy...@Sun.COM.
Rick Hillegas <Ri...@Sun.COM> writes:
> Hi Dyre,
>
> Thank you for digging into this. I noticed this cruft (but didn't go
> hunting for the problem) while cleaning up some other diffs in the 1.6
> derbyall. Yes, please log a JIRA on this and link it to DERBY-955, the
> master JIRA for 1.6 derbyall problems.
Logged as DERBY-1178
> The fix to this, combined with
> the fix I'm trying to effect, should eliminate another boatload of
> 1.6-specific canons.
--
dt
Re: Problem with new SQLException hierarchy in 1.6
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Dyre,
Thank you for digging into this. I noticed this cruft (but didn't go
hunting for the problem) while cleaning up some other diffs in the 1.6
derbyall. Yes, please log a JIRA on this and link it to DERBY-955, the
master JIRA for 1.6 derbyall problems. The fix to this, combined with
the fix I'm trying to effect, should eliminate another boatload of
1.6-specific canons.
Thanks!
-Rick
Dyre.Tjeldvoll@Sun.COM wrote:
>Hi.
>
>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. Should I log a JIRA?
>
>Also, I think it would be good to clean up the localization/message
>formatting code so that it becomes more robust and fail-fast.
>
>David, will this will be addressed by the ongoing internationalization work?
>
>
>