RE: Upgrading 1.1 EAR to 2.1 - OpenEJB 3 CMP/CMR Issues
I've done some more homework on this one. I've learned more and am a little closer to success. I've upgraded to a new J/Connector version of the MySQL JDBC Driver (5.1.7 from 3.1.9). I've also pointed my Data Sources at Linux and W32 MySQL servers. 1. I still generate an EJBException-openjpa.persistence.PersistenceException: SyntaxError: Encountered TYPE at line...CREATE TABLE TblNm (Column Info) TYPE = innodb The generated SQL statement with Type = innodb is for a CMR 1-M method on the EJB. When I set the MySQL sql_mode to ANSI I can get past this initial error that's generated on the CMP EJB finder. Recap: this occurs on a CMP Finder (Retrieve LocalEntity Collection) method and is related to the CMR method of the CMP EJB. Resolved by modifying MySQL server syntax with the following MySQL CLI command SET @GLOBAL.sql_mode = 'ANSI';. I believe this should work with the MySQL specific syntax given the proper OpenJPA JDBC Dictionary class. Server side CLI reveals that MySQL will actually utilize the ENGINE=InnoDB syntax when asked to SHOW CREATE TABLE tblNm;. This does not appear fixed by the JDBC Driver upgrade as I would have expected. The JDBC return for SHOW CREATE TABLE may still be using a TYPE rather than an ENGINE syntax and the may not be what the OpenJPA MySQLDictionary reflects. I'd confirm this for someone if provided enough guidance. 2. With the new J/Connector I get past the second error when instantiating the EJB. This second error was a NullPointerException that appeared to be related to the CMR method of the Entity when the previously discussed CMP Finder was invoked. Recap: JDBC Driver Upgrade resolved NullPointerException related to CMR method when CMP Finder method was invoked. 3. A few changes, a few obstacles overcome. Now I get an NullPointerException when trying to access the CMR field. I did some googling and understand the proxy object generation for a EJB 2.1 facade over top of OpenJPA with the -cmp2.jar. I've opened the -cmp2.jar and reviewed the openejb-cmp-generated-orm.xml. It appears to be accurate although I could confirm further. I do NOT see a generated persistence.xml in the -cmp2.jar. Should there be a persistence.xml in the -cmp2.jar, or does the container generate it as a class on load of the OpenJPA proxy class? How would one view the persistence settings of the CMP Proxy Class? I also see references to the JDBC dictionary class openjpa.jdbc.sql.MySQLDictionary in the G log, so I presume the persistence manager recognizes the SQL dialect as MySQL. Thanks for the assistance, It sounds like this thread should probably move to the OpenEJB or OpenJPA list at this point. Any particular individual to pick the thread up there? Mark Original Message Subject: Re: Upgrading 1.1 EAR to 2.1 - OpenEJB 3 CMP/CMR Issues From: David Jencks [EMAIL PROTECTED] Date: Fri, December 05, 2008 1:20 pm To: user@geronimo.apache.org On Dec 5, 2008, at 9:35 AM, Mark Aufdencamp wrote: Thanks for the response David, I intend to re-configure my Database Pool to point at W32 MySQL 5, rather than the Ubuntu MySQL 5 with the same JDBC client driver. They do have some differences between platforms in there default SQL syntax. The 'sql_mode' is Undefined on the Ubuntu default install and the default W32 defines STRICT_TRANS_TABLES, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION. G 1.1.1 worked fine against this W32 server, so I'll make sure it's not a server platform issue before moving on to the client driver. I'd expect the same syntax issues to arise with EJB 3 JPA when moving between platforms. Does anyone have cross platform (MySQL W32 to Linux) experiences with OpenJPA that can be shared? Can you confirm that OpenJPA wants/requires a persistence.xml and/or utilizes persistence.xml when supporting CMP/CMR? I've never actually looked at the code that does this but IIRC the cmp/cmr support generates a persistence.xml with some special name when it finds ejb 2.1 entity beans. I think if you supply a persistence.xml with the same name it will use that one instead. Asking on the openejb list might get better info. Thanks for confirming that CMP/CMR should work and was incorporated in the TCK for EJB3. Hopefully this is as simple as some SQL dialect issues! we can hope :-) thanks david jencks Mark Original Message Subject: Re: Upgrading 1.1 EAR to 2.1 - OpenEJB 3 CMP/CMR Issues From: David Jencks [EMAIL PROTECTED] Date: Fri, December 05, 2008 2:47 am To: user@geronimo.apache.org Hi Mark, Unfortunately I don't actually know what I'm talking about here in any detail Dain would know more. However I have a few suggestions: 1. We set the following properties in persistence.xml by default: if you want something different you should override them: openjpa.Log=commons
RE: Upgrading 1.1 EAR to 2.1 - OpenEJB 3 CMP/CMR Issues
Thanks for the response David, I intend to re-configure my Database Pool to point at W32 MySQL 5, rather than the Ubuntu MySQL 5 with the same JDBC client driver. They do have some differences between platforms in there default SQL syntax. The 'sql_mode' is Undefined on the Ubuntu default install and the default W32 defines STRICT_TRANS_TABLES, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION. G 1.1.1 worked fine against this W32 server, so I'll make sure it's not a server platform issue before moving on to the client driver. I'd expect the same syntax issues to arise with EJB 3 JPA when moving between platforms. Does anyone have cross platform (MySQL W32 to Linux) experiences with OpenJPA that can be shared? Can you confirm that OpenJPA wants/requires a persistence.xml and/or utilizes persistence.xml when supporting CMP/CMR? Thanks for confirming that CMP/CMR should work and was incorporated in the TCK for EJB3. Hopefully this is as simple as some SQL dialect issues! Mark Original Message Subject: Re: Upgrading 1.1 EAR to 2.1 - OpenEJB 3 CMP/CMR Issues From: David Jencks [EMAIL PROTECTED] Date: Fri, December 05, 2008 2:47 am To: user@geronimo.apache.org Hi Mark, Unfortunately I don't actually know what I'm talking about here in any detail Dain would know more. However I have a few suggestions: 1. We set the following properties in persistence.xml by default: if you want something different you should override them: openjpa.Log=commons openjpa.jdbc.DBDictionary=org.apache.openjpa.jdbc.sql.DerbyDictionary openjpa.jdbc.SynchronizeMappings=buildSchema(ForeignKeys=true) openjpa.jdbc.UpdateManager=operation-order openjpa.Sequence=table(Table=OPENJPASEQ, Increment=100) in particular the DBDictionary may be causing problems. I'm not sure whether the other properties might have more appropriate values. You can override these in your persistence.xml (in the appropriate format -- these are not actually from a default persistence.xml but from a gbean config) 2. By all means try a more recent mysql driver. 3. MySql used to have rather bizarre ideas about sql. Trying another database as an experiment might be useful. 4. Just in case you aren't currently, letting openjpa create the tables for you at least as an experiment might be informative. The tck has a bunch of ejb 2.1 cmp/cmr tests and they all work fine so at least a lot of it is verified to work propertly. Please let us know your progress. thanks david jencks On Dec 4, 2008, at 10:49 PM, Mark Aufdencamp wrote: Hi All, I'm upgrading an EAR from G 1.1.1-Win32-Tomcat to G 2.1.3-Linux- Tomcat. I've successfully installed G 2.1 and managed to deploy my Database Pools and Security Realms. I've edited my geonimo-application.xml and openejb-jar.xml to reflect the new deployment plan name space. I've managed to successfully deploy the EAR on the server. I even managed to migrate my databases to the new server after learning some MySQL intricacies of Win32 vs Linux table and column name case sensitivity. I can access my application and login via the defined JDBC Security Realm. Now the good stuff. It has an EJB 2.1 CMP/CMR component that gets wrapped by OpenJPA in OpenEJB 3. No problem, it should work, right? I receive an OpenJPA PersistenceException when first accessing the EntityBean from a Session Bean (I will double check the authenticity of this location, I believe it's an initial EJB Query). OpenJPA spits out a generated SQL Statement that it doesn't like. It appears to be an OpenJPA Syntax check of a SHOW CREATE TABLE TableName; It incorporates a MySQL specific table command ( TYPE = InnoDB ). This might pass validation if it were the newer MySQL syntax - ENGINE = InnoDB. The newest MySQL 5 Driver rather than the installed 3.1.12 from the Geronimo Driver Repository might fix this. Poking around and setting the MySQL sql_mode to ANSI seems to resolve this problem and will probably be more compatible with the default Derby SQL statement builder and syntax checker. So, I should hopefully be SQL dialect neutral at this point. Now I can retrieve a query of the Entities to display, but the CMR component seems to be broken. I have a Null Pointer Exception generated in the OpenEJB BaseEjbProxyHandler class with the CMR method identified. Further up the stack, SetValuedCmr in openejb.core.cmp.cmp2 is identified as the culprit. It appears that the CMR methods are broken and not capable of constructing the necessary queries. Am I missing something in the deployment descriptors to do CMP/CMR in OpenEJB 3? Do I need to setup some persistence information in open-ejb.xml for CMP to run in OpenEJB 3? Does a MySQL specific QL driver exist for G 2.1/OpenEJB 3? I
Re: Upgrading 1.1 EAR to 2.1 - OpenEJB 3 CMP/CMR Issues
On Dec 5, 2008, at 9:35 AM, Mark Aufdencamp wrote: Thanks for the response David, I intend to re-configure my Database Pool to point at W32 MySQL 5, rather than the Ubuntu MySQL 5 with the same JDBC client driver. They do have some differences between platforms in there default SQL syntax. The 'sql_mode' is Undefined on the Ubuntu default install and the default W32 defines STRICT_TRANS_TABLES, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION. G 1.1.1 worked fine against this W32 server, so I'll make sure it's not a server platform issue before moving on to the client driver. I'd expect the same syntax issues to arise with EJB 3 JPA when moving between platforms. Does anyone have cross platform (MySQL W32 to Linux) experiences with OpenJPA that can be shared? Can you confirm that OpenJPA wants/requires a persistence.xml and/or utilizes persistence.xml when supporting CMP/CMR? I've never actually looked at the code that does this but IIRC the cmp/cmr support generates a persistence.xml with some special name when it finds ejb 2.1 entity beans. I think if you supply a persistence.xml with the same name it will use that one instead. Asking on the openejb list might get better info. Thanks for confirming that CMP/CMR should work and was incorporated in the TCK for EJB3. Hopefully this is as simple as some SQL dialect issues! we can hope :-) thanks david jencks Mark Original Message Subject: Re: Upgrading 1.1 EAR to 2.1 - OpenEJB 3 CMP/CMR Issues From: David Jencks [EMAIL PROTECTED] Date: Fri, December 05, 2008 2:47 am To: user@geronimo.apache.org Hi Mark, Unfortunately I don't actually know what I'm talking about here in any detail Dain would know more. However I have a few suggestions: 1. We set the following properties in persistence.xml by default: if you want something different you should override them: openjpa.Log=commons openjpa.jdbc.DBDictionary=org.apache.openjpa.jdbc.sql.DerbyDictionary openjpa.jdbc.SynchronizeMappings=buildSchema(ForeignKeys=true) openjpa.jdbc.UpdateManager=operation-order openjpa.Sequence=table(Table=OPENJPASEQ, Increment=100) in particular the DBDictionary may be causing problems. I'm not sure whether the other properties might have more appropriate values. You can override these in your persistence.xml (in the appropriate format -- these are not actually from a default persistence.xml but from a gbean config) 2. By all means try a more recent mysql driver. 3. MySql used to have rather bizarre ideas about sql. Trying another database as an experiment might be useful. 4. Just in case you aren't currently, letting openjpa create the tables for you at least as an experiment might be informative. The tck has a bunch of ejb 2.1 cmp/cmr tests and they all work fine so at least a lot of it is verified to work propertly. Please let us know your progress. thanks david jencks On Dec 4, 2008, at 10:49 PM, Mark Aufdencamp wrote: Hi All, I'm upgrading an EAR from G 1.1.1-Win32-Tomcat to G 2.1.3-Linux- Tomcat. I've successfully installed G 2.1 and managed to deploy my Database Pools and Security Realms. I've edited my geonimo-application.xml and openejb-jar.xml to reflect the new deployment plan name space. I've managed to successfully deploy the EAR on the server. I even managed to migrate my databases to the new server after learning some MySQL intricacies of Win32 vs Linux table and column name case sensitivity. I can access my application and login via the defined JDBC Security Realm. Now the good stuff. It has an EJB 2.1 CMP/CMR component that gets wrapped by OpenJPA in OpenEJB 3. No problem, it should work, right? I receive an OpenJPA PersistenceException when first accessing the EntityBean from a Session Bean (I will double check the authenticity of this location, I believe it's an initial EJB Query). OpenJPA spits out a generated SQL Statement that it doesn't like. It appears to be an OpenJPA Syntax check of a SHOW CREATE TABLE TableName; It incorporates a MySQL specific table command ( TYPE = InnoDB ). This might pass validation if it were the newer MySQL syntax - ENGINE = InnoDB. The newest MySQL 5 Driver rather than the installed 3.1.12 from the Geronimo Driver Repository might fix this. Poking around and setting the MySQL sql_mode to ANSI seems to resolve this problem and will probably be more compatible with the default Derby SQL statement builder and syntax checker. So, I should hopefully be SQL dialect neutral at this point. Now I can retrieve a query of the Entities to display, but the CMR component seems to be broken. I have a Null Pointer Exception generated in the OpenEJB BaseEjbProxyHandler class with the CMR method identified. Further up the stack, SetValuedCmr in openejb.core.cmp.cmp2 is identified as the culprit. It appears that the CMR methods are broken and not capable of constructing
Upgrading 1.1 EAR to 2.1 - OpenEJB 3 CMP/CMR Issues
Hi All, I'm upgrading an EAR from G 1.1.1-Win32-Tomcat to G 2.1.3-Linux-Tomcat. I've successfully installed G 2.1 and managed to deploy my Database Pools and Security Realms. I've edited my geonimo-application.xml and openejb-jar.xml to reflect the new deployment plan name space. I've managed to successfully deploy the EAR on the server. I even managed to migrate my databases to the new server after learning some MySQL intricacies of Win32 vs Linux table and column name case sensitivity. I can access my application and login via the defined JDBC Security Realm. Now the good stuff. It has an EJB 2.1 CMP/CMR component that gets wrapped by OpenJPA in OpenEJB 3. No problem, it should work, right? I receive an OpenJPA PersistenceException when first accessing the EntityBean from a Session Bean (I will double check the authenticity of this location, I believe it's an initial EJB Query). OpenJPA spits out a generated SQL Statement that it doesn't like. It appears to be an OpenJPA Syntax check of a SHOW CREATE TABLE TableName; It incorporates a MySQL specific table command ( TYPE = InnoDB ). This might pass validation if it were the newer MySQL syntax - ENGINE = InnoDB. The newest MySQL 5 Driver rather than the installed 3.1.12 from the Geronimo Driver Repository might fix this. Poking around and setting the MySQL sql_mode to ANSI seems to resolve this problem and will probably be more compatible with the default Derby SQL statement builder and syntax checker. So, I should hopefully be SQL dialect neutral at this point. Now I can retrieve a query of the Entities to display, but the CMR component seems to be broken. I have a Null Pointer Exception generated in the OpenEJB BaseEjbProxyHandler class with the CMR method identified. Further up the stack, SetValuedCmr in openejb.core.cmp.cmp2 is identified as the culprit. It appears that the CMR methods are broken and not capable of constructing the necessary queries. Am I missing something in the deployment descriptors to do CMP/CMR in OpenEJB 3? Do I need to setup some persistence information in open-ejb.xml for CMP to run in OpenEJB 3? Does a MySQL specific QL driver exist for G 2.1/OpenEJB 3? I haven't found any specific discussion of running CMP/CMR from G 1.1 in G 2.1. Does it exist or do I get to be the guy:) TIA for the help and guidance, Mark Aufdencamp [EMAIL PROTECTED]
Re: Upgrading 1.1 EAR to 2.1 - OpenEJB 3 CMP/CMR Issues
Hi Mark, Unfortunately I don't actually know what I'm talking about here in any detail Dain would know more. However I have a few suggestions: 1. We set the following properties in persistence.xml by default: if you want something different you should override them: openjpa.Log=commons openjpa.jdbc.DBDictionary=org.apache.openjpa.jdbc.sql.DerbyDictionary openjpa.jdbc.SynchronizeMappings=buildSchema(ForeignKeys=true) openjpa.jdbc.UpdateManager=operation-order openjpa.Sequence=table(Table=OPENJPASEQ, Increment=100) in particular the DBDictionary may be causing problems. I'm not sure whether the other properties might have more appropriate values. You can override these in your persistence.xml (in the appropriate format -- these are not actually from a default persistence.xml but from a gbean config) 2. By all means try a more recent mysql driver. 3. MySql used to have rather bizarre ideas about sql. Trying another database as an experiment might be useful. 4. Just in case you aren't currently, letting openjpa create the tables for you at least as an experiment might be informative. The tck has a bunch of ejb 2.1 cmp/cmr tests and they all work fine so at least a lot of it is verified to work propertly. Please let us know your progress. thanks david jencks On Dec 4, 2008, at 10:49 PM, Mark Aufdencamp wrote: Hi All, I'm upgrading an EAR from G 1.1.1-Win32-Tomcat to G 2.1.3-Linux- Tomcat. I've successfully installed G 2.1 and managed to deploy my Database Pools and Security Realms. I've edited my geonimo-application.xml and openejb-jar.xml to reflect the new deployment plan name space. I've managed to successfully deploy the EAR on the server. I even managed to migrate my databases to the new server after learning some MySQL intricacies of Win32 vs Linux table and column name case sensitivity. I can access my application and login via the defined JDBC Security Realm. Now the good stuff. It has an EJB 2.1 CMP/CMR component that gets wrapped by OpenJPA in OpenEJB 3. No problem, it should work, right? I receive an OpenJPA PersistenceException when first accessing the EntityBean from a Session Bean (I will double check the authenticity of this location, I believe it's an initial EJB Query). OpenJPA spits out a generated SQL Statement that it doesn't like. It appears to be an OpenJPA Syntax check of a SHOW CREATE TABLE TableName; It incorporates a MySQL specific table command ( TYPE = InnoDB ). This might pass validation if it were the newer MySQL syntax - ENGINE = InnoDB. The newest MySQL 5 Driver rather than the installed 3.1.12 from the Geronimo Driver Repository might fix this. Poking around and setting the MySQL sql_mode to ANSI seems to resolve this problem and will probably be more compatible with the default Derby SQL statement builder and syntax checker. So, I should hopefully be SQL dialect neutral at this point. Now I can retrieve a query of the Entities to display, but the CMR component seems to be broken. I have a Null Pointer Exception generated in the OpenEJB BaseEjbProxyHandler class with the CMR method identified. Further up the stack, SetValuedCmr in openejb.core.cmp.cmp2 is identified as the culprit. It appears that the CMR methods are broken and not capable of constructing the necessary queries. Am I missing something in the deployment descriptors to do CMP/CMR in OpenEJB 3? Do I need to setup some persistence information in open-ejb.xml for CMP to run in OpenEJB 3? Does a MySQL specific QL driver exist for G 2.1/OpenEJB 3? I haven't found any specific discussion of running CMP/CMR from G 1.1 in G 2.1. Does it exist or do I get to be the guy:) TIA for the help and guidance, Mark Aufdencamp [EMAIL PROTECTED]