Re: new site look
Hi Guys, I'm the guy that put the original ActiveMQ design together. If you want I'll tweak it some more for you guys. Perhaps change the color scheme? Or do you just want a better integrated banner/logo? Once we get that done, perhaps you want a cool little software box like the ones that I made for: http://activemq.apache.org/activemq-411-release.html and http://geronimo.apache.org/downloads.html Regards, Hiram Marc Prud wrote: It's actually a pretty shameless (albeit attributed) ripoff of http:// activemq.apache.org/. Something with the previous templates broke recently (which itself was a shameless ripoff of http:// geronimo.apache.org/), so I figured it was a good opportunity to play around with the styles. I had been intending to clean it up and customize the schemes a little further, but, as usual, other events wound up taking priority. And, of course, we'll need a proper logo someday... and budding graphics designers out there? On Mar 27, 2007, at 10:54 AM, Eddie O'Neil wrote: +1 -- excellent work. Who knew! Eddie On 3/27/07, Patrick Linskey [EMAIL PROTECTED] wrote: Dude when did Marc figure out how to make pretty HTML? I love the new look. Thanks! -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. 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. -- View this message in context: http://www.nabble.com/new-site-look-tf3474563.html#a9810849 Sent from the open-jpa-dev mailing list archive at Nabble.com.
YAT - Yet another test to moderate me through...
Please disregard. Craig's helping me to get through. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
I see several possible problems with this commit. Are there tests
for this functionality checked in?
1. The property and logic for using the DefaultSchemaName are defined
in MappingInfo, but the default schema name is only ever set into
ClassMappingInfos. Not FieldMappingInfos, DiscriminatorMappingInfos,
etc.
2. MappingInfo uses the default schema name sometimes (line 445) but
ignores it other times (line 469).
3. It should not be necessary to prepend the schema name to the table
name in PersistenceMappingDefaults. The schema is already known.
Was that code added based on any testing? If so, perhaps it is
because of problem #2 above.
4. The XMLPersistenceMappingParser should not override the endClass
(String) method. It already overrides the endClassMapping
(ClassMetaData) method, which is a much more efficient place to set
the needed info. You could also do it in the startClassMapping method.
I'm happy to fix things myself, but I don't see any tests in the
commit to verify my fixes.
On Apr 2, 2007, at 9:48 PM, [EMAIL PROTECTED] wrote:
Author: mikedd
Date: Mon Apr 2 19:48:10 2007
New Revision: 525006
URL: http://svn.apache.org/viewvc?view=revrev=525006
Log:
OpenJPA-179 store defaultSchemaName in ClassMapping
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/meta/MappingInfo.java
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/XMLPersistenceMappingParser.java
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/meta/MappingInfo.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingInfo.java?
view=diffrev=525006r1=525005r2=525006
==
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/meta/MappingInfo.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/meta/MappingInfo.java Mon Apr 2 19:48:10 2007
@@ -21,6 +21,7 @@
import java.util.Collections;
import java.util.List;
+import org.apache.commons.lang.StringUtils;
import org.apache.openjpa.jdbc.conf.JDBCConfiguration;
import org.apache.openjpa.jdbc.schema.Column;
import org.apache.openjpa.jdbc.schema.ColumnIO;
@@ -69,6 +70,7 @@
private boolean _canFK = true;
private int _join = JOIN_NONE;
private ColumnIO _io = null;
+private String _defaultSchemaName = null;
/**
* Mapping strategy name.
@@ -439,6 +441,9 @@
if (schema == null) {
schemaName = Schemas.getNewTableSchema
((JDBCConfiguration)
repos.getConfiguration());
+if(StringUtils.isEmpty(schemaName)) {
+ schemaName = _defaultSchemaName;
+}
schema = group.getSchema(schemaName);
if (schema == null)
schema = group.addSchema(schemaName);
@@ -1764,4 +1769,12 @@
public void populate(Table local, Table foreign, Column col,
Object target, boolean inverse, int pos, int cols);
}
+
+public String getDefaultSchemaName() {
+return _defaultSchemaName;
+}
+
+public void setDefaultSchemaName(String schemaName) {
+_defaultSchemaName = schemaName;
+}
}
Modified: incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/
java/org/apache/openjpa/persistence/jdbc/
PersistenceMappingDefaults.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
PersistenceMappingDefaults.java?
view=diffrev=525006r1=525005r2=525006
==
--- incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java
(original)
+++ incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java
Mon Apr 2 19:48:10 2007
@@ -15,6 +15,7 @@
*/
package org.apache.openjpa.persistence.jdbc;
+import org.apache.commons.lang.StringUtils;
import org.apache.openjpa.jdbc.meta.ClassMapping;
import org.apache.openjpa.jdbc.meta.Discriminator;
import org.apache.openjpa.jdbc.meta.FieldMapping;
@@ -114,17 +115,31 @@
@Override
public String getTableName(ClassMapping cls, Schema schema) {
+String name = ;
+
+if(StringUtils.isNotEmpty(schema.getName())) {
+name +=schema.getName() + '.';
+}
+
if (cls.getTypeAlias() != null)
-return
Re: new site look
Hiram- I'm the guy that put the original ActiveMQ design together. If you want I'll tweak it some more for you guys. Perhaps change the color scheme? Or do you just want a better integrated banner/logo? Personally, I think it would be fantastic if we had someone with clear design talent making improvements to the site. I had tried to tweak the colors initially so it didn't look like such an obvious copy of the ActiveMQ site, but I have lousy color sense, and everything I tried wound up looking garish. So, +1 from me for making any improvements you like! Once we get that done, perhaps you want a cool little software box like the ones that I made for: http://activemq.apache.org/activemq-411-release.html and http://geronimo.apache.org/downloads.html I think that would be really nifty. Out of curiosity, how did you make those images? Is there some Photoshop Software Product Box template or something, or did you have to do it manually? On Apr 3, 2007, at 6:22 AM, Hiram Chirino wrote: Hi Guys, I'm the guy that put the original ActiveMQ design together. If you want I'll tweak it some more for you guys. Perhaps change the color scheme? Or do you just want a better integrated banner/logo? Once we get that done, perhaps you want a cool little software box like the ones that I made for: http://activemq.apache.org/activemq-411-release.html and http://geronimo.apache.org/downloads.html Regards, Hiram Marc Prud wrote: It's actually a pretty shameless (albeit attributed) ripoff of http:// activemq.apache.org/. Something with the previous templates broke recently (which itself was a shameless ripoff of http:// geronimo.apache.org/), so I figured it was a good opportunity to play around with the styles. I had been intending to clean it up and customize the schemes a little further, but, as usual, other events wound up taking priority. And, of course, we'll need a proper logo someday... and budding graphics designers out there? On Mar 27, 2007, at 10:54 AM, Eddie O'Neil wrote: +1 -- excellent work. Who knew! Eddie On 3/27/07, Patrick Linskey [EMAIL PROTECTED] wrote: Dude when did Marc figure out how to make pretty HTML? I love the new look. Thanks! -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. 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. -- View this message in context: http://www.nabble.com/new-site-look- tf3474563.html#a9810849 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
Hi Abe,
The testing I've done was to take a rather simple entity hierarchy and use
the mapping tool to generate sql. Most of the verification was manual
inspection of the sql file. I didn't decide on the best way to test it in a
unit test - I suppose generating the file and grepping for the expected
results or generating the tables and using native queries to check that they
exist would work. Both approaches seem a bit kludgy to me - maybe there are
better options that haven't occurred to me yet. I'll attach the tests that I
have to the JIRA report rather than cluttering up everyone's inbox.
There are also similar tests in our FVT bucket, which is where we found the
problem. I know there's more cleanup to be done here, but I thought it was
worth getting a first stab at it done in time for 0.9.7.
I've attached a patch with some of the changes you noted. It probably won't
save you much time, but it can't hurt.
Thank you for taking a look at the changes.
On 4/3/07, Abe White [EMAIL PROTECTED] wrote:
I see several possible problems with this commit. Are there tests
for this functionality checked in?
1. The property and logic for using the DefaultSchemaName are defined
in MappingInfo, but the default schema name is only ever set into
ClassMappingInfos. Not FieldMappingInfos, DiscriminatorMappingInfos,
etc.
Definitely oversight on my part.
2. MappingInfo uses the default schema name sometimes (line 445) but
ignores it other times (line 469).
Another good catch - I missed the else clause, but it doesn't seem to
resolve #3.
3. It should not be necessary to prepend the schema name to the table
name in PersistenceMappingDefaults. The schema is already known.
Was that code added based on any testing? If so, perhaps it is
because of problem #2 above.
I didn't have much luck without the changes in PersistenceMappingDefaults -
there is a schema object, but the name is null. There might be something
else that I missed though.
4. The XMLPersistenceMappingParser should not override the endClass
(String) method. It already overrides the endClassMapping
(ClassMetaData) method, which is a much more efficient place to set
the needed info. You could also do it in the startClassMapping method.
Agreed, I should have moved it to one of the endClassMapping method.
I'm happy to fix things myself, but I don't see any tests in the
commit to verify my fixes.
On Apr 2, 2007, at 9:48 PM, [EMAIL PROTECTED] wrote:
Author: mikedd
Date: Mon Apr 2 19:48:10 2007
New Revision: 525006
URL: http://svn.apache.org/viewvc?view=revrev=525006
Log:
OpenJPA-179 store defaultSchemaName in ClassMapping
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/meta/MappingInfo.java
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/XMLPersistenceMappingParser.java
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/meta/MappingInfo.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingInfo.java?
view=diffrev=525006r1=525005r2=525006
==
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/meta/MappingInfo.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/meta/MappingInfo.java Mon Apr 2 19:48:10 2007
@@ -21,6 +21,7 @@
import java.util.Collections;
import java.util.List;
+import org.apache.commons.lang.StringUtils;
import org.apache.openjpa.jdbc.conf.JDBCConfiguration;
import org.apache.openjpa.jdbc.schema.Column;
import org.apache.openjpa.jdbc.schema.ColumnIO;
@@ -69,6 +70,7 @@
private boolean _canFK = true;
private int _join = JOIN_NONE;
private ColumnIO _io = null;
+private String _defaultSchemaName = null;
/**
* Mapping strategy name.
@@ -439,6 +441,9 @@
if (schema == null) {
schemaName = Schemas.getNewTableSchema
((JDBCConfiguration)
repos.getConfiguration());
+if(StringUtils.isEmpty(schemaName)) {
+ schemaName = _defaultSchemaName;
+}
schema = group.getSchema(schemaName);
if (schema == null)
schema = group.addSchema(schemaName);
@@ -1764,4 +1769,12 @@
public void populate(Table local, Table foreign, Column col,
Object target, boolean inverse, int pos, int cols);
}
+
+public String getDefaultSchemaName() {
+return _defaultSchemaName;
+}
+
+public void setDefaultSchemaName(String schemaName) {
+_defaultSchemaName = schemaName;
+}
RE: Errors with 0.9.7
Here is the stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [spring/AbstractTransactionalCommonSpringBase.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: org/apache/openjpa/util/ProxyArrayList Caused by: java.lang.NoClassDefFoundError: org/apache/openjpa/util/ProxyArrayList at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at kodo.profile.proxies.ProfilingProxyManager.clinit(ProfilingProxyManager.java:20) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at kodo.conf.KodoProductDerivation.class$(KodoProductDerivation.java:31) at kodo.conf.KodoProductDerivation.beforeConfigurationLoad(KodoProductDerivation.java:93) at org.apache.openjpa.lib.conf.ProductDerivations.beforeConfigurationLoad(ProductDerivations.java:176) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:486) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:154) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:145) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:124) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:116) at org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:93) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:204) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:242) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1118) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1085) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:236) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:225) 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.findEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:374) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$AnnotatedMember.resolveEntityManager(PersistenceAnnotationBeanPostProcessor.java:541) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$AnnotatedMember.resolve(PersistenceAnnotationBeanPostProcessor.java:512) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$AnnotatedMember.inject(PersistenceAnnotationBeanPostProcessor.java:449) at
RE: Errors with 0.9.7
kodo.conf.KodoProductDerivation.beforeConfigurationLoad(KodoProductDeriv ation.java:93) Is Kodo available in your runtime environment or only OpenJPA? The stack trace suggests that you have a Kodo installation. Please elaborate the runtime environment with versions of OpenJPA, Kodo, Spring you have been using. Also can you post AbstractTransactionalCommonSpringBase.xml? Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: yangdq [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 2:31 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Errors with 0.9.7 Here is the stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [spring/AbstractTransactionalCommonSpringBase.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: org/apache/openjpa/util/ProxyArrayList Caused by: java.lang.NoClassDefFoundError: org/apache/openjpa/util/ProxyArrayList at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at kodo.profile.proxies.ProfilingProxyManager.clinit(ProfilingProxyManage r.java:20) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at kodo.conf.KodoProductDerivation.class$(KodoProductDerivation.java:31) at kodo.conf.KodoProductDerivation.beforeConfigurationLoad(KodoProductDeriv ation.java:93) at org.apache.openjpa.lib.conf.ProductDerivations.beforeConfigurationLoad(P roductDerivations.java:176) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigura tionImpl.java:486) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigura tionImpl.java:154) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigura tionImpl.java:145) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerI mpl.init(PersistenceProviderImpl.java:124) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerI mpl.init(PersistenceProviderImpl.java:116) at org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEn tityManagerFactory(PersistenceProviderImpl.java:93) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.creat eNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java: 204) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterProper tiesSet(AbstractEntityManagerFactoryBean.java:242) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1118) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1085) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObjec t(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.g etSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.get BeansOfType(DefaultListableBeanFactory.java:236) at org.springframework.beans.factory.support.DefaultListableBeanFactory.get BeansOfType(DefaultListableBeanFactory.java:225) at org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingA ncestors(BeanFactoryUtils.java:205) at org.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAn cestors(BeanFactoryUtils.java:292) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcess or.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcesso r.java:411) at
Build failure with autoboxing
This is strange. Autoboxing turned off somehow? I must be doing
something wrong. Just checked out from the tip of trunk,
[INFO] Building OpenJPA JDBC
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 15 source files to /Users/clr/openjpa/openjpa/trunk/openjpa-
jdbc/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/Users/clr/openjpa/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java:[242,31] incompatible types
found : boolean
required: java.lang.Boolean
/Users/clr/openjpa/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java:[249,29] operator ==
cannot be applied to java.lang.Boolean,boolean
/Users/clr/openjpa/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java:[253,34] operator ==
cannot be applied to java.lang.Boolean,boolean
public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null fetch.getHint
(openjpa.hint.updateClause)
!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;
=== here
if (fetch != null fetch.getHint
(openjpa.hint.isolationLevel)
!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)
=== here
//This sql is not for update so add FOR Read Only
clause
forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true)
{ === here
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: Build failure with autoboxing
This is strange. Autoboxing turned off somehow? I must be doing something wrong. ... /Users/clr/openjpa/openjpa/trunk/openjpa-jdbc/src/main/java/org/ apache/openjpa/jdbc/sql/DB2Dictionary.java:[242,31] incompatible types Stuff if kernel needs to be 1.4-compatible. 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: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
Hi David,
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?
Craig
public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null fetch.getHint
(openjpa.hint.updateClause)
!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;
=== here
if (fetch != null fetch.getHint
(openjpa.hint.isolationLevel)
!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)
=== here
//This sql is not for update so add FOR Read Only
clause
forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true)
{ === here
On Apr 3, 2007, at 12:35 PM, [EMAIL PROTECTED] wrote:
Author: wisneskid
Date: Tue Apr 3 12:34:59 2007
New Revision: 525252
URL: http://svn.apache.org/viewvc?view=revrev=525252
Log:
changes for JIRA OPENJPA-182
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/
AbstractDB2Dictionary.java?view=diffrev=525252r1=525251r2=525252
==
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr 3 12:34:59 2007
@@ -52,7 +52,7 @@
supportsLockingWithOrderClause = false;
supportsLockingWithOuterJoin = false;
supportsLockingWithInnerJoin = false;
-supportsLockingWithSelectRange = false;
+supportsLockingWithSelectRange = true;
requiresAutoCommitForMetaData = true;
requiresAliasForSubselect = true;
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?
view=diffrev=525252r1=525251r2=525252
==
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java Tue Apr 3 12:34:59 2007
@@ -15,13 +15,15 @@
*/
package org.apache.openjpa.jdbc.sql;
+import java.lang.reflect.Method;
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.SQLException;
import java.util.Arrays;
-
+import java.util.StringTokenizer;
import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
import org.apache.openjpa.jdbc.schema.Sequence;
+import org.apache.openjpa.lib.log.Log;
/**
* Dictionary for IBM DB2 database.
@@ -31,7 +33,18 @@
public String optimizeClause = optimize for;
public String rowClause = row;
-
+private int db2ServerType = 0;
+private static final int db2ISeriesV5R3AndEarlier = 1;
+private static final int db2UDBV81OrEarlier = 2;
+private static final int db2ZOSV8x = 3;
+private static final int db2UDBV82AndLater = 4;
+private static final int db2ISeriesV5R4AndLater = 5;
+ private static final String forUpdateOfClause=FOR UPDATE OF;
+private static final String withRSClause=WITH RS;
+private static final String withRRClause=WITH RR;
+private static final String useKeepUpdateLockClause= USE AND
KEEP UPDATE LOCKS;
+private static final String useKeepExclusiveLockClause=USE
AND KEEP EXCLUSIVE LOCKS;
+private static final String forReadOnlyClause = FOR READ ONLY;
public DB2Dictionary() {
platform = DB2;
validationSQL = SELECT DISTINCT(CURRENT TIMESTAMP) FROM
@@ -170,6 +183,18 @@
if (isJDBC3(metaData)) {
RE: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
I'm a little nervous about this change still. I don't like it that we're adding yet another way to configure locking, especially since it seems like the lock level settings should be sufficient (or nearly so) to handle per-transaction / per-query lock levels. I also still do not believe that isolationLevel should be a hint; it seems more rule-like than hint-like. To date, the OpenJPA model has not been to piggyback on the Query.setHint() facilities for vendor-specific metadata, but rather to use our OpenJPA extension classes (FetchPlan, etc.) to allow us to convey more structured data to the kernel. I think that the isolation level should probably be part of FetchPlan (or possibly JDBCFetchPlan), and the update information should be obtainable from the FetchPlan's read- and write-lock levels. I don't think that we should rush this change in just so it's in 0.9.7; we can always delay 0.9.7 if it's a must-have, or have a 0.9.8 that follows soon thereafter. Generally-speaking, my experience is that once code gets committed, it tends to not get cleaned up, so the argument let's get it in for the release and then fix it later usually ends up turning into let's get it in for the release. This seems especially true for a change like this, that is exposing new APIs (the hints). Thoughts? -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 03, 2007 12:35 PM To: open-jpa-commits@incubator.apache.org Subject: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache /openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java Author: wisneskid Date: Tue Apr 3 12:34:59 2007 New Revision: 525252 URL: http://svn.apache.org/viewvc?view=revrev=525252 Log: changes for JIRA OPENJPA-182 Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/AbstractDB2Dictionary.java incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/DB2Dictionary.java Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/AbstractDB2Dictionary.java URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-j dbc/src/main/java/org/apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java ?view=diffrev= 525252r1=525251r2=525252 == --- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/AbstractDB2Dictionary.java (original) +++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr 3 12:34:59 2007 @@ -52,7 +52,7 @@ supportsLockingWithOrderClause = false; supportsLockingWithOuterJoin = false; supportsLockingWithInnerJoin = false; -supportsLockingWithSelectRange = false; +supportsLockingWithSelectRange = true; requiresAutoCommitForMetaData = true; requiresAliasForSubselect = true; Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/DB2Dictionary.java URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-j dbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?view=di ffrev=525252r1= 525251r2=525252 == --- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/DB2Dictionary.java (original) +++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/DB2Dictionary.java Tue Apr 3 12:34:59 2007 @@ -15,13 +15,15 @@ */ package org.apache.openjpa.jdbc.sql; +import java.lang.reflect.Method; import java.sql.Connection; import java.sql.DatabaseMetaData; import java.sql.SQLException; import java.util.Arrays; - +import java.util.StringTokenizer; import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration; import org.apache.openjpa.jdbc.schema.Sequence; +import org.apache.openjpa.lib.log.Log; /** * Dictionary for IBM DB2 database. @@ -31,7 +33,18 @@ public String optimizeClause = optimize for; public String rowClause = row; - +private int db2ServerType = 0; +private static final int db2ISeriesV5R3AndEarlier = 1; +private static final int db2UDBV81OrEarlier = 2; +
Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing. Can you please fix this? And I'd like to see all those hints defined as static constants on the dictionary class and named for DB2 (if they're that specific) and capitalized while you're at it -- see OracleDictionary.SELECT_HINT for a template. 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: composite ID w/ another composite ID as a field
i can also pass along a maven2 project
Can you post the Java source of the test case and domain classes for us
to reproduce the error?
afaik, Application identity classes like PageId are not enhanced in
current versions, they used to be.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 11:57 AM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID w/ another composite ID as a field
thanks pinaki,
as a test, i removed Page.book as an @Id, and made the corresponding
change in PageId (removed the book field of type PageId). this caused
the class cast exception below to go away. so, it does appear to have
some relation of to the use of the composite ID within a composite ID,
although you're right it might be a completely different issue.
this is with a trunk (as of this morning) build of openjpa.
i have attached the log you asked for. nothing stood out. i can also
pass along a maven2 project that contains the test case that fails if
that helps. i can't see to attach it here directly though as apache's
spam filter doesn't like it. let me know.
thanks again.
Pinaki Poddar [EMAIL PROTECTED] wrote:
Jeff,
1. The errors look rather unrelated to original problem of
composite
id.
2. The errors apparently caused by enviroment setup, so please
a) get a clean 0.9.7 openjpa (either building locally from the
source, or pre-built jars from the openjpa web-site)
b) if the error persists, report with trace-level logging
(property name=openjpa.Log value=DefaultLevel=TRACE/
and complete stack trace.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 4:12 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID w/ another composite ID as a field
thanks pinaki,
after making those changes, on 0.9.6, i get:
Caused by: java.lang.ClassCastException:
org.apache.openjpa.util.ObjectId
at com.mycompany.book.Page.pcCopyKeyFieldsToObjectId(Page.java)
at
org.apache.openjpa.util.ApplicationIds.create(ApplicationIds.java:383)
at
org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2349)
i built the trunk locally, and mvn installed it into my local
repository. when i run against it, i get:
Caused by: java.lang.RuntimeException: There were errors
initializing
your configuration: org.apache.openjpa.lib.util.ParseException:
Instantiation of plugin QueryCompilationCache with value
true caused
an error java.lang.IllegalArgumentException:
java.lang.ClassNotFoundException:
org.apache.openjpa.util.CacheMap. The
alias or class name may have been misspelled (as it closely
matches the
valid plugin alias true), or the class may not be available in
the
class path. Valid aliases for this plugin are: [all, false,
true]
followed by:
Caused by: java.lang.IllegalArgumentException:
java.lang.ClassNotFoundException:
org.apache.openjpa.util.CacheMap
at serp.util.Strings.toClass(Strings.java:211)
at serp.util.Strings.toClass(Strings.java:140)
at
org.apache.openjpa.lib.conf.Configurations.newInstance(Configurations.ja
va:191)
are there known issues w/ 0.9.7? what i don't understand is that
...CacheMap is in the sample place, in the same JAR as w/ the
0.9.6
dependency, just in my local repository.
also odd is that i only see the one info message during
enhancement:
[java] 1268 book INFO [main] openjpa.Tool - No targets were
given. Running on all classes in your persistent classes list,
or all
metadata files in classpath directories if you have not listed
your
persistent classes. Use -help to display tool usage information.
no details are printed about the classes being enhanced.
obviously this
was working in version 0,9.6.
any ideas?
Pinaki Poddar wrote: Hello Jeff,
OpenJPA supports the cited example where Page using a composite
ID which
in turn refers to Book's composite ID.
Book/Page/Library classes work with
a) openjpa-0.9.7 (do not know whether observed errors are due to
usage
of earlier 0.9.6 version)
b) following modifications in Page.book field (with a + sign)
@Id
@Column(nullable = false)
@ManyToOne (cascade = CascadeType.ALL)
+ @JoinColumns({
+ @JoinColumn(name=book_library_LIBRARY_NAME,
Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
yes will do that
ritika
On 4/3/07, Craig L Russell [EMAIL PROTECTED] wrote:
Hi David,
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?
Craig
public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null fetch.getHint
(openjpa.hint.updateClause)
!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;
=== here
if (fetch != null fetch.getHint
(openjpa.hint.isolationLevel)
!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)
=== here
//This sql is not for update so add FOR Read Only
clause
forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true)
{ === here
On Apr 3, 2007, at 12:35 PM, [EMAIL PROTECTED] wrote:
Author: wisneskid
Date: Tue Apr 3 12:34:59 2007
New Revision: 525252
URL: http://svn.apache.org/viewvc?view=revrev=525252
Log:
changes for JIRA OPENJPA-182
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/
AbstractDB2Dictionary.java?view=diffrev=525252r1=525251r2=525252
==
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr 3 12:34:59 2007
@@ -52,7 +52,7 @@
supportsLockingWithOrderClause = false;
supportsLockingWithOuterJoin = false;
supportsLockingWithInnerJoin = false;
-supportsLockingWithSelectRange = false;
+supportsLockingWithSelectRange = true;
requiresAutoCommitForMetaData = true;
requiresAliasForSubselect = true;
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?
view=diffrev=525252r1=525251r2=525252
==
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java Tue Apr 3 12:34:59 2007
@@ -15,13 +15,15 @@
*/
package org.apache.openjpa.jdbc.sql;
+import java.lang.reflect.Method;
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.SQLException;
import java.util.Arrays;
-
+import java.util.StringTokenizer;
import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
import org.apache.openjpa.jdbc.schema.Sequence;
+import org.apache.openjpa.lib.log.Log;
/**
* Dictionary for IBM DB2 database.
@@ -31,7 +33,18 @@
public String optimizeClause = optimize for;
public String rowClause = row;
-
+private int db2ServerType = 0;
+private static final int db2ISeriesV5R3AndEarlier = 1;
+private static final int db2UDBV81OrEarlier = 2;
+private static final int db2ZOSV8x = 3;
+private static final int db2UDBV82AndLater = 4;
+private static final int db2ISeriesV5R4AndLater = 5;
+ private static final String forUpdateOfClause=FOR UPDATE OF;
+private static final String withRSClause=WITH RS;
+private static final String withRRClause=WITH RR;
+private static final String useKeepUpdateLockClause= USE AND
KEEP UPDATE LOCKS;
+private static final String useKeepExclusiveLockClause=USE
AND KEEP EXCLUSIVE LOCKS;
+private static final String forReadOnlyClause = FOR READ ONLY;
public DB2Dictionary() {
platform = DB2;
Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
Never mind. I fixed it. I guess we still need to decide whether the
change goes in, but meantime it should compile...
Craig
On Apr 3, 2007, at 12:58 PM, Ritika Maheshwari wrote:
yes will do that
ritika
On 4/3/07, Craig L Russell [EMAIL PROTECTED] wrote:
Hi David,
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?
Craig
public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null fetch.getHint
(openjpa.hint.updateClause)
!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;
=== here
if (fetch != null fetch.getHint
(openjpa.hint.isolationLevel)
!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)
=== here
//This sql is not for update so add FOR Read Only
clause
forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true)
{ === here
On Apr 3, 2007, at 12:35 PM, [EMAIL PROTECTED] wrote:
Author: wisneskid
Date: Tue Apr 3 12:34:59 2007
New Revision: 525252
URL: http://svn.apache.org/viewvc?view=revrev=525252
Log:
changes for JIRA OPENJPA-182
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/
AbstractDB2Dictionary.java?view=diffrev=525252r1=525251r2=525252
=
=
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr 3 12:34:59
2007
@@ -52,7 +52,7 @@
supportsLockingWithOrderClause = false;
supportsLockingWithOuterJoin = false;
supportsLockingWithInnerJoin = false;
-supportsLockingWithSelectRange = false;
+supportsLockingWithSelectRange = true;
requiresAutoCommitForMetaData = true;
requiresAliasForSubselect = true;
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?
view=diffrev=525252r1=525251r2=525252
=
=
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java Tue Apr 3 12:34:59 2007
@@ -15,13 +15,15 @@
*/
package org.apache.openjpa.jdbc.sql;
+import java.lang.reflect.Method;
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.SQLException;
import java.util.Arrays;
-
+import java.util.StringTokenizer;
import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
import org.apache.openjpa.jdbc.schema.Sequence;
+import org.apache.openjpa.lib.log.Log;
/**
* Dictionary for IBM DB2 database.
@@ -31,7 +33,18 @@
public String optimizeClause = optimize for;
public String rowClause = row;
-
+private int db2ServerType = 0;
+private static final int db2ISeriesV5R3AndEarlier = 1;
+private static final int db2UDBV81OrEarlier = 2;
+private static final int db2ZOSV8x = 3;
+private static final int db2UDBV82AndLater = 4;
+private static final int db2ISeriesV5R4AndLater = 5;
+ private static final String forUpdateOfClause=FOR UPDATE
OF;
+private static final String withRSClause=WITH RS;
+private static final String withRRClause=WITH RR;
+private static final String useKeepUpdateLockClause= USE AND
KEEP UPDATE LOCKS;
+private static final String
RE: Errors with 0.9.7
Yes, we use Kodo 4.1.2. The bundled openJPA version is 0.9.5, but we met some problem so we downloaded 0.9.6 and it worked fine with Kodo 4.1.2 and Spring 2.0.2. Now we need to use LinkedHashSet instead of HashSet in our JPA entity collection fields and 0.9.6 does not support it. It seems that 0.9.7 support LinkedHashSet, that was the reason we are evaluating 0.9.7. But it seemed Kodo 4.1.2 is not compatible with openJPA 0.9.7. The AbstractTransactionalCommonSpringBase.xml is attached below: ?xml version=1.0 encoding=UTF-8? !DOCTYPE beans PUBLIC -//SPRING//DTD BEAN//EN http://www.springframework.org/dtd/spring-beans.dtd; beans bean id=dataSource class=org.apache.commons.dbcp.BasicDataSource destroy-method=close property name=driverClassNamevalueoracle.jdbc.OracleDriver/value/property property name=urlvaluejdbc:oracle:thin:@localhost:1521:sid/value/property property name=usernamevalueabc/value/property property name=passwordvalueabc/value/property /bean bean id=vidaEntityManager class=com.psi.vida.platform.util.VidaEntityManager property name=entityManagerFactory ref=entityManagerFactory/ /bean bean id=entityManagerFactory class=org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean property name=persistenceXmlLocation value=spring/persistence_spring.xml / property name=dataSource ref=dataSource/ property name=jpaVendorAdapter bean class=org.springframework.orm.jpa.vendor.OpenJpaVendorAdapter property name=databasePlatform value=org.apache.openjpa.jdbc.sql.OracleDictionary/ /bean /property property name=loadTimeWeaver bean class=org.springframework.instrument.classloading.SimpleLoadTimeWeaver/ /property property name=jpaProperties props prop key=show_sqltrue/prop /props /property /bean bean class=org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor / bean id=transactionManager class=org.springframework.orm.jpa.JpaTransactionManager property name=entityManagerFactory ref=entityManagerFactory /property name=dataSource ref=dataSource/ /bean /beans Pinaki Poddar wrote: kodo.conf.KodoProductDerivation.beforeConfigurationLoad(KodoProductDeriv ation.java:93) Is Kodo available in your runtime environment or only OpenJPA? The stack trace suggests that you have a Kodo installation. Please elaborate the runtime environment with versions of OpenJPA, Kodo, Spring you have been using. Also can you post AbstractTransactionalCommonSpringBase.xml? Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: yangdq [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 2:31 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Errors with 0.9.7 Here is the stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [spring/AbstractTransactionalCommonSpringBase.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: org/apache/openjpa/util/ProxyArrayList Caused by: java.lang.NoClassDefFoundError: org/apache/openjpa/util/ProxyArrayList at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at kodo.profile.proxies.ProfilingProxyManager.clinit(ProfilingProxyManage r.java:20) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at kodo.conf.KodoProductDerivation.class$(KodoProductDerivation.java:31) at kodo.conf.KodoProductDerivation.beforeConfigurationLoad(KodoProductDeriv ation.java:93) at org.apache.openjpa.lib.conf.ProductDerivations.beforeConfigurationLoad(P roductDerivations.java:176) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigura tionImpl.java:486) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigura tionImpl.java:154) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigura tionImpl.java:145) at
Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
SQL provides capabilities for tuning of locking. In the case of DB2 this involves setting the isolation level, update lock, result set optimize set, etc. JPA spec does not provide support for these concepts but does provide a rather open ended setHint api. It is our intent to make use this api so that users can sets these values without having to make use of OpenJPA specific apis -- granted the hint name and value would be OpenJPA specific. Furthermore, we are intending to support static SQL. Static SQL is extremely important in the enterprise environment for our larger customers because (1) it provides better optimization of SQL and (2) auditability and security over who access the data and how it is accessed.In the case of static SQL, these hints would be defined on a NamedQuery definition and not through runtime api. On 4/3/07, Patrick Linskey [EMAIL PROTECTED] wrote: I'm a little nervous about this change still. I don't like it that we're adding yet another way to configure locking, especially since it seems like the lock level settings should be sufficient (or nearly so) to handle per-transaction / per-query lock levels. I also still do not believe that isolationLevel should be a hint; it seems more rule-like than hint-like. To date, the OpenJPA model has not been to piggyback on the Query.setHint() facilities for vendor-specific metadata, but rather to use our OpenJPA extension classes (FetchPlan, etc.) to allow us to convey more structured data to the kernel. I think that the isolation level should probably be part of FetchPlan (or possibly JDBCFetchPlan), and the update information should be obtainable from the FetchPlan's read- and write-lock levels. I don't think that we should rush this change in just so it's in 0.9.7; we can always delay 0.9.7 if it's a must-have, or have a 0.9.8 that follows soon thereafter. Generally-speaking, my experience is that once code gets committed, it tends to not get cleaned up, so the argument let's get it in for the release and then fix it later usually ends up turning into let's get it in for the release. This seems especially true for a change like this, that is exposing new APIs (the hints). Thoughts? -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 03, 2007 12:35 PM To: open-jpa-commits@incubator.apache.org Subject: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache /openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java Author: wisneskid Date: Tue Apr 3 12:34:59 2007 New Revision: 525252 URL: http://svn.apache.org/viewvc?view=revrev=525252 Log: changes for JIRA OPENJPA-182 Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/AbstractDB2Dictionary.java incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/DB2Dictionary.java Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/AbstractDB2Dictionary.java URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-j dbc/src/main/java/org/apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java ?view=diffrev= 525252r1=525251r2=525252 == --- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/AbstractDB2Dictionary.java (original) +++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr 3 12:34:59 2007 @@ -52,7 +52,7 @@ supportsLockingWithOrderClause = false; supportsLockingWithOuterJoin = false; supportsLockingWithInnerJoin = false; -supportsLockingWithSelectRange = false; +supportsLockingWithSelectRange = true; requiresAutoCommitForMetaData = true; requiresAliasForSubselect = true; Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/DB2Dictionary.java URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-j dbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?view=di ffrev=525252r1= 525251r2=525252 == --- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/DB2Dictionary.java (original) +++
RE: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
open ended setHint api. It is our intent to make use this api so that users can sets these values without having to make use of OpenJPA specific apis -- granted the hint name and value would be OpenJPA specific. ... for certain values of our. I think that it's important that we discuss API decisions as a group, as they have significant impacts on the OpenJPA product moving forward. This is especially important when there are dissenting views on a particular API decision, as is the case here. Currently, most of the precedent in OpenJPA is to use OpenJPA-specific APIs, rather than untyped strings, whenever possible for fetch configuration and behavior. See the APIs for controlling the fetch batch size, or the lock level, or the maximum fetch depth. Personally, I much prefer that model of operation, since it provides strong typing where vendor-specific extensions are used, and thus raises the awareness of developers that they are using a proprietary feature. Using string key-value pairs is notoriously error-prone and difficult to refactor, and in my opinion detracts from the usability of the API. accessed.In the case of static SQL, these hints would be defined on a NamedQuery definition and not through runtime api. Again, I don't think that 'hint' is really the right word for describing lock and isolation levels. We could also create new annotations to describe the lock levels and isolation settings needed for the named queries; we do not need to constrain ourselves to what is available in the JPA annotations / XML. This will mean a bit more work on our part, but I think that we should figure out what the right decision is for our users, and work from there, rather than just doing whatever fits into what the JPA spec provides API-wise. Similarly, these facilities seem useful for regular EM.find() calls; one of the nice things about the FetchPlan is that an EM has a FetchPlan and a Query has one, so similar fetching configurations can be implemented in a common manner. Thoughts? -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: David Wisneski [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 1:24 PM To: open-jpa-dev@incubator.apache.org Subject: Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache /openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java SQL provides capabilities for tuning of locking. In the case of DB2 this involves setting the isolation level, update lock, result set optimize set, etc. JPA spec does not provide support for these concepts but does provide a rather open ended setHint api. It is our intent to make use this api so that users can sets these values without having to make use of OpenJPA specific apis -- granted the hint name and value would be OpenJPA specific. Furthermore, we are intending to support static SQL. Static SQL is extremely important in the enterprise environment for our larger customers because (1) it provides better optimization of SQL and (2) auditability and security over who access the data and how it is accessed.In the case of static SQL, these hints would be defined on a NamedQuery definition and not through runtime api. On 4/3/07, Patrick Linskey [EMAIL PROTECTED] wrote: I'm a little nervous about this change still. I don't like it that we're adding yet another way to configure locking, especially since it seems like the lock level settings should be sufficient (or nearly so) to handle per-transaction / per-query lock levels. I also still do not believe that isolationLevel should be a hint; it seems more rule-like than hint-like. To date, the OpenJPA model has not been to piggyback on the Query.setHint() facilities for vendor-specific metadata, but rather to use our OpenJPA extension classes (FetchPlan, etc.) to allow us to convey more structured data to the kernel. I think that the isolation level should probably be part of FetchPlan (or possibly JDBCFetchPlan), and the update information should be obtainable from the FetchPlan's read- and write-lock levels. I don't think that we should rush this change in just so it's in 0.9.7; we can always delay 0.9.7 if it's a must-have, or have a 0.9.8 that follows soon thereafter. Generally-speaking, my experience is that once code gets committed, it tends to not get cleaned up, so the argument
RE: composite ID w/ another composite ID as a field
Pinaki Poddar [EMAIL PROTECTED] wrote: i can also pass along a maven2
project
Can you post the Java source of the test case and domain classes for us
to reproduce the error?
i sent a .zip of the maven2 project to you directly. if there is a better place
to post it, let me know.
afaik, Application identity classes like PageId are not enhanced in
current versions, they used to be.
i did not see any difference between the decompiled Page and PageId classes
from the failed case, and the case that works when i remove the book field from
PageId (besides the obvious ones).
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 11:57 AM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID w/ another composite ID as a field
thanks pinaki,
as a test, i removed Page.book as an @Id, and made the corresponding
change in PageId (removed the book field of type PageId). this caused
the class cast exception below to go away. so, it does appear to have
some relation of to the use of the composite ID within a composite ID,
although you're right it might be a completely different issue.
this is with a trunk (as of this morning) build of openjpa.
i have attached the log you asked for. nothing stood out. i can also
pass along a maven2 project that contains the test case that fails if
that helps. i can't see to attach it here directly though as apache's
spam filter doesn't like it. let me know.
thanks again.
Pinaki Poddar
wrote:
Jeff,
1. The errors look rather unrelated to original problem of
composite
id.
2. The errors apparently caused by enviroment setup, so please
a) get a clean 0.9.7 openjpa (either building locally from the
source, or pre-built jars from the openjpa web-site)
b) if the error persists, report with trace-level logging
(property name=openjpa.Log value=DefaultLevel=TRACE/
and complete stack trace.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 4:12 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID w/ another composite ID as a field
thanks pinaki,
after making those changes, on 0.9.6, i get:
Caused by: java.lang.ClassCastException:
org.apache.openjpa.util.ObjectId
at com.mycompany.book.Page.pcCopyKeyFieldsToObjectId(Page.java)
at
org.apache.openjpa.util.ApplicationIds.create(ApplicationIds.java:383)
at
org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2349)
i built the trunk locally, and mvn installed it into my local
repository. when i run against it, i get:
Caused by: java.lang.RuntimeException: There were errors
initializing
your configuration: org.apache.openjpa.lib.util.ParseException:
Instantiation of plugin QueryCompilationCache with value
true caused
an error java.lang.IllegalArgumentException:
java.lang.ClassNotFoundException:
org.apache.openjpa.util.CacheMap. The
alias or class name may have been misspelled (as it closely
matches the
valid plugin alias true), or the class may not be available in
the
class path. Valid aliases for this plugin are: [all, false,
true]
followed by:
Caused by: java.lang.IllegalArgumentException:
java.lang.ClassNotFoundException:
org.apache.openjpa.util.CacheMap
at serp.util.Strings.toClass(Strings.java:211)
at serp.util.Strings.toClass(Strings.java:140)
at
org.apache.openjpa.lib.conf.Configurations.newInstance(Configurations.ja
va:191)
are there known issues w/ 0.9.7? what i don't understand is that
...CacheMap is in the sample place, in the same JAR as w/ the
0.9.6
dependency, just in my local repository.
also odd is that i only see the one info message during
enhancement:
[java] 1268 book INFO [main] openjpa.Tool - No targets were
given. Running on all classes in your persistent classes list,
or all
metadata files in classpath directories if you have not listed
your
persistent classes. Use -help to display tool usage information.
no details are printed about the classes being enhanced.
obviously this
was working in version 0,9.6.
any ideas?
Pinaki Poddar wrote: Hello Jeff,
OpenJPA supports the cited example where Page using a composite
ID which
in turn refers to Book's composite ID.
Book/Page/Library classes work with
a) openjpa-0.9.7 (do not know whether observed errors are due to
usage
of earlier 0.9.6 version)
b) following modifications in Page.book field (with a + sign)
@Id
@Column(nullable = false)
@ManyToOne (cascade = CascadeType.ALL)
+ @JoinColumns({
+ @JoinColumn(name=book_library_LIBRARY_NAME,
referencedColumnName=library_LIBRARY_NAME),
+ @JoinColumn(name=book_BOOK_NAME,
referencedColumnName=BOOK_NAME)
})
private Book book;
where the JoinColumns specification refers to following schema
(as per
your Page/Book/Library class annotations):
mysql desc book;
Re: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
Thanks Patrick, That's exactly what I needed. I'll add a testcase shortly. I read through your response to one of Dave's commits and I think it applies to mine as well. Rather than hijacking that thread, I'm re-posting the relevant part here along with my response : I don't think that we should rush this change in just so it's in 0.9.7; we can always delay 0.9.7 if it's a must-have, or have a 0.9.8 that follows soon thereafter. Generally-speaking, my experience is that once code gets committed, it tends to not get cleaned up, so the argument let's get it in for the release and then fix it later usually ends up turning into let's get it in for the release. This seems especially true for a change like this, that is exposing new APIs (the hints). Thoughts? I agree. We need to try and avoid the commit and fix later mentality. If the code is not ready then it shouldn't be committed or the release should wait until the code is ready. On the other hand, I think there are cases where we can include limited functionality in the current release and then complete the function in release+1. An example of this is what I intended to do in OpenJPA-179. My intent was to include the support for default schemas which effected only the entities in orm.xml in 0.9.7, and then add support for persistence-unit wide defaults in 0.9.8. As Abe pointed out the code wasn't ready to be committed, and it needs to either be made ready or excluded from 0.9.8. For the record, I can go either way regarding OpenJPA-179 with one exception - I'm unlikely to finish the persistence unit wide changes in the near future, so if that's required it would be better to leave the function out of the release. On 4/3/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, You might want to take a look at the SQLListenerTestCase -- it's very useful for ensuring that the right SQL is issued by a given command. That, in conjunction with direct invocations of MappingTool.run () with a Configuration obtained from the test case's EMF, and JDK1.4 regex support, should make it pretty simple to put together a unit test case. -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: Tuesday, April 03, 2007 11:55 AM To: open-jpa-dev@incubator.apache.org Subject: Re: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/pers istence/jdbc/ Hi Abe, The testing I've done was to take a rather simple entity hierarchy and use the mapping tool to generate sql. Most of the verification was manual inspection of the sql file. I didn't decide on the best way to test it in a unit test - I suppose generating the file and grepping for the expected results or generating the tables and using native queries to check that they exist would work. Both approaches seem a bit kludgy to me - maybe there are better options that haven't occurred to me yet. I'll attach the tests that I have to the JIRA report rather than cluttering up everyone's inbox. There are also similar tests in our FVT bucket, which is where we found the problem. I know there's more cleanup to be done here, but I thought it was worth getting a first stab at it done in time for 0.9.7. I've attached a patch with some of the changes you noted. It probably won't save you much time, but it can't hurt. Thank you for taking a look at the changes. On 4/3/07, Abe White [EMAIL PROTECTED] wrote: I see several possible problems with this commit. Are there tests for this functionality checked in? 1. The property and logic for using the DefaultSchemaName are defined in MappingInfo, but the default schema name is only ever set into ClassMappingInfos. Not FieldMappingInfos, DiscriminatorMappingInfos, etc. Definitely oversight on my part. 2. MappingInfo uses the default schema name sometimes (line 445) but ignores it other times (line 469). Another good catch - I missed the else clause, but it doesn't seem to resolve #3. 3. It should not be necessary to prepend the schema name to the table name in PersistenceMappingDefaults. The schema is already known. Was that code added based on any testing? If so, perhaps it is because of problem #2 above. I didn't have much luck
Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
My experience is that customers don't like and tend not to use proprietary apis. They tend to understand and use the standard apis. If we can make a standard api do what we need that should be the preferrred approach over creating proprietary apis and annotations and then having to educate folks on how to use them. The JPA Hint was supposed to be a way to specify properties on a per query basis and that is exactly what we are trying to do in this case. On 4/3/07, Patrick Linskey [EMAIL PROTECTED] wrote: open ended setHint api. It is our intent to make use this api so that users can sets these values without having to make use of OpenJPA specific apis -- granted the hint name and value would be OpenJPA specific. ... for certain values of our. I think that it's important that we discuss API decisions as a group, as they have significant impacts on the OpenJPA product moving forward. This is especially important when there are dissenting views on a particular API decision, as is the case here. Currently, most of the precedent in OpenJPA is to use OpenJPA-specific APIs, rather than untyped strings, whenever possible for fetch configuration and behavior. See the APIs for controlling the fetch batch size, or the lock level, or the maximum fetch depth. Personally, I much prefer that model of operation, since it provides strong typing where vendor-specific extensions are used, and thus raises the awareness of developers that they are using a proprietary feature. Using string key-value pairs is notoriously error-prone and difficult to refactor, and in my opinion detracts from the usability of the API. accessed.In the case of static SQL, these hints would be defined on a NamedQuery definition and not through runtime api. Again, I don't think that 'hint' is really the right word for describing lock and isolation levels. We could also create new annotations to describe the lock levels and isolation settings needed for the named queries; we do not need to constrain ourselves to what is available in the JPA annotations / XML. This will mean a bit more work on our part, but I think that we should figure out what the right decision is for our users, and work from there, rather than just doing whatever fits into what the JPA spec provides API-wise. Similarly, these facilities seem useful for regular EM.find() calls; one of the nice things about the FetchPlan is that an EM has a FetchPlan and a Query has one, so similar fetching configurations can be implemented in a common manner. Thoughts? -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: David Wisneski [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 1:24 PM To: open-jpa-dev@incubator.apache.org Subject: Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache /openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java SQL provides capabilities for tuning of locking. In the case of DB2 this involves setting the isolation level, update lock, result set optimize set, etc. JPA spec does not provide support for these concepts but does provide a rather open ended setHint api. It is our intent to make use this api so that users can sets these values without having to make use of OpenJPA specific apis -- granted the hint name and value would be OpenJPA specific. Furthermore, we are intending to support static SQL. Static SQL is extremely important in the enterprise environment for our larger customers because (1) it provides better optimization of SQL and (2) auditability and security over who access the data and how it is accessed.In the case of static SQL, these hints would be defined on a NamedQuery definition and not through runtime api. On 4/3/07, Patrick Linskey [EMAIL PROTECTED] wrote: I'm a little nervous about this change still. I don't like it that we're adding yet another way to configure locking, especially since it seems like the lock level settings should be sufficient (or nearly so) to handle per-transaction / per-query lock levels. I also still do not believe that isolationLevel should be a hint; it seems more rule-like than hint-like. To date, the OpenJPA model has not been to piggyback on the Query.setHint() facilities for vendor-specific metadata, but rather to use our OpenJPA extension classes (FetchPlan, etc.) to allow us to convey more structured data to the kernel. I
RE: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
On the other hand, I think there are cases where we can include limited functionality in the current release and then complete the function in release+1. An example of this is what I intended to do in OpenJPA-179. I agree completely. In the case of OPENJPA-179, while I acknowledge that Abe has some good points about improvements in it, I'm not so worried about the feature going in. We may need to do more work on it, but (to my knowledge) it's an improvement over where things are right now, and it's not an API change, so it won't really have any long-term downsides. We just need to fix it more later on. Similarly, in the past, we have introduced partial new features that took multiple releases to finish completely; that works out fine, as long as we don't end up creating backwards-compatibility conflicts by doing so. Which, of course, involves careful planning of how the feature should be accessed. -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: Tuesday, April 03, 2007 2:17 PM To: open-jpa-dev@incubator.apache.org Subject: Re: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/pers istence/jdbc/ Thanks Patrick, That's exactly what I needed. I'll add a testcase shortly. I read through your response to one of Dave's commits and I think it applies to mine as well. Rather than hijacking that thread, I'm re-posting the relevant part here along with my response : I don't think that we should rush this change in just so it's in 0.9.7; we can always delay 0.9.7 if it's a must-have, or have a 0.9.8 that follows soon thereafter. Generally-speaking, my experience is that once code gets committed, it tends to not get cleaned up, so the argument let's get it in for the release and then fix it later usually ends up turning into let's get it in for the release. This seems especially true for a change like this, that is exposing new APIs (the hints). Thoughts? I agree. We need to try and avoid the commit and fix later mentality. If the code is not ready then it shouldn't be committed or the release should wait until the code is ready. On the other hand, I think there are cases where we can include limited functionality in the current release and then complete the function in release+1. An example of this is what I intended to do in OpenJPA-179. My intent was to include the support for default schemas which effected only the entities in orm.xml in 0.9.7, and then add support for persistence-unit wide defaults in 0.9.8. As Abe pointed out the code wasn't ready to be committed, and it needs to either be made ready or excluded from 0.9.8. For the record, I can go either way regarding OpenJPA-179 with one exception - I'm unlikely to finish the persistence unit wide changes in the near future, so if that's required it would be better to leave the function out of the release. On 4/3/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, You might want to take a look at the SQLListenerTestCase -- it's very useful for ensuring that the right SQL is issued by a given command. That, in conjunction with direct invocations of MappingTool.run () with a Configuration obtained from the test case's EMF, and JDK1.4 regex support, should make it pretty simple to put together a unit test case. -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: Tuesday, April 03, 2007 11:55 AM To: open-jpa-dev@incubator.apache.org Subject: Re: svn commit: r525006 - in /incubator/openjpa/trunk:
Re: new site look
+1 Always looking for some creative talent to make web presence better. Craig On Apr 3, 2007, at 6:22 AM, Hiram Chirino wrote: Hi Guys, I'm the guy that put the original ActiveMQ design together. If you want I'll tweak it some more for you guys. Perhaps change the color scheme? Or do you just want a better integrated banner/logo? Once we get that done, perhaps you want a cool little software box like the ones that I made for: http://activemq.apache.org/activemq-411-release.html and http://geronimo.apache.org/downloads.html Regards, Hiram Marc Prud wrote: It's actually a pretty shameless (albeit attributed) ripoff of http:// activemq.apache.org/. Something with the previous templates broke recently (which itself was a shameless ripoff of http:// geronimo.apache.org/), so I figured it was a good opportunity to play around with the styles. I had been intending to clean it up and customize the schemes a little further, but, as usual, other events wound up taking priority. And, of course, we'll need a proper logo someday... and budding graphics designers out there? On Mar 27, 2007, at 10:54 AM, Eddie O'Neil wrote: +1 -- excellent work. Who knew! Eddie On 3/27/07, Patrick Linskey [EMAIL PROTECTED] wrote: Dude when did Marc figure out how to make pretty HTML? I love the new look. Thanks! -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. 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. -- View this message in context: http://www.nabble.com/new-site-look- tf3474563.html#a9810849 Sent from the open-jpa-dev mailing list archive at Nabble.com. 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: 0.9.7: build changes
I agree that it would definitely make it easier to get started with the project's binary. The only downside is if a user might want to replace any of those JARs with newer -- presumably compatible! -- versions for some reason. It may not be an issue with OpenJPA, but with things like Struts, it's not uncommon for someone to want to swap out a version of commons-foobar.jar for something older / newer / different. So, as an alternate bundling -- +1. Eddie On 3/31/07, Craig L Russell [EMAIL PROTECTED] wrote: On Mar 29, 2007, at 5:00 PM, Patrick Linskey wrote: Also, we might want to think about other bundlings, such as creating a single jar with all dependencies, I'm not all that keen on merging other project's jars into a single monolithic jar. I think people expect that component-oriented software is going to have various required and optional dependencies. I feel that monolithic jar bundling is more appropriate for an application, rather than for a component. I agree, but I know that others disagree, and I don't see any reason why one is necessarily more right than another. The cost to us of having a separate jar / distro seems low, and if it helps with adoption, I don't see a downside. I think that it does help adoption, and I don't see a downside either. Craig -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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Thursday, March 29, 2007 11:15 AM To: open-jpa-dev@incubator.apache.org Subject: Re: 0.9.7: build changes On Mar 28, 2007, at 7:54 PM, Patrick Linskey wrote: One thing that I would like to see happen prior to 0.9.7 is a change to the build artifacts so that we don't have '-project' or '-all' tacked onto the releases everywhere. I've opened https://issues.apache.org/jira/browse/OPENJPA-194 for this and assigned it to myself. Also, we might want to think about other bundlings, such as creating a single jar with all dependencies, I'm not all that keen on merging other project's jars into a single monolithic jar. I think people expect that component-oriented software is going to have various required and optional dependencies. I feel that monolithic jar bundling is more appropriate for an application, rather than for a component. or a download that includes docs. What do you guys think? The binary assembly is meant to include the docs (and did on past releases). I notice that they are absent from recent snapshots, though. I'll try to figure out why that is. -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. 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!
why not an EntityExistsException was thrown?
I was confused in result of my test cases.
My test is about JPA exceptions. I use derby in my tests.
The first case is simply persist an object, the PK of the object has existed
in database,
so exception arose.
entityManager = factory.createEntityManager();
entityManager.getTransaction().begin();
...
entityManager.persist(anObject);
entityManager.getTransaction().commit();
exception is:
2|true|0.9.7-incubating-SNAPSHOT org.apache.openjpa.util.StoreException:
The transaction has been rolled back. See the nested exceptions for details
on the errors that occurred.
at
org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2091)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1938)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1836)
at
org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1754)
at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:76)
at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1311)
at
org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:863)
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:406)
at test.Main.main(Main.java:82)
Caused by: 2|false|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.util.StoreException: The statement was aborted because it
would have caused a duplicate key value in a unique or primary key
constraint or unique index identified by 'SQL070403054930170' defined on
'BSC'. {prepstmnt 15774883 INSERT INTO BSC (objid, objname, created,
msc_name, objclass) VALUES (?, ?, ?, ?, ?) [params=(long) 1, (String)
objname1, (Timestamp) 2006-05-04 18:13:51.0, (String) objname0, (String)
bsc]} [code=-1, state=23505]
FailedObject: [EMAIL PROTECTED]
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3764)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:103)
at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:68)
at
org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:200)
at
org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:86)
at
org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:86)
at
org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:69)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:511)
at
org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:127)
... 8 more
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: The statement
was aborted because it would have caused a duplicate key value in a unique
or primary key constraint or unique index identified by 'SQL070403054930170'
defined on 'BSC'. {prepstmnt 15774883 INSERT INTO BSC (objid, objname,
created, msc_name, objclass) VALUES (?, ?, ?, ?, ?) [params=(long) 1,
(String) objname1, (Timestamp) 2006-05-04 18:13:51.0, (String) objname0,
(String) bsc]} [code=-1, state=23505]
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:188)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$800(LoggingConnectionDecorator.java:53)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:854)
at
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:266)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1360)
at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:92)
... 15 more
I wonder why not an EntityExistsException was thrown?
In the second case, I add a query before persist,
entityManager = factory.createEntityManager();
/*
* query before persist, even bofore transaction
effects samely.
* this query makes exception thrown in persist section
difference.
* it seems that query what entity is not important,
* but must get result and result must has some record.
*/
RE: why not an EntityExistsException was thrown?
Cool -- that explains it then.
EM.commit() must throw RollbackExceptions (and
org.apache.openjpa.persistence.RollbackException extends
javax.persistence.RollbackException) when the transaction is rolled back
during the course of the commit.
If you get the nested exception from the RollbackException, I bet that
it's instanceof EntityExistsException.
Clearly, however, something is wonky with our exception printing
algorithm.
-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: wanyna [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 8:49 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: why not an EntityExistsException was thrown?
actual class of the exception:
class org.apache.openjpa.persistence.RollbackException
2|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.RollbackException: The
transaction has been
rolled back. See the nested exceptions for details on the errors that
occurred.
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
ManagerImpl.java:417)
at test.Main.main(Main.java:82)
Caused by: 0|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.PersistenceException: The
transaction has
been rolled back. See the nested exceptions for details on
the errors that
occurred.
at
org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerI
mpl.java:2091)
at
org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1938)
at
org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1836)
at
org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerIm
pl.java:1754)
at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalMana
gedRuntime.java:76)
at
org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1311)
at
org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBr
oker.java:863)
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
ManagerImpl.java:406)
... 1 more
Caused by: 0|false|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.PersistenceException: The statement was
aborted because it would have caused a duplicate key value in
a unique or
primary key constraint or unique index identified by
'SQL070403054930170'
defined on 'BSC'. {prepstmnt 15774883 INSERT INTO BSC (objid, objname,
created, msc_name, objclass) VALUES (?, ?, ?, ?, ?) [params=(long) 1,
(String) objname1, (Timestamp) 2006-05-04 18:13:51.0,
(String) objname0,
(String) bsc]} [code=-1, state=23505]
FailedObject: [EMAIL PROTECTED]
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBD
ictionary.java:3764)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptio
ns.java:94)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptio
ns.java:64)
at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.fl
ushInternal(PreparedStatementManagerImpl.java:103)
at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.fl
ush(PreparedStatementManagerImpl.java:68)
at
org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flu
shPrimaryRow(OperationOrderUpdateManager.java:200)
at
org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flu
sh(OperationOrderUpdateManager.java:86)
at
org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(Abs
tractUpdateManager.java:86)
at
org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(Abs
tractUpdateManager.java:69)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStor
eManager.java:511)
at
org.apache.openjpa.kernel.DelegatingStoreManager.flush(Delegat
ingStoreManager.java:127)
... 8 more
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException:
The statement
was aborted because it would have caused a duplicate key
value in a unique
or primary key constraint or unique index identified by
'SQL070403054930170'
defined on 'BSC'. {prepstmnt 15774883 INSERT INTO BSC (objid, objname,
created, msc_name, objclass) VALUES (?, ?, ?, ?, ?) [params=(long) 1,
(String) objname1, (Timestamp) 2006-05-04 18:13:51.0,
(String) objname0,
(String) bsc]} [code=-1, state=23505]
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(Lo
ggingConnectionDecorator.java:188)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$
RE: why not an EntityExistsException was thrown?
I can't find EntityExistsException nested in RollbackExceptions.
http://www.nabble.com/file/7646/exception.jpg
Will exception mechanism be planned to improve?
I think it's very important.
Patrick Linskey wrote:
Cool -- that explains it then.
EM.commit() must throw RollbackExceptions (and
org.apache.openjpa.persistence.RollbackException extends
javax.persistence.RollbackException) when the transaction is rolled back
during the course of the commit.
If you get the nested exception from the RollbackException, I bet that
it's instanceof EntityExistsException.
Clearly, however, something is wonky with our exception printing
algorithm.
-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: wanyna [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 8:49 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: why not an EntityExistsException was thrown?
actual class of the exception:
class org.apache.openjpa.persistence.RollbackException
2|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.RollbackException: The
transaction has been
rolled back. See the nested exceptions for details on the errors that
occurred.
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
ManagerImpl.java:417)
at test.Main.main(Main.java:82)
Caused by: 0|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.PersistenceException: The
transaction has
been rolled back. See the nested exceptions for details on
the errors that
occurred.
at
org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerI
mpl.java:2091)
at
org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1938)
at
org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1836)
at
org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerIm
pl.java:1754)
at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalMana
gedRuntime.java:76)
at
org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1311)
at
org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBr
oker.java:863)
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
ManagerImpl.java:406)
... 1 more
Caused by: 0|false|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.PersistenceException: The statement was
aborted because it would have caused a duplicate key value in
a unique or
primary key constraint or unique index identified by
'SQL070403054930170'
defined on 'BSC'. {prepstmnt 15774883 INSERT INTO BSC (objid, objname,
created, msc_name, objclass) VALUES (?, ?, ?, ?, ?) [params=(long) 1,
(String) objname1, (Timestamp) 2006-05-04 18:13:51.0,
(String) objname0,
(String) bsc]} [code=-1, state=23505]
FailedObject: [EMAIL PROTECTED]
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBD
ictionary.java:3764)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptio
ns.java:94)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptio
ns.java:64)
at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.fl
ushInternal(PreparedStatementManagerImpl.java:103)
at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.fl
ush(PreparedStatementManagerImpl.java:68)
at
org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flu
shPrimaryRow(OperationOrderUpdateManager.java:200)
at
org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flu
sh(OperationOrderUpdateManager.java:86)
at
org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(Abs
tractUpdateManager.java:86)
at
org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(Abs
tractUpdateManager.java:69)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStor
eManager.java:511)
at
org.apache.openjpa.kernel.DelegatingStoreManager.flush(Delegat
ingStoreManager.java:127)
... 8 more
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException:
The statement
was aborted because it would have caused a duplicate key
value in a unique
or primary key constraint or unique index identified by
'SQL070403054930170'
defined on 'BSC'. {prepstmnt 15774883 INSERT INTO BSC (objid, objname,
created, msc_name, objclass) VALUES (?, ?, ?, ?, ?) [params=(long) 1,
(String) objname1, (Timestamp) 2006-05-04 18:13:51.0,
(String) objname0,
(String)
Forced getter/setter access
Can anyone explain why this rule is in effect: When using property access, only the getter and setter method for a property should ever access the underlying persistent field directly. Other methods, including internal business methods in the persistent class, should go through the getter and setter methods when manipulating persistent state. (section 2.1.4 OpenJPA manual) This seems rather execution costly. If ,for instance, I have a Size class with hieght, width and length then to calculate and return volume I suffer a three method call overhead: return getWidth() * getLength() * getHieght(); This is opposed to a more efficient Return height * width * length Phill
Duplicate Query - where none exists
Anyone seen this before
WARN [main] openjpa.MetaData - Found duplicate query StoreFXPK in class
.. Ignoring.
This class has only three such named queries all different names and different
actual queries. See following
@NamedQueries( {
@NamedQuery(name = StoreFXPK, query = SELECT s FROM Store s
WHERE s.id = :primaryKey),
@NamedQuery(name = StoreFXTypeAndName, query = SELECT s FROM
Store s WHERE s.type = :type AND UPPER(s.name) LIKE :storeName OR
UPPER(s.displayName) = :storeName2),
@NamedQuery(name = StoreFXName, query = SELECT s FROM Store s
WHERE UPPER(s.name) = :storeName OR UPPER(s.displayName) = :storeName2)
})
I even renamed the duplicate parms to make sure it was not a trickle down
exception. Not only that, if I comment out the StoreFXPK query I get the same
error on the next named Query. I did a search on the workspace an this is only
used in one place (factory class) and define in another (persistent class). I
have no doubt this is something I have done but am unsure what it is I get the
follow stack trace when executing the following line:
Query q = em.createNamedQuery(StoreFXName); - not the same query mentioned in
the above warning...the plot thickens
The unmapped field in the stack trace is mapped.
4|true|0.0.0 org.apache.openjpa.persistence.ArgumentException: Errors
encountered while resolving metadata. See nested exceptions for details.
at
org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:501)
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:2
83)
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:3
38)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpres
sionBuilder.java:151)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLEx
pressionBuilder.java:131)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLEx
pressionBuilder.java:211)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLEx
pressionBuilder.java:181)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpres
sionBuilder.java:174)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBu
ilder.java:61)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExp
ressionBuilder.java:1657)
at
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:52)
at
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(Expressio
nStoreQuery.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.compile(QueryImpl.java:558)
at
org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery(EntityManagerI
mpl.java:699)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerIn
vocationHandler.invoke(ExtendedEntityManagerCreator.java:237)
at $Proxy34.createNamedQuery(Unknown Source)
at
ca.BidSpec.emall.stores.StoreFactoryImpl.getStoreValueObjectByName(StoreFactoryI
mpl.java:88)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils
.java:280)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(Ref
lectiveMethodInvocation.java:187)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveM
ethodInvocation.java:154)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(Transa
ctionInterceptor.java:107)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveM
ethodInvocation.java:176)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.j
ava:210)
at $Proxy32.getStoreValueObjectByName(Unknown Source)
at
RE: Forced getter/setter access
The main reason to support getter / setter access is for implementations that cannot intercept field accesses. So, the getters and setters are there so that the JPA implementation can create a subclass of your entity type (hence the no-final-classes rule) and track what happens as you invoke the setters and getters. In other words, your business methods become part of the JPA implementation's domain. So, when using property access, your contract with the JPA provider is that you'll access persistent attributes only through the setters and getters, which allows the implementation to track what you do and when you do it. If you could directly access the underlying state, the implementation would have no way to know what happened during the course of a transaction. This, in turn, would mean that the implementation would have to keep a copy of every bit of data that you read during a transaction, and then at commit / flush time compare the current values with the original values to figure out what to write back to the database. As it turns out, when you use OpenJPA, all your direct field accesses are replaced with synthetic static methods anyways, so from a performance standpoint, you'll see equivalent behavior either way. In my experience, persistent domain model field access performance in tight loops is rarely actually a performance bottleneck; it's almost always going back and forth to the database that ends up being the bottleneck, and thus the most important place to optimize. -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: Phill Moran [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 10:02 PM To: open-jpa-dev@incubator.apache.org Subject: Forced getter/setter access Can anyone explain why this rule is in effect: When using property access, only the getter and setter method for a property should ever access the underlying persistent field directly. Other methods, including internal business methods in the persistent class, should go through the getter and setter methods when manipulating persistent state. (section 2.1.4 OpenJPA manual) This seems rather execution costly. If ,for instance, I have a Size class with hieght, width and length then to calculate and return volume I suffer a three method call overhead: return getWidth() * getLength() * getHieght(); This is opposed to a more efficient Return height * width * length Phill 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: Forced getter/setter access
Granted, but with a reasonable implementation the cost should be low for: at commit / flush time compare the current values with the original values to figure out what to write back to the database. If you are going to issue tuned updates to the DB, determining what really changed (as opposed to what setter methods were called) can avoid unnecessary DB overheads. Anyway at the end of the day, you must use the getters/setters because the spec says so, and you should write portable apps where possible :-) -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 April 2007 5:21 p.m. To: open-jpa-dev@incubator.apache.org Subject: RE: Forced getter/setter access The main reason to support getter / setter access is for implementations that cannot intercept field accesses. So, the getters and setters are there so that the JPA implementation can create a subclass of your entity type (hence the no-final-classes rule) and track what happens as you invoke the setters and getters. In other words, your business methods become part of the JPA implementation's domain. So, when using property access, your contract with the JPA provider is that you'll access persistent attributes only through the setters and getters, which allows the implementation to track what you do and when you do it. If you could directly access the underlying state, the implementation would have no way to know what happened during the course of a transaction. This, in turn, would mean that the implementation would have to keep a copy of every bit of data that you read during a transaction, and then at commit / flush time compare the current values with the original values to figure out what to write back to the database. As it turns out, when you use OpenJPA, all your direct field accesses are replaced with synthetic static methods anyways, so from a performance standpoint, you'll see equivalent behavior either way. In my experience, persistent domain model field access performance in tight loops is rarely actually a performance bottleneck; it's almost always going back and forth to the database that ends up being the bottleneck, and thus the most important place to optimize. -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: Phill Moran [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 10:02 PM To: open-jpa-dev@incubator.apache.org Subject: Forced getter/setter access Can anyone explain why this rule is in effect: When using property access, only the getter and setter method for a property should ever access the underlying persistent field directly. Other methods, including internal business methods in the persistent class, should go through the getter and setter methods when manipulating persistent state. (section 2.1.4 OpenJPA manual) This seems rather execution costly. If ,for instance, I have a Size class with hieght, width and length then to calculate and return volume I suffer a three method call overhead: return getWidth() * getLength() * getHieght(); This is opposed to a more efficient Return height * width * length Phill 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: Forced getter/setter access
If you are going to issue tuned updates to the DB, determining what really changed (as opposed to what setter methods were called) can avoid unnecessary DB overheads. ... tuned for your implementation, that is. Often, business needs require that a transaction involves a large number of objects, and it would be unfortunate to have to compromise on transaction integrity just for the sake of a particular implementation. It's not just a matter of needing to periodically call flush() during a tx, but rather of having to design transactions that don't read too many objects. Happily, with OpenJPA, this is a non-issue, regardless of property or field access. -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: Evan Ireland [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 10:39 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Forced getter/setter access Granted, but with a reasonable implementation the cost should be low for: at commit / flush time compare the current values with the original values to figure out what to write back to the database. If you are going to issue tuned updates to the DB, determining what really changed (as opposed to what setter methods were called) can avoid unnecessary DB overheads. Anyway at the end of the day, you must use the getters/setters because the spec says so, and you should write portable apps where possible :-) -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 April 2007 5:21 p.m. To: open-jpa-dev@incubator.apache.org Subject: RE: Forced getter/setter access The main reason to support getter / setter access is for implementations that cannot intercept field accesses. So, the getters and setters are there so that the JPA implementation can create a subclass of your entity type (hence the no-final-classes rule) and track what happens as you invoke the setters and getters. In other words, your business methods become part of the JPA implementation's domain. So, when using property access, your contract with the JPA provider is that you'll access persistent attributes only through the setters and getters, which allows the implementation to track what you do and when you do it. If you could directly access the underlying state, the implementation would have no way to know what happened during the course of a transaction. This, in turn, would mean that the implementation would have to keep a copy of every bit of data that you read during a transaction, and then at commit / flush time compare the current values with the original values to figure out what to write back to the database. As it turns out, when you use OpenJPA, all your direct field accesses are replaced with synthetic static methods anyways, so from a performance standpoint, you'll see equivalent behavior either way. In my experience, persistent domain model field access performance in tight loops is rarely actually a performance bottleneck; it's almost always going back and forth to the database that ends up being the bottleneck, and thus the most important place to optimize. -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: Phill Moran [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 10:02 PM To: open-jpa-dev@incubator.apache.org Subject: Forced getter/setter access Can anyone explain why this rule is in effect: When using property access, only the getter and setter method for a property should ever access the underlying persistent field directly. Other methods, including internal business methods in the persistent class, should go through the getter and setter methods when manipulating persistent state. (section
