[jira] Commented: (JDO-539) JPA annotations tests fail
[ https://issues.apache.org/jira/browse/JDO-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533271 ] Andy Jefferson commented on JDO-539: Perhaps the "JPA Annotation Tests" should only be run under application identity, since JPA doesnt have an idea what is datastore identity > JPA annotations tests fail > -- > > Key: JDO-539 > URL: https://issues.apache.org/jira/browse/JDO-539 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > > companyAnnotatedNoRelationshipsJPAConcrete.conf and > companyAnnotatedNoRelationshipsJPAConcrete.conf fail: > test(org.apache.jdo.tck.mapping.CompletenessTest)javax.jdo.JDOUserException: > One or more instances could not be made persistent > at > org.jpox.AbstractPersistenceManager.makePersistentAll(AbstractPersistenceManager.java:694) > at > org.apache.jdo.tck.mapping.CompletenessTest.localSetUp(CompletenessTest.java:79) > at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:237) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:253) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > NestedThrowablesStackTrace: > javax.jdo.JDOFatalInternalException: Duplicate column name "PERSONID" defined > for table "applicationidentity0.EMPLOYEE_PHONENO_TYPE". You cannot map > multiple fields to the same column. The duplicated columns are specified by > org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.personid and > org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.person. > at > org.jpox.jdo.JPOXJDOHelper.getJDOExceptionForJPOXException(JPOXJDOHelper.java:369) > at > org.jpox.AbstractPersistenceManager.jdoMakePersistent(AbstractPersistenceManager.java:631) > at > org.jpox.AbstractPersistenceManager.makePersistentAll(AbstractPersistenceManager.java:680) > at > org.apache.jdo.tck.mapping.CompletenessTest.localSetUp(CompletenessTest.java:79) > at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:237) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:253) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > NestedThrowablesStackTrace: > Duplicate column name "PERSONID" defined for table > "applicationidentity0.EMPLOYEE_PHONENO_TYPE". You cannot map multiple fields > to the same column. The duplicated columns are specified by > org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.personid and > org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.person. > org.jpox.store.rdbms.exceptions.DuplicateColumnNameException: Duplicate > column name "PERSONID" defined for table > "applicationidentity0.EMPLOYEE_PHONENO_TYPE". You cannot map multiple fields > to the same column. The duplicated columns are specified by > org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.personid and > org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.person. > at > org.jpox.store.rdbms.table.AbstractTable.addDatastoreField(AbstractTable.java:261) > at > org.jpox.store.rdbms.mapping.RDBMSMappingManager.createDatastoreField(RDBMSMappingManager.java:840) > at > org.jpox.store.mapping.PersistenceCapableMapping.prepareDatastoreMapping(PersistenceCapableMapping.java:227) > at > org.jpox.store.mapping.PersistenceCapableMapping.initialize(PersistenceCapableMapping.java:123) > at > org.jpox.store.mapping.MappingFactory.createMapping(MappingFactory.java:93) > at > org.jpox.store.mapping.AbstractMappingManager.getMapping(AbstractMappingManager.java:234) > at > org.jpox.store.rdbms.table.ClassTable.manageFields(ClassTable.java:520) > at > org.jpox.store.rdbms.table.ClassTable.manageClass(ClassTable.java:400) > at > org.jpox.store.rdbms.table.ClassTable.initializeForClass(ClassTable.java:971) > at org.jpox.store.rdbms.table.ClassTable.initialize(ClassTable.java:271) > at > org.jpox.store.rdbms.RDBMSManager$ClassAdder.initializeClassTables(RDBMSManager.java:3408) > at > org.jpox.store.rdbms.RDBMS
[jira] Commented: (JDO-539) JPA annotations tests fail
[
https://issues.apache.org/jira/browse/JDO-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532904
]
Andy Jefferson commented on JDO-539:
Hi Michelle,
what is the mapping in JPAAppPhoneNumber supposed to be doing ?
public class JPAAppPhoneNumber implements Serializable {
@Id
@Column(name="PERSONID")
private long personid;
@ManyToOne
@JoinColumn(name="PERSONID", insertable=false, updatable=false)
private JPAAppPerson person;
...
}
You have a PK field with a column name of PERSONID, and you also want a N-1 to
have a FK using the same column (the PK) ? I'd expect the second to have its
own column - it cannot reuse the PK (JPA1 has no support for "compound
identity"/"identifying" relations)
> JPA annotations tests fail
> --
>
> Key: JDO-539
> URL: https://issues.apache.org/jira/browse/JDO-539
> Project: JDO
> Issue Type: Bug
> Components: tck2
>Affects Versions: JDO 2 maintenance release 1
>Reporter: Michelle Caisse
>Assignee: Andy Jefferson
>
> companyAnnotatedNoRelationshipsJPAConcrete.conf and
> companyAnnotatedNoRelationshipsJPAConcrete.conf fail:
> test(org.apache.jdo.tck.mapping.CompletenessTest)javax.jdo.JDOUserException:
> One or more instances could not be made persistent
> at
> org.jpox.AbstractPersistenceManager.makePersistentAll(AbstractPersistenceManager.java:694)
> at
> org.apache.jdo.tck.mapping.CompletenessTest.localSetUp(CompletenessTest.java:79)
> at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:237)
> at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:253)
> at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
> at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
> at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
> NestedThrowablesStackTrace:
> javax.jdo.JDOFatalInternalException: Duplicate column name "PERSONID" defined
> for table "applicationidentity0.EMPLOYEE_PHONENO_TYPE". You cannot map
> multiple fields to the same column. The duplicated columns are specified by
> org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.personid and
> org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.person.
> at
> org.jpox.jdo.JPOXJDOHelper.getJDOExceptionForJPOXException(JPOXJDOHelper.java:369)
> at
> org.jpox.AbstractPersistenceManager.jdoMakePersistent(AbstractPersistenceManager.java:631)
> at
> org.jpox.AbstractPersistenceManager.makePersistentAll(AbstractPersistenceManager.java:680)
> at
> org.apache.jdo.tck.mapping.CompletenessTest.localSetUp(CompletenessTest.java:79)
> at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:237)
> at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:253)
> at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
> at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
> at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
> NestedThrowablesStackTrace:
> Duplicate column name "PERSONID" defined for table
> "applicationidentity0.EMPLOYEE_PHONENO_TYPE". You cannot map multiple fields
> to the same column. The duplicated columns are specified by
> org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.personid and
> org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.person.
> org.jpox.store.rdbms.exceptions.DuplicateColumnNameException: Duplicate
> column name "PERSONID" defined for table
> "applicationidentity0.EMPLOYEE_PHONENO_TYPE". You cannot map multiple fields
> to the same column. The duplicated columns are specified by
> org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.personid and
> org.apache.jdo.tck.pc.companyAnnotatedJPA.JPAAppPhoneNumber.person.
> at
> org.jpox.store.rdbms.table.AbstractTable.addDatastoreField(AbstractTable.java:261)
> at
> org.jpox.store.rdbms.mapping.RDBMSMappingManager.createDatastoreField(RDBMSMappingManager.java:840)
> at
> org.jpox.store.mapping.PersistenceCapableMapping.prepareDatastoreMapping(PersistenceCapableMapping.java:227)
> at
> org.jpox.store.mapping.PersistenceCapableMapping.initialize(PersistenceCapableMapping.java:123)
> at
> org.jpox.store.mapping.MappingFactory.createMapping(MappingFactory.java:93)
> at
> org.jpox.store.mapping.AbstractMappingManager.getMapping(AbstractMappingManager.java:234)
> at
> org.jpo
Re: more feedback on new jdo docs
> If you're so inclined, you can file a patch to the documents in > question. You can attach the patch to the existant JIRA, just to make > it easy. Or just wait the necessary x hours for content to show up on the site; was corrected in SVN a few mins ago. Ahh, the power of SVN commit rights ... But the general comment does apply, please just add patches for the relevant docs to JDO-537 and they will be processed. -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Commented: (JDO-537) Upgrade Apache JDO site to encompass user-level documentation/guides etc
[ https://issues.apache.org/jira/browse/JDO-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532086 ] Andy Jefferson commented on JDO-537: Apache JDO logo moved to left hand side. Docs split between User and Implementor. Majority of JPOX docs migrated. > Upgrade Apache JDO site to encompass user-level documentation/guides etc > > > Key: JDO-537 > URL: https://issues.apache.org/jira/browse/JDO-537 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure > Reporter: Andy Jefferson > Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > Attachments: xdocs.zip > > > The Apache JDO site is good as far as it goes, but is typically at a > developer level. The vast majority of users don't read the JDO specification, > and certainly not in any detail. It would benefit from a revamp to take on > user-level docs describing basic JDO terminology such as PersistenceManager, > PersistenceManagerFactory, JDOQL, Extents etc etc. In addition some simple > worked examples would aid uptake. The JPOX site already has a selection of > such docs at > http://www.jpox.org/docs/jdo/jdo_overview.html > and they could be moved across. > The current site is generated using Anakia, but would likely be more > extensible and cleaner using Maven1 site/xdoc plugins. As a demonstration of > this, there is an initial Maven1 version of the Apache JDO site at > http://www.jpox.org/apachejdo/index.html > This demo has had very little configuration, and is located there temporarily > to allow feedback, and will be removed in the future. Maven1 site/xdoc allows > "navigation.xml" (to define the side navigation), "site.jsl" (to define the > velocity process of putting together top, side, body and bottom areas on each > page), and 3 CSS files to control styling, fonts and such. The side menu can > benefit from submenus with expand/collapse to aid display of large amounts of > content. > I'd anticipate adding the following side menu groups, but others may have > better ideas > * Documentation - with pages for different JDO concepts PM, PMF, JDOQL, > Extent, etc > * Tutorials - very simple worked examples, things like 1-1, or replication, > or how to have an M-N with attributes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
JDOCentral again
Hi Craig, you mentioned that Dirk Bartels was willing to change the jdocentral.com domain config to redirect to Apache JDO. This doesn't seem to have happened yet. Did he give a timescale of when it may be expected ? Other issue on JDOCentral:- There were a series of articles on JDOCentral. Two that spring to mind (since JPOX hyperlinked them some time ago) were by David Jordan "Managing your Relationships" "New features in JDO 2.0 Query Language" Any others still of relevance ? Would it be possible to get these copied across to Apache JDO? Does Dirk still have a copy of the content ? or does David have them still ? If so and the author is ok with trafserring to Apache JDO, could someone please attach them to JIRA JDO-537. -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Commented: (JDO-537) Upgrade Apache JDO site to encompass user-level documentation/guides etc
[ https://issues.apache.org/jira/browse/JDO-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531786 ] Andy Jefferson commented on JDO-537: Thanks for your comments Michelle. 1. Deployment. I added a Maven1 goal "savesite" that does the copy from target/docs to docs, so the deploy uses the existing mechanism (and I've never used maven site:deploy anyway so have no issue with using what you have there). 2. Logo link, now goes to "http://db.apache.org/jdo";. 3. Space on the header. We can put whatever you want there. See the JPOX docs, where we have a banner. This is defined in the xdocs/site.jsl file, the block that starts . Some sites put the parent Apache project (e.g http://db.apache.org) but in this case I see little point since that is not a project as such, just a storage container with no defined purpose. Open to suggestions ... "Java Data Objects" image of some form if anyone feels artistic ;-) 4. Switch to new design, so I've checked in the following Sending/usr/local/tck/jdo/site/HOWTO Adding /usr/local/tck/jdo/site/maven.xml Adding /usr/local/tck/jdo/site/project.properties Adding /usr/local/tck/jdo/site/project.xml Adding /usr/local/tck/jdo/site/xdocs/enhancement.xml Adding /usr/local/tck/jdo/site/xdocs/exceptions.xml Adding /usr/local/tck/jdo/site/xdocs/glossary.xml Sending/usr/local/tck/jdo/site/xdocs/impls.xml Adding /usr/local/tck/jdo/site/xdocs/jdo_dtd.xml Adding /usr/local/tck/jdo/site/xdocs/jdo_v_jpa.xml Adding /usr/local/tck/jdo/site/xdocs/jdo_v_jpa_orm.xml Adding /usr/local/tck/jdo/site/xdocs/jdohelper.xml Adding /usr/local/tck/jdo/site/xdocs/jdoquery_dtd.xml Adding /usr/local/tck/jdo/site/xdocs/navigation.xml Adding /usr/local/tck/jdo/site/xdocs/orm_dtd.xml Adding /usr/local/tck/jdo/site/xdocs/site.jsl Adding /usr/local/tck/jdo/site/xdocs/specifications.xml Adding /usr/local/tck/jdo/site/xdocs/style Adding /usr/local/tck/jdo/site/xdocs/style/maven-base.css Adding /usr/local/tck/jdo/site/xdocs/style/maven-classic.css Adding /usr/local/tck/jdo/site/xdocs/style/maven-theme.css Adding /usr/local/tck/jdo/site/xdocs/style/print.css Adding /usr/local/tck/jdo/site/xdocs/tutorials Adding /usr/local/tck/jdo/site/xdocs/tutorials/replication.xml Adding /usr/local/tck/jdo/site/xdocs/why_jdo.xml (and the associated docs files) Transmitting file data ... Committed revision 581216. So there are a small number of new docs added. Feel free to update as required. I've updated the HOWTO to describe the places needing changes when adding docs or changing the navigation. 5. The existing build.xml and lib files are still present currently, so we have an easy way of back-comparing, but need removing before closure of this JIRA. > Upgrade Apache JDO site to encompass user-level documentation/guides etc > > > Key: JDO-537 > URL: https://issues.apache.org/jira/browse/JDO-537 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure > Reporter: Andy Jefferson >Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > Attachments: xdocs.zip > > > The Apache JDO site is good as far as it goes, but is typically at a > developer level. The vast majority of users don't read the JDO specification, > and certainly not in any detail. It would benefit from a revamp to take on > user-level docs describing basic JDO terminology such as PersistenceManager, > PersistenceManagerFactory, JDOQL, Extents etc etc. In addition some simple > worked examples would aid uptake. The JPOX site already has a selection of > such docs at > http://www.jpox.org/docs/jdo/jdo_overview.html > and they could be moved across. > The current site is generated using Anakia, but would likely be more > extensible and cleaner using Maven1 site/xdoc plugins. As a demonstration of > this, there is an initial Maven1 version of the Apache JDO site at > http://www.jpox.org/apachejdo/index.html > This demo has had very little configuration, and is located there temporarily > to allow feedback, and will be removed in the future. Maven1 site/xdoc allows > "navigation.xml" (to define the side navigation), "site.jsl" (to define the > velocity process of putting together top, side, body and bottom areas on each > page), and 3 CSS files to control styling, fonts and such. T
[jira] Resolved: (JDO-517) NPE on enhancement of classes with persistent properties
[ https://issues.apache.org/jira/browse/JDO-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson resolved JDO-517. Resolution: Fixed Fix Version/s: JDO 2 maintenance release 1 Assignee: Andy Jefferson (was: Michelle Caisse) The 4 tests for persistent properties companyAnnotatedAllRelationshipsPCConcrete.conf companyAnnotatedAllRelationshipsPCPM.conf companyAnnotatedNoRelationshipsPCPM.conf companyAnnotatedNoRelationshipsPCConcrete.conf all now pass with JPOX CVS HEAD > NPE on enhancement of classes with persistent properties > > > Key: JDO-517 > URL: https://issues.apache.org/jira/browse/JDO-517 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse > Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > > To reproduce, edit project.propeties, go to the end of the file, and edit out > the comment and blank lines so that the classes in the companyAnnotatedPC > package are included in the argument list to the enhancer. > 11:39:16,031 (main) ERROR [JPOX.Enhancer] - An error was encountered reading > the specified input files. Please consult the log for details. The following > may help : Errors were encountered when loading the specified MetaData files > and classes. See the nested exceptions for details > Errors were encountered when loading the specified MetaData files and > classes. See the nested exceptions for details > org.jpox.exceptions.JPOXUserException: Errors were encountered when loading > the specified MetaData files and classes. See the nested exceptions for > details > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:299) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > Caused by: java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > ... 2 more > Nested Throwables StackTrace: > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-537) Upgrade Apache JDO site to encompass user-level documentation/guides etc
[ https://issues.apache.org/jira/browse/JDO-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-537: --- Attachment: xdocs.zip Current working set of files for "/jdo/site/". Note that the previous "lib" and "build.xml" aren't needed with this process. Simply type "maven site" and the docs are built under target/docs. Still need to then copy them into "docs" for consistency with the current process of putting the site onto Apache > Upgrade Apache JDO site to encompass user-level documentation/guides etc > > > Key: JDO-537 > URL: https://issues.apache.org/jira/browse/JDO-537 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Reporter: Andy Jefferson >Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > Attachments: xdocs.zip > > > The Apache JDO site is good as far as it goes, but is typically at a > developer level. The vast majority of users don't read the JDO specification, > and certainly not in any detail. It would benefit from a revamp to take on > user-level docs describing basic JDO terminology such as PersistenceManager, > PersistenceManagerFactory, JDOQL, Extents etc etc. In addition some simple > worked examples would aid uptake. The JPOX site already has a selection of > such docs at > http://www.jpox.org/docs/jdo/jdo_overview.html > and they could be moved across. > The current site is generated using Anakia, but would likely be more > extensible and cleaner using Maven1 site/xdoc plugins. As a demonstration of > this, there is an initial Maven1 version of the Apache JDO site at > http://www.jpox.org/apachejdo/index.html > This demo has had very little configuration, and is located there temporarily > to allow feedback, and will be removed in the future. Maven1 site/xdoc allows > "navigation.xml" (to define the side navigation), "site.jsl" (to define the > velocity process of putting together top, side, body and bottom areas on each > page), and 3 CSS files to control styling, fonts and such. The side menu can > benefit from submenus with expand/collapse to aid display of large amounts of > content. > I'd anticipate adding the following side menu groups, but others may have > better ideas > * Documentation - with pages for different JDO concepts PM, PMF, JDOQL, > Extent, etc > * Tutorials - very simple worked examples, things like 1-1, or replication, > or how to have an M-N with attributes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JDO-537) Upgrade Apache JDO site to encompass user-level documentation/guides etc
Upgrade Apache JDO site to encompass user-level documentation/guides etc Key: JDO-537 URL: https://issues.apache.org/jira/browse/JDO-537 Project: JDO Issue Type: Improvement Components: site and infrastructure Reporter: Andy Jefferson Assignee: Andy Jefferson Fix For: JDO 2 maintenance release 1 The Apache JDO site is good as far as it goes, but is typically at a developer level. The vast majority of users don't read the JDO specification, and certainly not in any detail. It would benefit from a revamp to take on user-level docs describing basic JDO terminology such as PersistenceManager, PersistenceManagerFactory, JDOQL, Extents etc etc. In addition some simple worked examples would aid uptake. The JPOX site already has a selection of such docs at http://www.jpox.org/docs/jdo/jdo_overview.html and they could be moved across. The current site is generated using Anakia, but would likely be more extensible and cleaner using Maven1 site/xdoc plugins. As a demonstration of this, there is an initial Maven1 version of the Apache JDO site at http://www.jpox.org/apachejdo/index.html This demo has had very little configuration, and is located there temporarily to allow feedback, and will be removed in the future. Maven1 site/xdoc allows "navigation.xml" (to define the side navigation), "site.jsl" (to define the velocity process of putting together top, side, body and bottom areas on each page), and 3 CSS files to control styling, fonts and such. The side menu can benefit from submenus with expand/collapse to aid display of large amounts of content. I'd anticipate adding the following side menu groups, but others may have better ideas * Documentation - with pages for different JDO concepts PM, PMF, JDOQL, Extent, etc * Tutorials - very simple worked examples, things like 1-1, or replication, or how to have an M-N with attributes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Apache JDO : site
I propose moving a number of JPOX docs general to JDO onto Apache JDO's site. To be more specific, we (JPOX) have some docs under http://www.jpox.org/docs/jdo/jdo_overview.html some of which need updating (some of the figures are outdated or could be cleaner), but all are based around explaining the JDO spec to users (since the average JDO user doesnt go near the spec, but may respond better to pretty flow charts and sample code). They would sit better over on Apache JDO IMHO. Issue 1 : Anyone against this move of content? Any issues, or any of the docs in that section not suitable ? Issue 2 : by moving these docs over, the Apache JDO site will start to get much more content than it currently has, and when this happens it may be necessary to add top-level navigation as well as the current side navigation, or to add hide/show features to the side navigation. Apache JDO currently uses some "Anakia" (?!) to generate the docs which I know little of (except that its Velocity underneath), so why is this used instead of Maven1 "site" plugin (which is also Velocity) ? Any objections to using Maven1 "site"? -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Commented: (JDO-535) Add method evictAll taking a class instance to PersistenceManager interface
[ https://issues.apache.org/jira/browse/JDO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531228 ] Andy Jefferson commented on JDO-535: JPOX CVS has this method already added, so applying the patch would cause us no problems. > Add method evictAll taking a class instance to PersistenceManager interface > --- > > Key: JDO-535 > URL: https://issues.apache.org/jira/browse/JDO-535 > Project: JDO > Issue Type: New Feature > Components: api2, api2-legacy >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen > Fix For: JDO 2 maintenance release 1 > > Attachments: JDO-535.patch > > > The PersistenceManager interface does not provide an evictAll method taking a > class instance, while the DataStoreCache interface does define this method to > evict instances from the second level cache. This allows to evict instances > for a particluar class. > I propose to add the following method to the PersisteneManager interface: >void evictAll (Class pcClass, boolean subclasses); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JDO-536) Exception during TearDown: org.jpox.sco.HashMap cannot be cast to org.jpox.sco.Map
[ https://issues.apache.org/jira/browse/JDO-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson resolved JDO-536. Resolution: Fixed Fix Version/s: JDO 2 maintenance release 1 Teardown error is fixed with JPOX CVS HEAD, and Apache JDO SVN latest. Test still fails but that's a different JIRA. > Exception during TearDown: org.jpox.sco.HashMap cannot be cast to > org.jpox.sco.Map > -- > > Key: JDO-536 > URL: https://issues.apache.org/jira/browse/JDO-536 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse >Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > > Exception on teardown in companyAnnotatedAllRelationshipsPCConcrete.conf, > datastore identity only, causes succeeding tests to fail. > 10:48:14,609 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > java.lang.ArrayIndexOutOfBoundsException: 0 > at > org.jpox.state.AbstractStateManager.replacingLongField(AbstractStateManager.java:850) > at org.apache.jdo.tck.pc.company.Address.jdoReplaceField(Address.java) > at > org.jpox.state.JDOStateManagerImpl.replaceField(JDOStateManagerImpl.java:2521) > at > org.jpox.state.JDOStateManagerImpl.replaceField(JDOStateManagerImpl.java:2400) > at > org.jpox.store.mapping.EmbeddedMapping.getObject(EmbeddedMapping.java:499) > at > org.jpox.store.rdbms.fieldmanager.ResultSetGetter.fetchObjectField(ResultSetGetter.java:111) > at > org.jpox.state.AbstractStateManager.replacingObjectField(AbstractStateManager.java:898) > at > org.apache.jdo.tck.pc.companyAnnotatedPC.PCDSCompany.jdoReplaceField(PCDSCompany.java) > at > org.apache.jdo.tck.pc.companyAnnotatedPC.PCDSCompany.jdoReplaceFields(PCDSCompany.java) > at > org.jpox.state.JDOStateManagerImpl.replaceFields(JDOStateManagerImpl.java:2606) > at > org.jpox.state.JDOStateManagerImpl.replaceFields(JDOStateManagerImpl.java:2625) > at > org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:238) > at org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:2772) > at > org.jpox.store.MappedStoreManager.fetchObject(MappedStoreManager.java:218) > at > org.jpox.state.JDOStateManagerImpl.loadSpecifiedFields(JDOStateManagerImpl.java:1415) > at > org.jpox.state.JDOStateManagerImpl.isLoaded(JDOStateManagerImpl.java:1759) > at > org.apache.jdo.tck.pc.companyAnnotatedPC.PCDSCompany.getAddress(PCDSCompany.java) > at > org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:225) > at > org.apache.jdo.tck.mapping.CompletenessTest.test(CompletenessTest.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > 10:48:14,703 (main) INFO [org.apache.jdo.tck] - Exception during > localTearDown: > javax.jdo.JDOUserException: One or more instances could not be deleted > at > org.jpox.AbstractPersistenceManager.deletePersistentAll(AbstractPersistenceManager.java:766) > at org.apache.jdo.tck.JDO_Test.deleteTearDownClasses(JDO_Test.java:436) > at org.apache.jdo.tck.JDO_Test.localTearDown(JDO_Test.java:358) > at org.apache.jdo.tck.JDO_Test.tearDown(JDO_Test.java:325) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:268) > at junit.framework.TestResult$1.p
Re: Enhancer error with spaces in path names
Hi Michelle, > After downloading new jpox jars, I started getting the following error, See http://www.jpox.org/servlet/jira/browse/CORE-3392 -- Andy (Java Persistent Objects - http://www.jpox.org)
TCK2 : JDO_Test.java prints out "tokenizer"
Hi, can someone please fix "JDO_Test.java" line 1056 that is printing out some debug "tokenizer = BLAH". Thx -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Commented: (JDO-529) ChangeQuery - DISTINCT is expected even though it is not specified
[
https://issues.apache.org/jira/browse/JDO-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529067
]
Andy Jefferson commented on JDO-529:
This query now has the ordering constraint of
firstname, lastname ASCENDING
If I read the spec 14.6.6 it says
"The ordering statement is a String containing one or more ordering
declarations separated by commas. Each ordering declaration is a Java
expression of an orderable type:
• primitives (boolean is non-portable);
• wrappers (Boolean is non-portable);
• BigDecimal;
• BigInteger;
• String;
• Date
followed by one of the following words: "ascending", "descending","asc", or
"desc"."
So shouldn't the ordering constraint should be
firstname ASCENDING, lastname ASCENDING
???
"firstname ASCENDING" is an "ordering declaration" using spec verbage, as is
"lastname ASCENDING". Unless we're having inbuilt default of ASCENDING, but I
didn't read that from the spec.
> ChangeQuery - DISTINCT is expected even though it is not specified
> --
>
> Key: JDO-529
> URL: https://issues.apache.org/jira/browse/JDO-529
> Project: JDO
> Issue Type: Test
> Components: tck2
>Reporter: Ilan Kirsh
>Assignee: Craig Russell
> Fix For: JDO 2 maintenance release 1
>
> Attachments: jdo-529.patch
>
>
> Test org.apache.jdo.tck.query.api.ChangeQuery expects 3 result objects:
> List expectedResult = Arrays.asList(new Object[] {
> new FullName("emp1First", "emp1Last"),
> new FullName("emp2First", "emp2Last"),
> new FullName("emp5First", "emp5Last")});
> But actually there should be 4 result objects:
> List expectedResult = Arrays.asList(new Object[] {
> new FullName("emp1First", "emp1Last"),
> new FullName("emp2First", "emp2Last"),
> new FullName("emp2First", "emp2Last"),
> new FullName("emp5First", "emp5Last")});
> because the result is not specified as DISTINCT.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-522) Draft proposal for CopyOnAttach property
[ https://issues.apache.org/jira/browse/JDO-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528975 ] Andy Jefferson commented on JDO-522: Craig, you can check in your patch when ready - JPOX should be fine. > Draft proposal for CopyOnAttach property > > > Key: JDO-522 > URL: https://issues.apache.org/jira/browse/JDO-522 > Project: JDO > Issue Type: Task > Components: api2 >Affects Versions: JDO 2 maintenance release 1 > Environment: n/a >Reporter: Chris Beams >Assignee: Chris Beams > Fix For: JDO 2 maintenance release 1 > > Attachments: CopyOnAttachWithDetachAllOnCommit.jpg, jdo-522.patch, > proposal-CopyOnAttach-draft2.rtf, proposal-CopyOnAttach.rtf > > > Minutes: JDO TCK Conference Call Friday, Aug 10, 9 am PDT > On 8/10/07, Craig L Russell <[EMAIL PROTECTED]> wrote: > Attendees: Chris Beams, Matthew Adams, Michelle Caisse, Craig Russell > Agenda: > 3. Attach (makePersistent) a detached instance always merges changes > into the cache. Can this behavior be changed to make the parameter > instance change its state, throwing an exception if there already is > an instance in the cache, based on a user-specified property? Seems > like this would be a good addition to the spec. AI Chris prepare a > proposal for the jdo expert group alias. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-517) NPE on enhancement of classes with persistent properties
[
https://issues.apache.org/jira/browse/JDO-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528453
]
Andy Jefferson commented on JDO-517:
Thx Michelle. Subsequent issue comes via
PCDSDepartment.java
public void setFundedEmps(Set employees) {
this._fundedEmps = (_fundedEmps != null) ? new HashSet(employees) : null;
}
If the implementation passes in null (like it does when nulling non-PK fields)
then the TCK code tries to create HashSet(null) which ends in tears. All
setters for collections/maps need to allow for null being passed in.
> NPE on enhancement of classes with persistent properties
>
>
> Key: JDO-517
> URL: https://issues.apache.org/jira/browse/JDO-517
> Project: JDO
> Issue Type: Bug
> Components: tck2
>Affects Versions: JDO 2 maintenance release 1
>Reporter: Michelle Caisse
>Assignee: Michelle Caisse
>
> To reproduce, edit project.propeties, go to the end of the file, and edit out
> the comment and blank lines so that the classes in the companyAnnotatedPC
> package are included in the argument list to the enhancer.
> 11:39:16,031 (main) ERROR [JPOX.Enhancer] - An error was encountered reading
> the specified input files. Please consult the log for details. The following
> may help : Errors were encountered when loading the specified MetaData files
> and classes. See the nested exceptions for details
> Errors were encountered when loading the specified MetaData files and
> classes. See the nested exceptions for details
> org.jpox.exceptions.JPOXUserException: Errors were encountered when loading
> the specified MetaData files and classes. See the nested exceptions for
> details
> at
> org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:299)
> at
> org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724)
> at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533)
> Caused by: java.lang.NullPointerException
> at
> org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594)
> at
> org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211)
> at
> org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133)
> at
> org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729)
> at
> org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265)
> ... 2 more
> Nested Throwables StackTrace:
> java.lang.NullPointerException
> at
> org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594)
> at
> org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211)
> at
> org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133)
> at
> org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729)
> at
> org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265)
> at
> org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724)
> at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533)
> java.lang.NullPointerException
> at
> org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594)
> at
> org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211)
> at
> org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133)
> at
> org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729)
> at
> org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265)
> at
> org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724)
> at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-522) Draft proposal for CopyOnAttach property
[ https://issues.apache.org/jira/browse/JDO-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528440 ] Andy Jefferson commented on JDO-522: No particular comment on the draft, just to note that JPOX CVS now provides an initial "CopyOnAttach" (limited testing) in line with the proposal. > Draft proposal for CopyOnAttach property > > > Key: JDO-522 > URL: https://issues.apache.org/jira/browse/JDO-522 > Project: JDO > Issue Type: Task > Components: api2 >Affects Versions: JDO 2 maintenance release 1 > Environment: n/a >Reporter: Chris Beams >Assignee: Chris Beams > Fix For: JDO 2 maintenance release 1 > > Attachments: CopyOnAttachWithDetachAllOnCommit.jpg, > proposal-CopyOnAttach-draft2.rtf, proposal-CopyOnAttach.rtf > > > Minutes: JDO TCK Conference Call Friday, Aug 10, 9 am PDT > On 8/10/07, Craig L Russell <[EMAIL PROTECTED]> wrote: > Attendees: Chris Beams, Matthew Adams, Michelle Caisse, Craig Russell > Agenda: > 3. Attach (makePersistent) a detached instance always merges changes > into the cache. Can this behavior be changed to make the parameter > instance change its state, throwing an exception if there already is > an instance in the cache, based on a user-specified property? Seems > like this would be a good addition to the spec. AI Chris prepare a > proposal for the jdo expert group alias. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Who is responsible for JDOCentral.com?
> > Is the JDO vendor community still serious about JDO? > > If so, I think they should fund to keep JDOCentral alive... > > I'd like to see the same. So I can understand your requirements better I ask the question "JDOCentral was what exactly ?" To me it was a central point for discussion of a technology. I would have thought that the logical successor is Apache JDO, or JPOX, or both. JDOCentral had :- 1. articles about use of JDO. JPOX has tried to provide an equivalent in the "Tutorials & Examples" section of our docs for each release. All docs are marked with what is JDO specific and what is an extension. 2. news about presentations etc. 3. forum for problems/discussions - that became a home to spammers for the final year of its life. Apache JDO has a mailing list for JDO-specific issues, and JPOX has a forum for real-world use. I've no problem with putting/moving any JPOX docs that are JDO-generic across on Apache JDO to facilitate a more logical division between technology and implementation. Perhaps you could define what more you mean with "keep JDOCentral alive"? -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Commented: (JDO-517) NPE on enhancement of classes with persistent properties
[
https://issues.apache.org/jira/browse/JDO-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528007
]
Andy Jefferson commented on JDO-517:
The test "companyAnnotatedAllRelationshipsPCConcrete.conf" for datastore
identity runs and gives the following error
1)
test(org.apache.jdo.tck.mapping.CompletenessTest)org.jpox.jdo.exceptions.CommitStateTransitionException:
A database transaction has been committed, but the following exceptions were
thrown while transitioning the state of the JDO objects participating in the
transaction.
[java] at
org.jpox.ObjectManagerImpl.postCommit(ObjectManagerImpl.java:2719)
[java] at
org.jpox.TransactionImpl.internalPostCommit(TransactionImpl.java:356)
[java] at org.jpox.TransactionImpl.commit(TransactionImpl.java:210)
[java] at org.jpox.jdo.JDOTransaction.commit(JDOTransaction.java:81)
[java] at
org.apache.jdo.tck.mapping.CompletenessTest.localSetUp(CompletenessTest.java:85)
[java] at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:240)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:256)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
[java] NestedThrowablesStackTrace:
[java] java.lang.IllegalStateException: Id is already set.
[java] at
org.apache.jdo.tck.pc.companyAnnotatedPC.PCDSInsurance.jdoSetinsid(PCDSInsurance.java:98)
[java] at
org.apache.jdo.tck.pc.companyAnnotatedPC.PCDSInsurance.jdoReplaceField(PCDSInsurance.java)
[java] at
org.apache.jdo.tck.pc.companyAnnotatedPC.PCDSMedicalInsurance.jdoReplaceField(PCDSMedicalInsurance.java)
[java] at
org.apache.jdo.tck.pc.companyAnnotatedPC.PCDSInsurance.jdoReplaceFields(PCDSInsurance.java)
[java] at
org.jpox.state.JDOStateManagerImpl.replaceFields(JDOStateManagerImpl.java:2606)
[java] at
org.jpox.state.JDOStateManagerImpl.replaceFields(JDOStateManagerImpl.java:2625)
[java] at
org.jpox.state.JDOStateManagerImpl.clearFieldsByNumbers(JDOStateManagerImpl.java:1051)
[java] at
org.jpox.state.JDOStateManagerImpl.clearNonPrimaryKeyFields(JDOStateManagerImpl.java:1040)
[java] at
org.jpox.state.jdo.PersistentNew.transitionCommit(PersistentNew.java:101)
[java] at
org.jpox.state.JDOStateManagerImpl.postCommit(JDOStateManagerImpl.java:4184)
[java] at
org.jpox.ObjectManagerImpl.postCommit(ObjectManagerImpl.java:2687)
[java] at
org.jpox.TransactionImpl.internalPostCommit(TransactionImpl.java:356)
[java] at org.jpox.TransactionImpl.commit(TransactionImpl.java:210)
[java] at org.jpox.jdo.JDOTransaction.commit(JDOTransaction.java:81)
[java] at
org.apache.jdo.tck.mapping.CompletenessTest.localSetUp(CompletenessTest.java:85)
[java] at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:240)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:256)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
So JPOX is trying to clear all non-PK fields in the post-commit phase, as it
should.
If I look inside the class PCDSInsurance.java I find
public void setInsid(long id) {
if (this._insid != 0)
throw new IllegalStateException("Id is already set.");
this._insid = id;
}
JPOX has to use this method (via the jdoSetinsid() method) to clear the field
(since the class was specified to use properties rather than fields), and the
TCK is preventing it. Suggest that this type of restriction be removed from the
companyAnnotatedPC classes
> NPE on enhancement of classes with persistent properties
>
>
> Key: JDO-517
> URL: https://issues.apache.org/jira/browse/JDO-517
> Project: JDO
> Issue Type: Bug
> Components: tck2
>Affects Versions: JDO 2 maintenance release 1
>Reporter: Michelle Caisse
>Assignee: Michelle Caisse
>
> To reproduce, edit project.propeties, go to the end of the file, and edit out
> the comment and blank lines so that the classes in the companyAnnotatedPC
> package are included in the argument list to the enhancer.
> 11:39:16,031 (main) ERROR [JPOX.Enhancer] - An error was encountered reading
> the specified input files. Please consult the log for details. The following
> may help : Errors were encountered when loading the spec
[jira] Updated: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
[ https://issues.apache.org/jira/browse/JDO-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-528: --- Attachment: (was: JDOHelper.patch) > JDOHelper.getObjectState() : convenience method to return the state of an > object > > > Key: JDO-528 > URL: https://issues.apache.org/jira/browse/JDO-528 > Project: JDO > Issue Type: New Feature > Components: api2 > Reporter: Andy Jefferson >Priority: Minor > Fix For: JDO 2 maintenance release 1 > > Attachments: JDOHelper.patch, ObjectState.patch > > > As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be > desirable for JDOHelper to have a method to return the object "state" of a > passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
[ https://issues.apache.org/jira/browse/JDO-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-528: --- Attachment: (was: ObjectState.patch) > JDOHelper.getObjectState() : convenience method to return the state of an > object > > > Key: JDO-528 > URL: https://issues.apache.org/jira/browse/JDO-528 > Project: JDO > Issue Type: New Feature > Components: api2 > Reporter: Andy Jefferson >Priority: Minor > Fix For: JDO 2 maintenance release 1 > > Attachments: JDOHelper.patch, ObjectState.patch > > > As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be > desirable for JDOHelper to have a method to return the object "state" of a > passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
[ https://issues.apache.org/jira/browse/JDO-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527870 ] Andy Jefferson commented on JDO-528: No reason other than I had that in a cut-paste of something else and was thinking more around having HOLLOW and P_NONTRANS as separate values at one point, ... but thanks for volunteering to update the patch ;-) > JDOHelper.getObjectState() : convenience method to return the state of an > object > > > Key: JDO-528 > URL: https://issues.apache.org/jira/browse/JDO-528 > Project: JDO > Issue Type: New Feature > Components: api2 > Reporter: Andy Jefferson >Priority: Minor > Fix For: JDO 2 maintenance release 1 > > Attachments: JDOHelper.patch, ObjectState.patch > > > As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be > desirable for JDOHelper to have a method to return the object "state" of a > passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JDO-517) NPE on enhancement of classes with persistent properties
[ https://issues.apache.org/jira/browse/JDO-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson reassigned JDO-517: -- Assignee: Michelle Caisse (was: Andy Jefferson) The enhancement of these tests seems to have been turned on in SVN, and they dont seem to clean out their data correctly ... causing all subsequent company tests to fail. > NPE on enhancement of classes with persistent properties > > > Key: JDO-517 > URL: https://issues.apache.org/jira/browse/JDO-517 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > > To reproduce, edit project.propeties, go to the end of the file, and edit out > the comment and blank lines so that the classes in the companyAnnotatedPC > package are included in the argument list to the enhancer. > 11:39:16,031 (main) ERROR [JPOX.Enhancer] - An error was encountered reading > the specified input files. Please consult the log for details. The following > may help : Errors were encountered when loading the specified MetaData files > and classes. See the nested exceptions for details > Errors were encountered when loading the specified MetaData files and > classes. See the nested exceptions for details > org.jpox.exceptions.JPOXUserException: Errors were encountered when loading > the specified MetaData files and classes. See the nested exceptions for > details > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:299) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > Caused by: java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > ... 2 more > Nested Throwables StackTrace: > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
[ https://issues.apache.org/jira/browse/JDO-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-528: --- Attachment: ObjectState.patch JDOHelper.patch Updated patches to 1. provide user-friendly toString on ObjectState enum 2. Remove unnecessary method 3. Merge HOLLOW / P_NONTRANS > JDOHelper.getObjectState() : convenience method to return the state of an > object > > > Key: JDO-528 > URL: https://issues.apache.org/jira/browse/JDO-528 > Project: JDO > Issue Type: New Feature > Components: api2 > Reporter: Andy Jefferson >Priority: Minor > Fix For: JDO 2 maintenance release 1 > > Attachments: JDOHelper.patch, ObjectState.patch > > > As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be > desirable for JDOHelper to have a method to return the object "state" of a > passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
[ https://issues.apache.org/jira/browse/JDO-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-528: --- Attachment: (was: JDOHelper.patch) > JDOHelper.getObjectState() : convenience method to return the state of an > object > > > Key: JDO-528 > URL: https://issues.apache.org/jira/browse/JDO-528 > Project: JDO > Issue Type: New Feature > Components: api2 > Reporter: Andy Jefferson >Priority: Minor > Fix For: JDO 2 maintenance release 1 > > > As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be > desirable for JDOHelper to have a method to return the object "state" of a > passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
[ https://issues.apache.org/jira/browse/JDO-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-528: --- Attachment: (was: ObjectState.patch) > JDOHelper.getObjectState() : convenience method to return the state of an > object > > > Key: JDO-528 > URL: https://issues.apache.org/jira/browse/JDO-528 > Project: JDO > Issue Type: New Feature > Components: api2 > Reporter: Andy Jefferson >Priority: Minor > Fix For: JDO 2 maintenance release 1 > > > As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be > desirable for JDOHelper to have a method to return the object "state" of a > passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
[ https://issues.apache.org/jira/browse/JDO-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-528: --- Attachment: JDOHelper.patch Updated JDOHelper for P_NONTRANS/P_NONTRANS_DIRTY bug > JDOHelper.getObjectState() : convenience method to return the state of an > object > > > Key: JDO-528 > URL: https://issues.apache.org/jira/browse/JDO-528 > Project: JDO > Issue Type: New Feature > Components: api2 > Reporter: Andy Jefferson >Priority: Minor > Fix For: JDO 2 maintenance release 1 > > Attachments: JDOHelper.patch, ObjectState.patch > > > As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be > desirable for JDOHelper to have a method to return the object "state" of a > passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
[ https://issues.apache.org/jira/browse/JDO-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-528: --- Attachment: (was: JDOHelper.patch) > JDOHelper.getObjectState() : convenience method to return the state of an > object > > > Key: JDO-528 > URL: https://issues.apache.org/jira/browse/JDO-528 > Project: JDO > Issue Type: New Feature > Components: api2 > Reporter: Andy Jefferson >Priority: Minor > Fix For: JDO 2 maintenance release 1 > > Attachments: JDOHelper.patch, ObjectState.patch > > > As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be > desirable for JDOHelper to have a method to return the object "state" of a > passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
[ https://issues.apache.org/jira/browse/JDO-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-528: --- Attachment: ObjectState.patch JDOHelper.patch Patches for JDOHelper, and new ObjectState enum to provide this functionality. Enum includes both HOLLOW and P_NONTRANS but with the same enum value (since they are indistinguishable using state information) > JDOHelper.getObjectState() : convenience method to return the state of an > object > > > Key: JDO-528 > URL: https://issues.apache.org/jira/browse/JDO-528 > Project: JDO > Issue Type: New Feature > Components: api2 > Reporter: Andy Jefferson >Priority: Minor > Fix For: JDO 2 maintenance release 1 > > Attachments: JDOHelper.patch, ObjectState.patch > > > As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be > desirable for JDOHelper to have a method to return the object "state" of a > passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JDO-528) JDOHelper.getObjectState() : convenience method to return the state of an object
JDOHelper.getObjectState() : convenience method to return the state of an object Key: JDO-528 URL: https://issues.apache.org/jira/browse/JDO-528 Project: JDO Issue Type: New Feature Components: api2 Reporter: Andy Jefferson Priority: Minor Fix For: JDO 2 maintenance release 1 As discussed on the jdo-dev mailing list cerca 5th August 2007, it would be desirable for JDOHelper to have a method to return the object "state" of a passed object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Explanation of notation in the spec draft?
> what does "A12.5.7-6A [...]" actually mean? An assert, for use by the TCK. Something to check on. > And why is something labeled "12.5.7" within the 12.6.7 section? No idea :-) -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: evict question
> I propose to add: > void evictAll (Class pcClass, boolean subclasses); +1 -- Andy (Java Persistent Objects - http://www.jpox.org)
TCK2 : src/java/org/apache/jdo/tck/mapping/RelationshipManyToManyNoRelationships.java
Hi,
this test seems to have an error. Line 154 has
emp1 = (Employee)pm.getObjectById(emp1Oid);
yet it should be
emp4 = (Employee)pm.getObjectById(emp4Oid);
since "emp4" is the Employee that is being compared just after ("emp1" is
never used).
--
Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Resolved: (JDO-525) Department.getEmployees().contains() returns wrong answer
[ https://issues.apache.org/jira/browse/JDO-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson resolved JDO-525. Resolution: Fixed Fix Version/s: JDO 2 maintenance release 1 Fixed in CVS HEAD. > Department.getEmployees().contains() returns wrong answer > - > > Key: JDO-525 > URL: https://issues.apache.org/jira/browse/JDO-525 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse > Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > > A number of tests in the new configuration relationshipAllRelationships.conf > give the following error: > testSetToExistingFromMappedSide(org.apache.jdo.tck.mapping.Relationship1ToManyAllRelationships)junit.framework.AssertionFailedError: > Assertion A15-3.1 (Relationship1ToManyAllRelationships) failed: : Test > aborted, precondition is false; expected dept.getEmployees() to contain emp1 > at > org.apache.jdo.tck.mapping.Relationship1ToManyAllRelationships.localSetUp(Relationship1ToManyAllRelationships.java:87) > dept1.getEmployees().contains(emp1) returns false, even though it is actually > true. Print statements showed that isEmpty() and size() return the correct > answer. contains() returned the correct answer after an invocation of > dept2.getEmployees(). > To reproduce, do: > maven -Djdo.tck.cfglist=relationshipAllRelationships.conf runtck.jdori -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-521) Create tests for relationship mapping (spec section 15.3)
[ https://issues.apache.org/jira/browse/JDO-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526000 ] Andy Jefferson commented on JDO-521: The negative test I was expecting to find was where you set up something like this Employee emp1 = new FullTimeEmployee(); MedicalInsurance ins1 = new MedicalInsurance(); Employee emp2 = new PartTimeEmployee(); emp1.setMedicalInsurance(ins1); ins1.setEmployee(emp2); pm.makePersistent(emp1); so in a single user operation inconsistent data is provided (hence independent of when data is flushed to the datastore) hence an expected JDOUserException. Does this exist ? > Create tests for relationship mapping (spec section 15.3) > - > > Key: JDO-521 > URL: https://issues.apache.org/jira/browse/JDO-521 > Project: JDO > Issue Type: Test > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Attachments: JDO-521.patch > > > We need a set of tests to test that an implementation syncs both sides of a > relationship on flush(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-521) Create tests for relationship mapping (spec section 15.3)
[ https://issues.apache.org/jira/browse/JDO-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525981 ] Andy Jefferson commented on JDO-521: The "negative" 1-1 relation tests raise a question. Let's take the first one. You have an already persistent Employee, and an already persistent MedicalInsurance. You then persist a new Employee. Ok, no problem with that. You then call emp1.setMedicalInsurance(medIns2); The spec says "In particular, making a change to one side of the relationship does not imply any runtime behavior by the JDO implementation to change the other side of the relationship in memory prior to flush" but that doesn't by my reading prohibit updating the in memory model, and so for any implementation that does update in-memory on each change these "negative" tests will fail since they don't allow for it. Or is it that there is some requirement to prohibit this ? An implementation *can* flush changes to the datastore without user-called flush() or commit() (unless using optimistic txns). PS. Any chance the test "conf" files can be called "managedRelations.conf" or something ? "relationshipsNoRelationships.conf" leaves me baffled ... since if it is for relationships and has no relationships?? surely it would have to have some relationships to test managed relationships ? Maybe I'm missing some secret naming schema > Create tests for relationship mapping (spec section 15.3) > - > > Key: JDO-521 > URL: https://issues.apache.org/jira/browse/JDO-521 > Project: JDO > Issue Type: Test > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Attachments: JDO-521.patch > > > We need a set of tests to test that an implementation syncs both sides of a > relationship on flush(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JDO-526) Implementation fails to set other side of relationship on flush()
[ https://issues.apache.org/jira/browse/JDO-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson resolved JDO-526. Resolution: Fixed Fix Version/s: JDO 2 maintenance release 1 I see no issues on 1-1 relations wrt "managed relations" with CVS HEAD. I presume this issue is for 1-1 relations, and the other one raised was for 1-N > Implementation fails to set other side of relationship on flush() > - > > Key: JDO-526 > URL: https://issues.apache.org/jira/browse/JDO-526 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse >Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > > Some tests for managed relationships fail because after the test sets one > side of the relationship, the implementation fails to set the other side on > flush(). For example: > testSetToNewFromMappedSide(org.apache.jdo.tck.mapping.Relationship1To1NoRelationships)junit.framework.AssertionFailedError: > > Assertion A15-3.1 (Relationship1To1NoRelationships) failed: > testSetToNewFromMappedSide: Postcondition is false; other side of > relationship not set on flush > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1115) > at > org.apache.jdo.tck.mapping.Relationship1To1NoRelationships.testSetToNewFromMappedSide(Relationship1To1NoRelationships.java:187) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:257) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > To reproduce, run either of: > maven -Djdo.tck.cfglist=relationshipNoRelationships.conf runtck.jdori > maven -Djdo.tck.cfglist=relationshipAllRelationships.conf runtck.jdori -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JDO-527) NullPointerException in JDO_Test.isTestToBePerformed()
NullPointerException in JDO_Test.isTestToBePerformed() -- Key: JDO-527 URL: https://issues.apache.org/jira/browse/JDO-527 Project: JDO Issue Type: Bug Reporter: Andy Jefferson Assignee: Michelle Caisse RUnning the TCK on "inheritance2.conf" with JPOX results in an NPE in JDO_Test.isTestToBePerformed(), as per the following stack trace Exception in constructor: test (java.lang.NullPointerException [java] at org.apache.jdo.tck.JDO_Test.isTestToBePerformed(JDO_Test.java:1058) [java] at org.apache.jdo.tck.JDO_Test.(JDO_Test.java:192) [java] at org.apache.jdo.tck.mapping.CompletenessTest.(CompletenessTest.java:43) "logger" is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
TCK2 : src/java/org/apache/jdo/tck/pc/companyAnnotatedPI/PIAppProject.java
seems to have :- @Element(types=org.apache.jdo.tck.pc.companyAnnotatedFC.FCAppEmployee.class, column="REVIEWER", foreignKey="PR_REV_FK") Set getReviewers(); @Element(types=org.apache.jdo.tck.pc.companyAnnotatedFC.FCAppEmployee.class, column="MEMBER", foreignKey="PM_MEMB_FK") Set getMembers(); whereas I think you ought to have those "types" as org.apache.jdo.tck.pc.companyAnnotatedPI.PIAppEmployee.class -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Commented: (JDO-517) NPE on enhancement of classes with persistent properties
[ https://issues.apache.org/jira/browse/JDO-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520503 ] Andy Jefferson commented on JDO-517: PCDSPerson seems to have 2 methods setLastname. One of them sets the personId ... so ought to be removed. Same goes for PCAppPerson. > NPE on enhancement of classes with persistent properties > > > Key: JDO-517 > URL: https://issues.apache.org/jira/browse/JDO-517 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse > Assignee: Andy Jefferson > > To reproduce, edit project.propeties, go to the end of the file, and edit out > the comment and blank lines so that the classes in the companyAnnotatedPC > package are included in the argument list to the enhancer. > 11:39:16,031 (main) ERROR [JPOX.Enhancer] - An error was encountered reading > the specified input files. Please consult the log for details. The following > may help : Errors were encountered when loading the specified MetaData files > and classes. See the nested exceptions for details > Errors were encountered when loading the specified MetaData files and > classes. See the nested exceptions for details > org.jpox.exceptions.JPOXUserException: Errors were encountered when loading > the specified MetaData files and classes. See the nested exceptions for > details > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:299) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > Caused by: java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > ... 2 more > Nested Throwables StackTrace: > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: All annotations issues...
On 15 August 2007, Craig L Russell wrote: > that I can find are resolved with the patch to https:// > issues.apache.org/jira/browse/JDO-515. > > If I've missed any, please let me know. Hi Craig, Persistent property has to have "field-name" specified. When specifying this with @Persistent are people expected to use "name" ? or perhaps we should add "fieldName" to be explicit and consistent ? -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Commented: (JDO-517) NPE on enhancement of classes with persistent properties
[ https://issues.apache.org/jira/browse/JDO-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519893 ] Andy Jefferson commented on JDO-517: > If a class is persistence-capable, by default fields of a particular type are > persistent. > Therefore, to use properties, fields must be marked not persistent. This is an imposition on the user IMHO. When a property is marked as persistent (and should have a field-name attribute defined according to the spec 18.14 - which they don't in this case) then that should automatically make the associated field NotPersistent with no need for marking it. You can't persistent both the field and the property (jdoSetXXX enhanced methods have to handle field OR property. I also don't see any NPE. I see Class org.apache.jdo.tck.pc.companyAnnotatedPC.PCDSInsurance has property fieldRepr declared in MetaData, but its setter method doesnt exist in the class! which is simply due to following JPA policy on persistent fields/properties - either all fields, or all properties. So if there is some property it finds all un-annotated getters and marks those as persistent - but since JDO is going a different route it needs different handling. Will take a while to allow for JDO rules on persistent props alongside catering for what we already cater for. > NPE on enhancement of classes with persistent properties > > > Key: JDO-517 > URL: https://issues.apache.org/jira/browse/JDO-517 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 > Reporter: Michelle Caisse >Assignee: Andy Jefferson > > To reproduce, edit project.propeties, go to the end of the file, and edit out > the comment and blank lines so that the classes in the companyAnnotatedPC > package are included in the argument list to the enhancer. > 11:39:16,031 (main) ERROR [JPOX.Enhancer] - An error was encountered reading > the specified input files. Please consult the log for details. The following > may help : Errors were encountered when loading the specified MetaData files > and classes. See the nested exceptions for details > Errors were encountered when loading the specified MetaData files and > classes. See the nested exceptions for details > org.jpox.exceptions.JPOXUserException: Errors were encountered when loading > the specified MetaData files and classes. See the nested exceptions for > details > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:299) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > Caused by: java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > ... 2 more > Nested Throwables StackTrace: > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata
[jira] Commented: (JDO-517) NPE on enhancement of classes with persistent properties
[ https://issues.apache.org/jira/browse/JDO-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519748 ] Andy Jefferson commented on JDO-517: Why are classes annotated with @NotPersistent on fields and @Persistent on properties ? I would expect (from other persistence specifications) to have one or the other annotated. Annotating fields (with any annotation) implies that fields are used for persistence, yet then it encounters properties with more annotations. Does the spec define the equivalent of access-type in JPA ? and what is supposed to happen when the user takes leave of senses and annotates everything under the sun ? > NPE on enhancement of classes with persistent properties > > > Key: JDO-517 > URL: https://issues.apache.org/jira/browse/JDO-517 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 >Reporter: Michelle Caisse > Assignee: Andy Jefferson > > To reproduce, edit project.propeties, go to the end of the file, and edit out > the comment and blank lines so that the classes in the companyAnnotatedPC > package are included in the argument list to the enhancer. > 11:39:16,031 (main) ERROR [JPOX.Enhancer] - An error was encountered reading > the specified input files. Please consult the log for details. The following > may help : Errors were encountered when loading the specified MetaData files > and classes. See the nested exceptions for details > Errors were encountered when loading the specified MetaData files and > classes. See the nested exceptions for details > org.jpox.exceptions.JPOXUserException: Errors were encountered when loading > the specified MetaData files and classes. See the nested exceptions for > details > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:299) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > Caused by: java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > ... 2 more > Nested Throwables StackTrace: > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) > java.lang.NullPointerException > at > org.jpox.metadata.annotations.JDOAnnotationReader.processFieldAnnotations(JDOAnnotationReader.java:1594) > at > org.jpox.metadata.annotations.AbstractAnnotationReader.getMetaDataForClass(AbstractAnnotationReader.java:211) > at > org.jpox.metadata.annotations.AnnotationManagerImpl.getMetaDataForClass(AnnotationManagerImpl.java:133) > at > org.jpox.metadata.MetaDataManager.loadAnnotationsForClass(MetaDataManager.java:1729) > at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:265) > at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:724) > at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:533) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JDO-515) Allow custom settings for some annotation enum values
Allow custom settings for some annotation enum values - Key: JDO-515 URL: https://issues.apache.org/jira/browse/JDO-515 Project: JDO Issue Type: Improvement Components: api2 Reporter: Andy Jefferson Fix For: JDO 2 maintenance release 1 JDO2.1 annotations utilise some enums defining the acceptable values for various strategies. The following need changing to allow implementations to provide custom values. @Persistence "valueStrategy", @DatastoreIdentity "strategy" are of the type IdGenerationStrategy. Changes required : 1. IdGenerationStrategy needs UNKNOWN changing to UNSPECIFIED. 2. @Persistence : add "customValueStrategy" 3. @DatastoreIdentity : add "customStrategy" @Inheritance "strategy" is of type InheritanceStrategy. Changes required : 1. InheritanceStrategy needs UNSPECIFIED adding. 2. @Inheritance : change "strategy" to have default of UNSPECIFIED 3. @Inheritance : add "customStrategy" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Minutes: JDO TCK Conference Call Friday, Aug 10, 9 am PDT
> 2. Annotations: discuss custom settings for enum-valued elements. We > need better javadoc for UNKNOWN, and in fact we might change UNKNOWN > to UNSPECIFIED so it's more clear from the name itself. AI Matthew > raise this issue on the alias. It also seems like adding a new value > of CUSTOM is unnecessary because if the user specifies a custom > value, the annotation processor just uses it, and verifies that the > standard strategy enum value is UNSPECIFIED. @Persistence "valueStrategy" @DatastoreIdentity "strategy" +1 to rename of UNKNOWN to UNSPECIFIED, and use of "customStrategy" (@DatastoreIdentity) / "customValueStrategy" (@Persistent) as per Craigs proposal. @Inheritance also has "strategy" To allow implementations to define their own inheritance strategies can we make the following changes 1. InheritanceStrategy : add UNSPECIFIED 2. @Inheritance : change "strategy" to have default of UNSPECIFIED 3. @Inheritance : add "customStrategy" I was going to raise this a JIRA for this but Apache JIRA seems to be dead ... -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: Implicitly setting @Column's defaultValue parameter
> In the case of a PC class with a field declared as > > @Column(name = "foo_bar", allowsNull = "false") > int fooBar = 0; > > It would be nice if the implementation would implicitly set the > default value for the column, as if the user had typed > > @Column(name = "foo_bar", allowsNull = "false", defaultValue = "0") > int fooBar = 0; Hi Chris, I'm intrigued where you think the implementation is going to find this information. When bytecode is generated (by the compiler) all such initialisations are dumped into available constructor methods and there is no obvious way of determining what comes from the users provided constructor, what comes from field initialisation, and what comes from static initialisation. Consequently when an enhancer (BCEL, ASM etc) come across the constructor method bytecode they can't separate it out easily. Adding this to a specification would have to imply the process for how it is possible since a "reference implementation" needs to be written. Same issue as http://www.jpox.org/servlet/jira/browse/ENHANCER-96 -- Andy (Java Persistent Objects - http://www.jpox.org)
MetaData : XML .v. Annotation precedence - primary-key
I came across a particular situation that impacts on the wording for the text
to go in the spec for precedence of XML and Annotation metadata.
I have :-
@PersistenceCapable
public class MyClass
{
@PrimaryKey
long id;
@Persistent
String name;
...
}
Question : Should we allow users to override the setting of "primary-key" in
XML when it is defined in the annotations ? or should the setting in the
annotations for which field(s) are PK be fixed ?
The problem comes in how to merge the value in annotations and value in XML.
With XML, due to the DTD/XSD, there will always be a value for "primary-key".
With annotations it will have a value only if the user provided one.
If we allow overrides via XML, then we must just take any value from XML
(since there is always a value when read in). This impacts on what a user has
to specify when overriding any information in XML. For example, if the user
wanted to override some info about the above class they would have to specify
the "primary-key" values correctly to make sure that they were respected (if
they didn't specify the "primary-key" element then they get the DTD default
of "false"!) hence duplicate definition.
My conclusion is that we should prohibit the override of "primary-key" when
the annotations have explicitly set the value. If annotations haven't set the
value then the value in XML should be respected.
Anyone disagree ?
--
Andy (Java Persistent Objects - http://www.jpox.org)
Re: Annotation enum : IdGeneratorStrategy
> As a perhaps lighter-weight variant on Andy's option (2) below, could
> we simply provide an alternative, string-based parameter to the
> annotation, such as 'customValueStrategy'?
>
> @Target({ElementType.FIELD, ElementType.METHOD})
> @Retention(RetentionPolicy.RUNTIME)
> public @interface Persistent
> {
> // ...
> IdGeneratorStrategy valueStrategy() default
> IdGeneratorStrategy.UNKNOWN;
> String customValueStrategy() default "";
> }
If going for this case a "CUSTOM" value should be added to the enum (rather
than using UNKNOWN - which is for where you don't want one, maybe it should
be NONE instead of UNKNOWN), and when it is CUSTOM the user supplies
the "customValueStrategy". Similarly in @DatastoreIdentity "strategy".
> Another option could be to have IdGeneratorStrategy become a marker
> interface and then have the enum be defined as something like:
> public interface IdGeneratorStrategy {}
> public enum StandardIdGeneratorStrategy implements
> IdGeneratorStrategy
> {
> UNKNOWN,
> NATIVE,
> // ...
> };
> This would allow implementations to supply custom id generators in a
> typesafe way:
>
> package org.jpox.annotations;
> public enum JPOXIdGeneratorStrategy implements IdGeneratorStrategy
> {
> AUID,
> // ...
> };
>
> I like this latter approach, because it demonstrates very clearly
> that my usage is vendor-specific and non-portable.
Well the implementors of annotations in the JDK decided on this classic
restriction :-
"only primitive, String, Class, annotation, enum are permitted as the types of
the element in an annotation" meaning that you can't have an element with an
interface type.
and we also can't "extend" an enum.
--
Andy (Java Persistent Objects - http://www.jpox.org)
Annotation enum : IdGeneratorStrategy
JDO2 defines particular id generation strategies ... "identity", "increment", "sequence", "uuid-string", "uuid-hex", "native". Obviously implementations can define their own add-on strategies. In XML we have free-form text and so people can just type and rely on the implementation providing one called "auid". In Annotations they currently can't do this since it uses an enum. Two possible options 1. Remove IdGeneratorStrategy enum and just let people type in the "valueStrategy" name (and @DatastoreIdentity "strategy"), so they can access implementations own variants too. 2. Make implementations use the @Extension to access these vendor add-on strategies and use IdGeneratorStrategy.UNKNOWN (which is in the enum currently) I'm swaying towards 1 since its more consistent with XML specification. Any opinions ? -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true
Hi, > > So if we introduce a flag that uses the same instance on attach, we > > might want to have the flag called CopyOnMakePersistent and have > > true be the current specified behavior and false be the new > > behavior we've been discussing. > > Sounds great to me. There's some fine print here, though: Just > because CopyOnMakePersistent is set to true, that doesn't mean that > makePersistent() will *always* return copies. For example, current > specified behavior says that when DetachAllOnCommit=false and calling > makePersistent() with a transient parameter, the returned object will > be the same instance, now transitioned to persistent-clean. This > behavior won't change because of our new option (regardless of > whether it is set to true or false), and we don't want folks to be > confused about that... I prefer the name you suggested to the one I originally wrote. Comments :- 1. "DetachAllOnCommit" has no bearing on what makePersistent() does - it defines what happens on tx.commit() only. makePersistent will (currently) return the original object if persisting a transient and return a copy if attaching. 2. How about calling it CopyOnAttach ? makePersistent has two roles ... persisting new, and attaching detached. I don't ever see a need to add control to the operation of persisting a new object, so the name "CopyOnAttach" distinguishes to just the attach process. -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true
> >> // and attach it a second time > > > > "foo" : detached-dirty -> persistent-clean > > I'm with you until this last one... It would transition from > persistent-clean to detached-clean upon committing the transaction, > right? If so, then we're aligned... Yes. It's the same operation as earlier, so it detaches on commit in line with "DetachAllOnCommit" defined behaviour in JDO2.0 spec -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true
> With this restriction in place, however, would I be able to do the
> following?
> // fetch a detched object
> Query q = pm.newQuery(Foo.class);
> q.setUnique(true);
> Foo foo = (Foo) q.execute();
"detachAllOnCommit" will transition instances to detached *at commit*. You
have no commit here (using nontransactionalRead ?). If you have tx.begin(),
tx.commit() around it then its definitely fine. Nothing in the spec
definition of "detachAllOnCommit" implies (to me) that queries run with
non-tx read will do the detach.
> // make it dirty:
> foo.setBar("bar");
"foo" : detached-clean -> detached-dirty
> // attach
> pm.currentTransaction().begin();
> pm.makePersistent(foo);
"foo" : detached-dirty -> persistent-clean
> pm.currentTransaction().commit();
"foo" : persistent-clean -> detached-clean
> // dirty it once more
> foo.addBaz("baz");
"foo" : detached-clean -> detached-dirty
> // and attach it a second time
"foo" : detached-dirty -> persistence-clean
> - wouldn't this cause the JDOUserException you mention above?
No. If referring to the same PM, the object would have been removed from L1
cache at detach. The exception I was referring to was if you did a separate
PM.detachCopy() or detached it from a different PM and *then* tried to attach
to the same PM as one that already had it.
--
Andy (Java Persistent Objects - http://www.jpox.org)
Re: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true
From discussion on JPOX forum about the same issue :- Now I can detach 2 or more copies of the very same persistent object. Consequently if I start a PM and decide I'm attaching them both, you would then expect the JDO implementation to play around with 2 persistent objects with the same underlying identity? Or to give an example :- * Object "x" is persistent with id "xId". * I detach "xd1" and "xd2", both with the same identity "xId". * I then start a PM and attach "xd1" and this migrates into P_CLEAN, and goes into the L1 cache as such referenced by the id "xId". * I then attach "xd2" and this migrates to P_CLEAN, and ... oh we can't cache that one since the identity already exists in the L1 cache but referring to a different object, breaking object uniqueness for an identity. So if you had a flag "javax.jdo.option.AttachOnPersist" that effectively changed the functionality of PM.makePersistent() to not return a COPY but to migrate the state of the passed object to persistent, then you hit this problem above. You could allow something of this form by imposing a restriction that if an object needs attaching, and that "AttachOnPersist" flag is set, and the PM already has a persistent object with that id then throw a JDOUserException. Clearly the primary use-case is where the user detaches a single object, and then wants to attach the same thing, so they typically never hit the duplicate detached object issue. -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Resolved: (JDO-509) Enhancement failure on persistent interface that extends non-persistent interface
[ https://issues.apache.org/jira/browse/JDO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson resolved JDO-509. Resolution: Fixed Think this issue is now resolved. All PI tests pass for me > Enhancement failure on persistent interface that extends non-persistent > interface > - > > Key: JDO-509 > URL: https://issues.apache.org/jira/browse/JDO-509 > Project: JDO > Issue Type: Bug > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: company_ds_jdo.patch > > > Imagine that the existing interface company.ICompany is not persistent and > there is a new interface company.PICompany that extends ICompany. Existing > xml metadata is modified to refer to PICompany rather than ICompany. On > enhancement, we get the error below. Craig suggests that using the > reflective "getDeclaredMethod" instead of the reflective "getMethod" could > give this error. These are changes that we would like to check in for the 2.1 > maintenance release. >[java] An error was encountered reading the specified input files. Please > consult the log for details. The following may help : Class > org.apache.jdo.tck.pc. > company.IPCompany has property null.companyid declared in MetaData, but this > method doesnt exist in the class! >[java] Exception in thread "main" Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] org.jpox.metadata.InvalidMetaDataException: Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] at > org.jpox.metadata.InterfaceMetaData.populatePropertyMetaData(InterfaceMetaData.java:538) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:436) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.JDOMetaDataManager.loadMetaDataForClass(JDOMetaDataManager.java:615) >[java] at > org.jpox.metadata.JDOMetaDataManager.getMetaDataForClassInternal(JDOMetaDataManager.java:308) >[java] at > org.jpox.metadata.AbstractClassMetaData.determineSuperClassName(AbstractClassMetaData.java:618) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:421) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:313) >[java] at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:716) >[java] at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:531) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JDO 2.1 specification draft can be reviewed...
Hi, > I'd like to see others' reaction to this proposal as well. > > String getObjectState(Object pc) I clearly think it's a good idea since that's why JPOX has it ;-) Anything that adds more information to the user domain and more clearly defines the object states is a good thing. I agree with the principle of making the return an enum (for the "api21" jar - obviously can't be like that in the legacy jar since that has to support 1.3+). The only issue is that HOLLOW and P_NONTRANS have the same combinations of the various "isPersistent", "isTransactional", etc fields and that is why the JPOX method outputs "hollow / persistent-nontransactional" -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: Abstract Class Persistence
Hi Craig, I've added your comments at http://www.jpox.org/servlet/wiki/en/Persistent_Abstract_Class_Design -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: Abstract Class Persistence
Hi Craig, > There is a small bit of design work to do. Should I post something to > the JPOX wiki? Good idea -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: Abstract Class Persistence
Hi Craig, > >> Is there a "getting started" building JPOX from source? I downloaded > >> Core, Enhancer, and Plugins but the maven goals don't seem to work. > > > > In general follow > > http://www.jpox.org/docs/project/building_maven1.html > > > > You'll probably need the top level too (because I seem to remember > > that > > Plugins inherit from them - you could just remove the line > > from > > project.xml to get over that part). > > I don't see a "top level" in the cvs repo. I did check out maven.xml, > project.xml, and project.properties. "top-level" is JPOX/ > Following the instructions at building_maven1.html, I get: > [Bruiser:~/jpox/cvs] clr% cd JPOX/Core/ > [Bruiser:cvs/JPOX/Core] clr% maven clean jar:install > __ __ > > | \/ |__ _Apache__ ___ > | > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > | > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > > Attempting to download jdo2-api-SNAPSHOT.jar. > Artifact /javax.jdo/jars/jdo2-api-SNAPSHOT.jar doesn't exists in > remote repository, but it exists locally > Attempting to download jpox-thirdparty-1.2-SNAPSHOT.jar. > WARNING: Failed to download jpox-thirdparty-1.2-SNAPSHOT.jar. > Attempting to download ojdbc14.jar. > WARNING: Failed to download ojdbc14.jar. > Attempting to download jpox-testframework-1.2-SNAPSHOT.jar. > Artifact /jpox/jars/jpox-testframework-1.2-SNAPSHOT.jar doesn't > exists in remote repository, but it exists locally > Attempting to download org.eclipse.equinox.registry-3.2.0.jar. > WARNING: Failed to download org.eclipse.equinox.registry-3.2.0.jar. > Attempting to download org.eclipse.equinox.common-3.2.0.jar. > WARNING: Failed to download org.eclipse.equinox.common-3.2.0.jar. > Attempting to download org.eclipse.core.runtime-3.2.0.jar. > WARNING: Failed to download org.eclipse.core.runtime-3.2.0.jar. > Attempting to download org.eclipse.osgi-3.2.0.jar. > WARNING: Failed to download org.eclipse.osgi-3.2.0.jar. > The build cannot continue because of the following unsatisfied > dependencies: > > jpox-thirdparty-1.2-SNAPSHOT.jar > ojdbc14.jar > org.eclipse.equinox.registry-3.2.0.jar (try downloading from http:// > eclipse.org/equinox/) > org.eclipse.equinox.common-3.2.0.jar (try downloading from http:// > eclipse.org/equinox/) > org.eclipse.core.runtime-3.2.0.jar (try downloading from http:// > eclipse.org/equinox/) > org.eclipse.osgi-3.2.0.jar (try downloading from http://eclipse.org/ > equinox/) So you need to 1. build "Plugins/ThirdParty" 2. put those other jars listed into your Maven repo in the respective places. You can find them under "JPOX/LibRepository" (see README.txt under "Core") -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: Abstract Class Persistence
Hi Craig, > Is there a "getting started" building JPOX from source? I downloaded > Core, Enhancer, and Plugins but the maven goals don't seem to work. In general follow http://www.jpox.org/docs/project/building_maven1.html You'll probably need the top level too (because I seem to remember that Plugins inherit from them - you could just remove the line from project.xml to get over that part). If you're using JDK1.4/1.5 then you will also need to download and build Plugins/ThirdParty before building Core (unless you're using JDK 1.6) - contains some stubs for the JDBC4 changes that we need to support for JPOX to run on JDK1.6. Any particular error? -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: @Implements uses String[]
> Is there a reason for @Implements to take String[] instead of Class[]? No -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: Abstract Class Persistence
Hi Craig, > The difference between Persistent Interface and Persistent Abstract > Class is: > > 1. interface PIXXX vs. abstract class PACXXX > 2. PIXXXImpl implements PIXXX vs. PACXXXImpl extends PACXXX > 3. All methods in PIXXX must be properties (corresponding get/set > methods) vs. all abstract methods in PACXXX must be properties. > 4. PIXXXImpl implements all property methods vs. PACXXXImpl > implements all property methods. > > I think that JPOX has already done the hard part in getting PI to > work. The remaining work is "mapping" the concepts of PI to PAC. > > If you point me in the right direction, I'll try to make a patch for JPOX. Ok, if you have time try the following :- 1. Core/src/java/org/jpox/ObjectManagerImpl.java has the method newInstance(). This hands off the creation to an "ImplementationCreator". 2. Enhancer/src/java/org/jpox/enhancer/ImplementationCreatorImpl.java It has a TODO at line 71. The processing of interfaces is at line 88 which utilises an "ImplementationGenerator". 3. Enhancer/src/java/org/jpox/enhancer/bcel/BCELImplementationGenerator.java This currently is only set up for interfaces (InterfaceMetaData), so would need extending to allow classes (ClassMetaData) - so a new constructor perhaps. ... and if you don't have time then we will get around to it at some point. Thx -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: Embedding fields of non-persistent types even when field-type is used
Hi Craig, > I agree that we're getting a bit far from reality with the framework > that we set up for deepEquality testing. It appears that a reflection- > based approach might work if we are unsuccessful in getting JPOX to > work with this artificial setup. > > Michelle and I have already prototyped a reflective approach for > comparing two object graphs. So that's our Plan B in case it's too > much work to force-fit JPOX persistent interface. Plan B shouldn't be needed. If all patches from JDO-503 are applied and latest JPOX is used then companyAnnotatedNoRelationshipsPIPM test passes ;-) -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: datastoreidentity_sql.patch applicationidentity_sql.patch Schema mapping updates to extend discriminator in two places of company model to 255 (it was 255 in several classes of company, but some had 64, so this adds consistency) > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: applicationidentity_company_package_jdo.patch, > applicationidentity_sql.patch, company_annotatedpi.patch, > datastoreidentity_company_package_jdo.patch, datastoreidentity_sql.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: company_annotatedpi.patch Further updates for schema mapping > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: applicationidentity_company_package_jdo.patch, > company_annotatedpi.patch, datastoreidentity_company_package_jdo.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: (was: company_annotatedpi.patch) > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: applicationidentity_company_package_jdo.patch, > datastoreidentity_company_package_jdo.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516280 ] Andy Jefferson commented on JDO-503: There is also a problem with companyAnnotatedPI and the schema that it uses. You have a discriminator column in several places of length 64. You now have class names that exceed this limit e.g "org.apache.jdo.tck.pc.companyAnnotatedPI.PIDSMedicalInsuranceImpl" (the name that JPOX generates for the generated implementation of the PI). Make it longer ? > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: applicationidentity_company_package_jdo.patch, > company_annotatedpi.patch, datastoreidentity_company_package_jdo.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: company_annotatedpi.patch Patch for whole of org.apache.jdo.tck.pc.companyAnnotatedPI package adding missing @Persistent(types=...) annotations and correcting some existing ones > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: applicationidentity_company_package_jdo.patch, > company_annotatedpi.patch, datastoreidentity_company_package_jdo.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: (was: applicationidentity_company_pidsemployee.patch) > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: applicationidentity_company_package_jdo.patch, > datastoreidentity_company_package_jdo.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: (was: datastoreidentity_company_pidsemployee.patch) > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: applicationidentity_company_package_jdo.patch, > datastoreidentity_company_package_jdo.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JDO-509) Enhancement failure on persistent interface that extends non-persistent interface
[ https://issues.apache.org/jira/browse/JDO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson reassigned JDO-509: -- Assignee: Michelle Caisse (was: Andy Jefferson) Latest JPOX CVS HEAD passes "companyPMInterface" (this test but using XML) with the new structure. The only problem is that that test doesn't seem to clean out its data after running. > Enhancement failure on persistent interface that extends non-persistent > interface > - > > Key: JDO-509 > URL: https://issues.apache.org/jira/browse/JDO-509 > Project: JDO > Issue Type: Bug > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: company_ds_jdo.patch > > > Imagine that the existing interface company.ICompany is not persistent and > there is a new interface company.PICompany that extends ICompany. Existing > xml metadata is modified to refer to PICompany rather than ICompany. On > enhancement, we get the error below. Craig suggests that using the > reflective "getDeclaredMethod" instead of the reflective "getMethod" could > give this error. These are changes that we would like to check in for the 2.1 > maintenance release. >[java] An error was encountered reading the specified input files. Please > consult the log for details. The following may help : Class > org.apache.jdo.tck.pc. > company.IPCompany has property null.companyid declared in MetaData, but this > method doesnt exist in the class! >[java] Exception in thread "main" Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] org.jpox.metadata.InvalidMetaDataException: Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] at > org.jpox.metadata.InterfaceMetaData.populatePropertyMetaData(InterfaceMetaData.java:538) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:436) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.JDOMetaDataManager.loadMetaDataForClass(JDOMetaDataManager.java:615) >[java] at > org.jpox.metadata.JDOMetaDataManager.getMetaDataForClassInternal(JDOMetaDataManager.java:308) >[java] at > org.jpox.metadata.AbstractClassMetaData.determineSuperClassName(AbstractClassMetaData.java:618) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:421) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:313) >[java] at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:716) >[java] at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:531) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: applicationidentity_company_package_jdo.patch Updates to persistent-interface definitions in package.jdo for app-id to add in all missing persistent properties and field-types. > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: applicationidentity_company_package_jdo.patch, > applicationidentity_company_pidsemployee.patch, > datastoreidentity_company_package_jdo.patch, > datastoreidentity_company_pidsemployee.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: applicationidentity_company_pidsemployee.patch Missing @Persistent and types for PIAppEmployee (in PIAppInsurance) > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: applicationidentity_company_pidsemployee.patch, > datastoreidentity_company_package_jdo.patch, > datastoreidentity_company_pidsemployee.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: datastoreidentity_company_pidsemployee.patch Missing @Persistent and types for PIDSEmployee under datastore-identity > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: datastoreidentity_company_package_jdo.patch, > datastoreidentity_company_pidsemployee.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-503: --- Attachment: datastoreidentity_company_package_jdo.patch Add missing definition of PIDepartment.employeeOfTheMonth as persistent in package.jdo > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > Attachments: datastoreidentity_company_package_jdo.patch > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-503) Create tests for JDO 2.1 annotations
[ https://issues.apache.org/jira/browse/JDO-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516203 ] Andy Jefferson commented on JDO-503: src/java/org/apache/jdo/tck/pc/companyAnnotatedPI/PIDSPerson.java refers to org.apache.jdo.tck.pc.companyAnnotatedPI.PIAppAddress.class. Perhaps that should be the DS class not the App class. > Create tests for JDO 2.1 annotations > > > Key: JDO-503 > URL: https://issues.apache.org/jira/browse/JDO-503 > Project: JDO > Issue Type: Task > Components: tck2 >Reporter: Michelle Caisse >Assignee: Michelle Caisse > Fix For: JDO 2 maintenance release 1 > > > Create tests for JDO annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-509) Enhancement failure on persistent interface that extends non-persistent interface
[ https://issues.apache.org/jira/browse/JDO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-509: --- Attachment: company_ds_jdo.patch Updated patch for datastoreidentity pc/company/package.jdo to fix collection fields with wrong element-type > Enhancement failure on persistent interface that extends non-persistent > interface > - > > Key: JDO-509 > URL: https://issues.apache.org/jira/browse/JDO-509 > Project: JDO > Issue Type: Bug > Components: tck2 >Reporter: Michelle Caisse > Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > Attachments: company_ds_jdo.patch > > > Imagine that the existing interface company.ICompany is not persistent and > there is a new interface company.PICompany that extends ICompany. Existing > xml metadata is modified to refer to PICompany rather than ICompany. On > enhancement, we get the error below. Craig suggests that using the > reflective "getDeclaredMethod" instead of the reflective "getMethod" could > give this error. These are changes that we would like to check in for the 2.1 > maintenance release. >[java] An error was encountered reading the specified input files. Please > consult the log for details. The following may help : Class > org.apache.jdo.tck.pc. > company.IPCompany has property null.companyid declared in MetaData, but this > method doesnt exist in the class! >[java] Exception in thread "main" Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] org.jpox.metadata.InvalidMetaDataException: Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] at > org.jpox.metadata.InterfaceMetaData.populatePropertyMetaData(InterfaceMetaData.java:538) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:436) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.JDOMetaDataManager.loadMetaDataForClass(JDOMetaDataManager.java:615) >[java] at > org.jpox.metadata.JDOMetaDataManager.getMetaDataForClassInternal(JDOMetaDataManager.java:308) >[java] at > org.jpox.metadata.AbstractClassMetaData.determineSuperClassName(AbstractClassMetaData.java:618) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:421) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:313) >[java] at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:716) >[java] at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:531) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-509) Enhancement failure on persistent interface that extends non-persistent interface
[ https://issues.apache.org/jira/browse/JDO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-509: --- Attachment: (was: company_ds_jdo.patch) > Enhancement failure on persistent interface that extends non-persistent > interface > - > > Key: JDO-509 > URL: https://issues.apache.org/jira/browse/JDO-509 > Project: JDO > Issue Type: Bug > Components: tck2 >Reporter: Michelle Caisse > Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > > Imagine that the existing interface company.ICompany is not persistent and > there is a new interface company.PICompany that extends ICompany. Existing > xml metadata is modified to refer to PICompany rather than ICompany. On > enhancement, we get the error below. Craig suggests that using the > reflective "getDeclaredMethod" instead of the reflective "getMethod" could > give this error. These are changes that we would like to check in for the 2.1 > maintenance release. >[java] An error was encountered reading the specified input files. Please > consult the log for details. The following may help : Class > org.apache.jdo.tck.pc. > company.IPCompany has property null.companyid declared in MetaData, but this > method doesnt exist in the class! >[java] Exception in thread "main" Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] org.jpox.metadata.InvalidMetaDataException: Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] at > org.jpox.metadata.InterfaceMetaData.populatePropertyMetaData(InterfaceMetaData.java:538) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:436) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.JDOMetaDataManager.loadMetaDataForClass(JDOMetaDataManager.java:615) >[java] at > org.jpox.metadata.JDOMetaDataManager.getMetaDataForClassInternal(JDOMetaDataManager.java:308) >[java] at > org.jpox.metadata.AbstractClassMetaData.determineSuperClassName(AbstractClassMetaData.java:618) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:421) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:313) >[java] at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:716) >[java] at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:531) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-509) Enhancement failure on persistent interface that extends non-persistent interface
[ https://issues.apache.org/jira/browse/JDO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-509: --- Attachment: company_ds_jdo.patch Patch for package.jdo under pc/company to add in missing lines for persistent properties > Enhancement failure on persistent interface that extends non-persistent > interface > - > > Key: JDO-509 > URL: https://issues.apache.org/jira/browse/JDO-509 > Project: JDO > Issue Type: Bug > Components: tck2 >Reporter: Michelle Caisse > Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > Attachments: company_ds_jdo.patch > > > Imagine that the existing interface company.ICompany is not persistent and > there is a new interface company.PICompany that extends ICompany. Existing > xml metadata is modified to refer to PICompany rather than ICompany. On > enhancement, we get the error below. Craig suggests that using the > reflective "getDeclaredMethod" instead of the reflective "getMethod" could > give this error. These are changes that we would like to check in for the 2.1 > maintenance release. >[java] An error was encountered reading the specified input files. Please > consult the log for details. The following may help : Class > org.apache.jdo.tck.pc. > company.IPCompany has property null.companyid declared in MetaData, but this > method doesnt exist in the class! >[java] Exception in thread "main" Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] org.jpox.metadata.InvalidMetaDataException: Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] at > org.jpox.metadata.InterfaceMetaData.populatePropertyMetaData(InterfaceMetaData.java:538) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:436) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.JDOMetaDataManager.loadMetaDataForClass(JDOMetaDataManager.java:615) >[java] at > org.jpox.metadata.JDOMetaDataManager.getMetaDataForClassInternal(JDOMetaDataManager.java:308) >[java] at > org.jpox.metadata.AbstractClassMetaData.determineSuperClassName(AbstractClassMetaData.java:618) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:421) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:313) >[java] at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:716) >[java] at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:531) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-511) Add "extensions" element to @Join, @Element, @Key, @Value, @DatastoreIdentity, ...
[
https://issues.apache.org/jira/browse/JDO-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516152
]
Andy Jefferson commented on JDO-511:
Please add it to @Query too. Forgot that in my first list.
> Add "extensions" element to @Join, @Element, @Key, @Value,
> @DatastoreIdentity, ...
> --
>
> Key: JDO-511
> URL: https://issues.apache.org/jira/browse/JDO-511
> Project: JDO
> Issue Type: Improvement
> Components: api2
>Reporter: Andy Jefferson
>Assignee: Craig Russell
> Fix For: JDO 2 maintenance release 1
>
>
> Vendors have their own extensions to various XML metadata elements and it is
> desirable for these to be usable with annotations. @PersistenceCapable,
> @Persistent, @Sequence offer these, but many others don't. The principal ones
> being
> @Join, @Element, @Key, @Value, @DatastoreIdentity, @Column, @Version,
> and they need the following adding
> /** Vendor extensions for this member.
> * @return the vendor extensions
> */
> Extension[] extensions() default {};
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-487) Pm.newInstance() fails when the parameter is an abstract class
[ https://issues.apache.org/jira/browse/JDO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516151 ] Andy Jefferson commented on JDO-487: This was raised in JPOX JIRA 1yr+ ago to add support for newInstance on abstract classes, which it has never supported. http://www.jpox.org/servlet/jira/browse/CORE-2792 > Pm.newInstance() fails when the parameter is an abstract class > -- > > Key: JDO-487 > URL: https://issues.apache.org/jira/browse/JDO-487 > Project: JDO > Issue Type: Bug > Components: tck2 >Affects Versions: JDO 2 maintenance release 1 > Environment: jpox SNAPSHOT >Reporter: Michelle Caisse >Assignee: Andy Jefferson > > org.apache.jdo.tck.api.persistencemanager.NewInstance fails attempting to > instantiate an abstract class. This test is just a stub of a future test > (see JDO-453). To reproduce, run > maven -Djdo.tck.cfglist=pm.conf runtck.jdori > [java] 1) > testNewInstance(org.apache.jdo.tck.api.persistencemanager.NewInstance)javax.jdo.JDOUserException: > java.lang.InstantiationException > [java] at > org.jpox.enhancer.ImplementationCreatorImpl.newInstance(ImplementationCreatorImpl.java:153) > [java] at > org.jpox.ObjectManagerImpl.newInstance(ObjectManagerImpl.java:3073) > [java] at > org.jpox.AbstractPersistenceManager.newInstance(AbstractPersistenceManager.java:1413) > [java] at > org.apache.jdo.tck.api.persistencemanager.NewInstance.runTestNewInstanceAbstractClass(NewInstance.java:91) > [java] at > org.apache.jdo.tck.api.persistencemanager.NewInstance.testNewInstance(NewInstance.java:65) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [java] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [java] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > [java] NestedThrowablesStackTrace: > [java] java.lang.InstantiationException > [java] at > sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:30) > [java] at > java.lang.reflect.Constructor.newInstance(Constructor.java:494) > [java] at java.lang.Class.newInstance0(Class.java:350) > [java] at java.lang.Class.newInstance(Class.java:303) > [java] at > org.jpox.enhancer.ImplementationCreatorImpl.newInstance(ImplementationCreatorImpl.java:123) > [java] at > org.jpox.ObjectManagerImpl.newInstance(ObjectManagerImpl.java:3073) > [java] at > org.jpox.AbstractPersistenceManager.newInstance(AbstractPersistenceManager.java:1413) > [java] at > org.apache.jdo.tck.api.persistencemanager.NewInstance.runTestNewInstanceAbstractClass(NewInstance.java:91) > [java] at > org.apache.jdo.tck.api.persistencemanager.NewInstance.testNewInstance(NewInstance.java:65) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [java] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [java] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:254) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Embedding fields of non-persistent types even when field-type is used
Hi Craig, Michelle, > The problem is that if you declare the PI* address property in > PICompany as > PIAddress getAddress() > void setAddress(PIAddress) > > then it doesn't implement ICompany any more, since you also need > these from the ICompany interface: > IAddress getAddress() > void setAddress(IAddress) > > And of course these are the methods that the e.g. FC classes > implement by casting the input IAddress to FCAddress. Which is what > we want the generated PICompanyImpl to do because we specify that the > type of the field is PIAddress. There are still places where there is no "types" (annotations) or "field-type" (XML) specified on overridden interface fields. I'll start from the one that "companyPMInterface.conf" complains about PIInsurance has no on field "employee". PIDSInsurance has no @Persistent(types=) on field "employee". Fix those and re-run, you then get the error on PIEmployee "dentalInsurance", "medicalInsurance", "department", "fundingDept", ... PIDSEmployee etc When those are fixed there are likely some others. Only when *all* of these are added can we address if JPOX can cope with that structure or not. As it is currently there are persistent properties that are not persistent. Maybe JPOX will cope ? PS. Let's face it, the persistent-interface structure is an artificially constructed case that is no longer representative of the real world, and staring at it for several minutes causes madness to set in ... -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: JDO TCK Conference Call Friday, July 27, 9 am PDT
> [From Craig, by email]: The tck with annotations isn't working yet, > although it does get past the enhancement step. There are issues with > relationships and embedded null values. Hi all, I ran the TCK today (with latest JPOX CVS) and all annotations tests pass except for the persistent-interface case. JPOX prior to this morning didn't support the "embeddedMapping" element on @Element, @Key, @Value, but it now does. Grab the latest jars in the nightly build area and you should be fine. -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: Company model : concrete classes and use of "field-type"
Hi Craig, > Looking briefly, it looks like the only cases are for the embedded > Address field. Is this what you are referring to? That's the one I spotted and didn't look further. PS. "api2" seems to be missing a couple of files being checked in for a working build test/java/javax/jdo/annotations/TestEmbeddedSet.java test/java/javax/jdo/annotations/TestEmbeddedMap.java - change the "embedded" to "embeddedMapping". -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Commented: (JDO-509) Enhancement failure on persistent interface that extends non-persistent interface
[ https://issues.apache.org/jira/browse/JDO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516019 ] Andy Jefferson commented on JDO-509: All of this is caused by the change in the model. The fact is that you now are trying to embed an interface type that is not persistent (neither PersistenceCapable, nor "persistent-interface"). Ok, you are specifying "field-type" but sadly JPOX doesn't cater for that (my previous fix was a guess since I didn't write support for PI's and turns out that it only worked around metadata consistency issues). JPOX's handling of "persistent-interface" is for use of relation fields that are either PC or persistent-interface only. > Enhancement failure on persistent interface that extends non-persistent > interface > - > > Key: JDO-509 > URL: https://issues.apache.org/jira/browse/JDO-509 > Project: JDO > Issue Type: Bug > Components: tck2 >Reporter: Michelle Caisse >Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > > Imagine that the existing interface company.ICompany is not persistent and > there is a new interface company.PICompany that extends ICompany. Existing > xml metadata is modified to refer to PICompany rather than ICompany. On > enhancement, we get the error below. Craig suggests that using the > reflective "getDeclaredMethod" instead of the reflective "getMethod" could > give this error. These are changes that we would like to check in for the 2.1 > maintenance release. >[java] An error was encountered reading the specified input files. Please > consult the log for details. The following may help : Class > org.apache.jdo.tck.pc. > company.IPCompany has property null.companyid declared in MetaData, but this > method doesnt exist in the class! >[java] Exception in thread "main" Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] org.jpox.metadata.InvalidMetaDataException: Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] at > org.jpox.metadata.InterfaceMetaData.populatePropertyMetaData(InterfaceMetaData.java:538) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:436) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.JDOMetaDataManager.loadMetaDataForClass(JDOMetaDataManager.java:615) >[java] at > org.jpox.metadata.JDOMetaDataManager.getMetaDataForClassInternal(JDOMetaDataManager.java:308) >[java] at > org.jpox.metadata.AbstractClassMetaData.determineSuperClassName(AbstractClassMetaData.java:618) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:421) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:313) >[java] at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:716) >[java] at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:531) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Company model : concrete classes and use of "field-type"
Hi, I just looked through the company model and noted that the concrete classes now have some fields marked with "field-type" in the XML (e.g Company.address). Why? The field has its own type so there is no need to specify that. It is typically for use where a field is an interface and so to define the implementation(s) that the field will accept. Is there a reason for specifying it ? -- Andy (Java Persistent Objects - http://www.jpox.org)
src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSProject.java
This file seems to be missing @Persistent(table="project_reviewer") against the field "reviewers". Hopefully some kind person will add it ;-) -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: [jira] Commented: (JDO-510) Remove @Field and @Property and replace them with @Persistent
Hi Craig, > The issue here is if both type and types are specified, which one > wins? Since types can be both single or multiple types, I think > there's less opportunity for error if there is only one element, and > types does it. And it is evocative of the notion that even though you > specified a type on your field/property (or not, for unadorned > collection/map types), there are more constraints on the actual types > that you can put into it. No problem with just having the "types" element for me ... that's what I had originally :-). What the user types @Element(types=MyElement.class) compared to the single form @Element(type=MyElement.class) is so similar I didn't see the point of the single form variant and, of course, it also allows multiple values for implementations that support it. Just want to avoid that option being included and then removed, and then back in again. > Meantime, I'll check in the change from boundTypes to types to keep things > moving. Thx. JPOX CVS now builds with latest Apache JDO jdo2-api.jar (@Persistent,@Element,@Key,@Value "boundTypes" -> "types", and also @Element,@Key,@Value "embedded" change). I've started the "nightly" build running so there are jars if anyone wants to run with it. -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: [jira] Commented: (JDO-510) Remove @Field and @Property and replace them with @Persistent
Hi Michael, > I think we should use the same name for all four annotation type and if > "boundTypes" is not meaningful we should go for "types". +1 "types" is shorter, is more meaningful, and is what many people are already using for the @Element, @Key, @Value. Yes I know Apache JDO haven't had a release, but there are some people who are using them. PS.1. Previously someone added the single form of this to @Field, @Element, @Key, @Value yet they have now silently disappeared. Are they coming back or leaving permanently ? Since I took the time to implement support for it, now I have to strip it back out ? PS.2. Can we have some sort of release of Apache JDO jdo2 SNAPSHOT jar to some location (date stamped perhaps) ? You're not in that "incubator" thing now and the only way to demonstrate to people that JDO is still alive is to actually provide them with samples of the deliverable (suitably named to represent its status). -- Andy (Java Persistent Objects - http://www.jpox.org)
[jira] Created: (JDO-511) Add "extensions" element to @Join, @Element, @Key, @Value, @DatastoreIdentity, ...
Add "extensions" element to @Join, @Element, @Key, @Value, @DatastoreIdentity,
...
--
Key: JDO-511
URL: https://issues.apache.org/jira/browse/JDO-511
Project: JDO
Issue Type: Improvement
Components: api2
Reporter: Andy Jefferson
Fix For: JDO 2 maintenance release 1
Vendors have their own extensions to various XML metadata elements and it is
desirable for these to be usable with annotations. @PersistenceCapable,
@Persistent, @Sequence offer these, but many others don't. The principal ones
being
@Join, @Element, @Key, @Value, @DatastoreIdentity, @Column, @Version,
and they need the following adding
/** Vendor extensions for this member.
* @return the vendor extensions
*/
Extension[] extensions() default {};
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Annotations for embedded Key, Value, and Element
Hi Craig, > I disagree on that placement of the other flags, back on to > @Field/@Property. They relate specifically to the element, key, value so > keep them on the associated annotation would be my vote. So then it really > comes down to namings of the global flag, and the mapping details > > 1. "embedded", "embeddedMapping" > 2. "embeddedElement", "embedded" This seems to have been ignored (by the most recent check in) and users can no longer specify the equivalent of "embedded-element" on the @Element (similarly embedded-key on @Key, embedded-value on @Value). I would like them reinstated, as per the above proposal. -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: [jira] Commented: (JDO-510) Remove @Field and @Property and replace them with @Persistent
Hi Craig, > Given that we had fieldType and fieldTypes in @Field and @Property, > and type and types in @Element, @Key, and @Value, I made them > consistent by changing types to boundTypes in @Element, @Key, and > @Value. > > Is this what we want? Or should we change boundTypes back to types > for all four annotation types? "boundTypes" does absolutely nothing for me. I don't see what is wrong with "types" and "fieldTypes", and that is, after all, what the XML has. -- Andy (Java Persistent Objects - http://www.jpox.org)
Re: [VOTE] remove @Field and @Property; add @Persistent
> Recently we updated the change list:
>
> Add Persistent[] members() default {} to @PersistenceCapable
> Added back PersistenceModifier persistenceModifier() to @Persistent
>
> If others agree, please vote.
+1
--
Andy
[jira] Commented: (JDO-509) Enhancement failure on persistent interface that extends non-persistent interface
[ https://issues.apache.org/jira/browse/JDO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514738 ] Andy Jefferson commented on JDO-509: Thx. Taking the actual issue a little further, you're overriding the field types of some of the methods with the PIXXX variant and that is the actual issue - all previous persistent-interface samples did nothing of the sort. Once I update JPOX to use that value it goes past the PICompany message and comes to PIPerson which has "address" declared as IAddress and the jdo file does nothing to set the "fieldType" so get the message org.jpox.metadata.InvalidMetaDataException: Field "org.apache.jdo.tck.pc.company.PIPerson.address" is of type "org.apache.jdo.tck.pc.company.IAddress" yet has been specified as embedded. JPOX doesnt support embedding of this type. Your embedded type must be PersistenceCapable" i.e you must define the fieldType or have a PC/persistent-interface type as the method type. > Enhancement failure on persistent interface that extends non-persistent > interface > - > > Key: JDO-509 > URL: https://issues.apache.org/jira/browse/JDO-509 > Project: JDO > Issue Type: Bug > Components: tck2 >Reporter: Michelle Caisse >Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > > Imagine that the existing interface company.ICompany is not persistent and > there is a new interface company.PICompany that extends ICompany. Existing > xml metadata is modified to refer to PICompany rather than ICompany. On > enhancement, we get the error below. Craig suggests that using the > reflective "getDeclaredMethod" instead of the reflective "getMethod" could > give this error. These are changes that we would like to check in for the 2.1 > maintenance release. >[java] An error was encountered reading the specified input files. Please > consult the log for details. The following may help : Class > org.apache.jdo.tck.pc. > company.IPCompany has property null.companyid declared in MetaData, but this > method doesnt exist in the class! >[java] Exception in thread "main" Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] org.jpox.metadata.InvalidMetaDataException: Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] at > org.jpox.metadata.InterfaceMetaData.populatePropertyMetaData(InterfaceMetaData.java:538) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:436) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.JDOMetaDataManager.loadMetaDataForClass(JDOMetaDataManager.java:615) >[java] at > org.jpox.metadata.JDOMetaDataManager.getMetaDataForClassInternal(JDOMetaDataManager.java:308) >[java] at > org.jpox.metadata.AbstractClassMetaData.determineSuperClassName(AbstractClassMetaData.java:618) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:421) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:313) >[java] at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:716) >[java] at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:531) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-509) Enhancement failure on persistent interface that extends non-persistent interface
[ https://issues.apache.org/jira/browse/JDO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514720 ] Andy Jefferson commented on JDO-509: Wish I hadn't done that svn update now. src/conf/configurations.list refers to companyFCAnnotatedNoRelationships.conf (and others) yet this doesn't exist now. > Enhancement failure on persistent interface that extends non-persistent > interface > - > > Key: JDO-509 > URL: https://issues.apache.org/jira/browse/JDO-509 > Project: JDO > Issue Type: Bug > Components: tck2 >Reporter: Michelle Caisse >Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > > Imagine that the existing interface company.ICompany is not persistent and > there is a new interface company.PICompany that extends ICompany. Existing > xml metadata is modified to refer to PICompany rather than ICompany. On > enhancement, we get the error below. Craig suggests that using the > reflective "getDeclaredMethod" instead of the reflective "getMethod" could > give this error. These are changes that we would like to check in for the 2.1 > maintenance release. >[java] An error was encountered reading the specified input files. Please > consult the log for details. The following may help : Class > org.apache.jdo.tck.pc. > company.IPCompany has property null.companyid declared in MetaData, but this > method doesnt exist in the class! >[java] Exception in thread "main" Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] org.jpox.metadata.InvalidMetaDataException: Class > org.apache.jdo.tck.pc.company.IPCompany has property null.companyid declared > in MetaData, but this method doesnt exist in the class! >[java] at > org.jpox.metadata.InterfaceMetaData.populatePropertyMetaData(InterfaceMetaData.java:538) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:436) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.JDOMetaDataManager.loadMetaDataForClass(JDOMetaDataManager.java:615) >[java] at > org.jpox.metadata.JDOMetaDataManager.getMetaDataForClassInternal(JDOMetaDataManager.java:308) >[java] at > org.jpox.metadata.AbstractClassMetaData.determineSuperClassName(AbstractClassMetaData.java:618) >[java] at > org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:421) >[java] at > org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) >[java] at > org.jpox.metadata.MetaDataManager.initialise(MetaDataManager.java:313) >[java] at > org.jpox.enhancer.JPOXEnhancer.getFileMetaDataForInput(JPOXEnhancer.java:716) >[java] at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:531) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-509) Enhancement failure on persistent interface that extends non-persistent interface
[ https://issues.apache.org/jira/browse/JDO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514695 ] Andy Jefferson commented on JDO-509: Hi Michelle, I don't understand the current situation. Have you checked in some persistent classes that causes large numbers of TCK tests to fail, because now there are many tests (19) with errors with that issue above. This means that I can't reliably use the TCK as a way of judging compliance with anything else. For example, companyNoRelationships.conf gives Field "null.address" is of type "org.apache.jdo.tck.pc.company.IAddress" yet has been specified as embedded. JPOX doesnt support embedding of this type. Your embedded type must be PersistenceCapable. [java] org.jpox.metadata.InvalidMetaDataException: Field "null.address" is of type "org.apache.jdo.tck.pc.company.IAddress" yet has been specified as embedded. JPOX doesnt support embedding of this type. Your embedded type must be PersistenceCapable. [java] at org.jpox.metadata.EmbeddedMetaData.populate(EmbeddedMetaData.java:141) [java] at org.jpox.metadata.AbstractPropertyMetaData.populate(AbstractPropertyMetaData.java:915) [java] at org.jpox.metadata.InterfaceMetaData.populatePropertyMetaData(InterfaceMetaData.java:527) [java] at org.jpox.metadata.InterfaceMetaData.populate(InterfaceMetaData.java:424) [java] at org.jpox.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:1590) [java] at org.jpox.metadata.JDOMetaDataManager.loadMetaDataForClass(JDOMetaDataManager.java:615) [java] at org.jpox.metadata.JDOMetaDataManager.getMetaDataForClassInternal(JDOMetaDataManager.java:308) [java] at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:772) [java] at org.jpox.ObjectManagerImpl.hasPersistenceInformationForClass(ObjectManagerImpl.java:3226) [java] at org.jpox.ObjectManagerImpl.assertClassPersistable(ObjectManagerImpl.java:3120) [java] at org.jpox.ObjectManagerImpl.persistObjectInternal(ObjectManagerImpl.java:1024) [java] at org.jpox.ObjectManagerImpl.persistObject(ObjectManagerImpl.java:987) [java] at org.jpox.AbstractPersistenceManager.jdoMakePersistent(AbstractPersistenceManager.java:589) [java] at org.jpox.AbstractPersistenceManager.makePersistentAll(AbstractPersistenceManager.java:643) [java] at org.apache.jdo.tck.mapping.CompletenessTest.localSetUp(CompletenessTest.java:79) [java] at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:237) [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:253) I also get several with things like java.lang.RuntimeException: Unable to construct CompanyFactory org.apache.jdo.tck.pc.company.CompanyFactoryAnnotatedFCPMDelegator [java] at org.apache.jdo.tck.pc.company.CompanyFactoryRegistry.registerFactory(CompanyFactoryRegistry.java:128) [java] at org.apache.jdo.tck.pc.company.CompanyFactoryRegistry.registerFactory(CompanyFactoryRegistry.java:105) [java] at org.apache.jdo.tck.mapping.CompletenessTest.localSetUp(CompletenessTest.java:73) [java] at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:237) [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:253) [java] at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) [java] Caused by: java.lang.ClassNotFoundException: org.apache.jdo.tck.pc.company.CompanyFactoryAnnotatedFCPMDelegator > Enhancement failure on persistent interface that extends non-persistent > interface > - > > Key: JDO-509 > URL: https://issues.apache.org/jira/browse/JDO-509 > Project: JDO > Issue Type: Bug > Components: tck2 >Reporter: Michelle Caisse >Assignee: Andy Jefferson > Fix For: JDO 2 maintenance release 1 > > > Imagine that the existing interface company.ICompany is not persistent and > there is a new interface company.PICompany that extends ICompany. Existing > xml metadata is modified to refer to PICompany rather than ICompany. On > enhancement, we get the error below. Craig suggests that using the > reflective "getDeclaredMethod" instead of the reflective "getMethod" could > give this error. These are changes that we would like to check in for the 2.1 > maintenance release. >[java] An error was encountered reading the specified input files. Please > consul
[jira] Commented: (JDO-510) Remove @Field and @Property and replace them with @Persistent
[ https://issues.apache.org/jira/browse/JDO-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514552 ] Andy Jefferson commented on JDO-510: There is a need for a way of overriding fields/properties in superclasses. To allow it for a single field/property would mean making @Persistent available at ElementType.TYPE, but rather than that it should be available for specifying multiple fields @Persistents?, @OverriddenMembers?, @Overrides?, @Members? > Remove @Field and @Property and replace them with @Persistent > - > > Key: JDO-510 > URL: https://issues.apache.org/jira/browse/JDO-510 > Project: JDO > Issue Type: New Feature > Components: api2 >Reporter: Craig Russell >Assignee: Craig Russell > Fix For: JDO 2 maintenance release 1 > > Attachments: jdo-510.patch > > > Annotations are different from xml ways that make it impossible to refer to > persistent fields and properties in the same way. We started out thinking > that we could simply map the xml field to annotations @Field and xml property > to @Property but could not refer to multiples in a sane way. > This change removes @Field and @Property and replaces them with @Persistent. > Other annotations that refer to these are changed so that they refer to > members instead of to fields or properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JDO TCK Conference Call Friday, July 20, 9 am PDT
Hi Craig, > This brings up a question. In JPOX, if you enhance a class with a > field that is NotPersistent, can you then in an embedded use case > mark the same field as Persistent? The only situation I'd currently thought of (but never tried) would be of not persisting a field that had been defined as persistent (not the other way around). The JPOX Enhancer doesn't do anything special in this situation so if the user enhanced it as non-persistent and tried that it would likely fail. I've certainly seen some situations where a particular class is defined with a full persistence definition, but when stored embedded only a subset of the fields are wanted to be persisted. > More questions than answers. Are we sure that it's a good idea to > allow overriding the PersistenceModifier in embedded usages? I'd like to allow the "downgrade" option (not persist a persistable field) since it should be common enough when embedding. As you pointed out, the "upgrade" option creates problems and would require special treatment to allow it so I've no problem ruling it out. -- Andy Java Persistent Objects (JPOX)
Re: JDO TCK Conference Call Friday, July 20, 9 am PDT
> The only reason to have PersistenceModifier at all is to make it > possible to say @Persistent > (persistenceModifier=PersistenceModifier.NONE) or @Persistent > (persistenceModifier=PersistenceModifier.TRANSACTIONAL). It can be > removed without loss of functionality. It *cannot* be removed with no loss of functionality. If I need to specify the fields of an embedded instance and I want to override the persistence-modifier setting of a field how would I do that? I don't see it since I cant specify @NotPersistent in the "fields" of @Embedded since it takes an array of @Persistent. -- Andy Java Persistent Objects (JPOX)
Re: DISCUSS remove @Field and @Property; add @Persistent
> Have I ever told you how much I *hate* using @Transient to describe > @NotPersistent? Transient is a serialization concept and I have no > trouble with a field that is both transient and persistent. That is, > not serialized but stored in the database. So calling something > @Transient is a big ugly blotch. Because if it's really transient, > you should mark it in the class as transient. No. You never told me ;-) nor did anybody else object when those annotations were added a lon time ago. So why not @NotPersistent ? -- Andy (Java Persistent Objects - http://www.jpox.org)
