Re: Compiling (build all) in eclipse
Comments inlined... - Original Message - From: Phill Moran [EMAIL PROTECTED] To: open-jpa-dev@incubator.apache.org Sent: Tuesday, April 10, 2007 5:06 AM Subject: RE: Compiling (build all) in eclipse Eclipse clean workspace Import Maven generate project (eclipse:eclispe) Build all -- Error There is no enhancement being done here by the Enchancer, Eclipse is simply generating class files - I'd imagine that is causing the error. The same POM builds fine externally through mvn package What do you mean that POM 'builds' fine through 'mvn package' - do you have the OpenJPA Maven plugin set up to enhance classes. Other interesting points: I was getting a NPE from maven build so I turn off the maven builder but that had no effect. Have also tried clean then build all, and physically deleted all resources All openJPAXXX jar are in the lib (repository) I am certain this is a configuration problem. Just not sure what Phill -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: April 9, 2007 12:59 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Compiling (build all) in eclipse Hmm. It sounds like maybe the Persistable class hasn't been enhanced. It's a surprising error, but it looks like OpenJPA hasn't really gotten into the loop at this point, which would explain why you're not seeing anything more informative. Could this explain the situation? -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: Monday, April 09, 2007 9:50 AM To: open-jpa-dev@incubator.apache.org Subject: Compiling (build all) in eclipse Troubles continue Any suggestions for this problem in eclipse??? org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'personFactory' defined in file [C:\BidSpec\emall\development\emall\target\classes\application Context.xml]: Initialization of bean failed; nested exception is java.lang.NoSuchMethodError: ca.BidSpec.emall.persistence.Persistable.pcGetManagedFieldCount()I Caused by: java.lang.NoSuchMethodError: ca.BidSpec.emall.persistence.Persistable.pcGetManagedFieldCount()I at ca.BidSpec.emall.stores.Store.clinit(Store.java) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at $Proxy26.clinit(Unknown Source) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeCo nstructorAccessorI mpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Dele gatingConstructorA ccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:588) at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy( JdkDynamicAopProxy .java:115) at org.springframework.aop.framework.ProxyFactory.getProxy(ProxyF actory.java:110) at org.springframework.aop.framework.autoproxy.AbstractAutoProxyC reator.createProxy (AbstractAutoProxyCreator.java:401) at org.springframework.aop.framework.autoproxy.AbstractAutoProxyC reator.postProcess AfterInitialization(AbstractAutoProxyCreator.java:279) at org.springframework.beans.factory.support.AbstractAutowireCapa bleBeanFactory.app lyBeanPostProcessorsAfterInitialization(AbstractAutowireCapabl eBeanFactory.java: 318) at org.springframework.beans.factory.support.AbstractAutowireCapa bleBeanFactory.ini tializeBean(AbstractAutowireCapableBeanFactory.java:1119) at org.springframework.beans.factory.support.AbstractAutowireCapa bleBeanFactory.cre ateBean(AbstractAutowireCapableBeanFactory.java:431) at org.springframework.beans.factory.support.AbstractBeanFactory$ 1.getObject(Abstra ctBeanFactory.java:254) at org.springframework.beans.factory.support.DefaultSingletonBean Registry.getSingle ton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory. getBean(AbstractBe anFactory.java:251) at org.springframework.beans.factory.support.AbstractBeanFactory. getBean(AbstractBe anFactory.java:163) at org.springframework.beans.factory.support.AbstractAutowireCapa bleBeanFactory.aut owireByName(AbstractAutowireCapableBeanFactory.java:862) at org.springframework.beans.factory.support.AbstractAutowireCapa bleBeanFactory.pop ulateBean(AbstractAutowireCapableBeanFactory.java:810) at org.springframework.beans.factory.support.AbstractAutowireCapa
RE: Unit testing
Via test coverage reports would we not know what parts do not have corresponding tests and through commit history we would know who added the fix/feature. So before the next release we can gently remind the committers to submit the missing test. This is likely to be only the occasional committer problem as a regular committer would monitor the forward progress they would see that a test is missing and could add it - sort of its own reminder. Phill -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] Sent: April 10, 2007 10:41 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Unit testing +1. We can do a better job of adding unit tests. Is there a way to link automated checking with JIRA? For bugs, features, and improvements we'll want new unit tests. For other changes that don't require a JIRA report (build files, null checks etc) we won't require new tests. I'm not sure whether this approach would work if the JIRA report was resolved/closed without code changes (config issue, classpath problem, etc). Even if we can't automate the checking with JIRA and svn I think this is a good rule of thumb. Rather than policing every commit for unit tests we can just check JIRA reports. It also allows some leeway if you were to commit unit tests separately from the code changes. If you're reviewing the changes based primarily on the commit email it might be easier to have them separate. On 4/10/07, Kevin Sutter [EMAIL PROTECTED] wrote: Patrick, I agree with your concern. Early on, I was at fault a couple of times with integrating changes without a corresponding unit testcase. But, with gentle reminders by the OpenJPA community, I've started to remember. So, as a start, I would challenge everyone to start monitoring the commits and request appropriate unit tests if none were provided. Either by replying to openjpa-dev or directly to the JIRA issue. Maybe with enough public reminders, we'll start to get the point across. I do know that in some cases, creating a unit test for a specific bug is easier said than done. Since we are pulling OpenJPA into a larger product (WebSphere in my case), some of the test scenarios that uncover a bug are quite complicated and involved. Creating an individual unit testcase to reproduce the problem is more effort and when time is critical, we sometimes go for the quick fix, ensure we don't regress, and integrate the change. I'm not trying to justify the lack of unit tests for these situations, I'm just explaining some background on why it happens once in a while. As far as new features being integrated into OpenJPA, there should be no excuse for lack of unit tests. We need to provide repeatable testcases for these new features. If users are providing patches for these new features, then it's easy to stop the commit until testcases are provided. If new features are committed without corresponding testcases, should we back out the changes? I know that's kind of extreme, but it would make a point. Of course, then we get into the feature vs bug fix discussion, but if everyone works at providing unit tests, then it's a moot point. Kevin On 4/9/07, Patrick Linskey [EMAIL PROTECTED] wrote: It should be part of the commit acceptance process. I agree that it should be part of the process, but I hope that with sufficient discipline and attention, we can avoid having to enforce this via automated rules. I definitely make changes that don't merit unit tests, such as changes to localized strings, null checks, build file changes, etc. -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: Monday, April 09, 2007 10:02 AM To: open-jpa-dev@incubator.apache.org Subject: RE: Unit testing +1 It should be part of the commit acceptance process. Otherwise OpenJPA will loose out to other ORM tools that will be perceived as less buggy. What is used for coverage monitoring, clover? We should also use checkstyle to give some insight into the code as well Phill -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: April 9, 2007 12:51 PM To: open-jpa-dev@incubator.apache.org Subject: Unit testing Hi, I'm a bit concerned about the lack of unit tests being put into
Re: How to set the type of the DB-field using @Externalizer
I'm trying to use the @Externalizer annotation but have problems with the resulting type of the DB-field - it's always a byte-array. You shouldn't need the @Type annotation -- the type will be inferred from the return type of the externalizer method. Are you dropping the database table in between attempts? It's possible that if your first attempt resulted in a byte array column because of some misconfiguration, OpenJPA will think it is supposed to reuse that column on subsequent mapping attempts, because technically it can fit anything in a byte-array column. 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: Unit testing
+1 I like this idea you can't close the item without a test case. Phill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: April 10, 2007 11:25 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Unit testing I think we need to take responsibility for this individually. Test coverage reports usually show woeful under-testing, so it's really up to the developer to know whether a test case is needed or not. It might be necessary at times to commit an urgent fix without having a full test suite to prove that the fix works, but best practice is to provide a test case along with the fix. We could make a guideline that until a test case is checked in, the JIRA issue should remain open. And when reviewing others' work, the missing test case can be used as a reason to un-resolve an issue. But I agree with Kevin that integrating new features without test cases is evil. In my experience, reminders long after the issue is resolved don't really work that well. Craig On Apr 10, 2007, at 7:57 AM, Phill Moran wrote: Via test coverage reports would we not know what parts do not have corresponding tests and through commit history we would know who added the fix/feature. So before the next release we can gently remind the committers to submit the missing test. This is likely to be only the occasional committer problem as a regular committer would monitor the forward progress they would see that a test is missing and could add it - sort of its own reminder. Phill -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] Sent: April 10, 2007 10:41 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Unit testing +1. We can do a better job of adding unit tests. Is there a way to link automated checking with JIRA? For bugs, features, and improvements we'll want new unit tests. For other changes that don't require a JIRA report (build files, null checks etc) we won't require new tests. I'm not sure whether this approach would work if the JIRA report was resolved/closed without code changes (config issue, classpath problem, etc). Even if we can't automate the checking with JIRA and svn I think this is a good rule of thumb. Rather than policing every commit for unit tests we can just check JIRA reports. It also allows some leeway if you were to commit unit tests separately from the code changes. If you're reviewing the changes based primarily on the commit email it might be easier to have them separate. On 4/10/07, Kevin Sutter [EMAIL PROTECTED] wrote: Patrick, I agree with your concern. Early on, I was at fault a couple of times with integrating changes without a corresponding unit testcase. But, with gentle reminders by the OpenJPA community, I've started to remember. So, as a start, I would challenge everyone to start monitoring the commits and request appropriate unit tests if none were provided. Either by replying to openjpa-dev or directly to the JIRA issue. Maybe with enough public reminders, we'll start to get the point across. I do know that in some cases, creating a unit test for a specific bug is easier said than done. Since we are pulling OpenJPA into a larger product (WebSphere in my case), some of the test scenarios that uncover a bug are quite complicated and involved. Creating an individual unit testcase to reproduce the problem is more effort and when time is critical, we sometimes go for the quick fix, ensure we don't regress, and integrate the change. I'm not trying to justify the lack of unit tests for these situations, I'm just explaining some background on why it happens once in a while. As far as new features being integrated into OpenJPA, there should be no excuse for lack of unit tests. We need to provide repeatable testcases for these new features. If users are providing patches for these new features, then it's easy to stop the commit until testcases are provided. If new features are committed without corresponding testcases, should we back out the changes? I know that's kind of extreme, but it would make a point. Of course, then we get into the feature vs bug fix discussion, but if everyone works at providing unit tests, then it's a moot point. Kevin On 4/9/07, Patrick Linskey [EMAIL PROTECTED] wrote: It should be part of the commit acceptance process. I agree that it should be part of the process, but I hope that with sufficient discipline and attention, we can avoid having to enforce this via automated rules. I definitely make changes that don't merit unit tests, such as changes to localized strings, null checks, build file changes, etc. -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
RE: Unit testing
I think we need to take responsibility for this individually. Test coverage reports usually show woeful under-testing, so it's really up to the developer to know whether a test case is needed or not. Currently, this will definitely be the case in OpenJPA, since the bulk of the Kodo test cases were JDO-based, and we at BEA have not yet ported them out to OpenJPA. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 8:25 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Unit testing I think we need to take responsibility for this individually. Test coverage reports usually show woeful under-testing, so it's really up to the developer to know whether a test case is needed or not. It might be necessary at times to commit an urgent fix without having a full test suite to prove that the fix works, but best practice is to provide a test case along with the fix. We could make a guideline that until a test case is checked in, the JIRA issue should remain open. And when reviewing others' work, the missing test case can be used as a reason to un-resolve an issue. But I agree with Kevin that integrating new features without test cases is evil. In my experience, reminders long after the issue is resolved don't really work that well. Craig On Apr 10, 2007, at 7:57 AM, Phill Moran wrote: Via test coverage reports would we not know what parts do not have corresponding tests and through commit history we would know who added the fix/feature. So before the next release we can gently remind the committers to submit the missing test. This is likely to be only the occasional committer problem as a regular committer would monitor the forward progress they would see that a test is missing and could add it - sort of its own reminder. Phill -Original Message- From: Michael Dick [mailto:[EMAIL PROTECTED] Sent: April 10, 2007 10:41 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Unit testing +1. We can do a better job of adding unit tests. Is there a way to link automated checking with JIRA? For bugs, features, and improvements we'll want new unit tests. For other changes that don't require a JIRA report (build files, null checks etc) we won't require new tests. I'm not sure whether this approach would work if the JIRA report was resolved/closed without code changes (config issue, classpath problem, etc). Even if we can't automate the checking with JIRA and svn I think this is a good rule of thumb. Rather than policing every commit for unit tests we can just check JIRA reports. It also allows some leeway if you were to commit unit tests separately from the code changes. If you're reviewing the changes based primarily on the commit email it might be easier to have them separate. On 4/10/07, Kevin Sutter [EMAIL PROTECTED] wrote: Patrick, I agree with your concern. Early on, I was at fault a couple of times with integrating changes without a corresponding unit testcase. But, with gentle reminders by the OpenJPA community, I've started to remember. So, as a start, I would challenge everyone to start monitoring the commits and request appropriate unit tests if none were provided. Either by replying to openjpa-dev or directly to the JIRA issue. Maybe with enough public reminders, we'll start to get the point across. I do know that in some cases, creating a unit test for a specific bug is easier said than done. Since we are pulling OpenJPA into a larger product (WebSphere in my case), some of the test scenarios that uncover a bug are quite complicated and involved. Creating an individual unit testcase to reproduce the problem is more effort and when time is critical, we sometimes go for the quick fix, ensure we don't regress, and integrate the change. I'm not trying to justify the lack of unit tests for these situations, I'm just explaining some background on why it happens once in a while. As far as new features being integrated into OpenJPA, there should be no excuse for lack of unit tests. We need to provide repeatable testcases for these new features. If users are providing patches for these new features, then it's easy
[jira] Commented: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used
[
https://issues.apache.org/jira/browse/OPENJPA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487816
]
Abe White commented on OPENJPA-201:
---
I'm sorry, but I don't understand what you're trying to accomplish. You say
that Winery maps to two tables, but I don't see any SecondaryTable defined for
it. You give the results of various annotations, but I don't know what the
actual schema looks like or what relations you want mapped to what columns.
Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if
the table argument is used
-
Key: OPENJPA-201
URL: https://issues.apache.org/jira/browse/OPENJPA-201
Project: OpenJPA
Issue Type: Bug
Environment: 0.9.7-incubating-SNAPSHOT
Reporter: George Hongell
Priority: Minor
Attachments: Wine.java, Winery.java
@Entity
@Table(name=CxWine)
public class Wine {
@Id
private Integer wineid;
...
@ManyToOne()
@JoinColumn(name=NEW_WINERY_WINERYID, referencedColumnName=WINERYID,
table=cxWinery)
//ignored @JoinColumn(name=NEW_WINERY_WINERYID,
referencedColumnName=WINERYID, table=cxWinery)
//ignored @JoinColumn(name=NEW_WINERY_WINERYID,
referencedColumnName=WINERYID, table=cxWinery)
//ignored @JoinColumn(name=NEW_WINERY_WINERYID, table=cxWINERY)
//ok @JoinColumn(name=NEW_WINERY_WINERYID, referencedColumnName=wineryid)
//ok @JoinColumn(name=NEW_WINERY_WINERYID)
private Winery winery;
...
}
generates
2744 cxwineTour TRACE [main] openjpa.jdbc.SQL - t 1094861122, conn
98698722 executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT
NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER,
rating SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER,
alcoholPercent DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName
VARCHAR(40), labelWineClass VARCHAR(20), labelWineColor VARCHAR(20),
estateBottled SMALLINT, hasSulfites SMALLINT, labelid INTEGER, mlContents
INTEGER, qualityDesignation VARCHAR(40), vineyardName VARCHAR(40), vintage
TIMESTAMP, wineName VARCHAR(40), winery_wineryid INTEGER, PRIMARY KEY
(wineid))
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-91) java.lang.VerifyError on websphere after application reload
[ https://issues.apache.org/jira/browse/OPENJPA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487819 ] david zhang commented on OPENJPA-91: Hi, Patrick, what kind of DB2 driver info we should put into the config? DB2 connection pool driver class name? java.lang.VerifyError on websphere after application reload --- Key: OPENJPA-91 URL: https://issues.apache.org/jira/browse/OPENJPA-91 Project: OpenJPA Issue Type: Bug Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in Rational Developer 7 ( Websphere 6.1 test environment ) connected to Oracle 9.2 database. OS: WinXP SP2 Reporter: Anders Monrad Priority: Minor Fix For: 0.9.8 Hi .. Not sure if this is a bug or just the way websphere reacts to openjpa. I have a small test program using OpenJPA against an Oracle database. I am running this program in the Websphere 6.1 test environment included with Rational Developer 7. This is all working just fine. But when I make changes to some ressource in the application, the chagnes are automatically published to the test environment and the app is restarted. After this I get the Exception below, whenever I try to access an EntityManager. If I restart the entire server, the app is running fine again. So I guess this is related to restarting the application. Caused by: java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:59) at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:131) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:182) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.init(JDBCConfigurationImpl.java:110) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.init(JDBCConfigurationImpl.java:100) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.init(JDBCConfigurationImpl.java:91) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance(JDBCBrokerFactory.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.openjpa.kernel.Bootstrap.invokeFactory(Bootstrap.java:117) at org.apache.openjpa.kernel.Bootstrap.newBrokerFactory(Bootstrap.java:57) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:70) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:78) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60) at util.EntityManagerFactoryHelper.getEntityManagerFactory(EntityManagerFactoryHelper.java:22) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-211) CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97
[ https://issues.apache.org/jira/browse/OPENJPA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487822 ] david zhang commented on OPENJPA-211: - Hi, Patrick, do you have any working persistence.xml with DB2 on WebSphere 6.1 using DataSource? Getting all kind of IllegalArgumentException really frustrate me. CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97 - Key: OPENJPA-211 URL: https://issues.apache.org/jira/browse/OPENJPA-211 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.6 Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in Rational Developer 7 ( Websphere 6.1 test environment ) connected to DB2 V9.1. OS: WinXP SP2 Reporter: david zhang Priority: Blocker Fix For: 0.9.8 Attachments: applicationContext.xml, mytestdata.jar, persistence.xml Hi, if I use the OpenJPA shipped with Spring 2.0.3, I got the following error when start application: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 Caused by: java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:59) at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:131) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:182) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:154) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:145) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:114) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:106) at org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:92) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:214) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:251) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1143) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1110) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:431) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:244) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:233) at org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:205) at org.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAncestors(BeanFactoryUtils.java:292) at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:411) at
Re: How to set the type of the DB-field using @Externalizer
I can't reproduce this. When I leave out the @Persistent annotation on the field or replace it with @Basic, I do indeed end up with a binary column. But if I correctly include the @Persistent annotation along with the @Externalizer, I get a varchar column. Can you narrow down your entity to the smallest possible class that exhibits the problem and post it to the list so we can try to reproduce the error? 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: PCEnhance
On 4/10/07, Phill Moran [EMAIL PROTECTED] wrote: Through maven and eclipse. I have log level trace set in persistence.xml but that has no impact. Maven is reporting that PCEnhance is returning non-zero and no reason why. So trace is set on either CLI or maven (same thing really). I don't remember seeing it anywhere in the docs from maven is it in Configuration and what is the tag? Use property name=openjpa.Log value=DefaultLevel=TRACE,SQL=TRACE / in your persistence.xml file (I think SQL=TRACE is not necessary). I'm using OpenJPA 0.9.7-SNAPSHOT's PCEnhancer from within M2 with maven-antrun-plugin. It gives a lot of information, i.e. [java] 62 derbyPU TRACE [main] openjpa.MetaData - Found 3 classes with metadata in 0 milliseconds. [java] 62 derbyPU TRACE [main] openjpa.Tool - Enhancer running on type class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny. [java] 125 derbyPU TRACE [main] openjpa.MetaData - Loading metadata for class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny under mode [META]. [java] 140 derbyPU TRACE [main] openjpa.MetaData - Parsing class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny. [java] 140 derbyPU TRACE [main] openjpa.MetaData - Parsing package pl.jaceklaskowski.jpa.entity.PracownikSpecjalny. [java] 187 derbyPU TRACE [main] openjpa.MetaData - Generating default metadata for type pl.jaceklaskowski.jpa.entity.PracownikSpecjalny. [java] 187 derbyPU TRACE [main] openjpa.MetaData - Using reflection for metadata generation. [java] 218 derbyPU TRACE [main] openjpa.MetaData - Loading metadata for class pl.jaceklaskowski.jpa.entity.Osoba under mode [META]. [java] 218 derbyPU TRACE [main] openjpa.MetaData - Parsing class pl.jaceklaskowski.jpa.entity.Osoba. ... Lots of information to digest. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Testing an OpenJPA module
On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Can I reuse instances?
On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote: Hi Dain, On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote: On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote: Hi Dain, I haven't looked in detail at the life cycle of CMP beans in a couple of years, but in general you can't simply keep the state of the underlying Entities through the life cycle. CMP beans are pooled and reused in transaction contexts and you have to load the state at specific points in the life cycle. It depends on the commit option the container is using. In commit option A, you assume the cmp engine is the sole user of the database, so you don't need to load. Normally people use commit option B where you keep instances activated with a specific primary key and reload the data in each tx. Using the primary key stored in the CMP bean to do em.find at the appropriate time is the obvious way to take advantage of the em second level cache. To the extent that this is not efficient, we should fix it in the JPA layer not the CMP layer. I would prefer to keep as much of the CMP stuff on the CMP side as possible so the JPA implementation can focus on JPA issues. One of the assumption of JPA is that entities are light weight and cheap to create, so you take the safe route and construct a new one when every you need an instance. In CMP the assumption is that entity instances are expensive to create, so less safe route and you pool them. Reusing instances is really a CMP problem, but I don't think it can be implemented without the help of the JPA engine. I'm afraid we're getting wrapped around the axle on definitions. Here's what I'm trying to get across: CMP Entity Beans are expensive to create and there's a lot of required behavior to manage them. You pretty much have to implement the life cycle in the spec. It's your choice how to implement the state part of the beans. You can use wrappers around various kinds of state objects like ResultSet or generated classes that contain fields with the state. Your implementation uses JPA Entities to hold the state. These JPA Entities are not at all specified by CMP Entity Beans. JPA Entities as cheap to create so all you need to do is hold on to the ids and when you need state from the database, ask JPA EntityManager for the state. If the state is already in the second level cache, this is very cheap to access. In my implementation the CMP entity is the JPA entity. They are the same object. There are no state holders. We choose this design to easy the transition from CMP to JPA but has the drawback that we are completely reliant on the JPA implementation for instance management. -dain
Re: @Column with precision and scale - how does it work?
I don't think Derby supports specifying the precision on type DOUBLE (maybe
other datbases do).
You should be able to specify the precision through the @Column annotation.
I believe @Column(columnDefinition=DECIMAL(5,2)) will work. I'm not sure
whether precision=x, scale=y with a type that maps to DECIMAL instead of
DOUBLE.
On 4/10/07, Jacek Laskowski [EMAIL PROTECTED] wrote:
Hi,
I wonder how I could restrict what values are inserted into a table
using @Column(precision=5, scale=2). When does it matter?
I'm using OpenJPA 0.9.7-SNAPSHOT with Derby and with the following:
@Column(precision = 5, scale = 2)
public double getPensja() {
return pensja;
}
OpenJPA executes the following CREATE
2969 derbyPU TRACE [main] openjpa.jdbc.SQL - t 11533424, conn
18662247 executing stmnt 23119024 CREATE TABLE Osoba (numer BIGINT
NOT NULL, dzienImienin TIMESTAMP, dzienUrodzin
TIMESTAMP, imie VARCHAR(255), kraj VARCHAR(255), nazwisko
VARCHAR(255), wersja INTEGER, pensja DOUBLE, tytul VARCHAR(255),
PRIMARY KEY (numer))
How could I restrict the precision and scale of the pensja field? Is
the columnDefinition attribute of @Column the last resort? When is the
others used? What databases are supported?
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
--
-Michael Dick
Re: Testing an OpenJPA module
Lot's of things could have gone wrong: there might be no META-INF/ persistence.xml file at all, it could have listed a missing provider class, or it could have a valid class, but one that had problems loading (due to a missing dependency). On Apr 10, 2007, at 12:52 PM, Jacek Laskowski wrote: On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Can I reuse instances?
On Apr 9, 2007, at 12:41 PM, Patrick Linskey wrote: you need an instance. In CMP the assumption is that entity instances are expensive to create, so less safe route and you pool them. Reusing instances is really a CMP problem, but I don't think it can be implemented without the help of the JPA engine. ... but it's not the JPA-visible itself that is necessarily going to be heavyweight, these days. Maybe the proxies shepherding the instance through the CMP lifecycle will be heavyweight, or certain fields in the instance sourced from JNDI. My point is that if you're seeing a performance penalty from creating the actual instances themselves, I'd be interested in knowing what it is, because potentially we could address that problem directly. If the penalty is some other parts of the instantiation process, or the fetching of the data from the database, well, that could be less resolvable. When a CMP instance is created there are two callbacks setEntityContext (the entity now exists) and activate (the entity now has a primary key). Both of these callbacks are allowed to lookup stuff in JNDI like EJBs and JDBC connections. Some applications cache lots of data and some even cache data from databases. So it could be very expensive. For most apps, these callbacks are empty. How are you coding the interaction between the (oh-so-wonderfully- named) commit options and the JPA data cache? I'm not because my implementation didn't work. I tried to implement them by keeping cache of instances. Then when an instance if fetched, I would check the global cache, and if there was an instance available, I would call merge. Then if commit option B, I would do a refresh (reload?). The problem was that merge returned a new instance making my global cache useless. -dain
Three minor issues with the OpenJPA User's Guide.
Section 1.2 is as follows: 1.2. Final Entity classes may not be final. No method of an entity class can be final. Note OpenJPA supports final classes and final methods. This wording is rather confusing. According to section 1. About This Document, the document provides an overview of the JPA standard. If one were to assume that the Notes are OpenJPA specific, and the rest is an overview of the standard, this could be seen as the user's guide saying that OpenJPA is breaking specs. In section 2.12. Order By OpenJPA expands the available ordering syntax. See ??? in the Reference Guide for details. In section 2. Entity Lifecycle Management For a given entity A, the refresh method behaves as follows: If A is a new entity, it is ignored. However, the remove operation cascades as defined below. If A is an existing managed entity, its state is refreshed from the datastore. If A is a removed entity, it is ignored. If A is a detached entity, an IllegalArgumentException is thrown. The refresh operation recurses on all relation fields of A whose cascades include CascadeType.REFRESH. The problem line is If A is a new entity, it is ignored. However, the remove operation cascades as defined below. This could be a copy and paste mistake from the above discription of the remove method. -- View this message in context: http://www.nabble.com/Three-minor-issues-with-the-OpenJPA-User%27s-Guide.-tf3555411.html#a9927486 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: Can I reuse instances?
Hi Dain, On Apr 10, 2007, at 12:58 PM, Dain Sundstrom wrote: On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote: Hi Dain, On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote: On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote: Hi Dain, I haven't looked in detail at the life cycle of CMP beans in a couple of years, but in general you can't simply keep the state of the underlying Entities through the life cycle. CMP beans are pooled and reused in transaction contexts and you have to load the state at specific points in the life cycle. It depends on the commit option the container is using. In commit option A, you assume the cmp engine is the sole user of the database, so you don't need to load. Normally people use commit option B where you keep instances activated with a specific primary key and reload the data in each tx. Using the primary key stored in the CMP bean to do em.find at the appropriate time is the obvious way to take advantage of the em second level cache. To the extent that this is not efficient, we should fix it in the JPA layer not the CMP layer. I would prefer to keep as much of the CMP stuff on the CMP side as possible so the JPA implementation can focus on JPA issues. One of the assumption of JPA is that entities are light weight and cheap to create, so you take the safe route and construct a new one when every you need an instance. In CMP the assumption is that entity instances are expensive to create, so less safe route and you pool them. Reusing instances is really a CMP problem, but I don't think it can be implemented without the help of the JPA engine. I'm afraid we're getting wrapped around the axle on definitions. Here's what I'm trying to get across: CMP Entity Beans are expensive to create and there's a lot of required behavior to manage them. You pretty much have to implement the life cycle in the spec. It's your choice how to implement the state part of the beans. You can use wrappers around various kinds of state objects like ResultSet or generated classes that contain fields with the state. Your implementation uses JPA Entities to hold the state. These JPA Entities are not at all specified by CMP Entity Beans. JPA Entities as cheap to create so all you need to do is hold on to the ids and when you need state from the database, ask JPA EntityManager for the state. If the state is already in the second level cache, this is very cheap to access. In my implementation the CMP entity is the JPA entity. They are the same object. There are no state holders. Now I understand. I don't think the design works, from lots of different perspectives. We choose this design to easy the transition from CMP to JPA but has the drawback that we are completely reliant on the JPA implementation for instance management. I don't think the design can work. The CMP protocol requires separating the CMP instance from its state. You are generating the CMP concrete implementation class as part of deployment, and the concrete class needs to contain state or a reference to state. My experience is that keeping state directly in the CMP bean isn't likely to work well. Sorry for the distracting comments. I didn't imagine that you were trying to directly persist CMP beans. Craig -dain 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: @Column with precision and scale - how does it work?
On 4/10/07, Michael Dick [EMAIL PROTECTED] wrote: I don't think Derby supports specifying the precision on type DOUBLE (maybe other datbases do). You're right - it doesn't. You should be able to specify the precision through the @Column annotation. I believe @Column(columnDefinition=DECIMAL(5,2)) will work. DECIMAL is a synonim of NUMERIC and either works well. I'm not sure whether precision=x, scale=y with a type that maps to DECIMAL instead of DOUBLE. That's my question how OpenJPA recognizes whether the attributes should be used or not. I don't think precision and scale are not used at all. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
RE: PCEnhance
Thanks Jacek, I have that entry in there and believe the issue is with Eclipse/my development environment. You see it is stopping the build process before it gets to enhance as I get no messages from OpenJPA (or eclipse) at all. This has been so frustrating that I have stopped trying to fix it and have moved to using Maven to compile and test. It means I also lose the ability to trace but I have not progressed my project in almost three weeks trying to solve various stack issues. I have also posted a message in the eclipse forum but there seems to be less attention paid to that one than this. When I figure it out I will post the solution back to this forum for others to discover Thanks again, Phill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: April 10, 2007 3:48 PM To: open-jpa-dev@incubator.apache.org Subject: Re: PCEnhance On 4/10/07, Phill Moran [EMAIL PROTECTED] wrote: Through maven and eclipse. I have log level trace set in persistence.xml but that has no impact. Maven is reporting that PCEnhance is returning non-zero and no reason why. So trace is set on either CLI or maven (same thing really). I don't remember seeing it anywhere in the docs from maven is it in Configuration and what is the tag? Use property name=openjpa.Log value=DefaultLevel=TRACE,SQL=TRACE / in your persistence.xml file (I think SQL=TRACE is not necessary). I'm using OpenJPA 0.9.7-SNAPSHOT's PCEnhancer from within M2 with maven-antrun-plugin. It gives a lot of information, i.e. [java] 62 derbyPU TRACE [main] openjpa.MetaData - Found 3 classes with metadata in 0 milliseconds. [java] 62 derbyPU TRACE [main] openjpa.Tool - Enhancer running on type class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny. [java] 125 derbyPU TRACE [main] openjpa.MetaData - Loading metadata for class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny under mode [META]. [java] 140 derbyPU TRACE [main] openjpa.MetaData - Parsing class pl.jaceklaskowski.jpa.entity.PracownikSpecjalny. [java] 140 derbyPU TRACE [main] openjpa.MetaData - Parsing package pl.jaceklaskowski.jpa.entity.PracownikSpecjalny. [java] 187 derbyPU TRACE [main] openjpa.MetaData - Generating default metadata for type pl.jaceklaskowski.jpa.entity.PracownikSpecjalny. [java] 187 derbyPU TRACE [main] openjpa.MetaData - Using reflection for metadata generation. [java] 218 derbyPU TRACE [main] openjpa.MetaData - Loading metadata for class pl.jaceklaskowski.jpa.entity.Osoba under mode [META]. [java] 218 derbyPU TRACE [main] openjpa.MetaData - Parsing class pl.jaceklaskowski.jpa.entity.Osoba. ... Lots of information to digest. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: PCEnhance
On 4/10/07, Phill Moran [EMAIL PROTECTED] wrote: This has been so frustrating that I have stopped trying to fix it and have moved to using Maven to compile and test. It means I also lose the ability to trace but I have not progressed my project in almost three weeks trying to solve various stack issues. I have also posted a message in the eclipse forum but there seems to be less attention paid to that one than this. When I figure it out I will post the solution back to this forum for others to discover Why not to use the javaagent in Eclipse then and the PCEnhancer in production? Run your apps in Eclipse with the following setting in the VM arguments panel of the Run configuration of your choice. -javaagent:c:/.m2/org/apache/openjpa/openjpa-all/0.9.7-incubating-SNAPSHOT/openjpa-all-0.9.7-incubating-SNAPSHOT.jar You should change the path to your M2 repo, though. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
RE: Testing an OpenJPA module
The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode-store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Testing an OpenJPA module
On 4/10/07, Pinaki Poddar [EMAIL PROTECTED] wrote: The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode-store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked Thanks! I've never thought about such an exhaustive list of possible problems one might run into. Nice to keep it handy. When I first encountered this error, my interpreation was (b) from the way the message was worded. Perhaps it's because I'm a mere developer so the only answer I'd have given would've been c) yet I knew others were possible too (just I don't see them so often). Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Testing an OpenJPA module
FYI, Persistence is an open source project at Glassfish. Anyone, even an OpenJPA contributor, who wants to contribute to the project for example to improve the error messages, is welcome to look at the sources and provide a patch. I know people who will be happy to commit usability patches. ;-) Craig On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode-store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Three minor issues with the OpenJPA User's Guide.
OpenJPA expands the available ordering syntax. See ??? in the Reference Guide for details. I'm assuming this should be referring to our Large Result Set capabilities. LRS capabilities don't affect OrderBy. The note should be removed -- OpenJPA does not expand the OrderBy syntax. (Kodo does, and I believe this is an accidental holdover from Kodo.) 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: Three minor issues with the OpenJPA User's Guide.
On 4/10/07, Abe White [EMAIL PROTECTED] wrote: OpenJPA expands the available ordering syntax. See ??? in the Reference Guide for details. I'm assuming this should be referring to our Large Result Set capabilities. LRS capabilities don't affect OrderBy. The note should be removed -- OpenJPA does not expand the OrderBy syntax. (Kodo does, and I believe this is an accidental holdover from Kodo.) Ahhh... okay. Thanks for the clarification. I will just remove the reference.
Re: @Column with precision and scale - how does it work?
I'm sorry, I misunderstood your question. I'm afraid I don't know how we determine when to apply the scale and precision. In this case the value should be ignored, since there's no way to set it on the column. If the attribute was of type BigDecimal then I think the precision and scale should apply. The catch here is that it looks like we're mapping BigDecimal to DOUBLE so that won't work. I'll have to take a closer look to determine where that mapping occurs, and what the correct mapping(s) should be. Would you mind opening a JIRA report for the problem? http://issues.apache.org/jira/browse/OPENJPA -Mike On 4/10/07, Jacek Laskowski [EMAIL PROTECTED] wrote: On 4/10/07, Michael Dick [EMAIL PROTECTED] wrote: I don't think Derby supports specifying the precision on type DOUBLE (maybe other datbases do). You're right - it doesn't. You should be able to specify the precision through the @Column annotation. I believe @Column(columnDefinition=DECIMAL(5,2)) will work. DECIMAL is a synonim of NUMERIC and either works well. I'm not sure whether precision=x, scale=y with a type that maps to DECIMAL instead of DOUBLE. That's my question how OpenJPA recognizes whether the attributes should be used or not. I don't think precision and scale are not used at all. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
Hi Mike, Did you accidentally remove the licenses from the xml files??? Craig On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote: Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- examples/pom.xml URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- incubating/openjpa-examples/pom.xml? view=diffrev=527320r1=527319r2=527320 == --- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml (original) +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml Tue Apr 10 14:59:02 2007 @@ -1,22 +1,4 @@ -?xml version=1.0 encoding=UTF-8? -!-- - Copyright 2006 The Apache Software Foundation. - - Licensed under the Apache License, Version 2.0 (the License); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an AS IS BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. --- -project xmlns=http://maven.apache.org/POM/4.0.0; - xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; - xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http:// maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdorg.apache.openjpa/groupId artifactIdopenjpa-examples/artifactId @@ -27,7 +9,7 @@ parent groupIdorg.apache.openjpa/groupId artifactIdopenjpa/artifactId -version0.9.7-incubating-SNAPSHOT/version +version0.9.7-incubating/version 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: svn commit: r527320 [2/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
This checkin looks like a line ending mismatch. All xml files should be specified as eol-style native. Craig On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote: Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- project/pom.xml URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- incubating/openjpa-project/pom.xml? view=diffrev=527320r1=527319r2=527320 == --- incubator/openjpa/branches/0.9.7-incubating/openjpa-project/ pom.xml (original) +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-project/ pom.xml Tue Apr 10 14:59:02 2007 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: How to set the type of the DB-field using @Externalizer
Hello!
Am Dienstag, 10. April 2007 19:17 schrieb Abe White:
I can't reproduce this. When I leave out the @Persistent annotation
on the field or replace it with @Basic, I do indeed end up with a
binary column. But if I correctly include the @Persistent annotation
along with the @Externalizer, I get a varchar column. Can you narrow
down your entity to the smallest possible class that exhibits the
problem and post it to the list so we can try to reproduce the error?
Finally it works. After I've reduced the project to one class with
one field and using derby as DB the problem was still the same. So
I found the problem in the ant-file that did the enhance and mapping
tasks.
But I don't understand the problem - maybe you have an explaination.
The problem was the entry 'pathelement path=${java.class.path}/' in
the element classpath. After I removed this line in both tasks it worked.
Here is the ant-file:
---
project name=openjpa-test default=refresh
descriptionJPA test/description
target name=enhance
taskdef name=openjpac
classname=org.apache.openjpa.ant.PCEnhancerTask/
openjpac
config propertiesFile=META-INF/persistence.xml/
fileset dir=${basedir}
include name=domain/*.java /
/fileset
classpath
pathelement location=${basedir}/
pathelement path=${java.class.path}/
/classpath
/openjpac
/target
target name=refresh depends=enhance
taskdef name=mappingtool
classname=org.apache.openjpa.jdbc.ant.MappingToolTask/
mappingtool action=buildSchema
config propertiesFile=META-INF/persistence.xml/
fileset dir=${basedir}
include name=domain/*.java /
/fileset
classpath
pathelement location=${basedir}//
pathelement path=${java.class.path}/
/classpath
/mappingtool
/target
/project
---
my classpath is:
lib/commons-collections-3.2.jar
lib/commons-lang-2.1.jar
lib/commons-logging-1.0.4.jar
lib/commons-pool-1.3.jar
lib/derby-10.2.2.0.jar
lib/geronimo-j2ee-connector_1.5_spec-1.0.1.jar
lib/geronimo-jms_1.1_spec-1.0.1.jar
lib/geronimo-jpa_3.0_spec-1.0.jar
lib/geronimo-jta_1.0.1B_spec-1.0.1.jar
lib/openjpa-all-0.9.7-incubating-SNAPSHOT.jar
lib/postgresql-8.1-408.jdbc3.jar
lib/serp-1.11.0.jar
Thanks for your help
Lukas
[jira] Created: (OPENJPA-213) @Column with precision and scale should result in NUMERIC(precision, scale)
@Column with precision and scale should result in NUMERIC(precision, scale) --- Key: OPENJPA-213 URL: https://issues.apache.org/jira/browse/OPENJPA-213 Project: OpenJPA Issue Type: Improvement Components: jpa Affects Versions: 0.9.7 Reporter: Jacek Laskowski @Column provides the precision and scale attributes, but there's no (easy) way to figure out how it affects the way OpenJPA works if any. It looks like OpenJPA reads the type of a persistent field and when it's double it maps it to DOUBLE in Derby regardless of the other attributes. When precision and scale are specified, a DDL should use NUMERIC(precision, scale) or its synonim - DECIMAL(precision, scale). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: @Column with precision and scale - how does it work?
On 4/10/07, Michael Dick [EMAIL PROTECTED] wrote: Would you mind opening a JIRA report for the problem? http://issues.apache.org/jira/browse/OPENJPA https://issues.apache.org/jira/browse/OPENJPA-213 Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
Hi Craig, Well I didn't intentionally remove them :-). It looks like they were removed by the maven plugin and this is one of the automated commits that it does. Looks like another gotcha with the tool. I'm going to rollback the changes again and see if I can fix the endline and the copyright problems. For the time being I'll leave the artifacts on people.apache.org/~mikedd. There should be another set of commits coming through later tonight tonight. Thanks for noticing the copyright problem. On 4/10/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Mike, Did you accidentally remove the licenses from the xml files??? Craig On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote: Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- examples/pom.xml URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- incubating/openjpa-examples/pom.xml? view=diffrev=527320r1=527319r2=527320 == --- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml (original) +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml Tue Apr 10 14:59:02 2007 @@ -1,22 +1,4 @@ -?xml version=1.0 encoding=UTF-8? -!-- - Copyright 2006 The Apache Software Foundation. - - Licensed under the Apache License, Version 2.0 (the License); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an AS IS BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. --- -project xmlns=http://maven.apache.org/POM/4.0.0; - xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; - xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http:// maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdorg.apache.openjpa/groupId artifactIdopenjpa-examples/artifactId @@ -27,7 +9,7 @@ parent groupIdorg.apache.openjpa/groupId artifactIdopenjpa/artifactId -version0.9.7-incubating-SNAPSHOT/version +version0.9.7-incubating/version Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- -Michael Dick
[jira] Commented: (OPENJPA-212) Constructor expression permits no other expressions in SELECT clause
[ https://issues.apache.org/jira/browse/OPENJPA-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487948 ] Patrick Linskey commented on OPENJPA-212: - You don't have a test case handy for this by any chance, do you? Constructor expression permits no other expressions in SELECT clause Key: OPENJPA-212 URL: https://issues.apache.org/jira/browse/OPENJPA-212 Project: OpenJPA Issue Type: Bug Components: query Affects Versions: 0.9.7 Reporter: Jacek Laskowski It seems that it's impossible to run a query with constructor expression beside other expressions in SELECT clause. Take a look at the following test that finishes with ClassCastException when the first element of resultQuery is returned (the 2nd line of the snippet). Am I doing something plain wrong? It doesn't work with Hibernate EntityManager 3.3.1, either yet TopLink Essentials 2.0 BUILD 40 runs fine. Query query = em.createQuery(SELECT NEW pl.jaceklaskowski.jpa.PewnaKlasa(p.nazwa, o.imie, o.nazwisko, o.numer), o, p.nazwa FROM Projekt p JOIN p.chair o); ListObject[] resultQuery = query.getResultList(); final Object[] firstElementInQueryResult = resultQuery.get(0); assert firstElementInQueryResult.length == 3; final Object firstElement = resultQuery.get(0)[0]; assert firstElement instanceof PewnaKlasa; final Object secondElement = resultQuery.get(0)[1]; assert secondElement instanceof Osoba; final Object thirdElement = resultQuery.get(0)[2]; assert thirdElement instanceof String; The exception is as follows (the line number is different though as the test above is incomplete - no class, imports and alike are shown): java.lang.ClassCastException: pl.jaceklaskowski.jpa.PewnaKlasa at pl.jaceklaskowski.jpa.OpenJPATest.testConstructorExpr(OpenJPATest.java:19) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-91) java.lang.VerifyError on websphere after application reload
[ https://issues.apache.org/jira/browse/OPENJPA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487950 ] Patrick Linskey commented on OPENJPA-91: Hi, Patrick, what kind of DB2 driver info we should put into the config? DB2 connection pool driver class name? It depends on how you want the configuration to be structured. If you already have a data source defined within the application server, then you should provide its JNDI name. Otherwise, you can either provide direct connection URL / driver name / user credential information to OpenJPA, or provide a pooling data source configuration. java.lang.VerifyError on websphere after application reload --- Key: OPENJPA-91 URL: https://issues.apache.org/jira/browse/OPENJPA-91 Project: OpenJPA Issue Type: Bug Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in Rational Developer 7 ( Websphere 6.1 test environment ) connected to Oracle 9.2 database. OS: WinXP SP2 Reporter: Anders Monrad Priority: Minor Fix For: 0.9.8 Hi .. Not sure if this is a bug or just the way websphere reacts to openjpa. I have a small test program using OpenJPA against an Oracle database. I am running this program in the Websphere 6.1 test environment included with Rational Developer 7. This is all working just fine. But when I make changes to some ressource in the application, the chagnes are automatically published to the test environment and the app is restarted. After this I get the Exception below, whenever I try to access an EntityManager. If I restart the entire server, the app is running fine again. So I guess this is related to restarting the application. Caused by: java.lang.VerifyError: class loading constraint violated (class: org/apache/openjpa/kernel/BrokerImpl method: newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;) at pc: 0 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:59) at java.lang.J9VMInternals.initialize(J9VMInternals.java:120) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:131) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:182) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.init(JDBCConfigurationImpl.java:110) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.init(JDBCConfigurationImpl.java:100) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.init(JDBCConfigurationImpl.java:91) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance(JDBCBrokerFactory.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.openjpa.kernel.Bootstrap.invokeFactory(Bootstrap.java:117) at org.apache.openjpa.kernel.Bootstrap.newBrokerFactory(Bootstrap.java:57) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:70) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:78) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60) at util.EntityManagerFactoryHelper.getEntityManagerFactory(EntityManagerFactoryHelper.java:22) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OPENJPA-182: reuse Connection constants or create our own?
One note of caution about using enums - there can be a problem in passing enums from a client to a server using RMI-IIOP serialiazation - see GlassFish issue https://glassfish.dev.java.net/issues/show_bug.cgi?id=193 for some details. regards, -marina Abe White wrote: I think that JDBCFetchPlan should take a Java 5 enum, and JDBCFetchConfiguration should use the Connection values. Certainly JDBCFetchConfiguration should use the Connection values. I personally have never had a problem with symbolic constants for settings, but enums for the FetchPlan are cool too. So long as the JPA QueryImpl parses the enum value and its string form correctly when using it as a hint. 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: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
I'm optimistic that after we cut the release, we can just do a bulk integ to trunk. -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 10, 2007 4:29 PM To: open-jpa-dev@incubator.apache.org Subject: Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-jdbc-5/ openjpa-jdbc/ openjpa-kernel-5/ openjpa-ker I'll add the urls and licenses to the branch. With a little luck we can apply the same patch to trunk and save some effort. Maybe that's overly optimistic thinking on my part though. On 4/10/07, Patrick Linskey [EMAIL PROTECTED] wrote: Speaking of licenses, I just went through trunk to look for files that don't contain the URL of the license file. I got the following: ./openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/H2Dic tionary.ja va ./openjpa-jdbc/src/main/resources/META-INF/services/org.apache .openjpa.l ib.conf.ProductDerivation ./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/meta /java-keyw ords.rsrc ./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/sche ma/schemas -doctype.rsrc ./openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/sql/ sql-keywor ds.rsrc ./openjpa-kernel/src/main/java/org/apache/openjpa/conf/BrokerV alue.java ./openjpa-kernel/src/main/java/org/apache/openjpa/enhance/Refl ection.jav a ./openjpa-kernel/src/main/java/org/apache/openjpa/kernel/Final izingBroke rImpl.java ./openjpa-kernel/src/main/resources/META-INF/services/org.apac he.openjpa .kernel.exps.ExpressionParser ./openjpa-persistence/src/main/resources/META-INF/services/jav ax.persist ence.spi.PersistenceProvider ./openjpa-persistence/src/main/resources/META-INF/services/org .apache.op enjpa.lib.conf.ProductDerivation ./openjpa-persistence/src/main/resources/org/apache/openjpa/pe rsistence/ orm-xsd.rsrc ./openjpa-persistence/src/main/resources/org/apache/openjpa/pe rsistence/ persistence-xsd.rsrc ./openjpa-persistence-jdbc/src/main/resources/META-INF/service s/org.apac he.openjpa.lib.conf.ProductDerivation Some of these files are formats / get parsed in ways that do not allow comments, but certainly all of the Java files should have licenses in them. I would just add the license headers in myself, except that then you'd need to patch your branch; can you add the headers to the files in this list that support comments? There were also 22 files in openjpa-*/src/test directories that don't have the headers. I'm assuming that when we package up the source, we don't include the test classes, and am therefore leaving those files out. 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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 3:26 PM To: open-jpa-dev@incubator.apache.org Cc: open-jpa-commits@incubator.apache.org Subject: Re: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-jdbc-5/ openjpa-jdbc/ openjpa-kernel-5/ openjpa-kernel/ Hi Mike, Did you accidentally remove the licenses from the xml files??? Craig On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote: Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- examples/pom.xml URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- incubating/openjpa-examples/pom.xml? view=diffrev=527320r1=527319r2=527320
RE: OPENJPA-182: reuse Connection constants or create our own?
Fascinating. Happily, as it turns out, we never compare these things
directly; instead, we extract a value from the enums and use that. The
value is populated in the enum constructor:
public enum IsolationLevel {
DEFAULT(-1),
NONE(Connection.TRANSACTION_NONE),
READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
private final int _connectionConstant;
private IsolationLevel(int connectionConstant) {
_connectionConstant = connectionConstant;
}
protected int getConnectionConstant() {
return _connectionConstant;
}
}
Do you know if the getConnectionConstant() method would return the same
value for different instances of the same module?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 10, 2007 4:39 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: OPENJPA-182: reuse Connection constants or
create our own?
One note of caution about using enums - there can be a
problem in passing enums
from a client to a server using RMI-IIOP serialiazation - see
GlassFish issue
https://glassfish.dev.java.net/issues/show_bug.cgi?id=193 for
some details.
regards,
-marina
Abe White wrote:
I think that JDBCFetchPlan should take a Java 5 enum, and
JDBCFetchConfiguration should use the Connection values.
Certainly JDBCFetchConfiguration should use the Connection
values. I
personally have never had a problem with symbolic constants for
settings, but enums for the FetchPlan are cool too. So
long as the
JPA QueryImpl parses the enum value and its string form correctly
when using it as a hint.
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.
Re: OPENJPA-182: reuse Connection constants or create our own?
It should be ok anyway in the same VM. Unfortunately I had conflicting messages
on weather it's the name or the ordinal that is guaranteed to work across the
VMs :(.
-marina
Patrick Linskey wrote:
Fascinating. Happily, as it turns out, we never compare these things
directly; instead, we extract a value from the enums and use that. The
value is populated in the enum constructor:
public enum IsolationLevel {
DEFAULT(-1),
NONE(Connection.TRANSACTION_NONE),
READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
private final int _connectionConstant;
private IsolationLevel(int connectionConstant) {
_connectionConstant = connectionConstant;
}
protected int getConnectionConstant() {
return _connectionConstant;
}
}
Do you know if the getConnectionConstant() method would return the same
value for different instances of the same module?
-Patrick
Re: Testing an OpenJPA module
It's pretty much defined by the spec that Persistence class just delegates to the providers to do the work and has no way to report the errors: 7.2 Bootstrapping in Java SE Environments The Persistence bootstrap class will locate all of the persistence providers ... and call createEntityManagerFactory() on them in turn until an appropriate backing provider returns an EntityManagerFactory. ... If a provider does not qualify as the provider for the named persistence unit, it must return null when createEntityManagerFactory is invoked on it. regards, -marina Craig L Russell wrote: FYI, Persistence is an open source project at Glassfish. Anyone, even an OpenJPA contributor, who wants to contribute to the project for example to improve the error messages, is welcome to look at the sources and provide a patch. I know people who will be happy to commit usability patches. ;-) Craig On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode-store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
RE: OPENJPA-182: reuse Connection constants or create our own?
As long as any given enum instance that corresponds to a
theoretically-unique enum value has internally-consistent state, we
should be in good shape. IOW, if the enum constructors are called
appropriately or internal state is otherwise maintained, then things
should work out fine.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 10, 2007 4:56 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: OPENJPA-182: reuse Connection constants or
create our own?
It should be ok anyway in the same VM. Unfortunately I had
conflicting messages
on weather it's the name or the ordinal that is guaranteed to
work across the
VMs :(.
-marina
Patrick Linskey wrote:
Fascinating. Happily, as it turns out, we never compare these things
directly; instead, we extract a value from the enums and
use that. The
value is populated in the enum constructor:
public enum IsolationLevel {
DEFAULT(-1),
NONE(Connection.TRANSACTION_NONE),
READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
private final int _connectionConstant;
private IsolationLevel(int connectionConstant) {
_connectionConstant = connectionConstant;
}
protected int getConnectionConstant() {
return _connectionConstant;
}
}
Do you know if the getConnectionConstant() method would
return the same
value for different instances of the same module?
-Patrick
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
Re: Can I reuse instances?
On Apr 10, 2007, at 1:24 PM, Craig L Russell wrote: Hi Dain, On Apr 10, 2007, at 12:58 PM, Dain Sundstrom wrote: On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote: Hi Dain, On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote: On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote: Hi Dain, I haven't looked in detail at the life cycle of CMP beans in a couple of years, but in general you can't simply keep the state of the underlying Entities through the life cycle. CMP beans are pooled and reused in transaction contexts and you have to load the state at specific points in the life cycle. It depends on the commit option the container is using. In commit option A, you assume the cmp engine is the sole user of the database, so you don't need to load. Normally people use commit option B where you keep instances activated with a specific primary key and reload the data in each tx. Using the primary key stored in the CMP bean to do em.find at the appropriate time is the obvious way to take advantage of the em second level cache. To the extent that this is not efficient, we should fix it in the JPA layer not the CMP layer. I would prefer to keep as much of the CMP stuff on the CMP side as possible so the JPA implementation can focus on JPA issues. One of the assumption of JPA is that entities are light weight and cheap to create, so you take the safe route and construct a new one when every you need an instance. In CMP the assumption is that entity instances are expensive to create, so less safe route and you pool them. Reusing instances is really a CMP problem, but I don't think it can be implemented without the help of the JPA engine. I'm afraid we're getting wrapped around the axle on definitions. Here's what I'm trying to get across: CMP Entity Beans are expensive to create and there's a lot of required behavior to manage them. You pretty much have to implement the life cycle in the spec. It's your choice how to implement the state part of the beans. You can use wrappers around various kinds of state objects like ResultSet or generated classes that contain fields with the state. Your implementation uses JPA Entities to hold the state. These JPA Entities are not at all specified by CMP Entity Beans. JPA Entities as cheap to create so all you need to do is hold on to the ids and when you need state from the database, ask JPA EntityManager for the state. If the state is already in the second level cache, this is very cheap to access. In my implementation the CMP entity is the JPA entity. They are the same object. There are no state holders. Now I understand. I don't think the design works, from lots of different perspectives. We choose this design to easy the transition from CMP to JPA but has the drawback that we are completely reliant on the JPA implementation for instance management. I don't think the design can work. The CMP protocol requires separating the CMP instance from its state. You are generating the CMP concrete implementation class as part of deployment, and the concrete class needs to contain state or a reference to state. My experience is that keeping state directly in the CMP bean isn't likely to work well. Sorry for the distracting comments. I didn't imagine that you were trying to directly persist CMP beans. I can assure the design works. -dain
RE: Testing an OpenJPA module
provide a patch. Will such a patch be given to Glassfish project? But some kind of committer-level privilege will be required, i suppose. have added few more informative messages to distinguish between different ways persistence unit creation/ lookup can fail. please advise on how to proceed on contributing a patch. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 4:14 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module FYI, Persistence is an open source project at Glassfish. Anyone, even an OpenJPA contributor, who wants to contribute to the project for example to improve the error messages, is welcome to look at the sources and provide a patch. I know people who will be happy to commit usability patches. ;-) Craig On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode-store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
