Just wanted to follow up and let you all know that this turns out to be
a bug in the IBM JIT library. Through much testing with JIT options
turned on and off and a debugging version of libjitc produced by IBM
support, I was able to nail down that in fact method inlining on the
ParseTreeWalker.getOrderClause() method was causing the problem we
observed... after hitting the method 10 times, JIT would kick in to
optimize, and wham! she breaks. We have a work-around in WebSphere
5.1/JDK 1.4.2 then (turn off method inlining for just the class and
method noted) and IBM is working on a patch.
jeff
>>> [EMAIL PROTECTED] 9/1/2004 10:54:53 AM >>>
>>> [EMAIL PROTECTED] 8/31/2004 6:12:18 PM >>>
>My view of the code for ParseTreeWalker indicates why there is an
>exception thrown: if you have an ORDER BY clause, but the child nodes
>(in my case UPPER(description) ASC and beginDate DESC and
>lastUpdatedDate DESC) are not present, the STringBuffer created has
no
>content. What is not clear is why this information would be present
>initially, but lost later on.
Can you please refine above statemenrt ? Pr more specifically, what do
you mean when saying 'are not present' ?
*****
Werner -
Thanx for the response.
By "not present", I mean that the only way the StringIndexOutOfBounds
exception can surface is if in the parsed OQL tree there is a
ParseNode
of type ORDER BY with no children. Here is the code I am looking at
in
ParseTreeWalker:
private String getOrderClause(ParseTreeNode orderClause) {
StringBuffer sb = new StringBuffer();
for (Enumeration e = orderClause.children(); e.hasMoreElements();
)
{
sb.append(", ");
ParseTreeNode curChild = (ParseTreeNode) e.nextElement();
int tokenType = curChild.getToken().getTokenType();
switch ( tokenType ) {
case KEYWORD_ASC:
sb.append( getSQLExpr( curChild.getChild(0) ) ).append( "
ASC
" );
break;
case KEYWORD_DESC:
sb.append( getSQLExpr( curChild.getChild(0) ) ).append( "
DESC " );
break;
case DOT: case IDENTIFIER:
sb.append( getSQLExpr( curChild ) ).append( " " );
break;
}
}
//remove the additional comma space at the beginning
sb.deleteCharAt(0).deleteCharAt(0);
return sb.toString();
}
The StringIndexOOB exception is occurring at the line
"sb.deleteCharAt(..." because, obviously, the StringBuffer has had
nothing appended to it. The only way for sb to be empty is if
orderClause.children() has no elements in it - there were no child
nodes. The fact that I get a StringIndexOOB exception is not really
the
root cause, just the proximal effect of the OQL parse tree somehow
being
in a bad state. Am I missing something in my thinking?
jeff
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
