geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Still remaining problems using openJPA
Date Mon, 23 Jul 2007 17:54:50 GMT
On Jul 23, 2007, at 9:40 AM, Ueberbach, Michael wrote:

> Hello,
> meanwhile I got along a bit further in deploying and using an EJB  
> 3.0 application on g2 (M6). But there still remain some open  
> questions:
> 1. I did openJPA enhancing on build time (via ant script) to  
> compare the results with enhancing on deploy time.
>    In both cases I didn't manage to use the property acces mode for  
> an entity bean. In all cases I tried the openJPA parser
>    says that there was the attempt "to use both field and property  
> access. Only one access method is permitted."
>    So at last I changed my code to field access mode.
I think your going to have to hit up the OpenJPA mailing list  
( for this one.
> 2. When using a certain dynamic query I got the following exception
>    "An error occurred while parsing the query filter 'SELECT person  
> FROM Person AS person WHERE LIKE ?1 ESCAPE '|''.
>     Error message: <1.0.0-SNAPSHOT-SNAPSHOT nonfatal user error>  
> org.apache.openjpa.kernel.jpql.ParseException:
>     Encountered "ESCAPE" at character 63, but expected: ["AND",  
> "GROUP", "HAVING", "OR", "ORDER", <EOF>]."
>    While the JPQL Language Reference says:
>    2.5.9
>    The syntax for the use of the comparison operator [ NOT ] LIKE  
> in a conditional expression is as follows:
>    string_expression [NOT] LIKE pattern_value [ESCAPE  
> escape_character]
I know old versions of mysql did not support the SQL standard LIKE  
EXCAPE clause, but I don't know if mysql ever got around to  
implementing this.  Looking at the openjpa docs, it is not listed as  
a limitation of the mysql integration ( 
latest/manual/manual.html#dbsupport_mysql_issues)  I suggest you read  
that over anyway, so you don't have any surprises with mysql.

Anyway, I suggest you first look at the mysql SQL documentation to  
see if it implements ESCAPE.  If it does, you most likely need to  
upgrade.  If not, I don't think there is anything you can do other  
then remove the ESCAPE clause.
> 3. The most important and irritating problem is the following:
>   After starting the database and then geronimo the first access to  
> persistent data by an ejb method results in the following exception:
>   ERROR [OpenEJB] The bean instances business method encountered a  
> system exception: Access denied for user 'geronimo'@'localhost' to  
> database 'GERONIMO_DB'
>   <1.0.0-SNAPSHOT-SNAPSHOT nonfatal general error>  
> org.apache.openjpa.persistence.PersistenceException: Access denied  
> for user 'geronimo'@'localhost' to database 'GERONIMO_DB'
>   The access is denied because the name of the database is  
> geronimo_db (lower cases) and MySQL on linux works case-sensitive.  
> But the correct writing
>   of the name has been used when deploying the database pool.
>   What is most astonishing is the following!!!
>   After stopping the database the attempt to get access to data  
> results in
>   [MCFConnectionInterceptor] Error occurred creating  
> ManagedConnection for  
> org.apache.geronimo.connector.outbound.ConnectionInfo@e99cbc
>   javax.resource.spi.ResourceAllocationException: Unable to obtain  
> physical connection to jdbc:mysql://localhost:3306/geronimo_db
>   at org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection 
> (
>   This is clear and expectable. But ...
>   after starting the database again: Everything works!
>   I can reproduce the whole thing. Conclusion at the moment is: To  
> get a working connection to the database I have to force the above  
> error situation first. Very strange!
>   May someone has an idea about this behaviour?
This is something we should be able to help you with.  Unfortunately,  
I this isn't my area, but hopefully David Jencks will respond quickly :)


View raw message