Re: problems building 0.9.7
Hi Roger 1) Should have been fixed by revision 527750. I didn't commit those changes right away though, so you might just need to run svn update. 2) I just extracted 0.9.7-incubating from svn and it built for me. Has anyone else built the branch recently? I'll take a closer look in the morning. 3) This is a known issue http://issues.apache.org/jira/browse/OPENJPA-5 - however it needs to be added to BUILDING.txt, and RELEASE-NOTES.html before we finalize release 0.9.7. Thank you for reminding me. On 4/11/07, roger.keays <[EMAIL PROTECTED]> wrote: A couple of observations: 1) the 0.9.7-incubating-RC1 branch has 0.9.8-incubating in the pom 2) I get test errors building the 0.9.7-incubating branch (see below) 3) I can't build with jdk1.6 The test errors are: testGetReference( org.apache.openjpa.persistence.inheritance.TestSharedMappedSuperclassIdValue ) Time elapsed: 0.126 sec <<< ERROR! java.lang.NoSuchFieldError: pcFlags at org.apache.openjpa.persistence.inheritance.MappedSuperclassL2.pcNewInstance (MappedSuperclassL2.java) at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:108) at org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1685) at org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1567) at org.apache.openjpa.meta.MetaDataRepository.processBuffer( MetaDataRepository.java:656) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta( MetaDataRepository.java:556) at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java :481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData( MetaDataRepository.java:285) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta( MetaDataRepository.java:521) at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java :481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData( MetaDataRepository.java:285) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2375) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2228) at org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java :1007) at org.apache.openjpa.persistence.EntityManagerImpl.persist( EntityManagerImpl.java:538) at org.apache.openjpa.persistence.inheritance.TestSharedMappedSuperclassIdValue.setUp (TestSharedMappedSuperclassIdValue.java:47) at junit.framework.TestCase.runBare(TestCase.java:125) testFind( org.apache.openjpa.persistence.inheritance.TestSharedMappedSuperclassIdValue ) Time elapsed: 0.291 sec <<< ERROR! java.lang.NoSuchFieldError: pcFlags at org.apache.openjpa.persistence.inheritance.MappedSuperclassL2.pcNewInstance (MappedSuperclassL2.java) at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:108) at org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1685) at org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1567) at org.apache.openjpa.meta.MetaDataRepository.processBuffer( MetaDataRepository.java:656) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta( MetaDataRepository.java:556) at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java :481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData( MetaDataRepository.java:285) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta( MetaDataRepository.java:521) at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java :481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData( MetaDataRepository.java:285) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2375) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2228) at org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java :1007) at org.apache.openjpa.persistence.EntityManagerImpl.persist( EntityManagerImpl.java:538) at org.apache.openjpa.persistence.inheritance.TestSharedMappedSuperclassIdValue.setUp (TestSharedMappedSuperclassIdValue.java:47) at junit.framework.TestCase.runBare(TestCase.java:125) testPersist( org.apache.openjpa.persistence.inheritance.TestMultipleMappedSuperclassHierarchy ) Time elapsed: 0.17 sec <<< ERROR! <0.0.0 fatal general error> org.apache.openjpa.persistence.PersistenceException: null at org.apache.openjpa.jdbc.meta.Discriminator.assertStrategy( Discriminator.java:406) at org.apache.openjpa.jdbc.meta.Discriminator.select(Discriminator.java:382) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.selectBaseMappings( JDBCStoreManager.java:1017) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.select( JDBCStoreManager.java:882) at org.apache.openjpa.jdbc.sql.SelectImpl.select(SelectImpl.java:794) at org.apache.openjpa.jdbc.sql.SelectImpl.selectIdentifi
problems building 0.9.7
A couple of observations: 1) the 0.9.7-incubating-RC1 branch has 0.9.8-incubating in the pom 2) I get test errors building the 0.9.7-incubating branch (see below) 3) I can't build with jdk1.6 The test errors are: testGetReference(org.apache.openjpa.persistence.inheritance.TestSharedMappedSuperclassIdValue) Time elapsed: 0.126 sec <<< ERROR! java.lang.NoSuchFieldError: pcFlags at org.apache.openjpa.persistence.inheritance.MappedSuperclassL2.pcNewInstance(MappedSuperclassL2.java) at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:108) at org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1685) at org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1567) at org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:656) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:556) at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:285) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:521) at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:285) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2375) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2228) at org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java:1007) at org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerImpl.java:538) at org.apache.openjpa.persistence.inheritance.TestSharedMappedSuperclassIdValue.setUp(TestSharedMappedSuperclassIdValue.java:47) at junit.framework.TestCase.runBare(TestCase.java:125) testFind(org.apache.openjpa.persistence.inheritance.TestSharedMappedSuperclassIdValue) Time elapsed: 0.291 sec <<< ERROR! java.lang.NoSuchFieldError: pcFlags at org.apache.openjpa.persistence.inheritance.MappedSuperclassL2.pcNewInstance(MappedSuperclassL2.java) at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:108) at org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1685) at org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1567) at org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:656) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:556) at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:285) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:521) at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:285) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2375) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2228) at org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java:1007) at org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerImpl.java:538) at org.apache.openjpa.persistence.inheritance.TestSharedMappedSuperclassIdValue.setUp(TestSharedMappedSuperclassIdValue.java:47) at junit.framework.TestCase.runBare(TestCase.java:125) testPersist(org.apache.openjpa.persistence.inheritance.TestMultipleMappedSuperclassHierarchy) Time elapsed: 0.17 sec <<< ERROR! <0.0.0 fatal general error> org.apache.openjpa.persistence.PersistenceException: null at org.apache.openjpa.jdbc.meta.Discriminator.assertStrategy(Discriminator.java:406) at org.apache.openjpa.jdbc.meta.Discriminator.select(Discriminator.java:382) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.selectBaseMappings(JDBCStoreManager.java:1017) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.select(JDBCStoreManager.java:882) at org.apache.openjpa.jdbc.sql.SelectImpl.select(SelectImpl.java:794) at org.apache.openjpa.jdbc.sql.SelectImpl.selectIdentifier(SelectImpl.java:842) at org.apache.openjpa.jdbc.sql.SelectImpl.selectIdentifier(SelectImpl.java:836) at org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.select(SelectConstructor.java:263) at org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeBulkOperation(JDBCStoreQuery.java:467) at org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeDelete(JDBCStoreQuery.java:420) at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:679) at org.apache.openjpa.kernel.QueryImpl.delete
Re: Shared classloader and subclasses
Abe White wrote:
>
> I've committed an equivalent patch to 0.9.7 in SVN revision 522623.
> Can you confirm whether this fixes your problem and, if so, close any
> CR you might have opened on this?
>
I've tested with /branches/0.9.7-incubating:527748 and it seems fine.
>> This works for me :) Here's a patch for 0.9.6 source. I've gone for
>> the
>> simplest solution, but it might be improved by looping over pcNames
>> instead
>> of _registered (?).
>>
>> http://www.nabble.com/file/7398/openjpa-diff openjpa-diff
>>
>> Index: MetaDataRepository.java
>> ===
>> --- MetaDataRepository.java
>> (.../tags/0.9.6/openjpa-kernel/src/main/java/org/apache/openjpa/meta)
>> (revision 3)
>> +++ MetaDataRepository.java
>> (.../branches/0.9.6-ninthavenue/openjpa-kernel/src/main/java/org/
>> apache/openjpa/meta)
>> (working copy)
>> @@ -302,7 +302,7 @@
>> return null;
>>
>> // check cache
>> -processRegisteredClasses();
>> +processRegisteredClasses(envLoader);
>> List classList = (List) _aliases.get(alias);
>>
>> // multiple classes may have been defined with the same
>> alias: we
>> @@ -928,7 +928,7 @@
>> }
>>
>> // check cache
>> -processRegisteredClasses();
>> +processRegisteredClasses(envLoader);
>> Class cls = (Class) _oids.get(oid.getClass());
>> if (cls != null)
>> return getMetaData(cls, envLoader, mustExist);
>> @@ -944,7 +944,7 @@
>> // if still not match, register any classes that look
>> similar to
>> the
>> // oid class and check again
>> resolveIdentityClass(oid);
>> -if (processRegisteredClasses().length > 0) {
>> +if (processRegisteredClasses(envLoader).length > 0) {
>> cls = (Class) _oids.get(oid.getClass());
>> if (cls != null)
>> return getMetaData(cls, envLoader, mustExist);
>> @@ -1262,7 +1262,7 @@
>> * Parses the metadata for all registered classes.
>> */
>> private void loadRegisteredClassMetaData(ClassLoader envLoader) {
>> -Class[] reg = processRegisteredClasses();
>> +Class[] reg = processRegisteredClasses(envLoader);
>> for (int i = 0; i < reg.length; i++) {
>> try {
>> getMetaData(reg[i], envLoader, false);
>> @@ -1276,7 +1276,7 @@
>> /**
>> * Updates our datastructures with the latest registered classes.
>> */
>> -Class[] processRegisteredClasses() {
>> +Class[] processRegisteredClasses(ClassLoader envLoader) {
>> if (_registered.isEmpty())
>> return EMPTY_CLASSES;
>>
>> @@ -1289,9 +1289,18 @@
>> }
>>
>> Collection failed = null;
>> +Collection pcNames = getPersistentTypeNames(false,
>> envLoader);
>> for (int i = 0; i < reg.length; i++) {
>> try {
>> -processRegisteredClass(reg[i]);
>> +
>> +/*
>> + * Only process classes known to this
>> MetaDataRepository,
>> + * since _registered contains all classes loaded by
>> + * PCRegistry.
>> + */
>> +if (pcNames.contains(reg[i].getName())) {
>> +processRegisteredClass(reg[i]);
>> +}
>> } catch (Throwable t) {
>> if (!_conf.getRetryClassRegistration())
>> throw new
>> MetaDataException(_loc.get("error-registered",
>> Index: ClassMetaData.java
>> ===
>> --- ClassMetaData.java
>> (.../tags/0.9.6/openjpa-kernel/src/main/java/org/apache/openjpa/meta)
>> (revision 4)
>> +++ ClassMetaData.java
>> (.../branches/0.9.6-ninthavenue/openjpa-kernel/src/main/java/org/
>> apache/openjpa/meta)
>> (working copy)
>> @@ -309,7 +309,7 @@
>> if (_owner != null)
>> return _repos.EMPTY_CLASSES;
>>
>> -_repos.processRegisteredClasses();
>> +_repos.processRegisteredClasses(getEnvClassLoader());
>> if (_subs == null) {
>> Collection subs = _repos.getPCSubclasses(_type);
>> _subs = (Class[]) subs.toArray(new Class[subs.size()]);
>>
>> --
>> View this message in context: http://www.nabble.com/Shared-
>> classloader-and-subclasses-tf3431312.html#a9655900
>> Sent from the open-jpa-dev mailing list archive at Nabble.com.
>>
>
> ___
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message
[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_12488233 ] david zhang commented on OPENJPA-211: - Please take a look at the latest applicationContext.xml and persistence.xml. BTW, Hibernate use the same concept, but it works on every environment, OpenJPA doesn't work on my environment. > 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.getBeansOfType(DefaultListableBeanFactory.java:233) > at > org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:205) > at > org.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAncestors(BeanFactoryUtils.java:292) > at > org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDef
[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_12488232 ] david zhang commented on OPENJPA-211: - No use, test on both WAS test environment and WAS standalone server, change the web classloader both to parent_first, parent_last. Still got the java.lang.IllegalArgumentException from code: rval = (byte[]) _getGlobalId.invoke(_extendedTransaction, null);. WAS: 6.0.3 with EJB Alpha, Spring 2.0.3(the latest release), OpenJPA 0.96. please take look at my applicationContext.xml and persistence.xml, please. > 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.getBeansOfType(DefaultListableBeanFactory.java:233) > at > org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:20
[jira] Updated: (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:all-tabpanel ] david zhang updated OPENJPA-211: Attachment: persistence.xml applicationContext.xml > 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.getBeansOfType(DefaultListableBeanFactory.java:233) > at > org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:205) > at > org.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAncestors(BeanFactoryUtils.java:292) > at > org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:411) > at > org.springframework.orm.jpa.support.PersistenceAnnotationBeanP
[jira] Created: (OPENJPA-215) unneeded left join SQL for queries with inner join fetch, related to issue OPENJPA-134
unneeded left join SQL for queries with inner join fetch, related to issue OPENJPA-134 Key: OPENJPA-215 URL: https://issues.apache.org/jira/browse/OPENJPA-215 Project: OpenJPA Issue Type: Bug Components: sql Affects Versions: 0.9.6, 0.9.7, 0.9.8 Reporter: Catalina Wei In verifying fixes for issue OPEN-134, found an outstanding problem. Extra unneeded join generated for the following query with inner join fetch while left join fetch generates correct SQL: select o from Order o inner join fetch o.lineitems the generated SQL has an extra left join that causes the result set empty, I will create a new JIRA issue for this problem: 1297 demo TRACE [main] openjpa.Query - Executing query: select o from Order o inner join fetch o.lineitems 1297 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 726281034 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t2.order_oid, t2.lid, t2.version, t2.cost, t2.part_partno, t2.quantity FROM TORDER t0 INNER JOIN TORDERITEM t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN TORDERITEM t2 ON t0.oid = t2.order_oid ORDER BY t2.order_oid ASC FOR READ ONLY Abe, I have verified this fix with EagerFetchMode parallel and join. However, there is an outstanding problem for the following query with inner join fetch while left join fetch generates correct SQL: select o from Order o inner join fetch o.lineitems the generated SQL has an extra left join that causes the result set empty, I will create a new JIRA issue for this problem: 1297 demo TRACE [main] openjpa.Query - Executing query: select o from Order o inner join fetch o.lineitems 1297 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 726281034 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t2.order_oid, t2.lid, t2.version, t2.cost, t2.part_partno, t2.quantity FROM TORDER t0 INNER JOIN TORDERITEM t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN TORDERITEM t2 ON t0.oid = t2.order_oid ORDER BY t2.order_oid ASC FOR READ ONLY -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER
Abe, I have verified this fix with EagerFetchMode parallel and join. However, there is an outstanding problem for the following query with inner join fetch while left join fetch generates correct SQL; the inner join fetch generates extra unneeded left join: select o from Order o inner join fetch o.lineitems the generated SQL has an extra left join that causes the result set empty, I will create a new JIRA issue for this problem: 1297 demo TRACE [main] openjpa.Query - Executing query: select o from Order o inner join fetch o.lineitems 1297 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 726281034 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t2.order_oid, t2.lid, t2.version, t2.cost, t2.part_partno, t2.quantity FROM TORDER t0 INNER JOIN TORDERITEM t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN TORDERITEM t2 ON t0.oid = t2.order_oid ORDER BY t2.order_oid ASC FOR READ ONLY Catalina On 4/11/07, Abe White (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/OPENJPA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Abe White resolved OPENJPA-134. --- Resolution: Fixed Assignee: (was: Abe White) Fixed the most egregious issue, which was the cyclic fetching of eager bidirectional relations. Changed to cut off SELECTs when we're traversing the back-ptr to the owning side of a relation we've already fetched. I'm not convinced all the other issues mentioned are bugs given the eager fetch settings used. Please open new JIRAs for any individual issues that you believe remain. Fixed in revision 527565. > Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER > - > > Key: OPENJPA-134 > URL: https://issues.apache.org/jira/browse/OPENJPA-134 > Project: OpenJPA > Issue Type: Bug > Components: sql >Reporter: Catalina Wei > Fix For: 0.9.8 > > > Running JPAConfiguration default setting for EagerFetchMode ( FetchModeValue.EAGER_PARALLEL), > the SQL generated is sub-optimal. > Consider the following entities: > lineitems( OneToMany ) > Order <===> OrderItem > order ( ManyToOne ) > Case 1: why not combining 2 SQL to 1 SQL ? > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o > 2173 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 1299336562 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0 > 2213 demo TRACE [main] openjpa.jdbc.SQL - [40 ms] spent > 2223 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 1406424020 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t1.order_oid, t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oidORDER BY t0.oid ASC > Case 2: extra unneeded LEFT OUTER JOIN, if eliminated, the selection aliase t2 should change to t1: > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o left join fetch o.lineitems > 2403 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 1500797300 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, t2.cost, t2.part_partno, t2.quantity FROM Order t0 LEFT OUTER JOIN OrderItem t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN OrderItem t2 ON t0.oid = t2.order_oid ORDER BY t2.order_oid ASC > Case 3: why not generating 1 SQL ? > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o > 2343 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 384833264 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0 > 2383 demo TRACE [main] openjpa.jdbc.SQL - [40 ms] spent > 2393 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 1722705582 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t2.oid, t2.version, t2.amount, t2.customer_countryCode, t2.customer_id, t2.delivered, t2.shipaddr, t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN Order t2 ON t1.order_oid = t2.oid ORDER BY t0.oid ASC > 2393 demo TRACE [main] openjpa.jdbc.SQL - [0 ms] spent > 3134 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 950548648 > SELECT t0.lid, t0.version, t0.cost, t1.oid, t1.version, t1.amount, t1
Re: Open JPA error-Could not locate metadata for the class using alias
Isn't it called an entity name in the JPA spec?
thanks,
-marina
Pinaki Poddar wrote:
Persistent Java classes when used in Query use an alias (which is, be
deafult, the unqualified name of the Java class). However, the alias is
known to the runtime once the Java class is loaded in to JVM. When the
very first JPA operation is a query and the persistence unit does not
explictly declare all the persistent classes, the runtime is not yet
aware of/registered the aliases. Hence the error.
possible resolution:
a) declare the persistent classes in tag of persistence.xml
b) load the class before using it -- e.g. call
Class.forName("a.b.c.MyClass")
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: saidulu chitipolu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 1:23 PM
To: open-jpa-dev@incubator.apache.org
Subject: Open JPA error-Could not locate metadata for the class using
alias
Hi,
I am trying to run standalone application access the database using
spring ,openjpa.
part of code in main method
EntityManagerFactory factory =
Persistence.createEntityManagerFactory("tsf");
EntityManager em = factory.createEntityManager();
System.out.println("--/ "+em);
Query q = em.createQuery("select m from AbstractItemEntity m");
List absEntity=q.getResultList();
facing the problem at
Query q = em.createQuery("select m from AbstractItemEntity m");
we have persistance.xml and orm files.
Log is as like below
your earliest suggetions are valuable
110 INFO [main] openjpa.Runtime - Starting OpenJPA 0.9.6-incubating
422 INFO [main] openjpa.jdbc.JDBC - Using dictionary class
"org.apache.openjpa.jdbc.sql.OracleDictionary".
766 INFO [main] openjpa.MetaData - Found 10 classes with metadata
in 31 milliseconds.
--/ [EMAIL PROTECTED]
Exception in thread "main" <4|true|0.9.6-incubating>
org.apache.openjpa.persistence.ArgumentException: Could not locate
metadata for the class using alias "AbstractItemEntity". Registered
alias mappings: "{AbstractItemEntity=null}"
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
y.java:343)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JP
QLExpressionBuilder.java:164)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaDat
a(JPQLExpressionBuilder.java:142)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaDat
a(JPQLExpressionBuilder.java:211)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaDat
a(JPQLExpressionBuilder.java:181)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JP
QLExpressionBuilder.java:174)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpr
essionBuilder.java:61)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate
(JPQLExpressionBuilder.java:1657)
at
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:52)
at
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(E
xpressionStoreQuery.java:145)
at
org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:642)
at
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:
623)
at
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java
:589)
at
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:65
1)
at
org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1464)
at
org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.j
ava:120)
at
org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:202)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:25
1)
at com.symcor.sis.tecp.dao.ExecuteDB.main(ExecuteDB.java:35)
-
Check out what you're missing if you're not on Yahoo! Messenger
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
Re: Float primary key?
On Apr 11, 2007, at 7:28 AM, Kevin Sutter wrote: Okay, I looked at the spec a bit closer and it looks like we need to allow for floats as primary keys: "The primary key (or field or property of a composite primary key) should be one of the following types: any Java primitive type; any primitive wrapper type; java.lang.String; java.util.Date; java.sql.Date. In general, however, approximate numeric types (e.g., floating point types) should never be used in primary keys." Although the spec clearly recommends against the use of floating points, floats are a primitive type (or the Float wrapper) and need to be allowed. With no special "AllowStupidApproximatePrimaryKeys" flag. :-) Am I trying to read too much into the spec or Dain's request? This seems to be something that we need to support. That's all I needed. Thanks, -dain
RE: Testing an OpenJPA module
Yes Sir, fully agree. Thought of a) adding a Map, Exception> to capture all the different (blank) catch blocks when a provider is initialized and report it as warning. b) change return type and exception handling of findAllProviders() I will post another patch to say what I mean in code. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey Sent: Wednesday, April 11, 2007 6:05 PM To: open-jpa-dev@incubator.apache.org Cc: cmp-dev Subject: RE: Testing an OpenJPA module Hi, Pinaki's change is a big improvement. I think that we can even go a bit further by returning a List from findAllProviders(), and then if the EMF lookup fails, we can include those exceptions in the PersistenceException that is returned. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Pinaki Poddar > Sent: Wednesday, April 11, 2007 3:55 PM > To: open-jpa-dev@incubator.apache.org > Cc: cmp-dev > Subject: RE: Testing an OpenJPA module > > Hello Craig, >Done. >Thanks for your advice. > >Please review: > https://glassfish.dev.java.net/issues/show_bug.cgi?id=2814 > > Pinaki Poddar > BEA Systems > 415.402.7317 > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 11, 2007 5:11 PM > To: open-jpa-dev@incubator.apache.org > Cc: cmp-dev > Subject: Re: Testing an OpenJPA module > > Hi Pinaki, > > On Apr 10, 2007, at 6:44 PM, Pinaki Poddar wrote: > > >> provide a patch. > > Will such a patch be given to Glassfish project? > > But some kind of committer-level privilege will be required, i > > suppose. > > > > have added few more informative messages to distinguish between > > different ways persistence unit creation/ lookup can fail. > > please advise on how to proceed on contributing a patch. > > This is great. Can you please file a Glassfish/persistence issue in > their issue tracker and attach your patch? If you have trouble doing > this, I'll be glad to help some more... > > Thanks! > > Craig > > > > > > Pinaki Poddar > > BEA Systems > > 415.402.7317 > > > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, April 10, 2007 4:14 PM > > To: open-jpa-dev@incubator.apache.org > > Subject: Re: Testing an OpenJPA module > > > > FYI, Persistence is an open source project at Glassfish. > > > > Anyone, even an OpenJPA contributor, who wants to contribute to the > > project for example to improve the error messages, is > welcome to look > > at the sources and provide a patch. I know people who will > be happy to > > > commit usability patches. ;-) > > > > Craig > > > > On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: > > > >> The error message could have been more specific in the > following way: > >> a) no META-INF/persistence.xml has not been found in classpath > >> b) META-INF/persistence.xml has been found but there is no 'ode- > >> store' > >> unit defined in it. > >> c) META-INF/persistence.xml has been found but provider > can not be > >> loaded/invoked > >> > >> When I first encountered this error, my interpreation was (b) from > >> the way the message was worded. > >> > >> > >> Pinaki Poddar > >> BEA Systems > >> 415.402.7317 > >> > >> > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jacek > > >> Laskowski > >> Sent: Tuesday, April 10, 2007 2:52 PM > >> To: open-jpa-dev@incubator.apache.org > >> Subject: Re: Testing an OpenJPA module > >> > >> On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: > >>> > >>> Glad you got it fixed. It's annoying that > >>> javax.persistence.Persistence doesn't provide more of a > clue as to > >>> why > >> > >>> it failed. > >> > >> I wonder what else you'd like to see other than what's already > >> printed out? It tells exactly why it's failed - "No Persistence > >> provider for EntityManager named ode-store" is just a JPA > version of > >> "NoClassDefFoundError" in "pure" Java. > >> > >> Jacek > >> > >> -- > >> Jacek Laskowski > >> http://www.JacekLaskowski.pl > >> > >> Notice: This email message, together with any attachments, may > >> contain information of BEA Systems, Inc., its > subsidiaries and > >> affiliated entities, that may be confidential, proprietary, > >> copyrighted and/or legally privileged, and is intended solely for > >> the use of the individual or entity named in this mess
Re: OPENJPA-134 and the 0.9.7 release
On 4/11/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > > 1. How good is the patch? Has it been put through whatever extensive > > Unit Tests tests anyone has? > > It passes all the OpenJPA tests against Derby and HSQL. It also passes > some other integration tests as well. It also works with DB2. I haven't been able to check out the performance benchmark yet, but functionally, it looks good. > 2. How easy is it to respin the release? I'd hope that this is a > > matter of a few hours but I'm not the one doing the work ;-) > > It shouldn't be hard. Grabbing the feature is probably the harder part, > and making the decision about whether to just throw away the branch and > re-branch or pick up the one feature. I've already started this conversation with Mike. He agrees that it's probably the right thing to do (to pick up openjpa-134), so he's willing to eat the extra work. It actually shouldn't be too bad. I'm going to start over from with a new openjpa-0.9.7-RC1 branch though - might as well get the rest of the fixes too. Kevin > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 11, 2007 2:32 PM > > To: open-jpa-dev@incubator.apache.org > > Subject: Re: OPENJPA-134 and the 0.9.7 release > > > > Generally in favor of including this performance patch with the > > release. Just a few questions: > > > > 1. How good is the patch? Has it been put through whatever extensive > > Unit Tests tests anyone has? > > > > 2. How easy is it to respin the release? I'd hope that this is a > > matter of a few hours but I'm not the one doing the work ;-) > > > > Procedurally there is no issue since Mike hasn't yet called > > for a vote. > > > > I'd be happy if the patch were included in the release candidate > > because it's the release candidate that the community should be > > testing. And if this patch has any issues, we'll hear about it. > > > > Craig > > > > On Apr 11, 2007, at 2:09 PM, Kevin Sutter wrote: > > > > > Question... > > > > > > Now that Abe has graciously resolved OpenJPA-134 ( > > > https://issues.apache.org/jira/browse/OPENJPA-134), I would really > > > like to > > > see this get included into the 0.9.7 release. This fix looks to > > > resolve the > > > redundant sql joins that were dogging the performance of certain > > > benchmarks. By including this fix in the 0.9.7 release, I think > > > our OpenJPA > > > story would be all that much better. > > > > > > Since we haven't started a vote yet, are there any issues > > with either > > > re-cutting the 0.9.7 branch or applying Abe's fix to the 0.9.7 > > > branch before > > > starting a vote? I would assume that neither of these options > > > would cause > > > much headache for Mike (famous last words)... > > > > > > Kevin > > > > Craig Russell > > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > > 408 276-5638 mailto:[EMAIL PROTECTED] > > P.S. A good JDO? O, Gasp! > > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual or > entity named in this message. If you are not the intended recipient, and > have received this message in error, please immediately return this by email > and then delete it. > -- -Michael Dick
RE: Testing an OpenJPA module
Hi, Pinaki's change is a big improvement. I think that we can even go a bit further by returning a List from findAllProviders(), and then if the EMF lookup fails, we can include those exceptions in the PersistenceException that is returned. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Pinaki Poddar > Sent: Wednesday, April 11, 2007 3:55 PM > To: open-jpa-dev@incubator.apache.org > Cc: cmp-dev > Subject: RE: Testing an OpenJPA module > > Hello Craig, >Done. >Thanks for your advice. > >Please review: > https://glassfish.dev.java.net/issues/show_bug.cgi?id=2814 > > Pinaki Poddar > BEA Systems > 415.402.7317 > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 11, 2007 5:11 PM > To: open-jpa-dev@incubator.apache.org > Cc: cmp-dev > Subject: Re: Testing an OpenJPA module > > Hi Pinaki, > > On Apr 10, 2007, at 6:44 PM, Pinaki Poddar wrote: > > >> provide a patch. > > Will such a patch be given to Glassfish project? > > But some kind of committer-level privilege will be required, i > > suppose. > > > > have added few more informative messages to distinguish between > > different ways persistence unit creation/ lookup can fail. > > please advise on how to proceed on contributing a patch. > > This is great. Can you please file a Glassfish/persistence issue in > their issue tracker and attach your patch? If you have trouble doing > this, I'll be glad to help some more... > > Thanks! > > Craig > > > > > > Pinaki Poddar > > BEA Systems > > 415.402.7317 > > > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, April 10, 2007 4:14 PM > > To: open-jpa-dev@incubator.apache.org > > Subject: Re: Testing an OpenJPA module > > > > FYI, Persistence is an open source project at Glassfish. > > > > Anyone, even an OpenJPA contributor, who wants to contribute to the > > project for example to improve the error messages, is > welcome to look > > at the sources and provide a patch. I know people who will > be happy to > > > commit usability patches. ;-) > > > > Craig > > > > On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: > > > >> The error message could have been more specific in the > following way: > >> a) no META-INF/persistence.xml has not been found in classpath > >> b) META-INF/persistence.xml has been found but there is no 'ode- > >> store' > >> unit defined in it. > >> c) META-INF/persistence.xml has been found but provider > can not be > >> loaded/invoked > >> > >> When I first encountered this error, my interpreation was (b) from > >> the way the message was worded. > >> > >> > >> Pinaki Poddar > >> BEA Systems > >> 415.402.7317 > >> > >> > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jacek > > >> Laskowski > >> Sent: Tuesday, April 10, 2007 2:52 PM > >> To: open-jpa-dev@incubator.apache.org > >> Subject: Re: Testing an OpenJPA module > >> > >> On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: > >>> > >>> Glad you got it fixed. It's annoying that > >>> javax.persistence.Persistence doesn't provide more of a > clue as to > >>> why > >> > >>> it failed. > >> > >> I wonder what else you'd like to see other than what's already > >> printed out? It tells exactly why it's failed - "No Persistence > >> provider for EntityManager named ode-store" is just a JPA > version of > >> "NoClassDefFoundError" in "pure" Java. > >> > >> Jacek > >> > >> -- > >> Jacek Laskowski > >> http://www.JacekLaskowski.pl > >> > >> Notice: This email message, together with any attachments, may > >> contain information of BEA Systems, Inc., its > subsidiaries and > >> affiliated entities, that may be confidential, proprietary, > >> copyrighted and/or legally privileged, and is intended solely for > >> the use of the individual or entity named in this message. > If you are > > >> not the intended recipient, and have received this message > in error, > >> please immediately return this by email and then delete it. > > > > Craig Russell > > Architect, Sun Java Enterprise System > http://java.sun.com/products/jdo > > 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! > > > > > > Notice: This email message, together with any attachments, may > > contain information of BEA Systems, Inc., its subsidiaries > > and affiliated ent
RE: Testing an OpenJPA module
Hello Craig, Done. Thanks for your advice. Please review: https://glassfish.dev.java.net/issues/show_bug.cgi?id=2814 Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 5:11 PM To: open-jpa-dev@incubator.apache.org Cc: cmp-dev Subject: Re: Testing an OpenJPA module Hi Pinaki, On Apr 10, 2007, at 6:44 PM, Pinaki Poddar wrote: >> provide a patch. > Will such a patch be given to Glassfish project? > But some kind of committer-level privilege will be required, i > suppose. > > have added few more informative messages to distinguish between > different ways persistence unit creation/ lookup can fail. > please advise on how to proceed on contributing a patch. This is great. Can you please file a Glassfish/persistence issue in their issue tracker and attach your patch? If you have trouble doing this, I'll be glad to help some more... Thanks! Craig > > > Pinaki Poddar > BEA Systems > 415.402.7317 > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 10, 2007 4:14 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Testing an OpenJPA module > > FYI, Persistence is an open source project at Glassfish. > > Anyone, even an OpenJPA contributor, who wants to contribute to the > project for example to improve the error messages, is welcome to look > at the sources and provide a patch. I know people who will be happy to > commit usability patches. ;-) > > Craig > > On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: > >> The error message could have been more specific in the following way: >> a) no META-INF/persistence.xml has not been found in classpath >> b) META-INF/persistence.xml has been found but there is no 'ode- >> store' >> unit defined in it. >> c) META-INF/persistence.xml has been found but provider can not be >> loaded/invoked >> >> When I first encountered this error, my interpreation was (b) from >> the way the message was worded. >> >> >> Pinaki Poddar >> BEA Systems >> 415.402.7317 >> >> >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek >> Laskowski >> Sent: Tuesday, April 10, 2007 2:52 PM >> To: open-jpa-dev@incubator.apache.org >> Subject: Re: Testing an OpenJPA module >> >> On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: >>> >>> Glad you got it fixed. It's annoying that >>> javax.persistence.Persistence doesn't provide more of a clue as to >>> why >> >>> it failed. >> >> I wonder what else you'd like to see other than what's already >> printed out? It tells exactly why it's failed - "No Persistence >> provider for EntityManager named ode-store" is just a JPA version of >> "NoClassDefFoundError" in "pure" Java. >> >> Jacek >> >> -- >> Jacek Laskowski >> http://www.JacekLaskowski.pl >> >> Notice: This email message, together with any attachments, may >> contain information of BEA Systems, Inc., its subsidiaries and >> affiliated entities, that may be confidential, proprietary, >> copyrighted and/or legally privileged, and is intended solely for >> the use of the individual or entity named in this message. If you are >> not the intended recipient, and have received this message in error, >> please immediately return this by email and then delete it. > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! > > > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries > and affiliated entities, that may be confidential, proprietary, > copyrighted and/or legally privileged, and is intended solely for > the use of the individual or entity named in this message. If you > are not the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: OPENJPA-134 and the 0.9.7 release
> 1. How good is the patch? Has it been put through whatever extensive > Unit Tests tests anyone has? It passes all the OpenJPA tests against Derby and HSQL. It also passes some other integration tests as well. It also works with DB2. I haven't been able to check out the performance benchmark yet, but functionally, it looks good. 2. How easy is it to respin the release? I'd hope that this is a > matter of a few hours but I'm not the one doing the work ;-) It shouldn't be hard. Grabbing the feature is probably the harder part, and making the decision about whether to just throw away the branch and re-branch or pick up the one feature. I've already started this conversation with Mike. He agrees that it's probably the right thing to do (to pick up openjpa-134), so he's willing to eat the extra work. Kevin > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 11, 2007 2:32 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: OPENJPA-134 and the 0.9.7 release > > Generally in favor of including this performance patch with the > release. Just a few questions: > > 1. How good is the patch? Has it been put through whatever extensive > Unit Tests tests anyone has? > > 2. How easy is it to respin the release? I'd hope that this is a > matter of a few hours but I'm not the one doing the work ;-) > > Procedurally there is no issue since Mike hasn't yet called > for a vote. > > I'd be happy if the patch were included in the release candidate > because it's the release candidate that the community should be > testing. And if this patch has any issues, we'll hear about it. > > Craig > > On Apr 11, 2007, at 2:09 PM, Kevin Sutter wrote: > > > Question... > > > > Now that Abe has graciously resolved OpenJPA-134 ( > > https://issues.apache.org/jira/browse/OPENJPA-134), I would really > > like to > > see this get included into the 0.9.7 release. This fix looks to > > resolve the > > redundant sql joins that were dogging the performance of certain > > benchmarks. By including this fix in the 0.9.7 release, I think > > our OpenJPA > > story would be all that much better. > > > > Since we haven't started a vote yet, are there any issues > with either > > re-cutting the 0.9.7 branch or applying Abe's fix to the 0.9.7 > > branch before > > starting a vote? I would assume that neither of these options > > would cause > > much headache for Mike (famous last words)... > > > > Kevin > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: OPENJPA-134 and the 0.9.7 release
> 1. How good is the patch? Has it been put through whatever extensive > Unit Tests tests anyone has? It passes all the OpenJPA tests against Derby and HSQL. It also passes some other integration tests as well. > 2. How easy is it to respin the release? I'd hope that this is a > matter of a few hours but I'm not the one doing the work ;-) It shouldn't be hard. Grabbing the feature is probably the harder part, and making the decision about whether to just throw away the branch and re-branch or pick up the one feature. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 11, 2007 2:32 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: OPENJPA-134 and the 0.9.7 release > > Generally in favor of including this performance patch with the > release. Just a few questions: > > 1. How good is the patch? Has it been put through whatever extensive > Unit Tests tests anyone has? > > 2. How easy is it to respin the release? I'd hope that this is a > matter of a few hours but I'm not the one doing the work ;-) > > Procedurally there is no issue since Mike hasn't yet called > for a vote. > > I'd be happy if the patch were included in the release candidate > because it's the release candidate that the community should be > testing. And if this patch has any issues, we'll hear about it. > > Craig > > On Apr 11, 2007, at 2:09 PM, Kevin Sutter wrote: > > > Question... > > > > Now that Abe has graciously resolved OpenJPA-134 ( > > https://issues.apache.org/jira/browse/OPENJPA-134), I would really > > like to > > see this get included into the 0.9.7 release. This fix looks to > > resolve the > > redundant sql joins that were dogging the performance of certain > > benchmarks. By including this fix in the 0.9.7 release, I think > > our OpenJPA > > story would be all that much better. > > > > Since we haven't started a vote yet, are there any issues > with either > > re-cutting the 0.9.7 branch or applying Abe's fix to the 0.9.7 > > branch before > > starting a vote? I would assume that neither of these options > > would cause > > much headache for Mike (famous last words)... > > > > Kevin > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Testing an OpenJPA module
Hi Pinaki, On Apr 10, 2007, at 6:44 PM, Pinaki Poddar wrote: provide a patch. Will such a patch be given to Glassfish project? But some kind of committer-level privilege will be required, i suppose. have added few more informative messages to distinguish between different ways persistence unit creation/ lookup can fail. please advise on how to proceed on contributing a patch. This is great. Can you please file a Glassfish/persistence issue in their issue tracker and attach your patch? If you have trouble doing this, I'll be glad to help some more... Thanks! Craig Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 4:14 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module FYI, Persistence is an open source project at Glassfish. Anyone, even an OpenJPA contributor, who wants to contribute to the project for example to improve the error messages, is welcome to look at the sources and provide a patch. I know people who will be happy to commit usability patches. ;-) Craig On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode- store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - "No Persistence provider for EntityManager named ode-store" is just a JPA version of "NoClassDefFoundError" in "pure" Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: Open JPA error-Could not locate metadata for the class using alias
Persistent Java classes when used in Query use an alias (which is, be
deafult, the unqualified name of the Java class). However, the alias is
known to the runtime once the Java class is loaded in to JVM. When the
very first JPA operation is a query and the persistence unit does not
explictly declare all the persistent classes, the runtime is not yet
aware of/registered the aliases. Hence the error.
possible resolution:
a) declare the persistent classes in tag of persistence.xml
b) load the class before using it -- e.g. call
Class.forName("a.b.c.MyClass")
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: saidulu chitipolu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 1:23 PM
To: open-jpa-dev@incubator.apache.org
Subject: Open JPA error-Could not locate metadata for the class using
alias
Hi,
I am trying to run standalone application access the database using
spring ,openjpa.
part of code in main method
EntityManagerFactory factory =
Persistence.createEntityManagerFactory("tsf");
EntityManager em = factory.createEntityManager();
System.out.println("--/ "+em);
Query q = em.createQuery("select m from AbstractItemEntity m");
List absEntity=q.getResultList();
facing the problem at
Query q = em.createQuery("select m from AbstractItemEntity m");
we have persistance.xml and orm files.
Log is as like below
your earliest suggetions are valuable
110 INFO [main] openjpa.Runtime - Starting OpenJPA 0.9.6-incubating
422 INFO [main] openjpa.jdbc.JDBC - Using dictionary class
"org.apache.openjpa.jdbc.sql.OracleDictionary".
766 INFO [main] openjpa.MetaData - Found 10 classes with metadata
in 31 milliseconds.
--/ [EMAIL PROTECTED]
Exception in thread "main" <4|true|0.9.6-incubating>
org.apache.openjpa.persistence.ArgumentException: Could not locate
metadata for the class using alias "AbstractItemEntity". Registered
alias mappings: "{AbstractItemEntity=null}"
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
y.java:343)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JP
QLExpressionBuilder.java:164)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaDat
a(JPQLExpressionBuilder.java:142)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaDat
a(JPQLExpressionBuilder.java:211)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaDat
a(JPQLExpressionBuilder.java:181)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JP
QLExpressionBuilder.java:174)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpr
essionBuilder.java:61)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate
(JPQLExpressionBuilder.java:1657)
at
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:52)
at
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(E
xpressionStoreQuery.java:145)
at
org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:642)
at
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:
623)
at
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java
:589)
at
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:65
1)
at
org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1464)
at
org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.j
ava:120)
at
org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:202)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:25
1)
at com.symcor.sis.tecp.dao.ExecuteDB.main(ExecuteDB.java:35)
-
Check out what you're missing if you're not on Yahoo! Messenger
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
Re: OPENJPA-134 and the 0.9.7 release
Generally in favor of including this performance patch with the release. Just a few questions: 1. How good is the patch? Has it been put through whatever extensive Unit Tests tests anyone has? 2. How easy is it to respin the release? I'd hope that this is a matter of a few hours but I'm not the one doing the work ;-) Procedurally there is no issue since Mike hasn't yet called for a vote. I'd be happy if the patch were included in the release candidate because it's the release candidate that the community should be testing. And if this patch has any issues, we'll hear about it. Craig On Apr 11, 2007, at 2:09 PM, Kevin Sutter wrote: Question... Now that Abe has graciously resolved OpenJPA-134 ( https://issues.apache.org/jira/browse/OPENJPA-134), I would really like to see this get included into the 0.9.7 release. This fix looks to resolve the redundant sql joins that were dogging the performance of certain benchmarks. By including this fix in the 0.9.7 release, I think our OpenJPA story would be all that much better. Since we haven't started a vote yet, are there any issues with either re-cutting the 0.9.7 branch or applying Abe's fix to the 0.9.7 branch before starting a vote? I would assume that neither of these options would cause much headache for Mike (famous last words)... Kevin Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
[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_12488191
]
david zhang commented on OPENJPA-211:
-
It seems WAS has no problem finding the implementation class: [EMAIL PROTECTED]
This code:
InitialContext ic = null;
try{
ic = new InitialContext();
ExtendedJTATransaction tran = (ExtendedJTATransaction)
ic.lookup("java:comp/websphere/ExtendedJTATransaction");
System.out.println(tran.getClass());
System.out.println(tran.getGlobalId());
System.out.println(tran.getLocalId());
}catch(Exception e){
e.printStackTrace();
}
has no problem return class name, with global trans id with null and local tran
id with 0.
However, in WASManagerRuntime, the method
rval = (byte[]) _getGlobalId.invoke(_extendedTransaction, null);
return IllegalArgumentException.
Now I create a DB2 XA datasource, change the application CL to parent_last,
then parent_first. Copy ibm was 6.1_runtime.jar in ear and java and web
projects depend on this jar. Still doesn't work.
However, this happened when Spring want to call OpenJPA transactionManager to
start a transaction. However, the global transaction is not there. So the
globalId is null and localId is 0. Am I missing something? I have a WAS
DataSource connect to DB2 without problem. And the resource reference within
the web application has no problem. (tested). So Why there's no transaction
withing this thread?
> 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.initi
OPENJPA-134 and the 0.9.7 release
Question... Now that Abe has graciously resolved OpenJPA-134 ( https://issues.apache.org/jira/browse/OPENJPA-134), I would really like to see this get included into the 0.9.7 release. This fix looks to resolve the redundant sql joins that were dogging the performance of certain benchmarks. By including this fix in the 0.9.7 release, I think our OpenJPA story would be all that much better. Since we haven't started a vote yet, are there any issues with either re-cutting the 0.9.7 branch or applying Abe's fix to the 0.9.7 branch before starting a vote? I would assume that neither of these options would cause much headache for Mike (famous last words)... Kevin
[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_12488176 ] david zhang commented on OPENJPA-211: - Yes, I'm running within embeded WAS server and change to 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.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAncestors(BeanFactoryUtils.java:292) > at > org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:411) > at > org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.fi
[jira] Resolved: (OPENJPA-214) Need to support floating point primary keys
[ https://issues.apache.org/jira/browse/OPENJPA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-214. --- Resolution: Fixed Assignee: (was: Abe White) Support float/Float and double/Double primary key fields in single-field identity handling. Fixed in revision 527648. > Need to support floating point primary keys > --- > > Key: OPENJPA-214 > URL: https://issues.apache.org/jira/browse/OPENJPA-214 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 0.9.7 >Reporter: Kevin Sutter > Fix For: 0.9.8 > > > Dain first reported this problem on the dev mailing list: > http://www.nabble.com/Float-primary-key--tf3557137.html > >My response: > >Okay, I looked at the spec a bit closer and it looks like we need to allow > >for floats as primary keys: > >"The primary key (or field or property of a composite primary key) should be > >one of the following types: > >any Java primitive type; any primitive wrapper type; java.lang.String; > >java.util.Date; > >java.sql.Date. In general, however, approximate numeric types (e.g., > >floating point types) should > >never be used in primary keys." > >Although the spec clearly recommends against the use of floating points, > >floats are a primitive type (or the Float wrapper) and need to be allowed. > >With no >special "AllowStupidApproximatePrimaryKeys" flag. :-) > >Am I trying to read too much into the spec or Dain's request? This seems to > >be something that we need to support. > >>Abe's response: > >>Given the spec section you quoted, you're definitely right. It's something > >>we need to support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-214) Need to support floating point primary keys
[ https://issues.apache.org/jira/browse/OPENJPA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White reassigned OPENJPA-214: - Assignee: Abe White > Need to support floating point primary keys > --- > > Key: OPENJPA-214 > URL: https://issues.apache.org/jira/browse/OPENJPA-214 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 0.9.7 >Reporter: Kevin Sutter > Assigned To: Abe White > Fix For: 0.9.8 > > > Dain first reported this problem on the dev mailing list: > http://www.nabble.com/Float-primary-key--tf3557137.html > >My response: > >Okay, I looked at the spec a bit closer and it looks like we need to allow > >for floats as primary keys: > >"The primary key (or field or property of a composite primary key) should be > >one of the following types: > >any Java primitive type; any primitive wrapper type; java.lang.String; > >java.util.Date; > >java.sql.Date. In general, however, approximate numeric types (e.g., > >floating point types) should > >never be used in primary keys." > >Although the spec clearly recommends against the use of floating points, > >floats are a primitive type (or the Float wrapper) and need to be allowed. > >With no >special "AllowStupidApproximatePrimaryKeys" flag. :-) > >Am I trying to read too much into the spec or Dain's request? This seems to > >be something that we need to support. > >>Abe's response: > >>Given the spec section you quoted, you're definitely right. It's something > >>we need to support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Open JPA error-Could not locate metadata for the class using alias
On 4/11/07, saidulu chitipolu <[EMAIL PROTECTED]> wrote: your earliest suggetions are valuable You may want to take a look at the following thread - http://www.mail-archive.com/open-jpa-dev@incubator.apache.org/msg02770.html. Make sure that your class is @Entity-annotated, PCEnhance it and put the enhanced classes in the application classloader. Consider sending the files - AbstractItemEntity.java and persistence.xml and how you run the app - with javaagent or you PCEnhance the entities. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Open JPA error-Could not locate metadata for the class using alias
Hi,
I am trying to run standalone application access the database using spring
,openjpa.
part of code in main method
EntityManagerFactory factory = Persistence.createEntityManagerFactory("tsf");
EntityManager em = factory.createEntityManager();
System.out.println("--/ "+em);
Query q = em.createQuery("select m from AbstractItemEntity m");
List absEntity=q.getResultList();
facing the problem at
Query q = em.createQuery("select m from AbstractItemEntity m");
we have persistance.xml and orm files.
Log is as like below
your earliest suggetions are valuable
110 INFO [main] openjpa.Runtime - Starting OpenJPA 0.9.6-incubating
422 INFO [main] openjpa.jdbc.JDBC - Using dictionary class
"org.apache.openjpa.jdbc.sql.OracleDictionary".
766 INFO [main] openjpa.MetaData - Found 10 classes with metadata in 31
milliseconds.
--/ [EMAIL PROTECTED]
Exception in thread "main" <4|true|0.9.6-incubating>
org.apache.openjpa.persistence.ArgumentException: Could not locate metadata
for the class using alias "AbstractItemEntity". Registered alias mappings:
"{AbstractItemEntity=null}"
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:343)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:164)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:142)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:211)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:181)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:174)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:61)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1657)
at org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:52)
at
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:145)
at org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:642)
at
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:623)
at
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:589)
at
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:651)
at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1464)
at
org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:120)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:202)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:251)
at com.symcor.sis.tecp.dao.ExecuteDB.main(ExecuteDB.java:35)
-
Check out what you're missing if you're not on Yahoo! Messenger
Re: Artifact names
You're right, if / when we bypass the deploy phase and execute scp (or something similar) ourselves then it'll be easy to put in the renaming logic. Thanks Patrick and Marc, On 4/11/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: Michael- I personally think that keeping "-project-" in the artifact zip name is tolerable. I too had looked around (albeit briefly) for a solution to this a while ago, and found none. Once OpenJPA is out of incubation and we are deploying releases to the Apache mirror system, we'll probably need to put in some more deployment-oriented logic that doesn't use the "deploy" phase, so at that time we might be able to put in some renaming logic. +1 for tolerating the artifact name "openjpa-project-0.9.7- incubating.zip". On Apr 11, 2007, at 8:34 AM, Michael Dick wrote: > Hi, > > I'm hitting a bit of a snag with the staging repository for release > 0.9.7. > Recently we made changes to remove -project from our the zip file > names. The > problem is that the maven install and deploy goals ignore the names we > provide and generate their own names ( > openjpa-project-0.9.7-incubating-xxx.zip). > > I searched through the users@maven.apache.org mailing list archives > and it > turns out this is a fairly common problem - usually resulting in a > response > of "working as designed". Here's an example > http://www.nabble.com/Installation-and-deployment- > tf1449780s177.html#a3916784 > > Does anyone vehemently object to putting -project back into the > names for > the 0.9.7 release? > > The only other way I know of to fix the names that get deployed > would be to > change the artifactId in the pom files (basically switch openjpa with > openjpa-project). Switching the names will impact anyone who has a > dependency on the base openjpa project. They'll have to update the > version > number anyway, but it will still be a little confusing if they used to > depend on openjpa-0.9.6 and now they depend on openjpa-project-0.9.7. > > Thanks, > > -- > -Michael Dick -- -Michael Dick
Re: Artifact names
On 4/11/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > Does anyone vehemently object to putting -project back into > the names for > the 0.9.7 release? I don't vehemently object for the 0.9.7 release, but I do vehemently object for the 1.0 release. I don't like these random bugs / limitations of our build process making their way into the project artifacts. I agree, I don't think I can resolve it cleanly in a timely manner for 0.9.7but I don't think they should be permanent additions. I searched through the users@maven.apache.org mailing list > archives and it > turns out this is a fairly common problem - usually resulting > in a response > of "working as designed". Here's an example > http://www.nabble.com/Installation-and-deployment-tf1449780s17 > 7.html#a3916784 Any chance that we can convince the people involved that while it may be working as designed, it's a common difficulty? I'll try. I suspect their argument will be that using the artifactId guarantees uniqueness in the repository. I think that having the artifactId in the path is unique enough. As a last resort we could bite the bullet and switch the artifactIds. It's not particularly friendly but it wouldn't be the end of the world to make the change on a major release boundary (hopefully when we leave the incubator). -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Michael Dick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 11, 2007 8:34 AM > To: open-jpa-dev@incubator.apache.org > Subject: Artifact names > > Hi, > > I'm hitting a bit of a snag with the staging repository for > release 0.9.7. > Recently we made changes to remove -project from our the zip > file names. The > problem is that the maven install and deploy goals ignore the names we > provide and generate their own names ( > openjpa-project-0.9.7-incubating-xxx.zip). > > I searched through the users@maven.apache.org mailing list > archives and it > turns out this is a fairly common problem - usually resulting > in a response > of "working as designed". Here's an example > http://www.nabble.com/Installation-and-deployment-tf1449780s17 > 7.html#a3916784 > > Does anyone vehemently object to putting -project back into > the names for > the 0.9.7 release? > > The only other way I know of to fix the names that get > deployed would be to > change the artifactId in the pom files (basically switch openjpa with > openjpa-project). Switching the names will impact anyone who has a > dependency on the base openjpa project. They'll have to > update the version > number anyway, but it will still be a little confusing if they used to > depend on openjpa-0.9.6 and now they depend on openjpa-project-0.9.7. > > Thanks, > > -- > -Michael Dick > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
On Apr 11, 2007, at 8:51 AM, Craig L Russell wrote: Hi Michael, On Apr 10, 2007, at 3:40 PM, Michael Dick wrote: Hi Craig, Well I didn't intentionally remove them :-). It looks like they were removed by the maven plugin and this is one of the automated commits that it does. Looks like another gotcha with the tool. The maven developers are Apache folk so it must be that the tool isn't properly set up. They know about Apache licenses. I have found the maven doc to be a bit abstruse so it wouldn't surprise me to find a special setting deep in the pom.xml that tells maven to build an Apache release... It might be this problem: http://jira.codehaus.org/browse/MNG-2820
Re: Testing an OpenJPA module
Are we looking at different classes? I can't find the code in javax.persistence.Persistence under GlassFish that looks up persistence units. It's all delegated to the providers. thanks, -marina Patrick Linskey wrote: If a provider does not qualify as the provider for the named persistence unit, it must return null when createEntityManagerFactory is invoked on it. That's what the provider must do when PersistenceProvider.createEntityManagerFactory() is called, not what the Persistence class must do. As you can see in the code, Persistence already throws exceptions if it can't find any persistence units. It could just be a bit more informative about why. -Patrick
RE: Testing an OpenJPA module
>From findAllProviders():
Enumeration resources =
loader.getResources("META-INF/services/" +
PersistenceProvider.class.getName());
If no resources are found, we've got a useful nugget of information: no
persistence providers are available in the current classloader.
Later in findAllProviders():
for (String s : names) {
try{
providers.add((PersistenceProvider)loader.loadClass(s).newInstance());
} catch (ClassNotFoundException exc){
} catch (InstantiationException exc){
} catch (IllegalAccessException exc){
}
}
In each of these catch blocks, we're throwing away information. If we
get an exception here, it means that a resource was listed in the
services lookup, but one of the classes listed wasn't loadable.
>From createEntityManagerFactory():
try{
findAllProviders();
} catch (IOException exc){};
It's unclear why this IOException would be consumed. It is propagated up
from the findAllProviders() resource-lookup code. Again, this is useful
information for the exception that's thrown later.
IMO, the methods in this class should do a better job of tracking
problems as they happen, and using this information for notifying the
calling code about why a failure might have happened. I would recommend
using the cause slot in the thrown exception for more detail, and
putting more descriptive text in place for certain common cases.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 11, 2007 10:11 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Testing an OpenJPA module
>
> Are we looking at different classes? I can't find the code in
> javax.persistence.Persistence under GlassFish that looks up
> persistence units.
> It's all delegated to the providers.
>
> thanks,
> -marina
>
> Patrick Linskey wrote:
> >>If a provider does not qualify as the provider for the named
> >>persistence unit,
> >>it must return null when createEntityManagerFactory is
> invoked on it.
> >
> >
> > That's what the provider must do when
> > PersistenceProvider.createEntityManagerFactory() is called,
> not what the
> > Persistence class must do.
> >
> > As you can see in the code, Persistence already throws
> exceptions if it
> > can't find any persistence units. It could just be a bit more
> > informative about why.
> >
> > -Patrick
> >
>
>
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
Re: Artifact names
Michael- I personally think that keeping "-project-" in the artifact zip name is tolerable. I too had looked around (albeit briefly) for a solution to this a while ago, and found none. Once OpenJPA is out of incubation and we are deploying releases to the Apache mirror system, we'll probably need to put in some more deployment-oriented logic that doesn't use the "deploy" phase, so at that time we might be able to put in some renaming logic. +1 for tolerating the artifact name "openjpa-project-0.9.7- incubating.zip". On Apr 11, 2007, at 8:34 AM, Michael Dick wrote: Hi, I'm hitting a bit of a snag with the staging repository for release 0.9.7. Recently we made changes to remove -project from our the zip file names. The problem is that the maven install and deploy goals ignore the names we provide and generate their own names ( openjpa-project-0.9.7-incubating-xxx.zip). I searched through the users@maven.apache.org mailing list archives and it turns out this is a fairly common problem - usually resulting in a response of "working as designed". Here's an example http://www.nabble.com/Installation-and-deployment- tf1449780s177.html#a3916784 Does anyone vehemently object to putting -project back into the names for the 0.9.7 release? The only other way I know of to fix the names that get deployed would be to change the artifactId in the pom files (basically switch openjpa with openjpa-project). Switching the names will impact anyone who has a dependency on the base openjpa project. They'll have to update the version number anyway, but it will still be a little confusing if they used to depend on openjpa-0.9.6 and now they depend on openjpa-project-0.9.7. Thanks, -- -Michael Dick
RE: Artifact names
> Does anyone vehemently object to putting -project back into > the names for > the 0.9.7 release? I don't vehemently object for the 0.9.7 release, but I do vehemently object for the 1.0 release. I don't like these random bugs / limitations of our build process making their way into the project artifacts. > I searched through the users@maven.apache.org mailing list > archives and it > turns out this is a fairly common problem - usually resulting > in a response > of "working as designed". Here's an example > http://www.nabble.com/Installation-and-deployment-tf1449780s17 > 7.html#a3916784 Any chance that we can convince the people involved that while it may be working as designed, it's a common difficulty? -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Michael Dick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 11, 2007 8:34 AM > To: open-jpa-dev@incubator.apache.org > Subject: Artifact names > > Hi, > > I'm hitting a bit of a snag with the staging repository for > release 0.9.7. > Recently we made changes to remove -project from our the zip > file names. The > problem is that the maven install and deploy goals ignore the names we > provide and generate their own names ( > openjpa-project-0.9.7-incubating-xxx.zip). > > I searched through the users@maven.apache.org mailing list > archives and it > turns out this is a fairly common problem - usually resulting > in a response > of "working as designed". Here's an example > http://www.nabble.com/Installation-and-deployment-tf1449780s17 > 7.html#a3916784 > > Does anyone vehemently object to putting -project back into > the names for > the 0.9.7 release? > > The only other way I know of to fix the names that get > deployed would be to > change the artifactId in the pom files (basically switch openjpa with > openjpa-project). Switching the names will impact anyone who has a > dependency on the base openjpa project. They'll have to > update the version > number anyway, but it will still be a little confusing if they used to > depend on openjpa-0.9.6 and now they depend on openjpa-project-0.9.7. > > Thanks, > > -- > -Michael Dick > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Testing an OpenJPA module
> If a provider does not qualify as the provider for the named > persistence unit, > it must return null when createEntityManagerFactory is invoked on it. That's what the provider must do when PersistenceProvider.createEntityManagerFactory() is called, not what the Persistence class must do. As you can see in the code, Persistence already throws exceptions if it can't find any persistence units. It could just be a bit more informative about why. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 10, 2007 5:10 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Testing an OpenJPA module > > It's pretty much defined by the spec that Persistence class > just delegates to > the providers to do the work and has no way to report the errors: > > 7.2 Bootstrapping in Java SE Environments > > The Persistence bootstrap class will locate all of the > persistence providers > <...> and call createEntityManagerFactory() on them in turn > until an appropriate > backing provider returns an EntityManagerFactory. > <...> > If a provider does not qualify as the provider for the named > persistence unit, > it must return null when createEntityManagerFactory is invoked on it. > > regards, > -marina > > Craig L Russell wrote: > > FYI, Persistence is an open source project at Glassfish. > > > > Anyone, even an OpenJPA contributor, who wants to > contribute to the > > project for example to improve the error messages, is > welcome to look > > at the sources and provide a patch. I know people who will > be happy to > > commit usability patches. ;-) > > > > Craig > > > > On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: > > > >> The error message could have been more specific in the > following way: > >> a) no META-INF/persistence.xml has not been found in classpath > >> b) META-INF/persistence.xml has been found but there is no > 'ode-store' > >> unit defined in it. > >> c) META-INF/persistence.xml has been found but provider can not be > >> loaded/invoked > >> > >> When I first encountered this error, my interpreation was > (b) from the > >> way the message was worded. > >> > >> > >> Pinaki Poddar > >> BEA Systems > >> 415.402.7317 > >> > >> > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jacek > >> Laskowski > >> Sent: Tuesday, April 10, 2007 2:52 PM > >> To: open-jpa-dev@incubator.apache.org > >> Subject: Re: Testing an OpenJPA module > >> > >> On 4/10/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: > >> > >>> > >>> Glad you got it fixed. It's annoying that > >>> javax.persistence.Persistence doesn't provide more of a > clue as to why > >> > >> > >>> it failed. > >> > >> > >> I wonder what else you'd like to see other than what's > already printed > >> out? It tells exactly why it's failed - "No Persistence > provider for > >> EntityManager named ode-store" is just a JPA version of > >> "NoClassDefFoundError" in "pure" Java. > >> > >> Jacek > >> > >> -- > >> Jacek Laskowski > >> http://www.JacekLaskowski.pl > >> > >> Notice: This email message, together with any attachments, may > >> contain information of BEA Systems, Inc., its > subsidiaries and > >> affiliated entities, that may be confidential, proprietary, > >> copyrighted and/or legally privileged, and is intended > solely for > >> the use of the individual or entity named in this message. > If you are > >> not the intended recipient, and have received this message > in error, > >> please immediately return this by email and then delete it. > > > > > > Craig Russell > > Architect, Sun Java Enterprise System > http://java.sun.com/products/jdo > > 408 276-5638 mailto:[EMAIL PROTECTED] > > P.S. A good JDO? O, Gasp! > > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Resolved: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER
[ https://issues.apache.org/jira/browse/OPENJPA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-134. --- Resolution: Fixed Assignee: (was: Abe White) Fixed the most egregious issue, which was the cyclic fetching of eager bidirectional relations. Changed to cut off SELECTs when we're traversing the back-ptr to the owning side of a relation we've already fetched. I'm not convinced all the other issues mentioned are bugs given the eager fetch settings used. Please open new JIRAs for any individual issues that you believe remain. Fixed in revision 527565. > Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER > - > > Key: OPENJPA-134 > URL: https://issues.apache.org/jira/browse/OPENJPA-134 > Project: OpenJPA > Issue Type: Bug > Components: sql >Reporter: Catalina Wei > Fix For: 0.9.8 > > > Running JPAConfiguration default setting for EagerFetchMode > (FetchModeValue.EAGER_PARALLEL), > the SQL generated is sub-optimal. > Consider the following entities: > lineitems( OneToMany ) > Order <===> OrderItem > order ( ManyToOne ) > Case 1: why not combining 2 SQL to 1 SQL ? > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o > 2173 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1299336562 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0 > 2213 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2223 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1406424020 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t1.order_oid, t1.part_partno, > t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oid > ORDER BY t0.oid ASC > Case 2: extra unneeded LEFT OUTER JOIN, if eliminated, the selection aliase > t2 should change to t1: > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o left join fetch o.lineitems > 2403 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1500797300 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, > t2.cost, t2.part_partno, t2.quantity FROM Order t0 LEFT OUTER JOIN OrderItem > t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN OrderItem t2 ON t0.oid = > t2.order_oid ORDER BY t2.order_oid ASC > Case 3: why not generating 1 SQL ? > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o > 2343 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 384833264 SELECT t0.oid, t0.version, t0.amount, > t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order > t0 > 2383 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2393 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1722705582 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t2.oid, t2.version, t2.amount, > t2.customer_countryCode, t2.customer_id, t2.delivered, t2.shipaddr, > t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = > t1.order_oid LEFT OUTER JOIN Order t2 ON t1.order_oid = t2.oid ORDER BY > t0.oid ASC > 2393 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > 3134 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 950548648 > SELECT t0.lid, t0.version, t0.cost, t1.oid, t1.version, t1.amount, > t1.customer_countryCode, t1.customer_id, t1.delivered, t1.shipaddr, > t0.part_partno, t0.quantity FROM OrderItem t0 LEFT OUTER JOIN Order t1 ON > t0.order_oid = t1.oid WHERE t0.order_oid = ? [params=(int) 88] > 3134 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > Case 4: duplicate selections and redundant joins > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o left join fetch o.lineitems > 2273 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1565154634 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, > t2.cost, t3.oid, t3.version, t3.amount, t3.customer_countryCode, > t3.customer_id, t3.delivered, t3.shipaddr, t2.part_partno, t2.quantity FROM
[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.
Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
Hi Michael, On Apr 10, 2007, at 3:40 PM, Michael Dick wrote: Hi Craig, Well I didn't intentionally remove them :-). It looks like they were removed by the maven plugin and this is one of the automated commits that it does. Looks like another gotcha with the tool. The maven developers are Apache folk so it must be that the tool isn't properly set up. They know about Apache licenses. I have found the maven doc to be a bit abstruse so it wouldn't surprise me to find a special setting deep in the pom.xml that tells maven to build an Apache release... Maybe we have to have a LICENSE.xml available somewhere for maven to stuff into the artifacts? I'm going to rollback the changes again and see if I can fix the endline and the copyright problems. For the time being I'll leave the artifacts on people.apache.org/~mikedd. There should be another set of commits coming through later tonight tonight. Thanks for noticing the copyright problem. Many eyes make light reading? ;-) Good job so far, by the way. I expected it would take several tries to get the process working smoothly. For me, the more important result of this exercise is the process; the release is secondary. Craig On 4/10/07, Craig L Russell <[EMAIL PROTECTED]> wrote: Hi Mike, Did you accidentally remove the licenses from the xml files??? Craig On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote: > Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- > examples/pom.xml > URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- > incubating/openjpa-examples/pom.xml? > view=diff&rev=527320&r1=527319&r2=527320 > = = > > --- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ > pom.xml (original) > +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ > pom.xml Tue Apr 10 14:59:02 2007 > @@ -1,22 +1,4 @@ > - > - > -http://maven.apache.org/POM/4.0.0"; > - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > - xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > +http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http:// > maven.apache.org/maven-v4_0_0.xsd"> > 4.0.0 > org.apache.openjpa > openjpa-examples > @@ -27,7 +9,7 @@ > > org.apache.openjpa > openjpa > -0.9.7-incubating-SNAPSHOT > +0.9.7-incubating Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- -Michael Dick Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Float primary key?
On 4/11/07, Abe White <[EMAIL PROTECTED]> wrote: Given the spec section you quoted, you're definitely right. It's something we need to support. https://issues.apache.org/jira/browse/OPENJPA-214
[jira] Created: (OPENJPA-214) Need to support floating point primary keys
Need to support floating point primary keys --- Key: OPENJPA-214 URL: https://issues.apache.org/jira/browse/OPENJPA-214 Project: OpenJPA Issue Type: Bug Components: jdbc Affects Versions: 0.9.7 Reporter: Kevin Sutter Fix For: 0.9.8 Dain first reported this problem on the dev mailing list: http://www.nabble.com/Float-primary-key--tf3557137.html >My response: >Okay, I looked at the spec a bit closer and it looks like we need to allow for >floats as primary keys: >"The primary key (or field or property of a composite primary key) should be >one of the following types: >any Java primitive type; any primitive wrapper type; java.lang.String; >java.util.Date; >java.sql.Date. In general, however, approximate numeric types (e.g., floating >point types) should >never be used in primary keys." >Although the spec clearly recommends against the use of floating points, >floats are a primitive type (or the Float wrapper) and need to be allowed. >With no >special "AllowStupidApproximatePrimaryKeys" flag. :-) >Am I trying to read too much into the spec or Dain's request? This seems to >be something that we need to support. >>Abe's response: >>Given the spec section you quoted, you're definitely right. It's something >>we need to support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Artifact names
Hi, I'm hitting a bit of a snag with the staging repository for release 0.9.7. Recently we made changes to remove -project from our the zip file names. The problem is that the maven install and deploy goals ignore the names we provide and generate their own names ( openjpa-project-0.9.7-incubating-xxx.zip). I searched through the users@maven.apache.org mailing list archives and it turns out this is a fairly common problem - usually resulting in a response of "working as designed". Here's an example http://www.nabble.com/Installation-and-deployment-tf1449780s177.html#a3916784 Does anyone vehemently object to putting -project back into the names for the 0.9.7 release? The only other way I know of to fix the names that get deployed would be to change the artifactId in the pom files (basically switch openjpa with openjpa-project). Switching the names will impact anyone who has a dependency on the base openjpa project. They'll have to update the version number anyway, but it will still be a little confusing if they used to depend on openjpa-0.9.6 and now they depend on openjpa-project-0.9.7. Thanks, -- -Michael Dick
Re: Float primary key?
> Although the spec clearly recommends against the use of floating > points, > floats are a primitive type (or the Float wrapper) and need to be > allowed. > With no special "AllowStupidApproximatePrimaryKeys" flag. :-) > > Am I trying to read too much into the spec or Dain's request? This > seems to > be something that we need to support. Given the spec section you quoted, you're definitely right. It's something we need to support. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Float primary key?
Okay, I looked at the spec a bit closer and it looks like we need to allow for floats as primary keys: "The primary key (or field or property of a composite primary key) should be one of the following types: any Java primitive type; any primitive wrapper type; java.lang.String; java.util.Date; java.sql.Date. In general, however, approximate numeric types (e.g., floating point types) should never be used in primary keys." Although the spec clearly recommends against the use of floating points, floats are a primitive type (or the Float wrapper) and need to be allowed. With no special "AllowStupidApproximatePrimaryKeys" flag. :-) Am I trying to read too much into the spec or Dain's request? This seems to be something that we need to support. Kevin On 4/11/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: Dain, When you mention the "CMP test suite" are you referring to the CTS TCK? If so, how does "CMP" correspond to EJB's and their use of JPA (in the EJB3 sense)? I understand your request. I'm just trying to understand whether this is a "requirement" or just a bad test case in the CTS TCK. The JPA spec is pretty clear that approximate types should never be used for primary keys -- although I suppose you could read it that some providers could allow this use. It just wouldn't be portable. Kevin On 4/10/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > > I know it is a really really really stupid idea to use an approximate > type at a primary key, but there is a test in the CMP test suite that > uses a float for a primary key. When I deploy this bean, I get an > exception like the following: > > Caused by: <0.9.7-incubating-SNAPSHOT fatal user error> > org.apache.openjpa.persistence.ArgumentException: Type "class > foo.FloatBeanEJB" declares field "cmpID" as a primary key, but keys > of type "java.lang.Float" are not supported. > at org.apache.openjpa.meta.ClassMetaData.validateAppIdClass > (ClassMetaData.java:1800) > at org.apache.openjpa.meta.ClassMetaData.validateIdentity > (ClassMetaData.java:1779) > at org.apache.openjpa.meta.ClassMetaData.validateMeta > (ClassMetaData.java:1696) > at org.apache.openjpa.meta.ClassMetaData.resolve > (ClassMetaData.java:1569) > at org.apache.openjpa.meta.MetaDataRepository.processBuffer > (MetaDataRepository.java:656) > at org.apache.openjpa.meta.MetaDataRepository.resolveMeta > (MetaDataRepository.java:556) > at org.apache.openjpa.meta.MetaDataRepository.resolve > (MetaDataRepository.java :481) > at org.apache.openjpa.meta.MetaDataRepository.getMetaData > (MetaDataRepository.java:285) > at org.apache.openjpa.meta.MetaDataRepository.resolveMeta > (MetaDataRepository.java:521) > at org.apache.openjpa.meta.MetaDataRepository.resolve > (MetaDataRepository.java:481) > at org.apache.openjpa.meta.MetaDataRepository.getMetaData > (MetaDataRepository.java:285) > at org.apache.openjpa.jdbc.meta.MappingRepository.getMapping > (MappingRepository.java :276) > at org.apache.openjpa.jdbc.meta.MappingTool.getMapping > (MappingTool.java:667) > at org.apache.openjpa.jdbc.meta.MappingTool.buildSchema > (MappingTool.java:739) > at org.apache.openjpa.jdbc.meta.MappingTool.run (MappingTool.java: > 637) > at > org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings > (JDBCBrokerFactory.java:161) > at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl > (JDBCBrokerFactory.java :127) > at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker > (AbstractBrokerFactory.java:171) > at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker > (DelegatingBrokerFactory.java:139) > at > org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMana > ger(EntityManagerFactoryImpl.java:187) > at > org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMana > ger(EntityManagerFactoryImpl.java :52) > > Is there any way I can turn off this warning? Maybe we can add an > "AllowStupidApproximatePrimaryKeys" flag. > > Please :) > > -dain >
Re: Float primary key?
I believe that OpenJPA will allow float pk fields, it's just that there's no built-in id class for them (see util.LongId, ShortId, etc). So you'd have to either add a built-in id class and alter OpenJPA's internal code to use it appropriately, or create your own id class and use it via the @IdClass annotation, as you would for a compound pk. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Float primary key?
Dain, When you mention the "CMP test suite" are you referring to the CTS TCK? If so, how does "CMP" correspond to EJB's and their use of JPA (in the EJB3 sense)? I understand your request. I'm just trying to understand whether this is a "requirement" or just a bad test case in the CTS TCK. The JPA spec is pretty clear that approximate types should never be used for primary keys -- although I suppose you could read it that some providers could allow this use. It just wouldn't be portable. Kevin On 4/10/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: I know it is a really really really stupid idea to use an approximate type at a primary key, but there is a test in the CMP test suite that uses a float for a primary key. When I deploy this bean, I get an exception like the following: Caused by: <0.9.7-incubating-SNAPSHOT fatal user error> org.apache.openjpa.persistence.ArgumentException: Type "class foo.FloatBeanEJB" declares field "cmpID" as a primary key, but keys of type "java.lang.Float" are not supported. at org.apache.openjpa.meta.ClassMetaData.validateAppIdClass (ClassMetaData.java:1800) at org.apache.openjpa.meta.ClassMetaData.validateIdentity (ClassMetaData.java:1779) at org.apache.openjpa.meta.ClassMetaData.validateMeta (ClassMetaData.java:1696) at org.apache.openjpa.meta.ClassMetaData.resolve (ClassMetaData.java:1569) at org.apache.openjpa.meta.MetaDataRepository.processBuffer (MetaDataRepository.java:656) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta (MetaDataRepository.java:556) at org.apache.openjpa.meta.MetaDataRepository.resolve (MetaDataRepository.java:481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData (MetaDataRepository.java:285) at org.apache.openjpa.meta.MetaDataRepository.resolveMeta (MetaDataRepository.java:521) at org.apache.openjpa.meta.MetaDataRepository.resolve (MetaDataRepository.java:481) at org.apache.openjpa.meta.MetaDataRepository.getMetaData (MetaDataRepository.java:285) at org.apache.openjpa.jdbc.meta.MappingRepository.getMapping (MappingRepository.java:276) at org.apache.openjpa.jdbc.meta.MappingTool.getMapping (MappingTool.java:667) at org.apache.openjpa.jdbc.meta.MappingTool.buildSchema (MappingTool.java:739) at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java: 637) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings (JDBCBrokerFactory.java:161) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl (JDBCBrokerFactory.java:127) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker (AbstractBrokerFactory.java:171) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker (DelegatingBrokerFactory.java:139) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMana ger(EntityManagerFactoryImpl.java:187) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMana ger(EntityManagerFactoryImpl.java:52) Is there any way I can turn off this warning? Maybe we can add an "AllowStupidApproximatePrimaryKeys" flag. Please :) -dain
