[jira] Commented: (OPENJPA-206) Key column does not cascade multiple joins.
[
https://issues.apache.org/jira/browse/OPENJPA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495089
]
Michael Dick commented on OPENJPA-206:
--
For what it's worth I've been able to reproduce the issue with a vanilla
junit test case using the entities provided.
i haven't been able to determine why Department is able to pick up the ID from
Company, but Employee can't pick up the IDs from Department.
I've been able to get it working by persisting Department Company objects
in one transaction, then adding the Employees in later. Is that an acceptable
workaround for what you're trying to do?
Key column does not cascade multiple joins.
---
Key: OPENJPA-206
URL: https://issues.apache.org/jira/browse/OPENJPA-206
Project: OpenJPA
Issue Type: Bug
Affects Versions: 0.9.7
Environment: WebSphere 6.1, DB2 v8.1
Reporter: Matt Anderson
Attachments: FunInheritanceJavaPI.zip
Problem: Parent keys will not cascade beyond one generation. Example:
Company -- Department -- Employee: Company key will not cascade to
Employee.
The following example further describes this issue.
A COMPANY table contains two columns, COMP_ID and NAME. The COMP_ID column
is the primary key.
A DEPARTMENT table contains three columns, COMP_ID, DEPT_ID, and NAME. The
COMP_ID and DEPT_ID columns are the primary key columns. The COMP_ID column
is a foreign key column which references the COMP_ID column in the COMPANY
table.
An EMPLOYEE table contains four columns, COMP_ID, DEPT_ID, EMP_ID, and NAME.
The COMP_ID, DEPT_ID, and EMP_ID columns are the primary key columns. The
COMP_ID and DEPT_ID columns are foreign key columns which reference the
COMP_ID and DEPT_ID columns respectively in the DEPARTMENT table.
An entity exists for each table, Company, Department, and Employee. The
Company entity has three attributes, compId, name, and departments. The
compId attribute maps to the COMP_ID column. The name attribute maps to the
NAME column. The departments attribute maps a one-to-many relationship to
the Department entity.
The Department entity has five attributes, compId, deptId, name, employees,
and company. The compId attribute maps to the COMP_ID column. The deptId
attribute maps to the DEPT_ID column. The name attribute maps to the NAME
column. The employees attribute maps a one-to-many relationship to the
Employee entity. The company attribute maps a many-to-one relationship to
the Company entity, joined by the COMP_ID column.
The Employee entity has five attributes, compId, deptId, empId, name, and
department. The compId attribute maps to the COMP_ID column. The deptId
attribute maps to the DEPT_ID column. The empId attribute maps to the EMP_ID
column. The name attribute maps to the NAME column. The department
attribute maps a many-to-one relationship to the Department entity, joined by
the COMP_ID and DEPT_ID columns.
Below are the eleven steps to re-create this problem.
1. A new Company entity is instantiated.
2. The name attribute on the Company instance is set to company.
3. A new Department entity is instantiated.
4. The name attribute on the Department instance is set to department.
5. The department attribute on the Company instance is set to the Department
instance.
6. A new Employee entity is instantiated.
7. The name attribute on the Employee instance is set to Frank.
8. The employee attribute on the Department instance is set to the Employee
instance.
9. The Employee instance is added to the employees attribute on the
Department instance.
10. The Department instance is added to the departments attribute on the
Company instance.
11. The Company instance is persisted.
The following SQL statements are executed.
INSERT INTO COMPANY (COMP_ID, NAME)
VALUES (?, ?)
[params=(long) 1, (String) company]
INSERT INTO DEPARTMENT (COMP_ID, DEPT_ID, NAME)
VALUES (?, ?, ?)
[params=(long) 1, (long) 1, (String) department]
INSERT INTO EMPLOYEE (DEPT_ID, EMP_ID, NAME)
VALUES (?, ?, ?)
[params=(long) 1, (long) 1, (String) Frank]
A PersistenceException is thrown because of the DB2 error noted below. The
COMP_ID column cascades to the DEPARTMENT table, but does not cascade to the
EMPLOYEE table.
DB2 SQL error: SQLCODE: -407, SQLSTATE: 23502, SQLERRMC: TBSPACEID=2,
TABLEID=4, COLNO=0 {prepstmnt 1256737512
INSERT INTO EMPLOYEE (DEPT_ID, EMP_ID, NAME)
VALUES (?, ?, ?)
[params=(long) 1, (long) 1, (String) Frank]} [code=-407, state=23502]SQLCA
OUTPUT[Errp=SQLDFMT1, Errd=[-2146041828, 28, 0, 0, 0, 0]]
An application is provided to demonstrate the issue. To setup and
unsuccessfully run demonstration with OpenJPA:
1. Add DB provider JAR(s) to the FunInheritanceJava project's build path.
2.
[jira] Commented: (OPENJPA-213) @Column with precision and scale should result in NUMERIC(precision, scale)
[ https://issues.apache.org/jira/browse/OPENJPA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494291 ] Michael Dick commented on OPENJPA-213: -- I'm not sure I agree with the description of the problem. I've been basing my assumptions on the conversions tables found at http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/getstart/mapping.html#1004791 The tables there indicate that a java.lang.Double should be mapped to DOUBLE, not NUMERIC or DECIMAL. If NUMERIC or DECIMAL is desired then the entity should use a variable of type java.math.BigDecimal. The way the problem description is worded we'd be changing the rules if precision and scale were specified in an annotation. It becomes a question of which is more important, the type of the variable or the annotations around it. An argument can be made for either side, but I'm inclined to side with the type of the variable trumping the annotations. I believe the language in the spec supports this interpretation too : From section 9.1.5 int precision (Optional) The precision for a decimal (exact0 (Value must be set by numeric) column. (Applies only if a decimal col- developer.) umn is used.) int scale (Optional) The scale for a decimal (exact0 numeric) column. (Applies only if a decimal col- umn is used.) Assuming that is the correct approach, there is still a problem with DB2 and Derby where the mapping tool creates a DOUBLE column for BigDecimals instead of a NUMERIC column. I'll use this JIRA to fix the problem with DB2 and Derby. @Column with precision and scale should result in NUMERIC(precision, scale) --- Key: OPENJPA-213 URL: https://issues.apache.org/jira/browse/OPENJPA-213 Project: OpenJPA Issue Type: Improvement Components: jpa Affects Versions: 0.9.7 Reporter: Jacek Laskowski Assigned To: Michael Dick @Column provides the precision and scale attributes, but there's no (easy) way to figure out how it affects the way OpenJPA works if any. It looks like OpenJPA reads the type of a persistent field and when it's double it maps it to DOUBLE in Derby regardless of the other attributes. When precision and scale are specified, a DDL should use NUMERIC(precision, scale) or its synonim - DECIMAL(precision, scale). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-222) FOR READ ONLY clause getting generated for subselects
[ https://issues.apache.org/jira/browse/OPENJPA-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick reassigned OPENJPA-222: Assignee: David Wisneski FOR READ ONLY clause getting generated for subselects - Key: OPENJPA-222 URL: https://issues.apache.org/jira/browse/OPENJPA-222 Project: OpenJPA Issue Type: Bug Components: jpa Affects Versions: 0.9.7 Reporter: Ritika Maheshwari Assigned To: David Wisneski Attachments: JIRA182-subselect.patch FOR READ ONLY clause is generated for subselects in DB2. which throws a DB2 Exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-153) WebSphere and non-jta-data-source and default ManagedRuntime
[ https://issues.apache.org/jira/browse/OPENJPA-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489156 ] Michael Dick commented on OPENJPA-153: -- Confirming Kevin's comments above, support for non-jta-datasources is working and will be included in the next release of the WebSphere EJB3 feature pack. WebSphere and non-jta-data-source and default ManagedRuntime Key: OPENJPA-153 URL: https://issues.apache.org/jira/browse/OPENJPA-153 Project: OpenJPA Issue Type: Improvement Components: jdbc Environment: WebSphere 6.1 Reporter: Patrick Linskey Fix For: 0.9.7 See OPENJPA-144. It would seem that in a WebSphere environment, when specifying a non-jta-data-source, the JDBC connection that OpenJPA looks up does not permit calls to Connection.commit(). This, in conjunction with OPENJPA-149, means that in a default configuration, OpenJPA cannot use non-JTA data sources in a WebSphere environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-184) use DB2 Diagnostic interface to report extended error diagnostics on SQL Exception
[ https://issues.apache.org/jira/browse/OPENJPA-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick resolved OPENJPA-184. -- Resolution: Fixed Resolving issue per Ritika's comments on the dev mailing list. use DB2 Diagnostic interface to report extended error diagnostics on SQL Exception -- Key: OPENJPA-184 URL: https://issues.apache.org/jira/browse/OPENJPA-184 Project: OpenJPA Issue Type: New Feature Environment: DB2 database Reporter: David Wisneski When using DB2 database and the SQLException occurs if the SQLException instance supports the DB2Diagnosable interface, extended error information from the SQLCA will be written to the SQL channel. The message format produced by DB2Diagnosable writer is SQLCA OUTPUT[Errp=SQLDMISR, Errd=[-2146893819, 5, 0, 0, -957, 0]] Errp is the name of the DB2 module that detected the error and Errd are 6 integers of diagnostic information, SQLWARN are 6 characters of warning flags.. Often this additional information can be used by an administrator in doing problem determination. This message will be appended to the persistence exception error message already created by OpenJPA and it will be written to SQL logging channel (if active). DB2Dictionary class is modified to use java reflection on the SQLException instance to determine if it supports DB2Diagnosble methods getErrp and if so it invokes the methods to retrieve Errp and Errd fields, formats and logs the error message. Reflection is used so that the DB2Dictionary does not contain any compile time or runtime dependency on the DB2 jdbc driver. If the DB2Diagnosable methods do not exist on the SQLException instance, no extended error information is logged. org.apache.openjpa.jdbc.sql.SQLException class is modified so in the event of an exception if the Dictionary is DB2, to call the Dictionary routines above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-211) CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97
[ https://issues.apache.org/jira/browse/OPENJPA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488379 ] Michael Dick commented on OPENJPA-211: -- Have you started a UserTransaction? That's the only other thing that I can think of that would cause the problem. We're using a WebSphere proprietary API to register for synchronization with the transaction service. The WebSphere API doesn't allow OpenJPA to start a new transaction automatically. I believe Hibernate uses the same API though and suffers the same restrictions. I'm sorry to say I have no experience with Spring. I'll try to reproduce the problem without Spring and see if that sheds any light. Sorry I can't give you a more definite answer right now. CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97 - Key: OPENJPA-211 URL: https://issues.apache.org/jira/browse/OPENJPA-211 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.6 Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in Rational Developer 7 ( Websphere 6.1 test environment ) connected to DB2 V9.1. OS: WinXP SP2 Reporter: david zhang Priority: Blocker Fix For: 0.9.8 Attachments: applicationContext.xml, applicationContext.xml, mytestdata.jar, persistence.xml, persistence.xml Hi, if I use the OpenJPA shipped with Spring 2.0.3, I got the following error when start application: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 Caused by: java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:59) at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:131) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:182) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:154) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:145) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:114) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:106) at org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:92) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:214) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:251) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1143) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1110) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:431) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:244) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:233)
[jira] Commented: (OPENJPA-211) CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97
[ https://issues.apache.org/jira/browse/OPENJPA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488108 ] Michael Dick commented on OPENJPA-211: -- It looks like WASManagedRuntime is having trouble finding the WebSphere specific transaction classes. Are you still running in the embedded test environment in RAD or does the problem occur on a standalone WebSphere server? RAD handles the classpath a little differently (or at least it used to back in version 5) and that might contribute to the problem. Have you changed any of the classloader settings (ie PARENT_LAST)? CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97 - Key: OPENJPA-211 URL: https://issues.apache.org/jira/browse/OPENJPA-211 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.6 Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in Rational Developer 7 ( Websphere 6.1 test environment ) connected to DB2 V9.1. OS: WinXP SP2 Reporter: david zhang Priority: Blocker Fix For: 0.9.8 Attachments: applicationContext.xml, mytestdata.jar, persistence.xml Hi, if I use the OpenJPA shipped with Spring 2.0.3, I got the following error when start application: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 Caused by: java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:59) at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:131) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:182) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:154) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:145) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:114) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:106) at org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:92) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:214) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:251) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1143) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1110) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:431) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:244) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:233) at org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:205) at
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487098 ] Michael Dick commented on OPENJPA-182: -- I have no practical experience with Sybase, but I did find this in their TransactSQL user's guide : Changing the isolation level for a query You can change the isolation level for a query by using the at isolation clause with the select or readtext statements. The at isolation clause supports isolation levels 0, 1, and 3. It does not support isolation level 2. The read uncommitted, read committed, and serializable options of at isolation represent isolation levels as listed below: at isolation option Isolation level read uncommited 0 read committed 1 serializable3 For example, the following two statements query the same table at isolation levels 0 and 3, respectively: select * from titles at isolation read uncommitted select * from titles at isolation serializable There's more information online here: http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlug/@Generic__BookTextView/53911;hf=0 db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS -- Key: OPENJPA-182 URL: https://issues.apache.org/jira/browse/OPENJPA-182 Project: OpenJPA Issue Type: New Feature Components: jdbc Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux Reporter: David Wisneski Assigned To: David Wisneski Attachments: OPENJPA-182.patch, openJPA182.patch A while back we changed the syntax of update locking from FOR UPDATE OF to WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because 1. if isolation=serializable is configured, then the syntax should be WITH RR USE AND KEEP UDPATE LOCKS 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 only supports read or exclusive locks. 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. So we change supportsLockingWithSelectRange = true in the AbstractDB2Dictionary class and change the DB2Dictionary to append the correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-185) optional attribute is not overriden by xml descriptor
[ https://issues.apache.org/jira/browse/OPENJPA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick reassigned OPENJPA-185: Assignee: Michael Dick optional attribute is not overriden by xml descriptor - Key: OPENJPA-185 URL: https://issues.apache.org/jira/browse/OPENJPA-185 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.0, 0.9.6 Reporter: Michael Dick Assigned To: Michael Dick Fix For: 0.9.7 Attachments: OpenJPA-185.patch.txt The optional attribute of the @Basic annotation is not being overriden if it's defined in orm.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-185) optional attribute is not overriden by xml descriptor
[ https://issues.apache.org/jira/browse/OPENJPA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick resolved OPENJPA-185. -- Resolution: Fixed optional attribute is not overriden by xml descriptor - Key: OPENJPA-185 URL: https://issues.apache.org/jira/browse/OPENJPA-185 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.0, 0.9.6 Reporter: Michael Dick Assigned To: Michael Dick Fix For: 0.9.7 Attachments: OpenJPA-185.patch.txt The optional attribute of the @Basic annotation is not being overriden if it's defined in orm.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-198) Finish fix for persistence-unit-defaults
Finish fix for persistence-unit-defaults Key: OPENJPA-198 URL: https://issues.apache.org/jira/browse/OPENJPA-198 Project: OpenJPA Issue Type: Sub-task Affects Versions: 0.9.8 Reporter: Michael Dick Assigned To: Michael Dick The changes for OpenJPA-179 (revision 525006) fix the problem where default schemas are not processed at all, however there are still some issues. 1. The persistence-unit-defaults only apply to entities within the xml descriptor, they will not apply to annotated entities which are in the same persistence unit. 2. In order to override the default schema the table name must be specified. These issues still need to be addressed, but can wait until after version 0.9.7 to be resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-179) Schemas defined in orm.xml are only applied when a name is also specified.
[ https://issues.apache.org/jira/browse/OPENJPA-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick resolved OPENJPA-179. -- Resolution: Fixed Fixed with revision 525006. Schemas defined in orm.xml are only applied when a name is also specified. --- Key: OPENJPA-179 URL: https://issues.apache.org/jira/browse/OPENJPA-179 Project: OpenJPA Issue Type: Bug Components: jpa Affects Versions: 0.9.6, 0.9.7 Reporter: Michael Dick Assigned To: Michael Dick Fix For: 0.9.7 Attachments: OpenJPA-179-example.zip If a default schema name is specified (either as a mapping file default or a persistence unit default) it will only be applied if a table name is also included in the same xml descriptor. For example if the xml file looks like this ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 persistence-unit-metadata persistence-unit-defaults schemaDefSchema/schema /persistence-unit-defaults /persistence-unit-metadata entity class=mdd.MyEntity attributes id name=id/id basic name=name/basic /attributes /entity entity class=mdd.MyEntityWithTable table name=MyEntityWithTable/ attributes id name=id/id basic name=name/basic /attributes /entity /entity-mappings The default schema will be applied to MyEntityWithTable, but will not be applied to MyEntity. The same applies if the xml looks like this : ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 schemaDefSchema/schema . . . /entity-mappings I think there are two problems here : 1. The mapping file default schema (example 2) should apply to every entity in the xml mapping file (except where it's overridden by another entry or an annotation). 2. A schema defined in the persistence-unit-defaults tag should apply to all entities in the persistence unit, not just the ones defined or overridden in the xml file. This default is overridden my the mapping file default schema, other xml schema entries and annotations. I'll attach a simple sample of the problem, in case I'm missing something. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-192) WASManagedRuntime's tm is used despite exception initializing WASManagedRuntime.
WASManagedRuntime's tm is used despite exception initializing WASManagedRuntime. - Key: OPENJPA-192 URL: https://issues.apache.org/jira/browse/OPENJPA-192 Project: OpenJPA Issue Type: Bug Reporter: Michael Dick Phill Moran reported a problem with WASManagedRuntime and Spring. Attached is the relevant portion of the stack trace : org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.jav a:196) Caused by: 4|true|0.0.0 org.apache.openjpa.persistence.InvalidStateException: An error occured reflecting WebSphere proprietary interfaces. Please ensure that you are running the application from within WebSphere Application Server (version 5.0.2 or newer). FailedObject: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at org.apache.openjpa.ee.WASManagedRuntime.endConfiguration(WASManagedRuntime.java: 344) at org.apache.openjpa.ee.AutomaticManagedRuntime.getTransactionManager(AutomaticMan agedRuntime.java:124) ... 39 more NestedThrowables: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.apache.openjpa.ee.JNDIManagedRuntime.getTransactionManager(JNDIManagedRuntim e.java:51) at org.apache.openjpa.ee.AutomaticManagedRuntime.getTransactionManager(AutomaticMan agedRuntime.java:140) I don't believe this is the root of the problem that he's running into, but it needs to be cleaned up before we go further. The error occurs when we configure the WASManagedRuntime and one approach is to swallow the exception at that time and proceed. A better approach is to look for a WebSphere signiture in the constructor to WASManagedRuntime, if it's not found throw an exception. The exception is handled by AutomaticRuntime and prevents WASManagedRuntime from being used again (this is similar to what WLSManagedRuntime does). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-192) WASManagedRuntime's tm is used despite exception initializing WASManagedRuntime.
[ https://issues.apache.org/jira/browse/OPENJPA-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-192: - Attachment: OpenJPA-192.patch.txt Attaching a rudimentary patch. The patch tries to find an instance of the WebSphere jtaextensions class whenever we create a new WASManagedRuntime instance. If the class isn't found a ClassNotFoundException will be thrown and the WASManagedRuntime instance won't be created. Basically it prevents an extraneous error from being logged when WebSphere isn't being used. WASManagedRuntime's tm is used despite exception initializing WASManagedRuntime. - Key: OPENJPA-192 URL: https://issues.apache.org/jira/browse/OPENJPA-192 Project: OpenJPA Issue Type: Bug Reporter: Michael Dick Attachments: OpenJPA-192.patch.txt Phill Moran reported a problem with WASManagedRuntime and Spring. Attached is the relevant portion of the stack trace : org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.jav a:196) Caused by: 4|true|0.0.0 org.apache.openjpa.persistence.InvalidStateException: An error occured reflecting WebSphere proprietary interfaces. Please ensure that you are running the application from within WebSphere Application Server (version 5.0.2 or newer). FailedObject: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at org.apache.openjpa.ee.WASManagedRuntime.endConfiguration(WASManagedRuntime.java: 344) at org.apache.openjpa.ee.AutomaticManagedRuntime.getTransactionManager(AutomaticMan agedRuntime.java:124) ... 39 more NestedThrowables: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.apache.openjpa.ee.JNDIManagedRuntime.getTransactionManager(JNDIManagedRuntim e.java:51) at org.apache.openjpa.ee.AutomaticManagedRuntime.getTransactionManager(AutomaticMan agedRuntime.java:140) I don't believe this is the root of the problem that he's running into, but it needs to be cleaned up before we go further. The error occurs when we configure the WASManagedRuntime and one approach is to swallow the exception at that time and proceed. A better approach is to look for a WebSphere signiture in the constructor to WASManagedRuntime, if it's not found throw an exception. The exception is handled by AutomaticRuntime and prevents WASManagedRuntime from being used again (this is similar to what WLSManagedRuntime does). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-185) optional attribute is not overriden by xml descriptor
optional attribute is not overriden by xml descriptor - Key: OPENJPA-185 URL: https://issues.apache.org/jira/browse/OPENJPA-185 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.6, 0.9.0 Reporter: Michael Dick Fix For: 0.9.7 The optional attribute of the @Basic annotation is not being overriden if it's defined in orm.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-185) optional attribute is not overriden by xml descriptor
[ https://issues.apache.org/jira/browse/OPENJPA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-185: - Attachment: OpenJPA-185.patch.txt optional attribute is not overriden by xml descriptor - Key: OPENJPA-185 URL: https://issues.apache.org/jira/browse/OPENJPA-185 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.0, 0.9.6 Reporter: Michael Dick Fix For: 0.9.7 Attachments: OpenJPA-185.patch.txt The optional attribute of the @Basic annotation is not being overriden if it's defined in orm.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-176) Exception prefixes should be human-readable
[ https://issues.apache.org/jira/browse/OPENJPA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483852 ] Michael Dick commented on OPENJPA-176: -- It looks like we just use type + error if the type isn't recognized. +1 as it is, but I'm not opposed to changing type + error to unexpected error or something similar. Exception prefixes should be human-readable --- Key: OPENJPA-176 URL: https://issues.apache.org/jira/browse/OPENJPA-176 Project: OpenJPA Issue Type: Improvement Components: diagnostics Affects Versions: 0.9.0, 0.9.6 Reporter: Marc Prud'hommeaux Assigned To: Marc Prud'hommeaux Priority: Trivial Attachments: OPENJPA-176.patch OpenJPA prefixes all exception messages with a string of the form exception type|is fatal|version, restulting in strings like 4|false|0.9.6-incubating org.apache.openjpa.persistence.PersistenceException. This isn't very useful to the casual observer, since no translation of the meaning of the fields is done. it would be nice if we translated the fatal and type parameters, so that the string looked like user-error|recoverable|0.9.6-incubating. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-179) Schemas defined in orm.xml are only applied when a name is also specified.
Schemas defined in orm.xml are only applied when a name is also specified. --- Key: OPENJPA-179 URL: https://issues.apache.org/jira/browse/OPENJPA-179 Project: OpenJPA Issue Type: Bug Components: jpa Affects Versions: 0.9.6, 0.9.7 Reporter: Michael Dick Fix For: 0.9.7 If a default schema name is specified (either as a mapping file default or a persistence unit default) it will only be applied if a table name is also included in the same xml descriptor. For example if the xml file looks like this ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 persistence-unit-metadata persistence-unit-defaults schemaDefSchema/schema /persistence-unit-defaults /persistence-unit-metadata entity class=mdd.MyEntity attributes id name=id/id basic name=name/basic /attributes /entity entity class=mdd.MyEntityWithTable table name=MyEntityWithTable/ attributes id name=id/id basic name=name/basic /attributes /entity /entity-mappings The default schema will be applied to MyEntityWithTable, but will not be applied to MyEntity. The same applies if the xml looks like this : ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 schemaDefSchema/schema . . . /entity-mappings I think there are two problems here : 1. The mapping file default schema (example 2) should apply to every entity in the xml mapping file (except where it's overridden by another entry or an annotation). 2. A schema defined in the persistence-unit-defaults tag should apply to all entities in the persistence unit, not just the ones defined or overridden in the xml file. This default is overridden my the mapping file default schema, other xml schema entries and annotations. I'll attach a simple sample of the problem, in case I'm missing something. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
[
https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482448
]
Michael Dick commented on OPENJPA-132:
--
I'm fine using Abe's patch. The patch I submitted was just focussed on
java.sql.Date, not the other java.sql classes. A simpler fix which adds more
function is usually a good thing.
java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
Key: OPENJPA-132
URL: https://issues.apache.org/jira/browse/OPENJPA-132
Project: OpenJPA
Issue Type: Bug
Components: kernel
Reporter: Michael Dick
Priority: Minor
Fix For: 0.9.7
Attachments: OpenJPA-132.patch.txt
Opening JIRA report to track the following problem (posted to development
forum
http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
I'm getting the following exception when I try to fetch an entity with a
java.sql.Date as the id :
java.lang.NoSuchMethodError:
org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
at org.apache.openjpa.kernel.StateManagerImpl.initialize
(StateManagerImpl.java:247)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
at org.apache.openjpa.kernel.DelegatingBroker.find
(DelegatingBroker.java:169)
at
org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
. . .
It's coming from the generated bytecode which expects there to be a getId
method that returns the same type of the Id, however java.sql.Date is using
the same ID class as java.util.Date. Do we need a separate class for
java.sql.Date?
Responses from Patrick and Craig follow. The consensus so far is to provide
ID separate classes for java.sql.Date and java.util.Date.
It looks like we either need a separate type for java.sql.Date (and
presumably java.sql.Timestamp), or we need to change the logic to accept
a getId() method that returns a type that is assignable from the id
field's type.
-Patrick
It's probably cleaner if we have separate classes for the different
types. That is, have the getId method in the new
org.apache.openjpa.util.SQLDateId return the proper type
(java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
really the same as java.util.Date.
-Craig
FTR, I think that I prefer separate classes as well; it's clearer, and
avoids any ambiguity with other subclasses in the future.
-Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-160: - Attachment: perf3.jpg Here's a jpg with the call to Class.newInstance() expanded. The data is from a different execution though so the numbers are a little different but they show the same problem. It looks like the time is spent in reflection accessing the constructor. I don't know what data to gather next though. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: perf2.jpg, perf3.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475455 ] Michael Dick commented on OPENJPA-160: -- We ran some more performance tests with the latest OpenJPA code and the issue appears to be with creating an instance of the BrokerImpl (when Configurations calls Class.newInstance). I was surprised that creating a new instance turned out to take so much time and I don't know what we'd could (or would want to) tinker with to try to make it faster to create. I'm not thrilled about adding the complexity of a reuse pool so I'm open to suggestions. The pool that we used before was a two level pool thread.toString+user+pass - collection of brokers. Adding a non static field to AbstractBrokerFactory sounds feasible too (unless there's an alternative to pooling). Still looking into whether we need a key in BrokerImpl - I'll follow up on that as well. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-160: - Attachment: perf2.jpg I have a screenshot from the performance tool. I don't have access to the performance test environment right now but I'll see what else I can share on Monday. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: perf2.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475102 ] Michael Dick commented on OPENJPA-160: -- Another performance issue we've run into is the overhead of creating a new BrokerImpl object when the application calls createEntityManager. The JPA spec clearly states that the provider needs to return a new EntityManager instance, and we're not trying to circumvent that requirement. However it seems plausible that we could reuse the underlying BrokerImpl object, once all the persistence data has been cleared (ie after BrokerImpl.free has been called). Implementing a fairly simple object reuse pool resulted in a significant performance improvement in our testing. I don't see this as being a violation of the intent of the spec, but I'd rather get a sense of consensus before I/we go any further. Questions : 1. Is there a reason why we can't reuse the BrokerImpl objects? 2. Assuming we can reuse the objects, where should we put the reuse pool? The original implementation created a static map in AbstractBrokerFactory. I'm not sure that's the best place for it though. BrokerImpl isn't a final class it's possible that different configurations could use different broker implementations (through the broker plugin). Maybe we need a new plugin which indicates that class to use as a Broker pool? 3. Should we pool the broker instances by default? I think we'll want this to be configurable, but I'm not sure it needs to be on by default. Justification : We've been running tests with the Sun Application Server and adding in a BrokerImpl reuse pool brings the performance on par with Hibernate. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-156) Cache class object used to create plugin values
Cache class object used to create plugin values --- Key: OPENJPA-156 URL: https://issues.apache.org/jira/browse/OPENJPA-156 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-156) Cache class object used to create plugin values
[ https://issues.apache.org/jira/browse/OPENJPA-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-156: - Attachment: openjpa-156.patch.txt Another performance issue we've run into is the call to Strings.toClass(clsName, findDerivedLoader(conf, loader)) in Configurations.newInstance(). To work around the problem we tried caching the Class created for a given ClassLoader. It's a relatively simple cache, but it yielded noticeable performance improvements. The attached patch is relative to openjpa-lib, I can attach one that is relative to trunk if that will help. Cache class object used to create plugin values --- Key: OPENJPA-156 URL: https://issues.apache.org/jira/browse/OPENJPA-156 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: openjpa-156.patch.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-140) Wrong package name in test classes
Wrong package name in test classes -- Key: OPENJPA-140 URL: https://issues.apache.org/jira/browse/OPENJPA-140 Project: OpenJPA Issue Type: Bug Reporter: Michael Dick It looks like the package for some of the new test classes is out of sync with where they are in the filesystem : Hi Mike, This is clearly wrong. Can you file a JIRA? Craig On Feb 9, 2007, at 8:17 AM, Michael Dick wrote: Hi Marc, The classes in incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/ apache/openjpa/persistence/models declare package org.apache.openjpa.persistence.models.company. This is causing a lot of errors in Eclipse, maven builds fine though. Is this intentional? Thanks, -Mike I'm not sure whether the java files should be moved or if the package declarations need to be changed though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-139) PersistenceException merging an entity with a Calendar field.
PersistenceException merging an entity with a Calendar field. -- Key: OPENJPA-139 URL: https://issues.apache.org/jira/browse/OPENJPA-139 Project: OpenJPA Issue Type: Bug Components: kernel Reporter: Michael Dick I get the following exception when I try to merge an entity which contains a java.util.Calendar field. 0|true|0.0.0 org.apache.openjpa.persistence.PersistenceException: mikedd.entities.CalendarEntity.cal at org.apache.openjpa.kernel.AttachStrategy.attachField(AttachStrategy.java:255) at org.apache.openjpa.kernel.VersionAttachStrategy.attach(VersionAttachStrategy.java:131) at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:236) at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:97) at org.apache.openjpa.kernel.BrokerImpl.attach(BrokerImpl.java:3141) at org.apache.openjpa.kernel.DelegatingBroker.attach(DelegatingBroker.java:1128) at org.apache.openjpa.persistence.EntityManagerImpl.merge(EntityManagerImpl.java:650) at mikedd.tests.TestCalendar.testMergeCalendar(TestCalendar.java:47) snip I'm running the test in eclipse and my classpath probably isn't set up to properly display the openjpa version, output from svnversion -c : 406193:505052M It looks like we're missing a case statement for JavaTypes.CALENDAR in org.apache.openjpa.kernelAttachStrategy.attachField. I added one under JavaTypes.DATE and that resolved the issue for me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
Key: OPENJPA-132
URL: https://issues.apache.org/jira/browse/OPENJPA-132
Project: OpenJPA
Issue Type: Bug
Components: kernel
Reporter: Michael Dick
Opening JIRA report to track the following problem (posted to development forum
http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
I'm getting the following exception when I try to fetch an entity with a
java.sql.Date as the id :
java.lang.NoSuchMethodError:
org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
at org.apache.openjpa.kernel.StateManagerImpl.initialize
(StateManagerImpl.java:247)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
at org.apache.openjpa.kernel.DelegatingBroker.find
(DelegatingBroker.java:169)
at
org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
. . .
It's coming from the generated bytecode which expects there to be a getId
method that returns the same type of the Id, however java.sql.Date is using the
same ID class as java.util.Date. Do we need a separate class for java.sql.Date?
Responses from Patrick and Craig follow. The consensus so far is to provide ID
separate classes for java.sql.Date and java.util.Date.
It looks like we either need a separate type for java.sql.Date (and
presumably java.sql.Timestamp), or we need to change the logic to accept
a getId() method that returns a type that is assignable from the id
field's type.
-Patrick
It's probably cleaner if we have separate classes for the different
types. That is, have the getId method in the new
org.apache.openjpa.util.SQLDateId return the proper type
(java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
really the same as java.util.Date.
-Craig
FTR, I think that I prefer separate classes as well; it's clearer, and
avoids any ambiguity with other subclasses in the future.
-Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-116) EntityManager.getDelegate should throw an IllegalStateException
[
https://issues.apache.org/jira/browse/OPENJPA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dick updated OPENJPA-116:
-
Attachment: openjpa-116-patch.txt
EntityManager.getDelegate should throw an IllegalStateException
Key: OPENJPA-116
URL: https://issues.apache.org/jira/browse/OPENJPA-116
Project: OpenJPA
Issue Type: Bug
Reporter: Michael Dick
Priority: Minor
Attachments: openjpa-116-patch.txt
EntityManager.getDelegate() should throw an IllegalStateException if the
EntityManager has been closed.
I noticed then when debugging other problems. According to the javadoc
http://java.sun.com/javaee/5/docs/api/javax/persistence/EntityManager.html#getDelegate()
we need to throw an exception if the EM has been closed.
In case I missed anything here's what I did to reproduce the problem.
EntityManagerFactory _emf =
Persistence.createEntityManagerFactory(test);
EntityManager em = _emf.createEntityManager();
em.close();
try {
Object o = em.getDelegate();
fail();
}
catch(IllegalStateException ise) {
System.out.println(Caught expected exception);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-116) EntityManager.getDelegate should throw an IllegalStateException
EntityManager.getDelegate should throw an IllegalStateException
Key: OPENJPA-116
URL: https://issues.apache.org/jira/browse/OPENJPA-116
Project: OpenJPA
Issue Type: Bug
Reporter: Michael Dick
Priority: Minor
EntityManager.getDelegate() should throw an IllegalStateException if the
EntityManager has been closed.
I noticed then when debugging other problems. According to the javadoc
http://java.sun.com/javaee/5/docs/api/javax/persistence/EntityManager.html#getDelegate()
we need to throw an exception if the EM has been closed.
In case I missed anything here's what I did to reproduce the problem.
EntityManagerFactory _emf =
Persistence.createEntityManagerFactory(test);
EntityManager em = _emf.createEntityManager();
em.close();
try {
Object o = em.getDelegate();
fail();
}
catch(IllegalStateException ise) {
System.out.println(Caught expected exception);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-65) Remove zip files from zip archive and remove -all from openjpa-all-${version}.jar
[ http://issues.apache.org/jira/browse/OPENJPA-65?page=all ]
Michael Dick resolved OPENJPA-65.
-
Resolution: Fixed
Forgot to close this earlier.
The individual models have been removed from the distribution zip files. The
-all suffix was also removed from the openjpa jar, but it has crept back in.
Since removing the modules was the main point of this report (IMHO) I'm marking
it as closed.
The -all suffix can be removed by using the outputFileNameMapping tag forthe
openjpa-all dependencySet in assembly.xml. Here's what the dependecy set might
look like :
dependencySet
outputDirectory//outputDirectory
unpackfalse/unpack
scoperuntime/scope
outputFileNameMappingopenjpa-${version}.${extension}/outputFileNameMapping
includes
includeorg.apache.openjpa:openjpa-all/include
/includes
/dependencySet
Remove zip files from zip archive and remove -all from
openjpa-all-${version}.jar
---
Key: OPENJPA-65
URL: http://issues.apache.org/jira/browse/OPENJPA-65
Project: OpenJPA
Issue Type: Task
Reporter: Michael Dick
Priority: Minor
The goal of this task is to change the packaging of the OpenJPA zip file so
that the individual modules (openjpa-lib, openjpa-kernel, etc) are not
included. The class files contained in the modules are already included in
openjpa-all-${version}.jar.
the task will also remove -all from openjpa-all-${version}.jar in order to
avoid confusion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OPENJPA-76) add-was-interfaces ant task throws exception on a non-clean build.
add-was-interfaces ant task throws exception on a non-clean build.
-
Key: OPENJPA-76
URL: http://issues.apache.org/jira/browse/OPENJPA-76
Project: OpenJPA
Issue Type: Bug
Components: kernel
Reporter: Michael Dick
Patrick Linskey found the problem and posted to the dev mailing list. Here's
the original post :
Hi,
I get the following stack trace when running 'mvn package'. It looks
like I don't have some required IBM classes in my classpath.
Surprisingly, this exception does not cause the build to fail, but
presumably, the output bytes are not the same as if this had run
successfully.
Does anyone have any suggestions for either getting the classes into the
classpath or moving the exception to runtime, so that there aren't
build-time dependency issues resulting in different jars from the same
sources?
Thanks,
-Patrick
Partial stack trace:
[INFO] [antrun:run {execution: add-was-interfaces}]
[INFO] Executing tasks
[java] java.lang.IllegalArgumentException:
java.lang.NoClassDefFoundError:
com/ibm/websphere/jtaextensions/SynchronizationCallback
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:180)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:710)
[java] at
org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:178)
[java] at
org.apache.tools.ant.taskdefs.Java.execute(Java.java:84)
[java] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[java] at org.apache.tools.ant.Task.perform(Task.java:364)
[java] at org.apache.tools.ant.Target.execute(Target.java:341)
[java] at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntM
ojo.java:108)
[java] at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
[java] at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa
nager.java:412)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default
LifecycleExecutor.java:534)
.
[java] Caused by: java.lang.IllegalArgumentException:
java.lang.NoClassDefFoundError:
com/ibm/websphere/jtaextensions/SynchronizationCallback
[java] at serp.util.Strings.toClass(Strings.java:211)
[java] at serp.util.Strings.toClass(Strings.java:140)
[java] at serp.bytecode.BCClass.getType(BCClass.java:565)
[java] at serp.bytecode.BCClass.write(BCClass.java:202)
[java] at
org.apache.openjpa.ee.WASManagedRuntime.main(WASManagedRuntime.java:412)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
Upon further examination the problem occurs if the WASSynchronization class is
modified a second time (ie you don't run mvn clean before running mvn package).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OPENJPA-65) Remove zip files from zip archive and remove -all from openjpa-all-${version}.jar
Remove zip files from zip archive and remove -all from
openjpa-all-${version}.jar
---
Key: OPENJPA-65
URL: http://issues.apache.org/jira/browse/OPENJPA-65
Project: OpenJPA
Issue Type: Task
Reporter: Michael Dick
Priority: Minor
The goal of this task is to change the packaging of the OpenJPA zip file so
that the individual modules (openjpa-lib, openjpa-kernel, etc) are not
included. The class files contained in the modules are already included in
openjpa-all-${version}.jar.
the task will also remove -all from openjpa-all-${version}.jar in order to
avoid confusion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-65) Remove zip files from zip archive and remove -all from openjpa-all-${version}.jar
[ http://issues.apache.org/jira/browse/OPENJPA-65?page=all ]
Michael Dick updated OPENJPA-65:
Attachment: openjpa-65.patch.txt
Attaching patch file.
The patch removes the modules from openjpa.zip and renames the jar created in
openjpa-all.
Remove zip files from zip archive and remove -all from
openjpa-all-${version}.jar
---
Key: OPENJPA-65
URL: http://issues.apache.org/jira/browse/OPENJPA-65
Project: OpenJPA
Issue Type: Task
Reporter: Michael Dick
Priority: Minor
Attachments: openjpa-65.patch.txt
The goal of this task is to change the packaging of the OpenJPA zip file so
that the individual modules (openjpa-lib, openjpa-kernel, etc) are not
included. The class files contained in the modules are already included in
openjpa-all-${version}.jar.
the task will also remove -all from openjpa-all-${version}.jar in order to
avoid confusion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-24) Allow OpenJPA to be extensible
[ http://issues.apache.org/jira/browse/OPENJPA-24?page=comments#action_12436323 ] Michael Dick commented on OPENJPA-24: - Thanks Abe, I was able to load a custom EMF with your changes. I might have more questions when I get a chance to experiment a little more. Allow OpenJPA to be extensible -- Key: OPENJPA-24 URL: http://issues.apache.org/jira/browse/OPENJPA-24 Project: OpenJPA Issue Type: Bug Components: kernel Reporter: Kevin Sutter Assigned To: Kevin Sutter The current OpenJPA architecture is not extendable to other implementations. For example, if somebody wanted to provide their own PersistenceProvider implementation, simply extending the org.apache.openjpa.PersistenceProviderImpl would not suffice due to the dependencies in the ConfigurationProviderImpl. The discussion for this improvement was started on the dev mailing list. Once it was determined that there was more to this request than a simple conditional or two, we decided to open a JIRA report. The complete history of this request can be found in the OpenJPA dev mailing list. The first message was posted by me (Kevin Sutter) on August 14, titled Extending the OpenJPA Implementation. I will attempt to paraphrase the current state of the problem... We have three main players in this issue. The PersistenceProvider, the ConfigurationProvider, and the ProductDerivation (along with the various implementations of these interfaces). Currently, the ConfigurationProvider is in the lib and is unaware of any specific persistence requirements. The ProductDerivation is in the kernel and, unfortunately, is aware of persistence requirements, specifically the spec and store types. Abe's postings have indicated that we need to make these two interfaces more aware of each other and work with each other. We need to start with either making ConfigurationProvider more persistence-aware and move it into kernel, or make ProductDerivations less persistence-aware and move it into lib. The latter approach is preferred. After we get this re-organization of the base framework complete, we still have a couple of other issues ot resolve: * Still need the ability to extend EMF's through a ProductDerivation. This should be doable by adding a new PluginValue to indicate what class of EMF to load. * There is still a question as to whether we will need to provide a custom PersistenceProviderImpl and ConfigurationProviderImpl pair. I still think this will be necessary. And, one of Abe's posts indicated that this might help with class loading issues when multiple versions of OpenJPA-based implementations are available in the same system. I also posted these questions last Friday. (Abe has responded with some answers, but I wanted to get this JIRA report created before trying to paraphrase his answers.) * You mention in several places about separating away the notion of specs and stores. In a general sense, I understand what these are. But, can you elaborate on how these types are used in the ConfigurationProvider and ProductDerivation interfaces? * I've moved the ProductDerivation interface to the lib and added the load methods from the ConfigurationProvider (as described in your previous notes). And, I've started to clean up the implementations that depend on these interfaces. But, concerning the implementation of the load methods... Now that we need to return a ConfigurationProvider, would you expect that we just new up a ConfigurationProviderImpl and then just call across to the load methods on the implementation? Since we want to keep the ProductDerivations stateless, I'm not sure how else you were expecting to create a ConfigurationProvider to return on these load methods. * Now that ConfigurationProvider is bare, the ConfigurationTestConfigurationProvider doesn't have much function. I'll need to take a look to see if this is even required any longer. * Can you shed a bit more light on the Configurations class? It doesn't implement nor extend any interfaces or classes, but it seems to provide many of the same methods as ConfigurationProvider, but as statics. And, it's dependent on having a Provider. Can you explain the relationship of this class in the bigger picture and how you think it might be affected by thes changes? That's enough for the initial JIRA report. We will now track this problem here instead of the dev mailing list. Thanks. Kevin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OPENJPA-34) Problem detecting parent's access type with runtime enhancement.
Problem detecting parent's access type with runtime enhancement. - Key: OPENJPA-34 URL: http://issues.apache.org/jira/browse/OPENJPA-34 Project: OpenJPA Issue Type: Bug Reporter: Michael Dick Priority: Minor Attachments: employee-project.zip I have a small hierarchy of entities specified in an xml descriptor (orm.xml), Employee, PartTimeEmployee and FullTimeEmployee. PartTimeEmployee and FullTimeEmployee extend Employee which is a MappedSuperclass. If I don't explicitly set the access type for either PartTimeEmployee or FullTimeEmployee in orm.xml and I use the static enhancer (org.apache.openjpa.enhance.PCEnhancer) everything works fine. If I use runtime enhancement I get a warning like this : 184 INFO [main] openjpa.MetaData - Found 3 classes with metadata in 7 milliseconds. 88 INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 180 INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary. 277 INFO [main] openjpa.MetaData - Found 4 classes with metadata in 1 milliseconds. 985 INFO [main] openjpa.MetaData - Parsing resource file:/home/mikedd/workspaces/openjpa/mdd/target/classes/META-INF/orm.xml. 1307 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.Employee. 1356 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.Employee. 1356 INFO [main] openjpa.MetaData - Parsing package mdd.entities.descriptor.Employee. 1385 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.PartTimeEmployee. 1385 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.PartTimeEmployee. 1389 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.FullTimeEmployee. 1390 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.FullTimeEmployee. 1394 INFO [main] openjpa.MetaData - Parsing class mdd.entities.descriptor.AbstractPersonnel. 1422 WARN [main] openjpa.Enhance - An exception was thrown while attempting to perform class file transformation on mdd/entities/descriptor/FullTimeEmployee: 4|false|0.0.0 org.apache.openjpa.util.UserException: Detected the following possible violations of the restrictions placed on property access persistent types: The member for for persistent property mdd.entities.descriptor.FullTimeEmployee.salary was not a method: private float mdd.entities.descriptor.FullTimeEmployee.salary. at org.apache.openjpa.enhance.PCEnhancer.processViolations(PCEnhancer.java:520) at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:287) at org.apache.openjpa.enhance.PCClassFileTransformer.transform(PCClassFileTransformer.java:122) at sun.instrument.TransformerManager.transform(TransformerManager.java:141) at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:174) at java.lang.ClassLoader.defineClassImpl(Native Method) From what I can tell after running the debugger the error occurs because the runtime enhancer isn't able to find the parent's metadata (and from that the access type). I don't think the spec is very clear in this regard. Access isn't a required attribute for entities, but the spec doesn't indicate what should happen if it isn't present (or if it does I didn't find it). I don't know whether this is a limitation of runtime enhancement (again I didn't see it documented anywhere, but maybe I didn't look hard enough). There are also plenty of solutions, specifying a default access type in orm.xml, or just adding access=PROPERTY to the entity will work. If it's not an architectural limitation though, I think we should try to get runtime enhancement to work in the same manner as static enhancement. In case it helps here's my javaagent setting : -javaagent:/home/mikedd/.m2/repository/org/apache/openjpa/openjpa-kernel-5/0.9.0-SNAPSHOT/openjpa-kernel-5-0.9.0-SNAPSHOT.jar=scanDevPath=true,MetaDataFactory=jpa I've attached the source that I've used to produce the problem, include the eclipse .project and .classpath files (you'll probably have to update these). There's also a pom.xml which can be used to compile or at least set up the classpath in eclipse. I don't know how to toggle between runtime and static enhancement with maven so I haven't used it to run the tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (OPENJPA-12) Default to strictIdentityTypes for JPA
[ http://issues.apache.org/jira/browse/OPENJPA-12?page=all ] Michael Dick resolved OPENJPA-12. - Resolution: Invalid Per comments on the dev mailing list. If the TCK passes with the property specified then there's no need to change the default behavior. I'm setting the resolution to invalid since it isn't really a bug (won't fix didn't sound right). Default to strictIdentityTypes for JPA -- Key: OPENJPA-12 URL: http://issues.apache.org/jira/browse/OPENJPA-12 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Michael Dick Priority: Minor Attachments: patch.txt The default behavior with OpenJPA is to be very forgiving regarding the Primary Key types passed in when calling EntityManager.find or EntityManager.getReference. For example if an Entity has an ID of type Long OpenJPA will attempt to convert anything that extend java.lang.Number and Strings (maybe others). This is a nice feature, but I don't think it should be the default behavior. The JPA spec indicates that an IllegalArgumentException should be thrown if the second argument is not a valid type for the Entity's primary key. There is some room for interpretation as to what constitutes a valid type, conversion for all Numbers makes sense, but String might be pushing it. Workaround : Add the following to persistence.xml property name=openjpa.Compatibility value=strictIdentityValues=true / Proposed Solution : The OpenJPA compatibility plugin provides a mechanism to enforce strict identity checking (defaulting to false). There's no need to change the default in the kernel (other persistence apis like JDO might be more lenient) so I propose changing the default in PersistenceProductDerivation.beforeConfigurationLoad(). Changing it there should only effect the JPA facade and leave the OpenJPA kernel's default in place for other facades. The value may be overridden by adding the following property to persistence.xml property name=openjpa.Compatibility value=strictIdentityValues=false / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
