New Apache db project loosely coupled to Apache JDO
Hi Brian, Geir, I'd like to start a sub-project that JDO needs but don't want to develop it in Apache JDO, because it goes beyond JDO. It is a memory model of relational database schema that can be used for O/R mapping GUI applications for JDO and EJB3, as well as the runtime mapping. Anyway, we could start building it in Apache JDO just because we have the infrastructure in place, but would really like *not* to have any JDO in the package name. We would want to call it org.apache.db.model and put interfaces there that could be reused by other projects. I'd also like to have an alias for talking about the model in the Apache DB group. Any of this make sense? Thanks, Craig 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: New Apache db project loosely coupled to Apache JDO
Makes sense, and might overlap a lot with the DdlUtils stuff. I cc:ed Tom Dudziak who knows a lot about that project. -Brian On Apr 27, 2005, at 12:00 PM, Craig Russell wrote: Hi Brian, Geir, I'd like to start a sub-project that JDO needs but don't want to develop it in Apache JDO, because it goes beyond JDO. It is a memory model of relational database schema that can be used for O/R mapping GUI applications for JDO and EJB3, as well as the runtime mapping. Anyway, we could start building it in Apache JDO just because we have the infrastructure in place, but would really like *not* to have any JDO in the package name. We would want to call it org.apache.db.model and put interfaces there that could be reused by other projects. I'd also like to have an alias for talking about the model in the Apache DB group. Any of this make sense? Thanks, Craig 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: New Apache db project loosely coupled to Apache JDO
Hi Brian, do you have a link to get more details about the DdlUtils stuff? Regards Michael Makes sense, and might overlap a lot with the DdlUtils stuff. I cc:ed Tom Dudziak who knows a lot about that project. -Brian On Apr 27, 2005, at 12:00 PM, Craig Russell wrote: Hi Brian, Geir, I'd like to start a sub-project that JDO needs but don't want to develop it in Apache JDO, because it goes beyond JDO. It is a memory model of relational database schema that can be used for O/R mapping GUI applications for JDO and EJB3, as well as the runtime mapping. Anyway, we could start building it in Apache JDO just because we have the infrastructure in place, but would really like *not* to have any JDO in the package name. We would want to call it org.apache.db.model and put interfaces there that could be reused by other projects. I'd also like to have an alias for talking about the model in the Apache DB group. Any of this make sense? Thanks, Craig 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 Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Collections of interfaces
Hi, Erik, Does this extension work with SchemaTool also? When I try it I get: JPOX SchemaTool (version 1.1.0-beta-3) : Creation of the schema Exception in thread main java.lang.NoClassDefFoundError: org/apache/jdo/tck/pc/fieldtypes/SimpleInterface at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at org.jpox.metadata.MetaDataUtils.resolvedClassForName(MetaDataUtils.java:348) at org.jpox.metadata.CollectionMetaData.populate(CollectionMetaData.java:116) at org.jpox.metadata.FieldMetaData.populate(FieldMetaData.java:618) at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:647) at org.jpox.metadata.MetaDataManager.initialiseMetaDataForClass(MetaDataManager.java:753) at org.jpox.metadata.MetaDataManager.getMetaDataForClassOrInterface(MetaDataManager.java:407) at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:259) at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:244) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.getReferencedClasses(RDBMSManager.java:2323) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTables(RDBMSManager.java:2118) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:2395) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.execute(RDBMSManager.java:2066) at org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:1936) at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:477) at org.jpox.SchemaTool.createSchemaTables(SchemaTool.java:176) at org.jpox.SchemaTool.main(SchemaTool.java:610) The metadata was: ... field name=ListOfSimpleInterface6 extension vendor-name=jpox key=implementation-classes value=org.apache.jdo.tck.pc.fieldtypes.SimpleInterface/ collection element-type=org.apache.jdo.tck.pc.fieldtypes.SimpleInterface /collection /field field name=ListOfSimpleInterface7 extension vendor-name=jpox key=implementation-classes value=org.apache.jdo.tck.pc.fieldtypes.SimpleInterface/ collection element-type=org.apache.jdo.tck.pc.fieldtypes.SimpleInterface embedded-element=true /collection /field ... -- Michelle [EMAIL PROTECTED] wrote: ??? JPOX supports it using the extension implementation-classes and listing all implementations there. Erik Bengtson -Original Message- From: Craig Russell [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 2:17 AM To: JDO Expert Group Subject: Collections of interfaces Javadogs, The JPOX team has pointed out that JDO doesn't require support for Collections of interfaces as persistent field types. Clearly, this was an oversight, as it was meant to be required and there are actually TCK tests for it. I'd like to correct the oversight in the JDO 2.0 spec. So I need to know: Are there any JDO implementations that do not support this? All implementations that claimed to pass the TCK should have run into this... Thanks, Craig 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: Collections of interfaces
Hi Michelle, On Apr 27, 2005, at 8:40 AM, Michelle Caisse wrote: Hi, Craig, I'm not sure what you mean by map. Are you referring to Erik's email about using the implementation-classes extension? I can figure that out, I would think. I assume it would go into the jdo file and not the orm. I was hoping (actually expecting) that the JPOX-specific stuff would be in the .orm file not the .jdo file. The .jdo file is supposed to be able to contain *just* the object model stuff, and no mapping information. And enumerating the classes that can implement the interface for the purpose of being able to map to the database seems like mapping information to me. This stuff falls into the category of what changes are allowed to the TCK files in order to pass the tests. I'd like to think that the .jdo files are not touchable, but the .orm files are allowed to be changed. So adding vendor-specific stuff to .jdo doesn't appeal to me. On another note, yesterday I collected more information on the OutOfMemoryError problem (http://issues.apache.org/jira/browse/JDO-21). It seems that there are several different causes: some instances of not closing the pmf and some specific tests that gobble memory and don't return it when they complete. If you know of specific cases where resources are not being closed or returned, these could be filed as individual JIRA bugs (assuming that it's easier to file a JIRA than just to fix it, using JDO-21 as the bug report to file it against). Do you have someone else who can work on this or is it in my queue? Anyone else on the alias who can help out here is welcome to do so. I really wish I had more people who were signed up... Craig -- Michelle Craig Russell wrote:Hi Michelle, Can you find out how to map the collections of interfaces that you are having trouble with? Thanks, Craig Begin forwarded message: From: [EMAIL PROTECTED] Date: April 26, 2005 11:46:43 PM PDT To: 'JDO Expert Group' [EMAIL PROTECTED]> Subject: RE: Collections of interfaces ??? JPOX supports it using the extension implementation-classes and listing all implementations there. Erik Bengtson -Original Message- From: Craig Russell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 27, 2005 2:17 AM To: JDO Expert Group Subject: Collections of interfaces Javadogs, The JPOX team has pointed out that JDO doesn't require support for Collections of interfaces as persistent field types. Clearly, this was an oversight, as it was meant to be required and there are actually TCK tests for it. I'd like to correct the oversight in the JDO 2.0 spec. So I need to know: Are there any JDO implementations that do not support this? All implementations that claimed to pass the TCK should have run into this... Thanks, Craig 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! Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! 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: Collections of interfaces
Exception in thread main java.lang.NoClassDefFoundError: org/apache/jdo/tck/pc/fieldtypes/SimpleInterface So it cant find the class SimpleInterface ? extension vendor-name=jpox key=implementation-classes value=org.apache.jdo.tck.pc.fieldtypes.SimpleInterface/ SimpleInterface is an interface not a class. implementation-classes is supposed to contain the names of the classes implementing the interface type of the field in question -- Andy Java Persistent Objects JDO - JPOX
Re: Collections of interfaces
Hi Michelle, This is confusing. The symptom points to a need to have the SimpleInterface in your class path when you run the enhancer. But if you are enhancing the FieldTypes class, SimpleInterface must be there or you would not be able to load the class to be enhanced. I'd guess you have to put into project.properties the field type classes SimpleInterface and SimpleClass in the pcclasses.files list. Craig On Apr 27, 2005, at 10:12 AM, Andy Jefferson wrote: Exception in thread main java.lang.NoClassDefFoundError: org/apache/jdo/tck/pc/fieldtypes/SimpleInterface So it cant find the class SimpleInterface ? extension vendor-name=jpox key=implementation-classes value=org.apache.jdo.tck.pc.fieldtypes.SimpleInterface/ SimpleInterface is an interface not a class. implementation-classes is supposed to contain the names of the classes implementing the interface type of the field in question -- Andy Java Persistent Objects JDO - JPOX 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: Collections of interfaces
Hi, Responses in-line. Craig Russell wrote: Hi Michelle, On Apr 27, 2005, at 8:40 AM, Michelle Caisse wrote: Hi, Craig, I'm not sure what you mean by map. Are you referring to Erik's email about using the implementation-classes extension? I can figure that out, I would think. I assume it would go into the jdo file and not the orm. I was hoping (actually expecting) that the JPOX-specific stuff would be in the .orm file not the .jdo file. The .jdo file is supposed to be able to contain *just* the object model stuff, and no mapping information. And enumerating the classes that can implement the interface for the purpose of being able to map to the database seems like mapping information to me. This stuff falls into the category of what changes are allowed to the TCK files in order to pass the tests. I'd like to think that the .jdo files are not touchable, but the .orm files are allowed to be changed. So adding vendor-specific stuff to .jdo doesn't appeal to me. I have the particular short-term task of using JPOX SchemaTool to generate the DDL and .orm files for the pc.fieldtypes classes containing collections of interfaces . So I don't yet have the .orm file in which to place any vendor extensions. This extension has been around since JPOX 1.0 (the JDO 1 release), so I assume that it is actually meant to go in the .jdo file. On another note, yesterday I collected more information on the OutOfMemoryError problem (http://issues.apache.org/jira/browse/JDO-21). It seems that there are several different causes: some instances of not closing the pmf and some specific tests that gobble memory and don't return it when they complete. If you know of specific cases where resources are not being closed or returned, these could be filed as individual JIRA bugs (assuming that it's easier to file a JIRA than just to fix it, using JDO-21 as the bug report to file it against). I will do a little more investigation and then file some individual JIRAs. Thanks, Craig. -- Michelle Do you have someone else who can work on this or is it in my queue? Anyone else on the alias who can help out here is welcome to do so. I really wish I had more people who were signed up... Craig -- Michelle Craig Russell wrote:Hi Michelle, Can you find out how to map the collections of interfaces that you are having trouble with? Thanks, Craig Begin forwarded message: *From: [EMAIL PROTECTED] *Date: *April 26, 2005 11:46:43 PM PDT *To: *'JDO Expert Group' [EMAIL PROTECTED] *Subject: RE: Collections of interfaces* ??? JPOX supports it using the extension implementation-classes and listing all implementations there. Erik Bengtson -Original Message- From: Craig Russell [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 2:17 AM To: JDO Expert Group Subject: Collections of interfaces Javadogs, The JPOX team has pointed out that JDO doesn't require support for Collections of interfaces as persistent field types. Clearly, this was an oversight, as it was meant to be required and there are actually TCK tests for it. I'd like to correct the oversight in the JDO 2.0 spec. So I need to know: Are there any JDO implementations that do not support this? All implementations that claimed to pass the TCK should have run into this... Thanks, Craig 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! Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! 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: Collections of interfaces
Craig, thanks, Yes, I needed to have SimpleInterface.class in my classpath. I was running SchemaTool on the enhanced jar in order to have the jdo and classes in one place, but the interface was missing. Fixed that, and I'm off and running. -- Michelle Craig Russell wrote: Hi Michelle, This is confusing. The symptom points to a need to have the SimpleInterface in your class path when you run the enhancer. But if you are enhancing the FieldTypes class, SimpleInterface must be there or you would not be able to load the class to be enhanced. I'd guess you have to put into project.properties the field type classes SimpleInterface and SimpleClass in the pcclasses.files list. Craig On Apr 27, 2005, at 10:12 AM, Andy Jefferson wrote: Exception in thread main java.lang.NoClassDefFoundError: org/apache/jdo/tck/pc/fieldtypes/SimpleInterface So it cant find the class SimpleInterface ? extension vendor-name=jpox key=implementation-classes value=org.apache.jdo.tck.pc.fieldtypes.SimpleInterface/ SimpleInterface is an interface not a class. implementation-classes is supposed to contain the names of the classes implementing the interface type of the field in question -- Andy Java Persistent Objects JDO - JPOX 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: New Apache db project loosely coupled to Apache JDO
Hi Thomas, Just today I looked for something like the ddlutils at the apache db web site and came up dry. Thanks for the info. We will be looking at this with keen interest, so let us know (via the alias of course) what it happening! Thanks, Craig On Apr 27, 2005, at 11:05 AM, Thomas Dudziak wrote: Brian McCallister wrote: On Apr 27, 2005, at 12:54 PM, Michael Bouschen wrote: Hi Brian, do you have a link to get more details about the DdlUtils stuff? http://db.apache.org/ddlutils/ DdlUtils and its site are freshly migrated, I need to update and enhance it in the next days. Feel free to register at the mailing lists: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] FYI, one of the main purposes of the migration of commons-sql to db.apache.org is that Torque and OJB (and others) can create/maintain a common codebase for DDL-related stuff, e.g. working with a database schema in code, creating/altering/deleting/dumping this database schema etc. Tom 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
