objectbridge-developers Mailing List for ObJectRelationalBridge (Page 9)
Brought to you by:
thma
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(33) |
Feb
(8) |
Mar
(3) |
Apr
(1) |
May
(18) |
Jun
(6) |
Jul
(15) |
Aug
(71) |
Sep
(29) |
Oct
(43) |
Nov
(77) |
Dec
(54) |
2002 |
Jan
(54) |
Feb
(147) |
Mar
(144) |
Apr
(163) |
May
(307) |
Jun
(240) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Galvin H. <gk...@ya...> - 2002-06-05 00:51:51
|
Encountered a null pointer exception that manifests itself when attempting to update a m:n relationship while using ODMG API - this is manifested in both TransactionImpl and ObjectReferenceDescriptor. In TransactionImpl: as it attempts to retrieve getforeignKeyfielddescriptors() from CollectionDescriptor(), the call can throw a null pointer exception. However, suppose that the CollectionDescriptor (ObjectReferenceDescriptor descendant) has its m_ForeignKeyFields not set or initialized. In fact, m_ForeignKeyFields are initialized only if addForeignKeyField() is called. Therefore, when getForeignKeyFieldDescriptors() is called, this code gets executed: Vector v = getForeignKeyFields(); /* WHAT HAPPENS IF v is NULL? NPE*/ // 2. get FieldDescriptor for each index from Class-descriptor Vector ret = new Vector(); Iterator iter = v.iterator(); while (iter.hasNext()) { Integer index = (Integer) iter.next(); ret.add(mif.getFieldDescriptorByIndex(index.intValue())); } TransactionImpl: ClassDescriptor itemCld = this.getBroker().getClassDescriptor(cds.getItemClass()); Object[] objPkValues = cld.getKeyValues(newTxObject); /* BEGIN NULL POINTER EXCEPTION THREAT */ FieldDescriptor[] itemFkFields = cds.getForeignKeyFieldDescriptors(itemCld); /* END NULL POINTER EXCEPTION THREAT */ while (colIterator.hasNext()) { Object item = colIterator.next(); // provide all items in collection attributes // with foreign key information before locking them! for (int j = 0; j < itemFkFields.length; j++) { FieldDescriptor fld = itemFkFields[j]; fld.getPersistentField().set(item, objPkValues[j]); } lock(item, lockMode); } Possible fix(es): 1) Have the m_ForeignKeyFields initialized and instantiated in the ObjectReferenceDescriptor() constructor 2) Modify TransactionImpl to detect whether or not a CollectionDescriptor has any fieldDescriptors at all - if not just call lock(item, lockMode). If so, provide all items in collection attributes with foreign key information before locking them. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Matthew b. <mat...@ya...> - 2002-06-04 22:15:51
|
+1 for b, and maybe do the code beautifier to remove extra lines at the same time :) tr...@th... wrote: +1 for b Travis ---- Original Message ---- From: Thomas Mahler Sent: 2002-06-04 To: Jason van Zyl , ojb Subject: [OJB-developers] Shifting to Jakarta Hi Jason, I fixed all the problems at last and released ojb-0-9 today! So now we can begin our shift to Jakarta. 1. The OJB developer list. below you find a list of our active developers. Please set up CVS on the jakarta servers for all of them. armin_w (armin waibel) arobinson (Andrew Robinson) baserose (Leandro Rodrigo Saad Cruz) brj (Jakob Braeuchi) ceperez (Carlos E. Perez) cgreenlee (Chris Greenlee) chrath (Christian Rath) dariusschier (Darius Schier) dpeugh (David Dixon-Peugh) florianbruckner (Florian Bruckner) gcole (George Cole) hhoang (Hai Hoang) jvanzyl (Jason van Zyl) mattbaird (Matthew Baird) mpoeschl (Martin Poeschl) neoflux (Matthew Porter) olegnitz (Oleg Nitz) pinkcoder (Angela Robertson) prophecyslides (Travis Reeder) saua (Joachim Sauer) thma (Thomas Mahler) vtx1800 (Dale Davis) The sourceforge account is also the email account (user vtx1800 can be reached by vt...@us...). [I removed two accounts, namely bigrana (Daniele de Petris) garf (Jon Garfunkel) as they have been absent for more than year now. ] 2. Moving of the code This may be a bit tricky as there is permanent activity on our CVS repository. I see two options: a. start to migrate the ojb0.9 state of the repository (marked by a version lable "rel-0-9") to see if everything is OK. If everything is fine we can checking the changes since rel-0-9. This approach will allow developers to checkin stuff while you set up everything in parallel. Disadvantage: getting things in sync will be quite a burden. b. we have to define a frozen zone where no one should checkin stuff into the *old* sf repository. You do the migration of the code. After you have finished this job, everyone is informed to work against the *new* repository. This will reduce migration problems like running out of sync. Disadvantage: the developers can't check in code for some time. (I vote for b. But of course it's up to you.) I hope I did not forget any important issues :-) thanks for your help, Thomas _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers --------------------------------- Do You Yahoo!? Sign-up for Video Highlights of 2002 FIFA World Cup |
From: Oleg N. <on...@uk...> - 2002-06-04 22:14:24
|
+1 for b) e-mail: on...@uk... I'd like to get cvs e-mail notifications if possible. Regards, Oleg On Tuesday 04 June 2002 23:58, Thomas Mahler wrote: > Hi Jason, > > I fixed all the problems at last and released ojb-0-9 today! > So now we can begin our shift to Jakarta. > > 1. The OJB developer list. below you find a list of our active > developers. Please set up CVS on the jakarta servers for all of them. > > armin_w (armin waibel) > arobinson (Andrew Robinson) > baserose (Leandro Rodrigo Saad Cruz) > brj (Jakob Braeuchi) > ceperez (Carlos E. Perez) > cgreenlee (Chris Greenlee) > chrath (Christian Rath) > dariusschier (Darius Schier) > dpeugh (David Dixon-Peugh) > florianbruckner (Florian Bruckner) > gcole (George Cole) > hhoang (Hai Hoang) > jvanzyl (Jason van Zyl) > mattbaird (Matthew Baird) > mpoeschl (Martin Poeschl) > neoflux (Matthew Porter) > olegnitz (Oleg Nitz) > pinkcoder (Angela Robertson) > prophecyslides (Travis Reeder) > saua (Joachim Sauer) > thma (Thomas Mahler) > vtx1800 (Dale Davis) > > The sourceforge account is also the email account (user vtx1800 can be > reached by vt...@us...). > > [I removed two accounts, namely > bigrana (Daniele de Petris) > garf (Jon Garfunkel) > as they have been absent for more than year now. ] > > 2. Moving of the code > This may be a bit tricky as there is permanent activity on our CVS > repository. > I see two options: > > a. start to migrate the ojb0.9 state of the repository (marked by a > version lable "rel-0-9") to see if everything is OK. > If everything is fine we can checking the changes since rel-0-9. > This approach will allow developers to checkin stuff while you set up > everything in parallel. Disadvantage: getting things in sync will be > quite a burden. > > b. we have to define a frozen zone where no one should checkin stuff > into the *old* sf repository. You do the migration of the code. > After you have finished this job, everyone is informed to work against > the *new* repository. > This will reduce migration problems like running out of sync. > Disadvantage: the developers can't check in code for some time. > > (I vote for b. But of course it's up to you.) > > I hope I did not forget any important issues :-) > > thanks for your help, > > Thomas > > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
From: Jason v. Z. <jv...@ze...> - 2002-06-04 21:29:03
|
On Tue, 2002-06-04 at 17:18, Thomas Mahler wrote: > Hi Jason, Hi Martin > > Jason van Zyl wrote: > > > Hi Thomas, > > > > Is the testbed working with Maven. I just released another version of > > Maven and it's stable now and the upgrade path in the future will be > > completely stable. > > > I installed Maven beta 4. But I'm still not sure what is expected to > happen by the build-maven.xml script. > > when I call ant -f build-maven.xml, the script executes several > (Torque)-tasks sucessfully: > prepare-tests: > project-sql-classpath: > project-create-db-classpath: > project-datasql-classpath: > project-insert-sql: > > Then it reaches the target maven:jar which fails with the following error: > maven:jar: > As part of the move to Jakarta I will clean up the project.xml descriptor. I haven't updated it for the release of b4. I leave both build systems in there for now and when the code is moved over I'll take care of it. > > Thomas -- jvz. Jason van Zyl jv...@ap... http://tambora.zenplex.org |
From: <tr...@th...> - 2002-06-04 21:28:13
|
+1 for b Travis ---- Original Message ---- From: Thomas Mahler <tho...@ho...> Sent: 2002-06-04 To: Jason van Zyl <jv...@ze...>, ojb <obj...@li...> Subject: [OJB-developers] Shifting to Jakarta Hi Jason, I fixed all the problems at last and released ojb-0-9 today! So now we can begin our shift to Jakarta. 1. The OJB developer list. below you find a list of our active developers. Please set up CVS on the jakarta servers for all of them. armin_w (armin waibel) arobinson (Andrew Robinson) baserose (Leandro Rodrigo Saad Cruz) brj (Jakob Braeuchi) ceperez (Carlos E. Perez) cgreenlee (Chris Greenlee) chrath (Christian Rath) dariusschier (Darius Schier) dpeugh (David Dixon-Peugh) florianbruckner (Florian Bruckner) gcole (George Cole) hhoang (Hai Hoang) jvanzyl (Jason van Zyl) mattbaird (Matthew Baird) mpoeschl (Martin Poeschl) neoflux (Matthew Porter) olegnitz (Oleg Nitz) pinkcoder (Angela Robertson) prophecyslides (Travis Reeder) saua (Joachim Sauer) thma (Thomas Mahler) vtx1800 (Dale Davis) The sourceforge account is also the email account (user vtx1800 can be reached by vt...@us...). [I removed two accounts, namely bigrana (Daniele de Petris) garf (Jon Garfunkel) as they have been absent for more than year now. ] 2. Moving of the code This may be a bit tricky as there is permanent activity on our CVS repository. I see two options: a. start to migrate the ojb0.9 state of the repository (marked by a version lable "rel-0-9") to see if everything is OK. If everything is fine we can checking the changes since rel-0-9. This approach will allow developers to checkin stuff while you set up everything in parallel. Disadvantage: getting things in sync will be quite a burden. b. we have to define a frozen zone where no one should checkin stuff into the *old* sf repository. You do the migration of the code. After you have finished this job, everyone is informed to work against the *new* repository. This will reduce migration problems like running out of sync. Disadvantage: the developers can't check in code for some time. (I vote for b. But of course it's up to you.) I hope I did not forget any important issues :-) thanks for your help, Thomas _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
From: Thomas M. <tho...@ho...> - 2002-06-04 21:18:28
|
Hi Jason, Hi Martin Jason van Zyl wrote: > Hi Thomas, > > Is the testbed working with Maven. I just released another version of > Maven and it's stable now and the upgrade path in the future will be > completely stable. I installed Maven beta 4. But I'm still not sure what is expected to happen by the build-maven.xml script. when I call ant -f build-maven.xml, the script executes several (Torque)-tasks sucessfully: prepare-tests: project-sql-classpath: project-create-db-classpath: project-datasql-classpath: project-insert-sql: Then it reaches the target maven:jar which fails with the following error: maven:jar: BUILD FAILED /home/tom/ojb-1-0/build-maven.xml:139: Target `jar' does not exist in this project. I don't know if this expected! I also don't know how I can use Maven to generate html documentation (and the website) from the xdoc that Martin provided! I tried several things like: ant -f build-maven.xml maven:docs Buildfile: build-maven.xml maven:docs: BUILD FAILED /home/tom/ojb-1-0/build-maven.xml:154: java.io.FileNotFoundException: /home/tom/ojb-1-0/build-docs.xml (Datei oder Verzeichnis nicht gefunden) I really would appreciate to use the new layout Martin showed under: http://jakarta.apache.org/~mpoeschl/ojb. But I did not find any means to build it. (Building HTML doumentation is somewhat urgent for me, as I want to work on the documentation a lot for the 1.0 release.) > I am going to upgrade the descriptor in the repo as I > would prefer if this was the default build method when the code is moved > over to Jakarta. Now that almost everything has been cleaned up in Maven > in this release I feel more comfortable pushing. Continuous Integration > will soon be available with Maven :-) > Once we can do everything with Maven and Torque, what we have been doing with my old ant script and our db-setup.sql, we should of course use it. But we should wait with dropping the old stuff until the new scripts are working without problems. > We are also adding some testing features today that will make group > testing and single class testing easier. When you run a group of tests, > the default, a set of reports are generated. When you run a single test > the output is displayed on the console. > > At any rate I will update the descriptor in the repo today to match the > official release, unless Martin has already done it. > > As a side note, if anyone else from this group wants to try Maven I > would be glad to help setup any projects that you might want to convert. > > cheers, Thomas |
From: Jason v. Z. <jv...@ze...> - 2002-06-04 21:10:51
|
On Tue, 2002-06-04 at 16:58, Thomas Mahler wrote: > Hi Jason, > > I fixed all the problems at last and released ojb-0-9 today! > So now we can begin our shift to Jakarta. > > 1. The OJB developer list. below you find a list of our active > developers. Please set up CVS on the jakarta servers for all of them. > > armin_w (armin waibel) > arobinson (Andrew Robinson) > baserose (Leandro Rodrigo Saad Cruz) > brj (Jakob Braeuchi) > ceperez (Carlos E. Perez) > cgreenlee (Chris Greenlee) > chrath (Christian Rath) > dariusschier (Darius Schier) > dpeugh (David Dixon-Peugh) > florianbruckner (Florian Bruckner) > gcole (George Cole) > hhoang (Hai Hoang) > jvanzyl (Jason van Zyl) > mattbaird (Matthew Baird) > mpoeschl (Martin Poeschl) > neoflux (Matthew Porter) > olegnitz (Oleg Nitz) > pinkcoder (Angela Robertson) > prophecyslides (Travis Reeder) > saua (Joachim Sauer) > thma (Thomas Mahler) > vtx1800 (Dale Davis) Looks good. In addition can each of send me the email address you check if you don't check your sourceforge account. > The sourceforge account is also the email account (user vtx1800 can be > reached by vt...@us...). > > [I removed two accounts, namely > bigrana (Daniele de Petris) > garf (Jon Garfunkel) > as they have been absent for more than year now. ] > > 2. Moving of the code > This may be a bit tricky as there is permanent activity on our CVS > repository. > I see two options: > > a. start to migrate the ojb0.9 state of the repository (marked by a > version lable "rel-0-9") to see if everything is OK. > If everything is fine we can checking the changes since rel-0-9. > This approach will allow developers to checkin stuff while you set up > everything in parallel. Disadvantage: getting things in sync will be > quite a burden. > > b. we have to define a frozen zone where no one should checkin stuff > into the *old* sf repository. You do the migration of the code. > After you have finished this job, everyone is informed to work against > the *new* repository. > This will reduce migration problems like running out of sync. > Disadvantage: the developers can't check in code for some time. > > (I vote for b. But of course it's up to you.) Plan b. is usally better. I will set up all the accounts and wait for every to receive their initial password. At this point we declare the repository frozen and I will move the code. I'm not like the sourceforge admins, I can move the repository and have it up and running in 30 minutes. > I hope I did not forget any important issues :-) I think everything is good. > thanks for your help, No problem :-) > Thomas > > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers -- jvz. Jason van Zyl jv...@ap... http://tambora.zenplex.org |
From: Thomas M. <tho...@ho...> - 2002-06-04 20:58:37
|
Hi Jason, I fixed all the problems at last and released ojb-0-9 today! So now we can begin our shift to Jakarta. 1. The OJB developer list. below you find a list of our active developers. Please set up CVS on the jakarta servers for all of them. armin_w (armin waibel) arobinson (Andrew Robinson) baserose (Leandro Rodrigo Saad Cruz) brj (Jakob Braeuchi) ceperez (Carlos E. Perez) cgreenlee (Chris Greenlee) chrath (Christian Rath) dariusschier (Darius Schier) dpeugh (David Dixon-Peugh) florianbruckner (Florian Bruckner) gcole (George Cole) hhoang (Hai Hoang) jvanzyl (Jason van Zyl) mattbaird (Matthew Baird) mpoeschl (Martin Poeschl) neoflux (Matthew Porter) olegnitz (Oleg Nitz) pinkcoder (Angela Robertson) prophecyslides (Travis Reeder) saua (Joachim Sauer) thma (Thomas Mahler) vtx1800 (Dale Davis) The sourceforge account is also the email account (user vtx1800 can be reached by vt...@us...). [I removed two accounts, namely bigrana (Daniele de Petris) garf (Jon Garfunkel) as they have been absent for more than year now. ] 2. Moving of the code This may be a bit tricky as there is permanent activity on our CVS repository. I see two options: a. start to migrate the ojb0.9 state of the repository (marked by a version lable "rel-0-9") to see if everything is OK. If everything is fine we can checking the changes since rel-0-9. This approach will allow developers to checkin stuff while you set up everything in parallel. Disadvantage: getting things in sync will be quite a burden. b. we have to define a frozen zone where no one should checkin stuff into the *old* sf repository. You do the migration of the code. After you have finished this job, everyone is informed to work against the *new* repository. This will reduce migration problems like running out of sync. Disadvantage: the developers can't check in code for some time. (I vote for b. But of course it's up to you.) I hope I did not forget any important issues :-) thanks for your help, Thomas |
From: Jakob B. <jbr...@ho...> - 2002-06-04 17:34:18
|
hi georg, you're right. there's no testcase for reference proxy the problem is caused by the wrong class being used to build the proxy. the bug is fixed by : ... if (rds.isLazy()) { referencedProxy = getClassDescriptor(referencedClass).getDynamicProxyClass(); } ... in method getReferencedObject() of PersistenceBrokerImpl. i'll do some testing tomorrow morning , and check it in if all goes well. hth jakob ----- Original Message ----- From: "Georg Schneider" <ge...@me...> To: "Mahler Thomas" <tho...@it...> Cc: <obj...@li...> Sent: Tuesday, June 04, 2002 4:30 PM Subject: [OJB-developers] reference proxies not working > Hi Thomas, > > I just tried out the new release and I noticed that reference proxies are > still not working due to a bug I mentioned in the following posting > > http://sourceforge.net/mailarchive/forum.php?thread_id=664723&forum_id=4880 > > Please correct me if I am wrong, but there seems to be no testcase testing > reference proxies, so I constructed one and attached it to this posting. > If you run that testcase you should see an IllegalArgumentException being > thrown, which should disappear when fixing the code as mentioned in the > posting (btw, there is a typo in my posting, it should be > referencedProxy=null, and not referenceProxy=null :-) ) > > The get the testcase running you have to do 3 things: > > 1.) put the ArticleWithReferenceProxy.java file from the attachement into > the test/ojb/broker/ directory (the class simply extends Article, so I can > put a new mapping into the repository) > > 2.) add the mapping-xml from the attachement to the repository_junit.xml > file. The mapping is basically a copy of the mapping for the > Article-class, the major difference being the addition of proxy="true" for the reference-descriptor > for productGroup > > 3.) add the method testReferenceProxies() from the attachement to the > ProxyExample class in the test/ojb/broker/ directory > > > Cheers > > Georg > |
From: Matthew B. <ma...@so...> - 2002-06-04 16:40:30
|
Known issue. I started the JCA and finished it before jboss finished "fixing" how they did connections in the db, which then broke the jca. In the meanwhile, I refactored OJB to not be PB==connection, so it would work in a managed environment. I never got around to fixing the JCA. I did, however, check in an MBEAN for integrating into JBoss that is working nicely. Look for tested, correct JCA in a week or so. -----Original Message----- From: Fin Steenbjerg [mailto:fs...@pi...] Sent: Tuesday, June 04, 2002 8:15 AM To: obj...@li... Subject: [OJB-developers] JBOSS Connector Problem Hi We are trying to get the new J2EE connector (the latest source from the trunk) to work with JBOSS 3.0 RC1. I have successfully deployed the connector and created a test session bean with container managed transactions. The bean does the following tasks: 1. gets the Implementation from JNDI 2. calls newDatabase at the implementation object 3. calls makePersistent at the database 4. closes the database. It seems like there are some problems with the transaction handling. The transactions are committed twice. The first time the commit is called the call sequence is as follows: ojb.odmg.TransactionImpl.commit(TransactionImpl.java:375) ojb.odmg.J2EETransactionImpl.commit(J2EETransactionImpl.java:107) ojb.odmg.J2EETransactionImpl.beforeCompletion(J2EETransactionImpl.java:88) org.jboss.tm.TxCapsule.doBeforeCompletion(TxCapsule.java:1331) JBoss is calling the beforeCompletion because J2EETransaction implements the Synchronization interface. Why is this done ? The JBoss should always retrieve the transaction via the DatabaseManagedConnection.getLocalTransaction() method. The second time the transaction is committed an exception is thrown: 2002-06-04 13:58:34,506 INFO [STDOUT] [DEFAULT] ERROR: 2002-06-04 13:58:34,506 INFO [STDOUT] commit: null 2002-06-04 13:58:34,506 ERROR [STDERR] org.odmg.TransactionNotInProgressException 2002-06-04 13:58:34,506 ERROR [STDERR] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:371) 2002-06-04 13:58:34,506 ERROR [STDERR] at ojb.odmg.J2EETransactionImpl.commit(J2EETransactionImpl.java:107) 2002-06-04 13:58:34,506 ERROR [STDERR] at ojb.connector.DatabaseManagedConnection.commit(DatabaseManagedConnection.jav a:140) 2002-06-04 13:58:34,506 ERROR [STDERR] at org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectio nEventListener.commit(LocalTxConnectionManager.java:536) 2002-06-04 13:58:34,506 ERROR [STDERR] at org.jboss.tm.TxCapsule.commitResources(TxCapsule.java:1656) 2002-06-04 13:58:34,506 ERROR [STDERR] at org.jboss.tm.TxCapsule.commit(TxCapsule.java:357) 2002-06-04 13:58:34,506 ERROR [STDERR] at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:76) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:190) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:12 9) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.jav a:313) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:706) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:364) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) 2002-06-04 13:58:34,516 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:148) 2002-06-04 13:58:34,516 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Transport.java:144) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:7 01) 2002-06-04 13:58:34,516 ERROR [STDERR] at java.lang.Thread.run(Thread.java:536) JBoss is here calling the commit method at the transaction retrieved via the DatabaseManagedConnection.getLocalTransaction() method. This is the actual commit. Any suggestions on how to get this working ?? BTW I am using the following switches in the OJB.properties files regarding J2EE (I have also tried the default settings): PersistenceBrokerClass=ojb.broker.ta.PersistenceBrokerJ2EEImpl PersistenceBrokerFactoryClass=ojb.broker.ta.PersistenceBrokerFactoryJ2EEImpl Regards, Fin. ------------------------------------------------- Fin Steenbjerg Pine Tree Systems Damhaven 5D 7100 Vejle Denmark Phone: +45 76416500 Phone Direct: +45 76416542 mailto:fs...@pi... <mailto:fs...@pi...> Web: http:\\www.pine.dk <http://www.pine.dk/> home mailto:ki...@ma... <mailto:ki...@ma...> home phone: +45 75753677 -------------------------------------------------- |
From: Fin S. <fs...@pi...> - 2002-06-04 15:10:17
|
Hi We are trying to get the new J2EE connector (the latest source from the trunk) to work with JBOSS 3.0 RC1. I have successfully deployed the connector and created a test session bean with container managed transactions. The bean does the following tasks: 1. gets the Implementation from JNDI 2. calls newDatabase at the implementation object 3. calls makePersistent at the database 4. closes the database. It seems like there are some problems with the transaction handling. The transactions are committed twice. The first time the commit is called the call sequence is as follows: ojb.odmg.TransactionImpl.commit(TransactionImpl.java:375) ojb.odmg.J2EETransactionImpl.commit(J2EETransactionImpl.java:107) ojb.odmg.J2EETransactionImpl.beforeCompletion(J2EETransactionImpl.java:88) org.jboss.tm.TxCapsule.doBeforeCompletion(TxCapsule.java:1331) JBoss is calling the beforeCompletion because J2EETransaction implements the Synchronization interface. Why is this done ? The JBoss should always retrieve the transaction via the DatabaseManagedConnection.getLocalTransaction() method. The second time the transaction is committed an exception is thrown: 2002-06-04 13:58:34,506 INFO [STDOUT] [DEFAULT] ERROR: 2002-06-04 13:58:34,506 INFO [STDOUT] commit: null 2002-06-04 13:58:34,506 ERROR [STDERR] org.odmg.TransactionNotInProgressException 2002-06-04 13:58:34,506 ERROR [STDERR] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:371) 2002-06-04 13:58:34,506 ERROR [STDERR] at ojb.odmg.J2EETransactionImpl.commit(J2EETransactionImpl.java:107) 2002-06-04 13:58:34,506 ERROR [STDERR] at ojb.connector.DatabaseManagedConnection.commit(DatabaseManagedConnection.jav a:140) 2002-06-04 13:58:34,506 ERROR [STDERR] at org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectio nEventListener.commit(LocalTxConnectionManager.java:536) 2002-06-04 13:58:34,506 ERROR [STDERR] at org.jboss.tm.TxCapsule.commitResources(TxCapsule.java:1656) 2002-06-04 13:58:34,506 ERROR [STDERR] at org.jboss.tm.TxCapsule.commit(TxCapsule.java:357) 2002-06-04 13:58:34,506 ERROR [STDERR] at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:76) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:190) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:12 9) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.jav a:313) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:706) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) 2002-06-04 13:58:34,516 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:364) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) 2002-06-04 13:58:34,516 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:148) 2002-06-04 13:58:34,516 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Transport.java:144) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) 2002-06-04 13:58:34,516 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:7 01) 2002-06-04 13:58:34,516 ERROR [STDERR] at java.lang.Thread.run(Thread.java:536) JBoss is here calling the commit method at the transaction retrieved via the DatabaseManagedConnection.getLocalTransaction() method. This is the actual commit. Any suggestions on how to get this working ?? BTW I am using the following switches in the OJB.properties files regarding J2EE (I have also tried the default settings): PersistenceBrokerClass=ojb.broker.ta.PersistenceBrokerJ2EEImpl PersistenceBrokerFactoryClass=ojb.broker.ta.PersistenceBrokerFactoryJ2EEImpl Regards, Fin. ------------------------------------------------- Fin Steenbjerg Pine Tree Systems Damhaven 5D 7100 Vejle Denmark Phone: +45 76416500 Phone Direct: +45 76416542 mailto:fs...@pi... Web: http:\\www.pine.dk home mailto:ki...@ma... home phone: +45 75753677 -------------------------------------------------- |
From: Georg S. <ge...@me...> - 2002-06-04 14:30:47
|
Hi Thomas, I just tried out the new release and I noticed that reference proxies are still not working due to a bug I mentioned in the following posting http://sourceforge.net/mailarchive/forum.php?thread_id=664723&forum_id=4880 Please correct me if I am wrong, but there seems to be no testcase testing reference proxies, so I constructed one and attached it to this posting. If you run that testcase you should see an IllegalArgumentException being thrown, which should disappear when fixing the code as mentioned in the posting (btw, there is a typo in my posting, it should be referencedProxy=null, and not referenceProxy=null :-) ) The get the testcase running you have to do 3 things: 1.) put the ArticleWithReferenceProxy.java file from the attachement into the test/ojb/broker/ directory (the class simply extends Article, so I can put a new mapping into the repository) 2.) add the mapping-xml from the attachement to the repository_junit.xml file. The mapping is basically a copy of the mapping for the Article-class, the major difference being the addition of proxy="true" for the reference-descriptor for productGroup 3.) add the method testReferenceProxies() from the attachement to the ProxyExample class in the test/ojb/broker/ directory Cheers Georg |
From: Domagoj J. <do...@la...> - 2002-06-04 13:53:55
|
OK it's working now : PersistenceBroker Tests are passed , but some ODMG Tests are failed mostly with error : [junit] org.odmg.TransactionAbortedException: Can't convert from: byte array where original exception fired from : JdbcAccess::public void executeInsert(ClassDescriptor mif, Object obj) throws PersistenceBrokerException I am working with Informix Dynamic Server 2000, database is using UTF-8, and driver is aware of that. And I am still using version 0.8.375. The errors are the same for <JDBC_LEVEL> 1.0 and 2.0 and driver that I am using is JDBC 2.0 compatible (informix says that, but in API docs there are some JDBC 2.0 related methods marked with "not yet supported"). here is the "ant -debug junit" printout if you are interested in it : ---------------------------------------------------------------------------------------------------------------------------------- ..................... prepare-tests: FileSet: Setup file scanner in dir C:\java\ojb\src\test\ojb with patternSet{ includes: [repository*, *.properties] excludes: [] } [copy] repository_user.xml omitted as C:\java\ojb\build\test\ojb\repository_user.xml is up to date. [copy] repository_junit.xml omitted as C:\java\ojb\build\test\ojb\repository_junit.xml is up to date. [copy] repository_internal.xml omitted as C:\java\ojb\build\test\ojb\repository_internal.xml is up to date. [copy] OJB.properties omitted as C:\java\ojb\build\test\ojb\OJB.properties is up to date. [copy] repository.dtd omitted as C:\java\ojb\build\test\ojb\repository.dtd is up to date. [copy] repository.xml omitted as C:\java\ojb\build\test\ojb\repository.xml is up to date. [copy] log4j.properties omitted as C:\java\ojb\build\test\ojb\log4j.properties is up to date. FileSet: Setup file scanner in dir C:\java\ojb\src\test\ojb\broker with patternSet{ includes: [] excludes: [*.java] } [copy] omitted as C:\java\ojb\build\test\ojb\broker is up to date. FileSet: Setup file scanner in dir C:\java\ojb\src\test\ojb\odmg with patternSet{ includes: [] excludes: [*.java] } [copy] omitted as C:\java\ojb\build\test\ojb\odmg is up to date. [copy] Copying 1 file to C:\java\ojb\src\test\setup [copy] Copying C:\java\ojb\src\test\setup\db-setup.sql to C:\java\ojb\src\test\setup\db-setup.java Property ${jdbc.driver.class} has not been set [replace] Replacing in C:\java\ojb\src\test\setup\db-setup.java: $JDBCDRIVER$ --> ${jdbc.driver.class} Property ${jdbc.connection.url} has not been set [replace] Replacing in C:\java\ojb\src\test\setup\db-setup.java: $JDBCURL$ --> ${jdbc.connection.url} tests: [echo] using switches: -HSQLDB, -ORACLE, -MS_ACCESS, -INSTANTDB, -DB2, -POSTGRESQL, -MYSQL, +INFORMIX, -MSSQLSERVER2000 [java] Running in same VM org.hsqldb.util.CodeSwitcher src/test/setup -HSQLDB -MS_ACCESS -ORACLE -INSTANTDB -DB2 -POSTGRESQL -MYSQL +INFORMIX -MSSQLSERVER2000 FileSet: Setup file scanner in dir \java\ojb\lib with patternSet{ includes: [**/*.jar, **/*.zip] excludes: [] } force loading org.hsqldb.util.CodeSwitcher Finding class org.hsqldb.util.CodeSwitcher Class java.lang.Object loaded from parent loader Class java.lang.Throwable loaded from parent loader Class java.lang.Exception loaded from parent loader Class java.io.Reader loaded from parent loader Class java.io.FileReader loaded from parent loader Class java.io.Writer loaded from parent loader Class java.io.FileWriter loaded from parent loader Class java.io.BufferedReader loaded from parent loader Class java.io.LineNumberReader loaded from parent loader Class java.io.OutputStreamWriter loaded from parent loader Class java.lang.String loaded from parent loader Class java.util.Vector loaded from parent loader Class java.io.File loaded from parent loader Class java.lang.StringBuffer loaded from parent loader Class java.lang.System loaded from parent loader Class java.io.PrintStream loaded from parent loader [java] . [move] Moving 1 files to C:\java\ojb\src\test\setup [move] Attempting to rename: C:\java\ojb\src\test\setup\db-setup.java to C:\java\ojb\src\test\setup\database-setup.sql FileSet: Setup file scanner in dir C:\java\ojb\src\test\setup with patternSet{ includes: [] excludes: [] } [copy] db-setup.sql omitted as C:\java\ojb\build\test\setup\db-setup.sql is up to date. [copy] database-setup.sql added as C:\java\ojb\build\test\setup\database-setup.sql is outdated. [copy] omitted as C:\java\ojb\build\test\setup is up to date. [copy] Copying 1 file to C:\java\ojb\build\test\setup [copy] Copying C:\java\ojb\src\test\setup\database-setup.sql to C:\java\ojb\build\test\setup\database-setup.sql [delete] Deleting: C:\java\ojb\src\test\setup\database-setup.sql junit: FileSet: Setup file scanner in dir \java\ojb\lib with patternSet{ includes: [**/*.jar, **/*.zip] excludes: [] } FileSet: Setup file scanner in dir \java\ojb\lib with patternSet{ includes: [**/*.jar, **/*.zip] excludes: [] } [junit] Forking C:\IBMJAVA1_3\JRE\..\bin\java.exe -classpath C:\java\ojb\build\classes;C:\java\ojb\lib\antlr_compiletime.jar;C:\java\ojb\lib\ejb.jar;C:\java\ojb\lib\servlet.jar;C:\java\ojb\lib\jdbc2_0-stdext.jar;C:\java\ojb\lib\crimson.jar;C:\java\ojb\lib\antlr.jar;C:\java\ojb\lib\antlr.debug.jar;C:\java\ojb\lib\log4j.jar;C:\java\ojb\lib\hsqldb.jar;C:\java\ojb\lib\ant.jar;C:\java\ojb\lib\gnu-regexp-1.1.4.jar;C:\java\ojb\lib\jta-spec1_0_1.jar;C:\java\ojb\lib\junit.jar;C:\java\ojb\lib\proxy.jar;C:\java\ojb\build\test\ojb;C:\java\ifxjdbc\ifxjdbc.jar junit.textui.TestRunner test.ojb.broker.AllTests FileSet: Setup file scanner in dir \java\ojb\lib with patternSet{ includes: [**/*.jar, **/*.zip] excludes: [] } FileSet: Setup file scanner in dir \java\ojb\lib with patternSet{ includes: [**/*.jar, **/*.zip] excludes: [] } Execute:Java13CommandLauncher: C:\IBMJAVA1_3\JRE\..\bin\java.exe -classpath C:\java\ojb\build\classes;C:\java\ojb\lib\antlr_compiletime.jar;C:\java\ojb\lib\ejb.jar;C:\java\ojb\lib\servlet.jar;C:\java\ojb\lib\jdbc2_0-stdext.jar;C:\java\ojb\lib\crimson.jar;C:\java\ojb\lib\antlr.jar;C:\java\ojb\lib\antlr.debug.jar;C:\java\ojb\lib\log4j.jar;C:\java\ojb\lib\hsqldb.jar;C:\java\ojb\lib\ant.jar;C:\java\ojb\lib\gnu-regexp-1.1.4.jar;C:\java\ojb\lib\jta-spec1_0_1.jar;C:\java\ojb\lib\junit.jar;C:\java\ojb\lib\proxy.jar;C:\java\ojb\build\test\ojb;C:\java\ifxjdbc\ifxjdbc.jar junit.textui.TestRunner test.ojb.broker.AllTests [junit] .[BOOT] INFO: OJB.properties: file:/C:/java/ojb/build/test/ojb/OJB.properties [junit] [ojb.broker.ta.ConfigurationProperties] INFO: ojb.broker.ta.ConfigurationProperties read OJB.properties [junit] [ojb.broker.ta.ConfigurationProperties] INFO: OJB.properties: file:/C:/java/ojb/build/test/ojb/OJB.properties [junit] [BOOT] INFO: OJB.properties: file:/C:/java/ojb/build/test/ojb/OJB.properties [junit] [ojb.broker.ta.PersistenceBrokerFactoryFactory] INFO: Implementation of PersistencebrokerFactory: ojb.broker.ta.PersistenceBrokerFactoryDefaultImpl [junit] ..... [junit] Time: 24,6 [junit] [junit] OK (47 tests) [junit] FileSet: Setup file scanner in dir \java\ojb\lib with patternSet{ includes: [**/*.jar, **/*.zip] excludes: [] } FileSet: Setup file scanner in dir \java\ojb\lib with patternSet{ includes: [**/*.jar, **/*.zip] excludes: [] } [junit] Forking C:\IBMJAVA1_3\JRE\..\bin\java.exe -classpath C:\java\ojb\build\classes;C:\java\ojb\lib\antlr_compiletime.jar;C:\java\ojb\lib\ejb.jar;C:\java\ojb\lib\servlet.jar;C:\java\ojb\lib\jdbc2_0-stdext.jar;C:\java\ojb\lib\crimson.jar;C:\java\ojb\lib\antlr.jar;C:\java\ojb\lib\antlr.debug.jar;C:\java\ojb\lib\log4j.jar;C:\java\ojb\lib\hsqldb.jar;C:\java\ojb\lib\ant.jar;C:\java\ojb\lib\gnu-regexp-1.1.4.jar;C:\java\ojb\lib\jta-spec1_0_1.jar;C:\java\ojb\lib\junit.jar;C:\java\ojb\lib\proxy.jar;C:\java\ojb\build\test\ojb;C:\java\ifxjdbc\ifxjdbc.jar junit.textui.TestRunner test.ojb.odmg.AllTests FileSet: Setup file scanner in dir \java\ojb\lib with patternSet{ includes: [**/*.jar, **/*.zip] excludes: [] } FileSet: Setup file scanner in dir \java\ojb\lib with patternSet{ includes: [**/*.jar, **/*.zip] excludes: [] } Execute:Java13CommandLauncher: C:\IBMJAVA1_3\JRE\..\bin\java.exe -classpath C:\java\ojb\build\classes;C:\java\ojb\lib\antlr_compiletime.jar;C:\java\ojb\lib\ejb.jar;C:\java\ojb\lib\servlet.jar;C:\java\ojb\lib\jdbc2_0-stdext.jar;C:\java\ojb\lib\crimson.jar;C:\java\ojb\lib\antlr.jar;C:\java\ojb\lib\antlr.debug.jar;C:\java\ojb\lib\log4j.jar;C:\java\ojb\lib\hsqldb.jar;C:\java\ojb\lib\ant.jar;C:\java\ojb\lib\gnu-regexp-1.1.4.jar;C:\java\ojb\lib\jta-spec1_0_1.jar;C:\java\ojb\lib\junit.jar;C:\java\ojb\lib\proxy.jar;C:\java\ojb\build\test\ojb;C:\java\ifxjdbc\ifxjdbc.jar junit.textui.TestRunner test.ojb.odmg.AllTests [junit] [BOOT] INFO: OJB.properties: file:/C:/java/ojb/build/test/ojb/OJB.properties [junit] .[ojb.broker.ta.ConfigurationProperties] INFO: ojb.broker.ta.ConfigurationProperties read OJB.properties [junit] [ojb.broker.ta.ConfigurationProperties] INFO: OJB.properties: file:/C:/java/ojb/build/test/ojb/OJB.properties [junit] [BOOT] INFO: OJB.properties: file:/C:/java/ojb/build/test/ojb/OJB.properties [junit] [ojb.broker.ta.PersistenceBrokerFactoryFactory] INFO: Implementation of PersistencebrokerFactory: ojb.broker.ta.PersistenceBrokerFactoryDefaultImpl [junit] [ojb.broker.accesslayer.StatementsForClass] ERROR: The specified table (elvis) is not in the database. [junit] java.sql.SQLException: The specified table (elvis) is not in the database. [junit] at com.informix.jdbc.IfxSqli.addException(IfxSqli.java:3021) [junit] at com.informix.jdbc.IfxSqli.receiveError(IfxSqli.java:3335) [junit] at com.informix.jdbc.IfxSqli.dispatchMsg(IfxSqli.java:2288) [junit] at com.informix.jdbc.IfxSqli.receiveMessage(IfxSqli.java:2208) [junit] at com.informix.jdbc.IfxSqli.executePrepare(IfxSqli.java:1081) [junit] at com.informix.jdbc.IfxResultSet.executePrepare(IfxResultSet.java:197) [junit] at com.informix.jdbc.IfxPreparedStatement.setupExecutePrepare(IfxPreparedStatement.java:185) [junit] at com.informix.jdbc.IfxPreparedStatement.<init>(IfxPreparedStatement.java:167) [junit] at com.informix.jdbc.IfxSqliConnect.prepareStatement(IfxSqliConnect.java:1558) [junit] at ojb.broker.accesslayer.StatementsForClass.prepareStatement(StatementsForClass.java:147) [junit] at ojb.broker.accesslayer.StatementsForClass.getUpdateStmt(StatementsForClass.java:421) [junit] at ojb.broker.accesslayer.StatementManager.getUpdateStatement(StatementManager.java:484) [junit] at ojb.broker.accesslayer.JdbcAccess.executeUpdate(JdbcAccess.java:276) [junit] at ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1310) [junit] at ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1258) [junit] at ojb.odmg.states.StateOldDirty.commit(StateOldDirty.java:104) [junit] at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:104) [junit] at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:200) [junit] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:350) [junit] at test.ojb.odmg.OdmgExamples.testBrokerCrash(OdmgExamples.java:510) [junit] at java.lang.reflect.Method.invoke(Native Method) [junit] at junit.framework.TestCase.runTest(TestCase.java:166) [junit] at junit.framework.TestCase.runBare(TestCase.java:140) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:131) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:173) [junit] at junit.framework.TestSuite.run(TestSuite.java:168) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:173) [junit] at junit.framework.TestSuite.run(TestSuite.java:168) [junit] at junit.textui.TestRunner.doRun(TestRunner.java:74) [junit] at junit.textui.TestRunner.start(TestRunner.java:234) [junit] at junit.textui.TestRunner.main(TestRunner.java:112) [junit] org.odmg.TransactionAbortedException: Can't convert from: byte array [junit] at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:114) [junit] at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:200) [junit] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:350) [junit] at test.ojb.odmg.DListTest.testAddingWithIndex(DListTest.java:209) [junit] at java.lang.reflect.Method.invoke(Native Method) [junit] at junit.framework.TestCase.runTest(TestCase.java:166) [junit] at junit.framework.TestCase.runBare(TestCase.java:140) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:131) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:173) [junit] at junit.framework.TestSuite.run(TestSuite.java:168) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:173) [junit] at junit.framework.TestSuite.run(TestSuite.java:168) [junit] at junit.textui.TestRunner.doRun(TestRunner.java:74) [junit] at junit.textui.TestRunner.start(TestRunner.java:234) [junit] at junit.textui.TestRunner.main(TestRunner.java:112) [junit] org.odmg.TransactionAbortedException: Can't convert from: byte array [junit] at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:114) [junit] at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:200) [junit] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:350) [junit] at test.ojb.odmg.DListTest.testAdding(DListTest.java:126) [junit] at java.lang.reflect.Method.invoke(Native Method) [junit] at junit.framework.TestCase.runTest(TestCase.java:166) [junit] at junit.framework.TestCase.runBare(TestCase.java:140) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:131) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:173) [junit] at junit.framework.TestSuite.run(TestSuite.java:168) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:173) [junit] at junit.framework.TestSuite.run(TestSuite.java:168) [junit] at junit.textui.TestRunner.doRun(TestRunner.java:74) [junit] at junit.textui.TestRunner.start(TestRunner.java:234) [junit] at junit.textui.TestRunner.main(TestRunner.java:112) [junit] ..E.....E.E.F.E.E.E.F.F.F......................... [junit] ......................................... [junit] ........... [junit] Time: 18,07 [junit] There were 6 errors: [junit] 1) testNrmAndDlists(test.ojb.odmg.OdmgExamples) [junit] org.odmg.TransactionNotInProgressException [junit] at ojb.odmg.TransactionImpl.abort(TransactionImpl.java:371) [junit] at test.ojb.odmg.OdmgExamples.testNrmAndDlists(OdmgExamples.java:314) [junit] 2) testUnBind(test.ojb.odmg.NamedRoots) [junit] org.odmg.TransactionAbortedException: Can't convert from: byte array [junit] at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:114) [junit] at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:200) [junit] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:350) [junit] at test.ojb.odmg.NamedRoots.testUnBind(NamedRoots.java:335) [junit] 3) testLookup(test.ojb.odmg.NamedRoots) [junit] org.odmg.TransactionAbortedException: Can't convert from: byte array [junit] at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:114) [junit] at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:200) [junit] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:350) [junit] at test.ojb.odmg.NamedRoots.testLookup(NamedRoots.java:265) [junit] 4) testBind(test.ojb.odmg.NamedRoots) [junit] org.odmg.TransactionAbortedException: Can't convert from: byte array [junit] at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:114) [junit] at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:200) [junit] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:350) [junit] at test.ojb.odmg.NamedRoots.testBind(NamedRoots.java:135) [junit] 5) testDSet(test.ojb.odmg.DListTest) [junit] org.odmg.TransactionAbortedException: Can't convert from: byte array [junit] at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:114) [junit] at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:200) [junit] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:350) [junit] at test.ojb.odmg.DListTest.testDSet(DListTest.java:334) [junit] 6) testDBag(test.ojb.odmg.DListTest) [junit] org.odmg.TransactionAbortedException: Can't convert from: byte array [junit] at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:114) [junit] at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:200) [junit] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:350) [junit] at test.ojb.odmg.DListTest.testDBag(DListTest.java:302) [junit] There were 4 failures: [junit] 1) testDoubleBindInOneTx(test.ojb.odmg.NamedRoots)junit.framework.AssertionFailedError: Can't convert from: byte array [junit] at test.ojb.odmg.NamedRoots.testDoubleBindInOneTx(NamedRoots.java:223) [junit] 2) testAddingWithIndex(test.ojb.odmg.DListTest)junit.framework.AssertionFailedError: NRM problem: Can't convert from: byte array [junit] at test.ojb.odmg.DListTest.testAddingWithIndex(DListTest.java:214) [junit] 3) testAdding(test.ojb.odmg.DListTest)junit.framework.AssertionFailedError: NRM problem: Can't convert from: byte array [junit] at test.ojb.odmg.DListTest.testAdding(DListTest.java:131) [junit] 4) testAdding(test.ojb.odmg.DMapTest)junit.framework.AssertionFailedError: Can't convert from: byte array [junit] at test.ojb.odmg.DMapTest.testAdding(DMapTest.java:144) [junit] [junit] FAILURES!!! [junit] Tests run: 93, Failures: 4, Errors: 6 [junit] Total time: 50 seconds |
From: Mahler T. <tho...@it...> - 2002-06-04 07:52:16
|
Hi all, =20 after some minor problems I managed to assemble a new release. As I had to fix several bugs to get this release stable, I did not find = the time to keep the documentation up to date. In particular the documentation regarding the repository is out of sync = due to the redesigned repository.dtd. =20 Lasse Lindg=E5rd wrote a stylesheet to transform existing repositories = to the new syntax. I hope this will help users to migrate quickly! From the relase notes: Changes in Release 0.9 new features: - Servlet Implementation of PersistenceBrokerServer, allows to easily deploy the OJB Server as a normal Http-Servlet - JDO prototype and sample application. Cuurently we are using the bytecode enhancer from the JDO Reference Implementation. We are not allowed to ship the jdori.jar from SUN's reference implementation. If you play around with our JDO sample, just download jdori.jar from = SUN and add it to the ojb-0-9/lib directory! - complete redesign of the repository grammar. To help users to migrate their existing repository.xml files we provide a XSLT stylesheet (see ojb-0-9/src/test/test/ojb/0.8to0.9.xsl) - performance test-suite for the ODMG implementation - Full JTA and JCA integration! - PersistenceBroker interface now extends the org.odbms.ObjectContainer interface to provide a better integration for the S.O.D.A query API. bug fixes: - tons of bug fixes Refactorings: - performance enhancements - redesign of SqlGenerator - redesign of the build process, now using Torque and Maven - redesign of Repository parser - ConversionStrategies have been moved from the class-level to the field-level.=20 With this release we are feature complete for the 1.0 release! For 1.0 you should not expect more features to be added. In OJB 1.0 we will have more bug fixes, better documentation and we = will add the=20 prefix "org.apache" to all ojb packages to reflect our new home at = Jakarta. Important note: We did not yet change the documentation to reflect the changes to the repository.dtd. We will try to correct it asap. cheers, =20 Thomas =20 |
From: Thomas M. <tho...@ho...> - 2002-06-04 05:06:46
|
Hi Mike, Mike Hogan wrote: > Hi, > > I have just posted this to jdocentral. Please forgive the cross posting. > > I got quite excited about JDO because I figured it would allow me persist > data on the serverside without the muckiness of Entity Beans. I also figure > JDO objects could act as my value objects - that I could return them to the > presentation layer from my session beans. I see that there are arguments > for and against that idea on this site and others. But lets leave that > argument aside and assume I want to return my JDO instances as value objects > from session beans. > > The problem is of course that if I return the head of a graph of objects, > the whole graph will get serialized back to the client. The only way around > that right now that I can see if judicious placement of nulls to cut the > graph. OJB provides several concepts to deal with such situations: - you can configure OJB to use proxy objects instead of "real" object references. This will cut your graph *and* allow you to navigate to the "real" object if necessary. OJB proxies are serializable and can be excuted even in remote JVMs ! - you can configure OJB not to retrieve Object references. It will simply place null values in the reference objects. This will cut your graph, but OJB can't follow the references automatically. So for *most* situations using proxies should be asolutely sufficient. > > But it seems to me JDO is well positioned to do this for me. Lets assume > the JDO runtime loads data for an object only when the reference to that > object is navigated (the root object is a special case). This will allow me > surf my object graph to my hearts content in my session bean, loading data > as I go. Very easy to implement with OJB. > When I have done the surfing I want to do, I currently have to insert nulls > to cut a section out of the object graph so I can serialize it back to the > client. Would it not be possible to tell the persistence manager NOT to > load data for any further references that are navigated, but to return null > instead. Then I can simply do persistenceManager.cut(), and serialize a > section of the graph back to the client - java serialization will be bound > to the area of the graph I surfed. > > Now, this might very well remove the opportunity to do preloading of data > for performance reasons. But it would be really cool if these access paths > were implemented in 2.0. Then I could load an object from the db and tell > the PM what the expected access path is, with one access path per use case. > This will allow me load data in a performant way while still sectioning the > graph. OJB has a Metaobject protocol to manipulate the behaviour of object references etc. at runtime. To implement you idea with OJB is quite straightforward. > > One extra nice extension would be a means to indicate what access paths > follow a given access path. For example, if I am executing the "login" use > case, I would tell the PM to work with the "login" access path. But I could > also inform it (at deployment time probably) that after the "login" use > case, the "order item" use case or the "logout" use case can follow. To the > JDO runtime, this will mean the "order item" or the "logout" access path > will follow, and it can preload both if it chooses, or, depending on their > relative frequence, load one of them. All this is possible with OJB already today. Don't wait for 2.0 ! cheers, Thomas > Cheers, > Mike > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
From: Thomas M. <tho...@ho...> - 2002-06-04 05:06:10
|
Hi again Brian, Brian Devries wrote: <snip> > I could not see this in the CVS tree, would you be able to send on this > implementation? > sorry, I forgot to mention its available on the download page under: http://prdownloads.sourceforge.net/objectbridge/ojb_mod.zip?download > >> You might also implement a SequenceManager, that does not lock the >> table, but inserts a row with the new primary key. >> This will preserve uniqueness of the primary key across all running >> applications (incl. OJB). >> >> In my above mentioned project I will go this way. >> > > Were you planning on inserting no data into this new row? It doesn't > look like the SequenceManager is given a reference to the object to > generate an ID for, which means it can't actually insert the data. > Yes, that's a problem for NOT NULLable columns! I have no idea how to solve this right now. > Also, I'm assuming you would need to do the insert but not commit that > transaction, as this would show up in any concurrent queries on the > table? > I think this won't do any harm, it would just result in some unused numbers in case of a rollback... > >> Say you have two classes A and B. A has a collection of Bs. >> say we have an object a of type A that holds a collection of 5 Bs. >> >> Navigability is unidirectional from A to B. That is a B has no >> > reference > >> to its A! >> >> The objects are newly created and primary and foreign keys are not >> > assigned. > >> Now we lock a (and the 5 Bs) to a tx without assignment of Identities >> > >> and foreignkeys. >> >> Now we try to commit the tx: >> If we try to store one of the Bs it won't have its foreignkey >> > attribute > >> pointing to its A filled. >> >> As there is no reference back to a the Transactionmanager has no way >> > to > >> know how to fill the foreign key attribute. >> >> The only place the transactionmanager can do this is on registering >> > A, > >> or later when Bs are added to the collection attribute of a. >> > > It looks like the commit of the ObjectEnvelopeTable already orders the > commit of all objects in the transaction to account for referential > integrity dependencies and then commits each object in the correct > order. As the code commits objects in that order couldn't the foreign > key attributes of objects in a collection be assigned prior to > committing that object? > > The steps would be: > > Commit is called on object A. > > Commit is first called on any reference objects (during which foreign > keys are assigned by broker layer). > > Reference fields in object A are set with keys from committed reference > objects. > > Object A is persisted through the broker and foreign keys assigned in > the broker layer. > > Inverse foreign keys are assigned to any objects in collections found in > A. > > Commit is called on all objects in collections of A. > > In such a scenario, I don't think it matters that B objects would have > no reference to object A. It would behave just like currently when you > lock object A, it iterates through the tree of objects in the correct > order to be able to assign reference and collection keys correctly. It > seems that the same method can be used at commit time just as it is at > lock time. > > I think such an approach would still leave primary key generation part > of the broker layer, but allow for more flexibility in when the keys are > actually generated in the ODMG layer. > Oops, you have been digging quite deep into my code... I think you are right here. The only drawback I can see is that PK and FK attributes won't be visible before transaction commit. Maybe this is OK for most scenarios. But for other this might cause problems... I'm not sure about this. Needs some more thinking. cheers, Thomas > As always, thanks for all your efforts with this project. They are very > appreciated. > -Brian > > -- > Brian DeVries Sr. Software Engineer > mailto:bde...@in... http://www.intraware.com > Voice: 925.253.6516 Fax: 925.253.6785 > -------------------------------------------------------- > Intraware... The leading provider of Electronic Software > Delivery and Management (ESDM) Solutions > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
From: David F. <dw...@la...> - 2002-06-03 22:39:40
|
I should attach a log and traceback that might prove useful: [ojb.broker.singlevm.PersistenceBrokerImpl] DEBUG: getIteratorFromQuery class gov.lanl.COAS.ObservationData_, Query from class gov.lanl.COAS.ObservationData_ where ( ( personId LIKE ? ) AND (code=? ) ) AND (( startTime>= ? ) AND (startTime<= ? ) OR ( stopTime<= ? ) AND (stopTime>= ? ) ) [ojb.broker.accesslayer.RsIterator] DEBUG: RsIterator(Query from class gov.lanl.COAS.ObservationData_ where ( ( personId LIKE ? ) AND (code= ? ) ) AND (( startTime>= ? ) AND (startTime<= ? ) OR ( stopTime<= ? ) AND (stopTime>= ? ) ) , table: ObservationData_ FieldDescriptions: [Lojb.broker.metadata.FieldDescriptor;@8d7ace) [ojb.broker.singlevm.PersistenceBrokerImpl] DEBUG: getObjectByIdentity gov.lanl.COAS.ObservationValue_{0} [ojb.broker.singlevm.PersistenceBrokerImpl] ERROR: expected type: interface gov.lanl.COAS.ObservationValue_ [ojb.broker.singlevm.PersistenceBrokerImpl] DEBUG: getObjectByIdentity gov.lanl.COAS.ObservationValue_{0} [ojb.broker.accesslayer.RsIterator] ERROR: null ojb.broker.PersistenceBrokerSQLException at ojb.broker.accesslayer.JdbcAccess.materializeObject(JdbcAccess.java:352) at ojb.broker.singlevm.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.java:1074) at ojb.broker.singlevm.PersistenceBrokerImpl.getObjectByIdentity(PersistenceBrokerImpl.java:1169) at ojb.broker.singlevm.PersistenceBrokerImpl.getReferencedObject(PersistenceBrokerImpl.java:744) at ojb.broker.singlevm.PersistenceBrokerImpl.retrieveReferences(PersistenceBrokerImpl.java:519) at ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:269) at ojb.broker.accesslayer.RsIterator.next(RsIterator.java:153) at ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:888) at ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:954) at ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1042) at ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1029) at gov.lanl.Database.OJBDatabaseMgr.retrieveElements(OJBDatabaseMgr.java:429) at gov.lanl.COAS.QueryAccessImpl.retrieveObservations(QueryAccessImpl.java:1030) at gov.lanl.COAS.QueryAccessImpl.getObservationsWithPolicy(QueryAccessImpl.java:812) at gov.lanl.COAS.QueryAccessImpl.get_observations_by_time(QueryAccessImpl.java:403) at org.omg.DsObservationAccess.QueryAccessPOA._OB_op_get_observations_by_time(QueryAccessPOA.java:430) at org.omg.DsObservationAccess.QueryAccessPOA._invoke(QueryAccessPOA.java:138) at com.ooc.OBPortableServer.ServantDispatcher.dispatch(ServantDispatcher.java:211) at com.ooc.OBPortableServer.POA_impl._OB_dispatch(POA_impl.java:1734) at com.ooc.OB.DispatchRequest_impl.invoke(DispatchRequest_impl.java:52) at com.ooc.OB.DispatchSameThread_impl.dispatch(DispatchStrategyFactory_impl.java:46) at com.ooc.OB.Upcall.invoke(Upcall.java:426) at com.ooc.OB.GIOPServerWorkerThreaded.receiverRun(GIOPServerWorkerThreaded.java:528) at com.ooc.OB.GIOPServerWorkerThreaded$ReceiverThread.run(GIOPServerWorkerThreaded.java:70) Caused by: java.sql.SQLException: No value specified for parameter 2 at org.gjt.mm.mysql.PreparedStatement.executeQuery(Unknown Source) at ojb.broker.accesslayer.JdbcAccess.materializeObject(JdbcAccess.java:327) ... 23 more The hsqldb version looks almost the same up to the error. It gives a warning about a defining a public constructor for gov.lanl.COAS.String_ which is in instance of the gov.lanl.COAS.ObservationValue_ interface and proceeds to get the object. Suggestions would be appreciated. Dave At 04:21 PM 6/3/2002 -0600, David Forslund wrote: >My application runs fine with hsqldb under ojb-.0.8.400 >When I try using mysql, I get the error message: > >[ojb.broker.accesslayer.RsIterator] ERROR: null > >in every query. > >In addition, I see in some cases an >[ojb.broker.singlevm.PersistenceBrokerImpl] ERROR: expected interface >gov.lanl.COAS.ObservationValue_ > >and there is an ojb.brokerPersistentBrokerSQLException thrown in >materializeObject. > >the class listed above is in a ReferenceDescriptor for a polymorphic object. > >I don't see any observable errors when I load the database. > >I don't understand why mysql should behave differently from hsqldb. >Is something else needed for ojb with mysql to be able to handle >polymorphic objects? > >Thanks, > >Dave > > >_______________________________________________________________ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >_______________________________________________ >Objectbridge-developers mailing list >Obj...@li... >https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
From: David F. <dw...@la...> - 2002-06-03 22:21:54
|
My application runs fine with hsqldb under ojb-.0.8.400 When I try using mysql, I get the error message: [ojb.broker.accesslayer.RsIterator] ERROR: null in every query. In addition, I see in some cases an [ojb.broker.singlevm.PersistenceBrokerImpl] ERROR: expected interface gov.lanl.COAS.ObservationValue_ and there is an ojb.brokerPersistentBrokerSQLException thrown in materializeObject. the class listed above is in a ReferenceDescriptor for a polymorphic object. I don't see any observable errors when I load the database. I don't understand why mysql should behave differently from hsqldb. Is something else needed for ojb with mysql to be able to handle polymorphic objects? Thanks, Dave |
From: Brian D. <bde...@in...> - 2002-06-03 18:05:47
|
Hi Thomas, Thanks for the response. Thomas Mahler wrote: > There is a code-contribution to use OJB with oracle sequencenumbers. But > it has not been incorporated to the main distribution yet. I could not see this in the CVS tree, would you be able to send on this implementation? > You might also implement a SequenceManager, that does not lock the > table, but inserts a row with the new primary key. > This will preserve uniqueness of the primary key across all running > applications (incl. OJB). > > In my above mentioned project I will go this way. Were you planning on inserting no data into this new row? It doesn't look like the SequenceManager is given a reference to the object to generate an ID for, which means it can't actually insert the data. Also, I'm assuming you would need to do the insert but not commit that transaction, as this would show up in any concurrent queries on the table? > Say you have two classes A and B. A has a collection of Bs. > say we have an object a of type A that holds a collection of 5 Bs. > > Navigability is unidirectional from A to B. That is a B has no reference > to its A! > > The objects are newly created and primary and foreign keys are not assigned. > > Now we lock a (and the 5 Bs) to a tx without assignment of Identities > and foreignkeys. > > Now we try to commit the tx: > If we try to store one of the Bs it won't have its foreignkey attribute > pointing to its A filled. > > As there is no reference back to a the Transactionmanager has no way to > know how to fill the foreign key attribute. > > The only place the transactionmanager can do this is on registering A, > or later when Bs are added to the collection attribute of a. It looks like the commit of the ObjectEnvelopeTable already orders the commit of all objects in the transaction to account for referential integrity dependencies and then commits each object in the correct order. As the code commits objects in that order couldn't the foreign key attributes of objects in a collection be assigned prior to committing that object? The steps would be: Commit is called on object A. Commit is first called on any reference objects (during which foreign keys are assigned by broker layer). Reference fields in object A are set with keys from committed reference objects. Object A is persisted through the broker and foreign keys assigned in the broker layer. Inverse foreign keys are assigned to any objects in collections found in A. Commit is called on all objects in collections of A. In such a scenario, I don't think it matters that B objects would have no reference to object A. It would behave just like currently when you lock object A, it iterates through the tree of objects in the correct order to be able to assign reference and collection keys correctly. It seems that the same method can be used at commit time just as it is at lock time. I think such an approach would still leave primary key generation part of the broker layer, but allow for more flexibility in when the keys are actually generated in the ODMG layer. As always, thanks for all your efforts with this project. They are very appreciated. -Brian -- Brian DeVries Sr. Software Engineer mailto:bde...@in... http://www.intraware.com Voice: 925.253.6516 Fax: 925.253.6785 -------------------------------------------------------- Intraware... The leading provider of Electronic Software Delivery and Management (ESDM) Solutions |
From: Mike H. <me...@mi...> - 2002-06-03 17:56:44
|
Hi, I have just posted this to jdocentral. Please forgive the cross posting. I got quite excited about JDO because I figured it would allow me persist data on the serverside without the muckiness of Entity Beans. I also figure JDO objects could act as my value objects - that I could return them to the presentation layer from my session beans. I see that there are arguments for and against that idea on this site and others. But lets leave that argument aside and assume I want to return my JDO instances as value objects from session beans. The problem is of course that if I return the head of a graph of objects, the whole graph will get serialized back to the client. The only way around that right now that I can see if judicious placement of nulls to cut the graph. But it seems to me JDO is well positioned to do this for me. Lets assume the JDO runtime loads data for an object only when the reference to that object is navigated (the root object is a special case). This will allow me surf my object graph to my hearts content in my session bean, loading data as I go. When I have done the surfing I want to do, I currently have to insert nulls to cut a section out of the object graph so I can serialize it back to the client. Would it not be possible to tell the persistence manager NOT to load data for any further references that are navigated, but to return null instead. Then I can simply do persistenceManager.cut(), and serialize a section of the graph back to the client - java serialization will be bound to the area of the graph I surfed. Now, this might very well remove the opportunity to do preloading of data for performance reasons. But it would be really cool if these access paths were implemented in 2.0. Then I could load an object from the db and tell the PM what the expected access path is, with one access path per use case. This will allow me load data in a performant way while still sectioning the graph. One extra nice extension would be a means to indicate what access paths follow a given access path. For example, if I am executing the "login" use case, I would tell the PM to work with the "login" access path. But I could also inform it (at deployment time probably) that after the "login" use case, the "order item" use case or the "logout" use case can follow. To the JDO runtime, this will mean the "order item" or the "logout" access path will follow, and it can preload both if it chooses, or, depending on their relative frequence, load one of them. Cheers, Mike |
From: Domagoj J. <do...@la...> - 2002-06-03 15:28:46
|
Hi guys I have modified switches to use Informix. I have modified db-setup.sql with my connection string for informix. Setup of db goes well (Tables in my db are created by ant calling of ScriptTool.class), but junit tests are failing with messages "Table not found" (mostly at : ojb.broker.accesslayer.JdbcAccess.executeQuery(JdbcAccess.java:199) ). But the tables are in the db, what's wrong, I just have no idea. PLEASE just shoot some ideas what to check ...... If someone wants to look "ant -debug junit" printout it is in attacment. |
From: Jakob B. <jbr...@ho...> - 2002-06-03 14:06:57
|
hi, can anybody _please_ tell me how to configure the build process for a db different than hsqldb. i modified the build.properties as follows: ... HSQLDB=-HSQLDB MS_ACCESS=+MS_ACCESS ... but torque still uses hsqldb as displayed on the console: ... [torque-sql] Resolver: used database.dtd from org.apache.torque.engine.database.transform package project-create-db-classpath: [echo] driver="org.hsqldb.jdbcDriver" url="jdbc:hsqldb:target/test/OJB" userid="sa" password="" [torque-create-db] Using classpath [torque-create-db] Generating to file D:\Java\eclipse_0602\workspace\ojb-1-0\target\src\sql\create-db.sql ... jakob ----- Original Message ----- From: "Thomas Mahler" <tho...@ho...> To: "Matthew baird" <mat...@ya...> Cc: "Jakob Braeuchi" <jbr...@ho...>; "ojb" <obj...@li...> Sent: Sunday, June 02, 2002 10:07 PM Subject: Re: [OJB-developers] JUNIT failures & errors > The real solution would be to test against all supported databases: > > Hypersonic (HsqlDb) > MS_ACCESS > ORACLE > INSTANTDB > DB2 > POSTGRESQL > MYSQL > INFORMIX > MSSQLSERVER2000 > > (There have also been contributions for Sybase compatibility that have > not yet been incorporated into the distro yet. Its quite similar to > Ms-SqlServer.) > > cheers, > > Thomas > > Matthew baird wrote: > > > what subset of databases *should* be tested on to catch possible > > errors? HSQLDB seems to be easy to test on, MSSQL server covers sybase > > as well, and I know Oracle needs specific testing. Is it enough to test > > on those three > > > > > > > > > > ------------------------------------------------------------------------ > > *Do You Yahoo!?* > > Yahoo! <http://rd.yahoo.com/welcome/*http://fifaworldcup.yahoo.com> - > > Official partner of 2002 FIFA World Cup > |
From: Jason v. Z. <jv...@ze...> - 2002-06-03 12:02:35
|
Hi Thomas, Is the testbed working with Maven. I just released another version of Maven and it's stable now and the upgrade path in the future will be completely stable. I am going to upgrade the descriptor in the repo as I would prefer if this was the default build method when the code is moved over to Jakarta. Now that almost everything has been cleaned up in Maven in this release I feel more comfortable pushing. Continuous Integration will soon be available with Maven :-) We are also adding some testing features today that will make group testing and single class testing easier. When you run a group of tests, the default, a set of reports are generated. When you run a single test the output is displayed on the console. At any rate I will update the descriptor in the repo today to match the official release, unless Martin has already done it. As a side note, if anyone else from this group wants to try Maven I would be glad to help setup any projects that you might want to convert. -- jvz. Jason van Zyl jv...@ap... http://tambora.zenplex.org |
From: Mahler T. <tho...@it...> - 2002-06-03 09:25:15
|
Hi, > Hi guys > > I just wanted to write my test case to see how OJB updates > One to Many > references and I first looked at AutomaticForeignKeys class at > testOneManyReference() method. > > I think that this test case is wrong , at the comparing of > the article > names it is comparing the same objects : > I marked bad lines with " ************** " , and there is a > comment how it > should be. You are right. It's a bug in the testcase! > I made the changes and run the junit tests and then this test failed. > Please could someone take a peek at this because I am not yet > that familiar > with OJB. I'll check this! cheers, Thomas > > > Cheers > > .............................................................. > ................ > public void testOneManyReference() > { > try > { > Article art1 = new Article(); > art1.setArticleName("TOPLink"); > Article art2 = new Article(); > art2.setArticleName("OJB"); > Article art3 = new Article(); > art3.setArticleName("CASTOR"); > ProductGroup pg = new ProductGroup(); > pg.setName("O/R mapping tools"); > pg.add(art1); > pg.add(art2); > pg.add(art3); > Identity a1OID = new Identity(art1); > Identity a2OID = new Identity(art2); > Identity a3OID = new Identity(art3); > Identity pgOID = new Identity(pg); > broker.store(pg); > broker.clearCache(); > InterfaceProductGroup readInPG = > (InterfaceProductGroup) > broker.getObjectByIdentity(pgOID); > assertEquals(pg.getName(), readInPG.getName()); > > assertEquals(pg.getAllArticles().size(), > readInPG.getAllArticles().size()); > > // SHOULD BE : InterfaceArticle art1a = > (InterfaceArticle) > readInPG.getAllArticles().get(0); > // readInPG instead pg > > InterfaceArticle art1a = > (InterfaceArticle) pg.getAllArticles().get(0); > **************** > InterfaceArticle art2a = > (InterfaceArticle) pg.getAllArticles().get(1); > **************** > InterfaceArticle art3a = > (InterfaceArticle) pg.getAllArticles().get(2); > **************** > assertEquals(art1.getArticleName(), > art1a.getArticleName()); > assertEquals(art2.getArticleName(), > art2a.getArticleName()); > assertEquals(art3.getArticleName(), > art3a.getArticleName()); > } > catch (Throwable t) > { > System.out.println(t.getMessage()); > t.printStackTrace(); > fail(t.getMessage()); > } > } > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
From: Domagoj J. <do...@la...> - 2002-06-03 09:05:46
|
Hi guys I just wanted to write my test case to see how OJB updates One to Many references and I first looked at AutomaticForeignKeys class at testOneManyReference() method. I think that this test case is wrong , at the comparing of the article names it is comparing the same objects : I marked bad lines with " ************** " , and there is a comment how it should be. I made the changes and run the junit tests and then this test failed. Please could someone take a peek at this because I am not yet that familiar with OJB. Cheers .............................................................................. public void testOneManyReference() { try { Article art1 = new Article(); art1.setArticleName("TOPLink"); Article art2 = new Article(); art2.setArticleName("OJB"); Article art3 = new Article(); art3.setArticleName("CASTOR"); ProductGroup pg = new ProductGroup(); pg.setName("O/R mapping tools"); pg.add(art1); pg.add(art2); pg.add(art3); Identity a1OID = new Identity(art1); Identity a2OID = new Identity(art2); Identity a3OID = new Identity(art3); Identity pgOID = new Identity(pg); broker.store(pg); broker.clearCache(); InterfaceProductGroup readInPG = (InterfaceProductGroup) broker.getObjectByIdentity(pgOID); assertEquals(pg.getName(), readInPG.getName()); assertEquals(pg.getAllArticles().size(), readInPG.getAllArticles().size()); // SHOULD BE : InterfaceArticle art1a = (InterfaceArticle) readInPG.getAllArticles().get(0); // readInPG instead pg InterfaceArticle art1a = (InterfaceArticle) pg.getAllArticles().get(0); **************** InterfaceArticle art2a = (InterfaceArticle) pg.getAllArticles().get(1); **************** InterfaceArticle art3a = (InterfaceArticle) pg.getAllArticles().get(2); **************** assertEquals(art1.getArticleName(), art1a.getArticleName()); assertEquals(art2.getArticleName(), art2a.getArticleName()); assertEquals(art3.getArticleName(), art3a.getArticleName()); } catch (Throwable t) { System.out.println(t.getMessage()); t.printStackTrace(); fail(t.getMessage()); } } |