[jira] Commented: (OPENJPA-61) Missing usage of TransactionSynchronizationRegistry
[ https://issues.apache.org/jira/browse/OPENJPA-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496911 ] Michael Dick commented on OPENJPA-61: - The patch looks good on our end, running with the Transacton Synchronization Registry in WebSphere. If other vendors would like to test it out as well that's fine with me, but you have my +1 to integrate.. > Missing usage of TransactionSynchronizationRegistry > --- > > Key: OPENJPA-61 > URL: https://issues.apache.org/jira/browse/OPENJPA-61 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Reporter: Kevin Sutter > Assigned To: Kevin Sutter > Fix For: 1.1.0 > > Attachments: OPENJPA-61.patch > > > A discussion on the dev mailing list indicates that OpenJPA currently does > not utilize the TransactionSynchronizationRegistry. Although OpenJPA does > provide other means of finding and accessing the various TransactionManagers, > we should update OpenJPA to use the standard interfaces. Following are the > two notes on this subject... > > > o David Jencks <[EMAIL PROTECTED]> to open-jpa-dev More options > Sep 27 (19 hours ago) > I'm trying to get openjpa running in geronimo and wonder how openjpa > locates the TransactionSynchronizationRegistry. Grep'ing for > TransactionSynchronizationRegistry I don't see it used anywhere in > the code base. What am I missing? > thanks > david jencks > > o Marc Prud'hommeaux to open-jpa-dev More options Sep 27 (19 > hours ago) > David- > We don't use TransactionSynchronizationRegistry (not yet, at least). > Instead, we manually locate the TransactionManager via appserver- > specific heuristics defined in openjpa-kernel/src/main/java/org/ > apache/openjpa/ee/AutomaticManagedRuntime.java > If the Geronimo TransactionManager is accessible from JNDI or some > method invocation, you can just add it into AutomaticManagedRuntime > as a default (you can test it out by specifying the > "openjpa.ManagedRuntime" property to "jndi > (TransactionManagerName=java:/GeronimoJNDINameForTransactionManager)". > We may add support for integration via > TransactionSynchronizationRegistry in the future, but the fact that > it doesn't provide support for accessing the current Transaction > would mean that we would need to rework some OpenJPA internals. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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_12496566
]
Michael Dick commented on OPENJPA-206:
--
Unfortunately I did mean to use two transactions and I haven't been able to
find a workaround that doesn't. I'll keep looking for the real fix.
> 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. Modify FunInheritanceJava/src/META-INF/applicationcontext-jpa.xml to set
> the correct dataSource class, user, password, and currentSchema.
> 3. Modify FunInheritanceJava/database/createtables.sql to set current schema
> to matc
[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 O
[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] Commented: (OPENJPA-61) Missing usage of TransactionSynchronizationRegistry
[ https://issues.apache.org/jira/browse/OPENJPA-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491409 ] Michael Dick commented on OPENJPA-61: - Marc, I started testing this with the WebSphere EJB3 feature pack. So far I haven't found any bugs, but I've really only run a few simple tests. I'll add more comments to the JIRA when I've tested it more thoroughly. > Missing usage of TransactionSynchronizationRegistry > --- > > Key: OPENJPA-61 > URL: https://issues.apache.org/jira/browse/OPENJPA-61 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Reporter: Kevin Sutter > Assigned To: Kevin Sutter > Fix For: 1.1.0 > > Attachments: OPENJPA-61.patch > > > A discussion on the dev mailing list indicates that OpenJPA currently does > not utilize the TransactionSynchronizationRegistry. Although OpenJPA does > provide other means of finding and accessing the various TransactionManagers, > we should update OpenJPA to use the standard interfaces. Following are the > two notes on this subject... > > > o David Jencks <[EMAIL PROTECTED]> to open-jpa-dev More options > Sep 27 (19 hours ago) > I'm trying to get openjpa running in geronimo and wonder how openjpa > locates the TransactionSynchronizationRegistry. Grep'ing for > TransactionSynchronizationRegistry I don't see it used anywhere in > the code base. What am I missing? > thanks > david jencks > > o Marc Prud'hommeaux to open-jpa-dev More options Sep 27 (19 > hours ago) > David- > We don't use TransactionSynchronizationRegistry (not yet, at least). > Instead, we manually locate the TransactionManager via appserver- > specific heuristics defined in openjpa-kernel/src/main/java/org/ > apache/openjpa/ee/AutomaticManagedRuntime.java > If the Geronimo TransactionManager is accessible from JNDI or some > method invocation, you can just add it into AutomaticManagedRuntime > as a default (you can test it out by specifying the > "openjpa.ManagedRuntime" property to "jndi > (TransactionManagerName=java:/GeronimoJNDINameForTransactionManager)". > We may add support for integration via > TransactionSynchronizationRegistry in the future, but the fact that > it doesn't provide support for accessing the current Transaction > would mean that we would need to rework some OpenJPA internals. > -- 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] Updated: (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 updated OPENJPA-222: - Attachment: JIRA182-subselect.patch Attaching Ritika's patch here. > 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 > 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] 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-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] 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.(OpenJPAConfigurationImpl.java:182) > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:154) > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:145) > at > org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.(PersistenceProviderImpl.java:114) > at > org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.(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
[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.(OpenJPAConfigurationImpl.java:182) > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:154) > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:145) > at > org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.(PersistenceProviderImpl.java:114) > at > org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.(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 > org.
[jira] Assigned: (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:all-tabpanel ] Michael Dick reassigned OPENJPA-213: Assignee: Michael Dick > @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] Updated: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-182: - Fix Version/s: 0.9.7 > db2 update lock syntax WITH 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 > Fix For: 0.9.7 > > Attachments: OPENJPA-182.patch, openJPA182.patch, > openjpa182TestCase.jar > > > 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] Commented: (OPENJPA-182) db2 update lock syntax WITH 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 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] 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 > > 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"> > > > DefSchema > > > > > > > > > > > > > > > > > The default schema will be applied to MyEntityWithTable, but will not be > applied to MyEntity. The same applies if the xml looks like this : > > 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"> > DefSchema > . . . > > 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 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] Assigned: (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 reassigned OPENJPA-179: Assignee: Michael Dick > 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 > > 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"> > > > DefSchema > > > > > > > > > > > > > > > > > The default schema will be applied to MyEntityWithTable, but will not be > applied to MyEntity. The same applies if the xml looks like this : > > 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"> > DefSchema > . . . > > 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 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] 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] 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] Updated: (OPENJPA-194) Correct suffixes of build artifacts to elimiate '-all' and '-project'
[
https://issues.apache.org/jira/browse/OPENJPA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dick updated OPENJPA-194:
-
Attachment: OpenJPA-194-1.patch.txt
The attached patch should resolve the first part of the problem. It's just a
matter of adding
openjpa-${version}.${extension}
to the assembly xml file.
I'm not sure about the second part of the problem. There should be a similar
way to override the -project suffix, but I haven't been able to find it.
HTH, sorry if I'm butting in.
> Correct suffixes of build artifacts to elimiate '-all' and '-project'
> -
>
> Key: OPENJPA-194
> URL: https://issues.apache.org/jira/browse/OPENJPA-194
> Project: OpenJPA
> Issue Type: Sub-task
> Components: build / infrastructure
>Affects Versions: 0.9.0, 0.9.6
>Reporter: Marc Prud'hommeaux
> Assigned To: Marc Prud'hommeaux
>Priority: Minor
> Fix For: 0.9.7
>
> Attachments: OpenJPA-194-1.patch.txt
>
>
> The aggregate jar that is built with OpenJPA is currently named
> "openjpa-all-0.9.7-VERSION.jar". It would be nice to change this to be just
> "openjpa-0.9.7-VERSION.jar".
--
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-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-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] 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] 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 " 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 "". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (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 updated OPENJPA-179: - Attachment: OpenJPA-179-example.zip Attaching simple example. Contains a test which just drives some SQL statements which show the default schema is only used if I define a table in orm.xml. > 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 > > 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 > > 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"> > > > DefSchema > > > > > > > > > > > > > > > > > The default schema will be applied to MyEntityWithTable, but will not be > applied to MyEntity. The same applies if the xml looks like this : > > 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"> > DefSchema > . . . > > 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 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-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 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"> DefSchema The default schema will be applied to MyEntityWithTable, but will not be applied to MyEntity. The same applies if the xml looks like this : 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"> DefSchema . . . 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 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-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:all-tabpanel
]
Michael Dick updated OPENJPA-132:
-
Attachment: OpenJPA-132.patch.txt
Attaching a patch.
The patch includes a new Id class for java.sql.Date and the appropriate hooks
so that if will be used.
I chose to move the SQL_DATE constant from JavaSQLTypes to its superclass
JavaTypes. The constant for java.sql.Date needed to be visible to the classes
in openjpa-kernel and I didn't see a reason to have define two constants.
The remainder of the changes are fairly straightforward whenever there is
special processing for java.util.Date I did the same thing for java.sql.Date.
I'll attach testcases separately, this is probably a big enough patch file to
review and the tests need a little cleaning up.
> 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] 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_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] 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-160) Reuse BrokerImpl objects
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-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-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] 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) 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 :
/
false
runtime
openjpa-${version}.${extension}
org.apache.openjpa: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
>
> 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-76) add-was-interfaces ant task throws exception on a "non-clean" build.
[ http://issues.apache.org/jira/browse/OPENJPA-76?page=all ]
Michael Dick updated OPENJPA-76:
Attachment: openjpa-76-patch.txt
Attaching a patch file which avoids the problem (at least for the time being).
The problem occurs when the new BCClass is written out to the file system. The
patch will check whether the interface is already included in the class. If the
"new" interface is already there the program will terminate.
The larger question remains: should Serp be used in this manner, or should a
stub class be created and used at compile time. Currently a stub class for
misc.sun.Perf is being created in the openjpa-lib project, but is removed
before the jar files are created and is not distributed with OpenJPA.
> 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
> Attachments: openjpa-76-patch.txt
>
>
> 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-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] Commented: (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=comments#action_12440779 ]
Michael Dick commented on OPENJPA-65:
-
Kevin found a bug in the patch and removed it on Friday afternoon.
Removing the modules from the zip file was the easy part, no problems there.
Removing the -all suffix from openjpa-all.jar was trickier. I was able to
create the jar, but maven renames it when when the jar is installed to the
local repository. I can package the "right" jar in the .zip fairly easily, but
I can't change the jar that gets installed in the local repository.
I've come up wtih a few options, but I'm not thrilled with them :
1.) Just change the file that gets put in the zip file. This will work, but I
don't like having two names for the same jar (I can be over ruled though).
2.) Create the jar in the openjpa project instead of the openjpa-all project.
I'm not sure how this will work out since I haven't tried it. It looks like it
will resolve the maven repository issue, but I think there might be ordering
problems.
3.) Leave openjpa-all-${version} alone and just remove the modules.
There might be other options that I haven't found yet (I'm open to suggestions).
> 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] 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] Resolved: (OPENJPA-34) Problem detecting parent's access type with runtime enhancement.
[ http://issues.apache.org/jira/browse/OPENJPA-34?page=all ] Michael Dick resolved OPENJPA-34. - Resolution: Fixed Appears to be resolved (not sure which change fixed it though). > 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 admin
[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, s
[jira] Commented: (OPENJPA-24) Allow OpenJPA to be extensible
[ http://issues.apache.org/jira/browse/OPENJPA-24?page=comments#action_12436086 ] Michael Dick commented on OPENJPA-24: - It looks like creating an extension is fairly straight forward. With the changes Pinaki committed yesterday I was able to create a simple test extension. All I did was create three classes, a ProductDerivation, a PersistenceProvider, and a ConfigurationProvider. I extended PersistenceProductDerivation, PersistenceProviderImpl and ConfigurationImpl respectively, although I suppose one could write their own if they really wanted/needed to. To get a fairly simple wrapper extension working all I had to do was override : ProductDerivation.newConfigurationProvider() , and ConfigurationProvider.getPersistenceProviderName(). I didn't see any methods in PersistenceProviderImpl that I needed to change. The last thing I did was register the ProductDerivation and PersistenceProvider as services, and update persistence.xml (specifying the new PersistenceProvider for my persistent unit). After that the new PersistenceProvider, etc. were used and generated the configuration appropriately (as far as I can tell). Each ProductDerivation is called to load a ConfigurationProvider until the first non-null ConfigurationProvider is found. The ConfigProvider and PersistenceProvider need to match and so forth. Is there anything glaring that I missed? Admittedly all I did was a proof of concept. For a real world extension like Kodo 4.1 there will be other bits to change, changing the default properties in ConfigurationProvider.loadGlobals() for example. I'm sure Pinaki will have a more information and a more robust example. One other thing I wasn't clear on is the type for the extension (TYPE_SPEC, TYPE_PRODUCT,etc). My first guess is that any extensions would use TYPE_PRODUCT (value 100), but I could see it being TYPE_PRODUCT_STORE as well. PersistenceProductDerivation is TYPE_SPEC (value 0) and the ProductDerivations are sorted in ascending order. If extensions are of TYPE_PRODUCT then the default Apache derivation will always be checked first. If we assume that when an extension is present it will be used more often than the default we might want to have any extensions' derivations called first. That's all I found. I didn't mean to steal Pinaki's thunder, just wanted to show that someone else has had some success. > 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
[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 > 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 > 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
[jira] Created: (OPENJPA-12) Default to strictIdentityTypes for JPA
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 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 -- 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
