views:

44

answers:

1

Hello,

I am migrating an existing application from Weblogic server 9 to JBoss 5.

My problem is with a query that has a character condition in the WHERE clause, like this one:

SELECT DISTINCT OBJECT(myObject) 
FROM MyObject myObject 
WHERE myObject.myAttribute = 'F'

... which I believe was working with WLS now leads to an aborted deployment with JBoss, because of the following reason:

Caused by: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "\'F\'" 
at line 1, column 99.
Was expecting one of:
    "ABS" ...
    "LENGTH" ...
    "LOCATE" ...
    "SQRT" ...
    "MOD" ...
    "(" ...
    "+" ...
    "-" ...
    <INTEGER_LITERAL> ...
    <FLOATING_POINT_LITERAL> ...
    <NUMERIC_VALUED_PARAMETER> ...
    <NUMERIC_VALUED_PATH> ...

The ejb-jar.xml and the jbosscmp-jdbc.xml files declare the type and the attribute. In the Java files, the getter and setter methods for this attribute both use the java.lang.Character type. The Oracle database column is of type CHAR(1).

The Query compiler declared in the jbosscmp-jdbc.xml file is

org.jboss.ejb.plugins.cmp.jdbc.EJBQLToSQL92Compiler

This compiler is the one that should be used with EJBQL 2.1 queries. Changing the compiler to the default JDBCEJBQLCompiler doesn't change anything.

Anybody knows what's wrong here?

Thanks for your help! :-)

+1  A: 

EJBQL only knows String, Integer and Boolean-Literals in the WHERE-clause. 'F' is a String and the query is expecting an smallint-value, because I guess, that char is mapped to some integer values.

EDIT: Maybe using the literal ascii-code 70 of 'F' can be used for this query. Nevertheless: The SQL CHAR data type should not be used for database columns that are mapped to cmp fields. Maybe alter it to varchar.

Michael Konietzka
Hi, thanks for your answer! If it knows about String literals, and 'F' is a String, then everytrhing should work fine, shouldn't it? Or have I misundersood your answer?EDIT: ok, now I get it :-) I will try that!
Séb
No, I guess it is mapping the char to smallint internally and is expecting an int literal in the query.
Michael Konietzka
Changing the type to String and the DB type to VARCHAR did the trick. Thanks for the advice on the use of the CHAR data type :-)
Séb