AW: Still remaining problems using openJPA
Many thanks to all who answered. To the (minor) issue concerning the LIKE operator with ESCAPE clause: The MySQL version I use supports this kind of select. Using the appropriate property inside the persistance.xml (as Peter said) is an interesting hint (thanks). But this is a more static way of describing the case, I tried to do this dynamically. To answer the other questions: The MySQL database is created outside geronimo (by script). The database remains and will not be created again. The Geronimo database connection pool was deployed using the console (so I have no plan). Only the neccessary entries were made (name, driver class, connection details), all default values were accepted (except one: minimum size of pool was set to 1) The persistance.xml is the following: persistence persistence-unit name=StammdatenVerwaltung descriptionZugriff auf Stammdaten/description providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider jta-data-sourceMySQLPool/jta-data-source non-jta-data-sourceMySQLPool/non-jta-data-source /persistence-unit /persistence I compared three szenarios, always starting with both database and geronimo down: 1. Starting DB Starting Geronimo Client call -- Exception (Access denied for user 'geronimo'@'localhost' to database 'GERONIMO_DB') Stopping DB Starting DB Client call -- ok 2. Starting Geronimo Starting DB Client call -- Exception (Access denied for user 'geronimo'@'localhost' to database 'GERONIMO_DB') Stopping DB Starting DB Client call -- ok 3. Starting Geronimo Client call -- Exception (Unable to obtain physical connection to jdbc:mysql://localhost:3306/geronimo_db) Starting DB Client call -- ok (Client call means call of session bean method fetching data from standalone java client) At the moment (for testing) I can live with this handling, but for productive purposes this would be a problem. Thanks Michael -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED] Gesendet: Montag, 23. Juli 2007 23:26 An: user@geronimo.apache.org Betreff: Re: Still remaining problems using openJPA
Re: AW: Still remaining problems using openJPA
On Jul 25, 2007, at 6:30 AM, Ueberbach, Michael wrote: Many thanks to all who answered. To the (minor) issue concerning the LIKE operator with ESCAPE clause: The MySQL version I use supports this kind of select. Using the appropriate property inside the persistance.xml (as Peter said) is an interesting hint (thanks). But this is a more static way of describing the case, I tried to do this dynamically. To answer the other questions: The MySQL database is created outside geronimo (by script). The database remains and will not be created again. The Geronimo database connection pool was deployed using the console (so I have no plan). Only the neccessary entries were made (name, driver class, connection details), all default values were accepted (except one: minimum size of pool was set to 1) The persistance.xml is the following: persistence persistence-unit name=StammdatenVerwaltung descriptionZugriff auf Stammdaten/description providerorg.apache.openjpa.persistence.PersistenceProviderImpl/ provider jta-data-sourceMySQLPool/jta-data-source non-jta-data-sourceMySQLPool/non-jta-data-source /persistence-unit /persistence I compared three szenarios, always starting with both database and geronimo down: 1. Starting DB Starting Geronimo Client call -- Exception (Access denied for user 'geronimo'@'localhost' to database 'GERONIMO_DB') Stopping DB Starting DB Client call -- ok 2. Starting Geronimo Starting DB Client call -- Exception (Access denied for user 'geronimo'@'localhost' to database 'GERONIMO_DB') Stopping DB Starting DB Client call -- ok 3. Starting Geronimo Client call -- Exception (Unable to obtain physical connection to jdbc:mysql://localhost:3306/geronimo_db) Starting DB Client call -- ok (Client call means call of session bean method fetching data from standalone java client) At the moment (for testing) I can live with this handling, but for productive purposes this would be a problem. The only thing unusual in this is that you have set the pool min size to 1 rather than 0. IIRC this means that the first connection in the pool will have been created without a client request for a connection. This is the connection that is causing the problems. Could you see what happens if you set the min size to 0? If that fixes the problem please file a jira issue with the details above, it means that the min size connections aren't getting created correctly. many thanks! david jencks Thanks Michael -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED] Gesendet: Montag, 23. Juli 2007 23:26 An: user@geronimo.apache.org Betreff: Re: Still remaining problems using openJPA
Still remaining problems using openJPA
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. 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 person.name 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] 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 [EMAIL PROTECTED] javax.resource.spi.ResourceAllocationException: Unable to obtain physical connection to jdbc:mysql://localhost:3306/geronimo_db at org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection(JDBCDriver MCF.java:98) 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? regard and thanks Michael
Re: Still remaining problems using openJPA
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 ([EMAIL PROTECTED]) 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 person.name 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 (http://openjpa.apache.org/docs/ 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 [EMAIL PROTECTED] javax.resource.spi.ResourceAllocationException: Unable to obtain physical connection to jdbc:mysql://localhost:3306/geronimo_db at org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection (JDBCDriverMCF.java:98) 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 :) -dain
Re: Still remaining problems using openJPA
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. 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 person.name LIKE ?1 ESCAPE '|''. I don't know if this is any help but I found and have been using this. The interesting part is the SearchStringEscape. property name=openjpa.jdbc.DBDictionary value=mysql(SupportsSubselect=false, UseClobs=true, SearchStringEscape=)/ thanks Peter Petersson 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] 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 [EMAIL PROTECTED] javax.resource.spi.ResourceAllocationException: Unable to obtain physical connection to jdbc:mysql://localhost:3306/geronimo_db at org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection(JDBCDriverMCF.java:98) 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? regard and thanks Michael
Re: Still remaining problems using openJPA
On Jul 23, 2007, at 10:54 AM, Dain Sundstrom wrote: 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: snip 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 [EMAIL PROTECTED] javax.resource.spi.ResourceAllocationException: Unable to obtain physical connection to jdbc:mysql://localhost:3306/geronimo_db at org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection (JDBCDriverMCF.java:98) 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 :) This is pretty bizarre :-) Could you show your plans for setting up the mysql datasource(s) and the persistence.xml you are using? Also, I'm not sure about the sequence of all the steps involved what is creating the tables in the db? A script? openjpa? Something else? If a script, how is it run? For instance I wonder if steps like this would make any difference: - if you are using a script: start db create tables stop db start db start geronimo (or deploy/start your datasource + application) If you are letting openjpa create your tables, do you have a non-jta- datasource specified? I could not get derby to work with openjpa without a non-jta-datasource. I stopped investigating why after a lot of frustration, but one symptom was that a connection that had been used outside a jta transaction to execute ddl or updating the sequence table appeared to lose track of the schema it was supposed to be using by default. So I suggest adding a non-jta-datasource if you don't have one. thanks david jencks -dain
AW: AW: Problems using openJPA
Hello David, To your last question: The SUN spec says In addition to returning and setting the persistent state of the instance, the property accessor methods may contain other business logic as well, for example, to perform validation. The persistence provider runtime executes this logic when property-based access is used. openJPA follows this in offering the two possibilities of accessing. The openJPA manual says JPA offers two modes of persistent state access: field access, and property access. To use property access, set your entity element's access attribute to PROPERTY, or place your metadata and mapping annotations on the getter method. Each class must use either field access or property access for all state; you cannot use both access types within the same class. The whole problem is that the described way to choose the property access by placing the annotations at the getter methods does not show any effects. More worse openJPA throws an org.apache.openjpa.util.UserException (as described) and does not choose any of the two alternative ways. This exceptions sounds as if the annotations set at the getter methods were not reckognized when parsing the entity classes. The question for me is: Have I to do something more (or have I chosen the wrong annotations or what ever) to get this code working? The test with jboss was done to see whether there also an error would be visible, but it was not. I agree that this gives no final security about the compliance of jboss. Indeed my aim is to get the thing working on geronimo/openJPA! Thanks for any help Michael -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 17. Juli 2007 23:30 An: user@geronimo.apache.org Betreff: Re: AW: Problems using openJPA On Jul 17, 2007, at 9:25 AM, Ueberbach, Michael wrote: Hi Jacek, I had to make a little break, now I'm trying to get back to the last situation. Following your last advices: reducing the persistance.xml to the neccessary elements works for deploying, but does not help in fetching data. In fact the same exception (...Could not locate metadata for the class ...) is thrown. I checked the code again: - no field is annotated - every getter is annotated (at least with @Basic) - every other method named with get... Is annotated @Transient Therefore the access type has to be clear (= PROPERTY). Nevertheless this is not recognized. So I've tried two things: First: I put a xml mapping file (orm.xml) inside the deployment jar, where I explicitly set the access type to PROPERTY for all classes. The deployment works, but the warning 1.0.0-SNAPSHOT-SNAPSHOT nonfatal user error org.apache.openjpa.util.UserException: Type de.lama.sample3.stammdaten.ejb.PersonBean attempts to use both field and property access. Only one access method is permitted. remains and the method call still doesn't work. Second: I deployed the whole stuff unchanged (except the deployment plan) to a jboss server(4.04) to compare the results. Here everything works as expected. As result it seems to me that if there isn't an error inside the deployed code that jboss does not find, there must be something wrong with parsing the classes annotations in geronimo resp. openjpa. I haven't looked into your problem in detail, but I don't think you can conclude from hibernate's ability to deploy an app X that X is entirely spec compliant and can be deployed on all other compliant jpa implementations. Out of curiousity why are you using property access? I have yet to understand why anyone would do this given a choice hoping for enlightenment. thanks david jencks regards Michael -Ursprüngliche Nachricht- Von: Ueberbach, Michael [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 10. Juli 2007 18:06 An: user@geronimo.apache.org; [EMAIL PROTECTED] Betreff: AW: Problems using openJPA Hi Jacek, Thanks for your hints. To the first point: I've already seen this in the spec. I'm quite shure there is no access via the instance variables (but I will prove it again). I will also try to eliminate the entries in persistance.xml that are not neccessary. I'll tell the results as soon as possible. Michael -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jacek Laskowski Gesendet: Dienstag, 10. Juli 2007 11:19 An: user@geronimo.apache.org Betreff: Re: Problems using openJPA On 7/10/07, Ueberbach, Michael [EMAIL PROTECTED] wrote: Hello Jacek, meanwhile I'm able to send the jar I deployed to geronimo. I attach it to this mail, sources should be included. Also the persistence.xml that is used. As you can see I put @Basic annotations to all property getters explicitly (although I think this should be default) to make shure that access should be done by property (and not by field). Nevertheless this seems not be recognized by openJPA. It would
AW: Problems using openJPA
Hi Jacek, I had to make a little break, now I'm trying to get back to the last situation. Following your last advices: reducing the persistance.xml to the neccessary elements works for deploying, but does not help in fetching data. In fact the same exception (...Could not locate metadata for the class ...) is thrown. I checked the code again: - no field is annotated - every getter is annotated (at least with @Basic) - every other method named with get... Is annotated @Transient Therefore the access type has to be clear (= PROPERTY). Nevertheless this is not recognized. So I've tried two things: First: I put a xml mapping file (orm.xml) inside the deployment jar, where I explicitly set the access type to PROPERTY for all classes. The deployment works, but the warning 1.0.0-SNAPSHOT-SNAPSHOT nonfatal user error org.apache.openjpa.util.UserException: Type de.lama.sample3.stammdaten.ejb.PersonBean attempts to use both field and property access. Only one access method is permitted. remains and the method call still doesn't work. Second: I deployed the whole stuff unchanged (except the deployment plan) to a jboss server(4.04) to compare the results. Here everything works as expected. As result it seems to me that if there isn't an error inside the deployed code that jboss does not find, there must be something wrong with parsing the classes annotations in geronimo resp. openjpa. regards Michael -Ursprüngliche Nachricht- Von: Ueberbach, Michael [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 10. Juli 2007 18:06 An: user@geronimo.apache.org; [EMAIL PROTECTED] Betreff: AW: Problems using openJPA Hi Jacek, Thanks for your hints. To the first point: I've already seen this in the spec. I'm quite shure there is no access via the instance variables (but I will prove it again). I will also try to eliminate the entries in persistance.xml that are not neccessary. I'll tell the results as soon as possible. Michael -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jacek Laskowski Gesendet: Dienstag, 10. Juli 2007 11:19 An: user@geronimo.apache.org Betreff: Re: Problems using openJPA On 7/10/07, Ueberbach, Michael [EMAIL PROTECTED] wrote: Hello Jacek, meanwhile I'm able to send the jar I deployed to geronimo. I attach it to this mail, sources should be included. Also the persistence.xml that is used. As you can see I put @Basic annotations to all property getters explicitly (although I think this should be default) to make shure that access should be done by property (and not by field). Nevertheless this seems not be recognized by openJPA. It would be great if you have any idea why and what should be done. Hi Michael, I've just started looking into it, but thought I'd tell you that when you use property-based access (via getters) you should not access the entity state via instance fields. You don't need to specify vendor element in the persistence.xml file. Geronimo defaults to OpenJPA. According to the spec (6.2.1.4 provider p.135): The provider element must be specified if the application is dependent upon a particular persistence provider being used. You don't need to specify class elements in Java EE env (as opposed to Java SE env). The container looks for other files unless exclude-unlisted-classes element is specified (which is not the case in your example). See if that helps out. Going to spot other (mis)uses of the spec that might cause the trouble. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: AW: Problems using openJPA
On Jul 17, 2007, at 9:25 AM, Ueberbach, Michael wrote: Hi Jacek, I had to make a little break, now I'm trying to get back to the last situation. Following your last advices: reducing the persistance.xml to the neccessary elements works for deploying, but does not help in fetching data. In fact the same exception (...Could not locate metadata for the class ...) is thrown. I checked the code again: - no field is annotated - every getter is annotated (at least with @Basic) - every other method named with get... Is annotated @Transient Therefore the access type has to be clear (= PROPERTY). Nevertheless this is not recognized. So I've tried two things: First: I put a xml mapping file (orm.xml) inside the deployment jar, where I explicitly set the access type to PROPERTY for all classes. The deployment works, but the warning 1.0.0-SNAPSHOT-SNAPSHOT nonfatal user error org.apache.openjpa.util.UserException: Type de.lama.sample3.stammdaten.ejb.PersonBean attempts to use both field and property access. Only one access method is permitted. remains and the method call still doesn't work. Second: I deployed the whole stuff unchanged (except the deployment plan) to a jboss server(4.04) to compare the results. Here everything works as expected. As result it seems to me that if there isn't an error inside the deployed code that jboss does not find, there must be something wrong with parsing the classes annotations in geronimo resp. openjpa. I haven't looked into your problem in detail, but I don't think you can conclude from hibernate's ability to deploy an app X that X is entirely spec compliant and can be deployed on all other compliant jpa implementations. Out of curiousity why are you using property access? I have yet to understand why anyone would do this given a choice hoping for enlightenment. thanks david jencks regards Michael -Ursprüngliche Nachricht- Von: Ueberbach, Michael [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 10. Juli 2007 18:06 An: user@geronimo.apache.org; [EMAIL PROTECTED] Betreff: AW: Problems using openJPA Hi Jacek, Thanks for your hints. To the first point: I've already seen this in the spec. I'm quite shure there is no access via the instance variables (but I will prove it again). I will also try to eliminate the entries in persistance.xml that are not neccessary. I'll tell the results as soon as possible. Michael -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jacek Laskowski Gesendet: Dienstag, 10. Juli 2007 11:19 An: user@geronimo.apache.org Betreff: Re: Problems using openJPA On 7/10/07, Ueberbach, Michael [EMAIL PROTECTED] wrote: Hello Jacek, meanwhile I'm able to send the jar I deployed to geronimo. I attach it to this mail, sources should be included. Also the persistence.xml that is used. As you can see I put @Basic annotations to all property getters explicitly (although I think this should be default) to make shure that access should be done by property (and not by field). Nevertheless this seems not be recognized by openJPA. It would be great if you have any idea why and what should be done. Hi Michael, I've just started looking into it, but thought I'd tell you that when you use property-based access (via getters) you should not access the entity state via instance fields. You don't need to specify vendor element in the persistence.xml file. Geronimo defaults to OpenJPA. According to the spec (6.2.1.4 provider p.135): The provider element must be specified if the application is dependent upon a particular persistence provider being used. You don't need to specify class elements in Java EE env (as opposed to Java SE env). The container looks for other files unless exclude- unlisted-classes element is specified (which is not the case in your example). See if that helps out. Going to spot other (mis)uses of the spec that might cause the trouble. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Problems using openJPA
On 7/10/07, Ueberbach, Michael [EMAIL PROTECTED] wrote: Hello Jacek, meanwhile I'm able to send the jar I deployed to geronimo. I attach it to this mail, sources should be included. Also the persistence.xml that is used. As you can see I put @Basic annotations to all property getters explicitly (although I think this should be default) to make shure that access should be done by property (and not by field). Nevertheless this seems not be recognized by openJPA. It would be great if you have any idea why and what should be done. Hi Michael, I've just started looking into it, but thought I'd tell you that when you use property-based access (via getters) you should not access the entity state via instance fields. You don't need to specify vendor element in the persistence.xml file. Geronimo defaults to OpenJPA. According to the spec (6.2.1.4 provider p.135): The provider element must be specified if the application is dependent upon a particular persistence provider being used. You don't need to specify class elements in Java EE env (as opposed to Java SE env). The container looks for other files unless exclude-unlisted-classes element is specified (which is not the case in your example). See if that helps out. Going to spot other (mis)uses of the spec that might cause the trouble. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
AW: Problems using openJPA
Hi Jacek, Thanks for your hints. To the first point: I've already seen this in the spec. I'm quite shure there is no access via the instance variables (but I will prove it again). I will also try to eliminate the entries in persistance.xml that are not neccessary. I'll tell the results as soon as possible. Michael -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jacek Laskowski Gesendet: Dienstag, 10. Juli 2007 11:19 An: user@geronimo.apache.org Betreff: Re: Problems using openJPA On 7/10/07, Ueberbach, Michael [EMAIL PROTECTED] wrote: Hello Jacek, meanwhile I'm able to send the jar I deployed to geronimo. I attach it to this mail, sources should be included. Also the persistence.xml that is used. As you can see I put @Basic annotations to all property getters explicitly (although I think this should be default) to make shure that access should be done by property (and not by field). Nevertheless this seems not be recognized by openJPA. It would be great if you have any idea why and what should be done. Hi Michael, I've just started looking into it, but thought I'd tell you that when you use property-based access (via getters) you should not access the entity state via instance fields. You don't need to specify vendor element in the persistence.xml file. Geronimo defaults to OpenJPA. According to the spec (6.2.1.4 provider p.135): The provider element must be specified if the application is dependent upon a particular persistence provider being used. You don't need to specify class elements in Java EE env (as opposed to Java SE env). The container looks for other files unless exclude-unlisted-classes element is specified (which is not the case in your example). See if that helps out. Going to spot other (mis)uses of the spec that might cause the trouble. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Problems using openJPA
Hello all,
I have some problems using openJPA with Geronimo V2 (M6RC1). The application
(stateless session beans and entity beans) is written in EJB3-Style
using only annotations (persistence.xml is the only descriptor) and is deployed
succesfully.
When trying to fetch some data the following exception is thrown
23:38:42,637 ERROR [OpenEJB] The bean instances business method encountered a
system exception: Could not locate metadata for the class using alias Person.
This could mean that the OpenJPA enhancer or load-time weaver was not run on
the type whose alias is Person. Registered alias mappings: {Person=null}
1.0.0-SNAPSHOT-SNAPSHOT fatal user error
org.apache.openjpa.persistence.ArgumentException: Could not locate metadata for
the class using alias Person. This could mean that the OpenJPA enhancer or
load-time weaver was not run on the type whose alias is Person. Registered
alias mappings: {Person=null}
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:348)
(...)
(Person is the name used in the @entity annotation for the entity bean.)
There are some other warnings before. But I do not really understand their
importance and whether they are relying to the exception coming later.
First this one while deploying (coming a lot of times):
23:31:35,979 WARN [Runtime] The property named
openjpa.ClassTransformerOptions was not recognized and will be ignored,
although the name closely matches a valid property called
openjpa.ClassResolver.
Second this one while trying to fetch the data
23:38:41,410 WARN [Enhance] An exception was thrown while attempting to
perform class file transformation on
de/lama/sample3/stammdaten/ejb/PersonBean:
1.0.0-SNAPSHOT-SNAPSHOT nonfatal user error
org.apache.openjpa.util.UserException: Type
de.lama.sample3.stammdaten.ejb.PersonBean attempts to use both field and
property access. Only one access method is permitted.
This second warning seems strange to me because all used property getters are
annotated and no private field has any annotation, so the access method
is clear.
Has someone an idea what's going wrong here?
Many thanks for any advice.
dbh Logistics IT AG
Michael Ueberbach
Software Management
Faulenstr. 31, 28195 Bremen
Fon:+49 421 30902-49
Fax:+49 421 30902-57
E-Mail: [EMAIL PROTECTED]
Internet: www.dbh.de - www.plusmove.de http://www.plusmove.de
dbh Logistics IT AG, Sitz / Registered Office: Faulenstraße 31, 28195 Bremen,
Deutschland / Germany
Registergericht / Companies' Register: Amtsgericht Bremen, HRB 20499
Vorstandsvorsitzender / Chief Executive Officer (CEO): Reimund Ott
Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Klaus
Platz
Haftungsausschluss:
Diese Nachricht enthält vertrauliche Informationen und ist ausschließlich für
den Adressaten bestimmt. Falls Sie die Daten irrtümlich erhalten haben, nehmen
Sie bitte Kontakt mit dem Absender auf und löschen Sie die Daten auf jedem
Computer und Datenträger. Die dbh Logistics IT AG ist nicht verantwortlich für
die ordnungsgemäße, vollständige und verzögerungsfreie Übertragung der
Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er
unsererseits durch einen Brief oder ein Fax entsprechend bestätigt wird.
Exclusion of Liability:
This message contains confidential information and is destined for the
recipient exclusively. Should you have received these data by mistake, please
contact the originator and delete the data from all your computers and data
storage media. dbh Logistics IT AG is not liable for the proper, complete and
undelayed transmission of the message. The content of the e-mail is not legally
binding, unless it is confirmed appropriately by a supplementary fax or letter
from us.
Re: Problems using openJPA
On 7/9/07, Ueberbach, Michael [EMAIL PROTECTED] wrote:
23:38:42,637 ERROR [OpenEJB] The bean instances business method encountered
a system exception: Could not locate metadata for the class using alias
Person. This could mean that the OpenJPA enhancer or load-time weaver was
not run on the type whose alias is Person. Registered alias mappings:
{Person=null}
...
First this one while deploying (coming a lot of times):
23:31:35,979 WARN [Runtime] The property named
openjpa.ClassTransformerOptions was not recognized and will be ignored,
although the name closely matches a valid property called
openjpa.ClassResolver.
Ignore it.
23:38:41,410 WARN [Enhance] An exception was thrown while attempting to
perform class file transformation on
de/lama/sample3/stammdaten/ejb/PersonBean:
1.0.0-SNAPSHOT-SNAPSHOT nonfatal user error
org.apache.openjpa.util.UserException: Type
de.lama.sample3.stammdaten.ejb.PersonBean attempts to use
both field and property access. Only one access method is permitted.
That's the culprit. Could you publish the entity jar you deployed to
Geronimo. I think that Geronimo doesn't add much to it - OpenJPA (the
default JPA provider) can't do its job and complains and so does
Geronimo.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
AW: Problems using openJPA
Hello Jacek,
Thanks for the prompt answer. I will send the jar as soon as possible.
Unfortunately I'm at the moment not at my used workplace.
Regards
Michael
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jacek Laskowski
Gesendet: Montag, 9. Juli 2007 11:49
An: user@geronimo.apache.org
Betreff: Re: Problems using openJPA
On 7/9/07, Ueberbach, Michael [EMAIL PROTECTED] wrote:
23:38:42,637 ERROR [OpenEJB] The bean instances business method
encountered a system exception: Could not locate metadata for the
class using alias Person. This could mean that the OpenJPA enhancer
or load-time weaver was not run on the type whose alias is Person.
Registered alias mappings:
{Person=null}
...
First this one while deploying (coming a lot of times):
23:31:35,979 WARN [Runtime] The property named
openjpa.ClassTransformerOptions was not recognized and will be
ignored, although the name closely matches a valid property called
openjpa.ClassResolver.
Ignore it.
23:38:41,410 WARN [Enhance] An exception was thrown while attempting
to perform class file transformation on
de/lama/sample3/stammdaten/ejb/PersonBean:
1.0.0-SNAPSHOT-SNAPSHOT nonfatal user error
org.apache.openjpa.util.UserException: Type
de.lama.sample3.stammdaten.ejb.PersonBean attempts to use both field
and property access. Only one access method is permitted.
That's the culprit. Could you publish the entity jar you deployed to Geronimo.
I think that Geronimo doesn't add much to it - OpenJPA (the default JPA
provider) can't do its job and complains and so does Geronimo.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
