[jira] [Commented] (JDO-822) Verify compatibility with JDK 20
[ https://issues.apache.org/jira/browse/JDO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729123#comment-17729123 ] Craig L Russell commented on JDO-822: - +1 Continue to build/test on JDK20 and then change to JDK21 when available. > Verify compatibility with JDK 20 > > > Key: JDO-822 > URL: https://issues.apache.org/jira/browse/JDO-822 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-815) Change headers on source files to use https:// instead of http://
[ https://issues.apache.org/jira/browse/JDO-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-815. - Resolution: Fixed > Change headers on source files to use https:// instead of http:// > - > > Key: JDO-815 > URL: https://issues.apache.org/jira/browse/JDO-815 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Craig L Russell >Assignee: Craig L Russell >Priority: Minor > Fix For: JDO 3.2.2, JDO 3.3 > > > The license headers in all source files use > [http://www.apache.org/licenses/LICENSE-2.0] > The headers should instead use > [https://www.apache.org/licenses/LICENSE-2.0] > This change should also be made in pom.xml > We will need to wait until RAT 0.14 is released in order to pass the RAT test > for license headers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-815) Change headers on source files to use https:// instead of http://
[ https://issues.apache.org/jira/browse/JDO-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17628469#comment-17628469 ] Craig L Russell commented on JDO-815: - There are about 1000 files that need to be changed; .jdo, .xml, .java and a number of license files. Waiting for a good time to make the change. > Change headers on source files to use https:// instead of http:// > - > > Key: JDO-815 > URL: https://issues.apache.org/jira/browse/JDO-815 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Craig L Russell >Assignee: Craig L Russell >Priority: Minor > Fix For: JDO 3.2.2, JDO 3.3 > > > The license headers in all source files use > [http://www.apache.org/licenses/LICENSE-2.0] > The headers should instead use > [https://www.apache.org/licenses/LICENSE-2.0] > This change should also be made in pom.xml > We will need to wait until RAT 0.14 is released in order to pass the RAT test > for license headers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618384#comment-17618384 ] Craig L Russell commented on JDO-709: - > What's the alternative solution? Perhaps you could be explicit with some sample code that you would like to see supported. Thanks. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-815) Change headers on source files to use https:// instead of http://
[ https://issues.apache.org/jira/browse/JDO-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-815. - Resolution: Fixed For the record, I manually edited the pom.xml files, NOTICE, LICENSE, and README. For the rest of the files, I used this command: find . \( ! -regex '.*/\..*' \) -type f | xargs sed -i '' 's/http:\/\/www\.apache/https:\/\/www\.apache/g' > Change headers on source files to use https:// instead of http:// > - > > Key: JDO-815 > URL: https://issues.apache.org/jira/browse/JDO-815 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Craig L Russell >Assignee: Craig L Russell >Priority: Minor > Fix For: JDO 3.2.2 > > > The license headers in all source files use > [http://www.apache.org/licenses/LICENSE-2.0] > The headers should instead use > [https://www.apache.org/licenses/LICENSE-2.0] > This change should also be made in pom.xml > We will need to wait until RAT 0.14 is released in order to pass the RAT test > for license headers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-815) Change headers on source files to use https:// instead of http://
[ https://issues.apache.org/jira/browse/JDO-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17560691#comment-17560691 ] Craig L Russell commented on JDO-815: - The way to run RAT against the source directory is to go to any directory and run: mvn apache-rat:check > Change headers on source files to use https:// instead of http:// > - > > Key: JDO-815 > URL: https://issues.apache.org/jira/browse/JDO-815 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Craig L Russell >Assignee: Craig L Russell >Priority: Minor > Fix For: JDO 3.2.2 > > > The license headers in all source files use > [http://www.apache.org/licenses/LICENSE-2.0] > The headers should instead use > [https://www.apache.org/licenses/LICENSE-2.0] > This change should also be made in pom.xml > We will need to wait until RAT 0.14 is released in order to pass the RAT test > for license headers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-815) Change headers on source files to use https:// instead of http://
[ https://issues.apache.org/jira/browse/JDO-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17543173#comment-17543173 ] Craig L Russell commented on JDO-815: - This can be tested by specifying RAT 0.14-SNAPSHOT. The 0.14 release is due out shortly... > Change headers on source files to use https:// instead of http:// > - > > Key: JDO-815 > URL: https://issues.apache.org/jira/browse/JDO-815 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Craig L Russell >Assignee: Craig L Russell >Priority: Minor > Fix For: JDO 3.2.2 > > > The license headers in all source files use > [http://www.apache.org/licenses/LICENSE-2.0] > The headers should instead use > [https://www.apache.org/licenses/LICENSE-2.0] > This change should also be made in pom.xml > We will need to wait until RAT 0.14 is released in order to pass the RAT test > for license headers. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (JDO-815) Change headers on source files to use https:// instead of http://
[ https://issues.apache.org/jira/browse/JDO-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-815: Description: The license headers in all source files use [http://www.apache.org/licenses/LICENSE-2.0] The headers should instead use [https://www.apache.org/licenses/LICENSE-2.0] This change should also be made in pom.xml We will need to wait until RAT 0.14 is released in order to pass the RAT test for license headers. was: The license headers in all source files use [http://www.apache.org/licenses/LICENSE-2.0] The headers should instead use [https://www.apache.org/licenses/LICENSE-2.0|http://www.apache.org/licenses/LICENSE-2.0] This change should also be made in pom.xml We will need to wait until RAT 0.14 is released in order to pass the RAT test for license headers. > Change headers on source files to use https:// instead of http:// > - > > Key: JDO-815 > URL: https://issues.apache.org/jira/browse/JDO-815 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Craig L Russell >Assignee: Craig L Russell >Priority: Minor > Fix For: JDO 3.2.2 > > > The license headers in all source files use > [http://www.apache.org/licenses/LICENSE-2.0] > The headers should instead use > [https://www.apache.org/licenses/LICENSE-2.0] > This change should also be made in pom.xml > We will need to wait until RAT 0.14 is released in order to pass the RAT test > for license headers. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (JDO-815) Change headers on source files to use https:// instead of http://
[ https://issues.apache.org/jira/browse/JDO-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-815: Description: The license headers in all source files use [http://www.apache.org/licenses/LICENSE-2.0] The headers should instead use [https://www.apache.org/licenses/LICENSE-2.0|http://www.apache.org/licenses/LICENSE-2.0] This change should also be made in pom.xml We will need to wait until RAT 0.14 is released in order to pass the RAT test for license headers. was: The license headers in all source files use [http://www.apache.org/licenses/LICENSE-2.0] The headers should instead use [https://www.apache.org/licenses/LICENSE-2.0|http://www.apache.org/licenses/LICENSE-2.0] This change should also be made in pom.xml > Change headers on source files to use https:// instead of http:// > - > > Key: JDO-815 > URL: https://issues.apache.org/jira/browse/JDO-815 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Craig L Russell >Assignee: Craig L Russell >Priority: Minor > Fix For: JDO 3.2.2 > > > The license headers in all source files use > [http://www.apache.org/licenses/LICENSE-2.0] > The headers should instead use > [https://www.apache.org/licenses/LICENSE-2.0|http://www.apache.org/licenses/LICENSE-2.0] > This change should also be made in pom.xml > We will need to wait until RAT 0.14 is released in order to pass the RAT test > for license headers. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (JDO-815) Change headers on source files to use https:// instead of http://
Craig L Russell created JDO-815: --- Summary: Change headers on source files to use https:// instead of http:// Key: JDO-815 URL: https://issues.apache.org/jira/browse/JDO-815 Project: JDO Issue Type: Task Components: api, tck Affects Versions: JDO 3.2.1 Reporter: Craig L Russell Assignee: Craig L Russell Fix For: JDO 3.2.2 The license headers in all source files use [http://www.apache.org/licenses/LICENSE-2.0] The headers should instead use [https://www.apache.org/licenses/LICENSE-2.0|http://www.apache.org/licenses/LICENSE-2.0] This change should also be made in pom.xml -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[ https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512640#comment-17512640 ] Craig L Russell commented on JDO-806: - This question on stackoverflow seems to be relevant to our discussion: [https://stackoverflow.com/questions/8229740/xml-schema-header-namespace-config] Are we using the terminology correctly? > Use apache URL for schemaLocation of JDO XSDs > - > > Key: JDO-806 > URL: https://issues.apache.org/jira/browse/JDO-806 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > In JDO 3.2 the schemaLocation of JDO XSDs link to > [http://xmlns.jcp.org/xml/ns/jdo/] where is one of jdo_3_2.xsd, > jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site > [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that > the 3.2 XSDs are available under this URL (see JDO-744). > One idea ist might be to switch to an Apache URL, where we can control the > download sites. > This change requires corresponding changes to the specification, api, and > tck. Here is a proposed plan to implement: > # Update the xsds and dtds in the api/resources to change the headers. > # Update the xsds and dtds in the db.apache.org/jdo/xmlns with the changes. > # Update the xsds and dtds in the tck with the changes. This step will fail > without a corresponding change to the reference implementation. > # Update the specification with the changes. A partial list of affected > sections: > ## 11.1.4 p. 122 > ## 18.24 p. 261 > ## 18.25 p. 265 > ## 18.26 p. 287, 298 > ## New C.23 Changes since 3.2 p. 404 > Open question: should we keep the version number of the xsd and dtd files as > 3.2 even though the api, tck, and specification will be updated to 3.2.1? I > would say yes, and only change the version number of the files if there is a > change to the content of the xsd and/or dtd. > My proposal is: the 3.2.1 version of JDO would still refer to the 3.2 version > of the xsd and dtd. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[ https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512636#comment-17512636 ] Craig L Russell commented on JDO-806: - Should the headers in the xsd and dtd files change http to https? I cannot find a definitive answer to this question. > Use apache URL for schemaLocation of JDO XSDs > - > > Key: JDO-806 > URL: https://issues.apache.org/jira/browse/JDO-806 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > In JDO 3.2 the schemaLocation of JDO XSDs link to > [http://xmlns.jcp.org/xml/ns/jdo/] where is one of jdo_3_2.xsd, > jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site > [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that > the 3.2 XSDs are available under this URL (see JDO-744). > One idea ist might be to switch to an Apache URL, where we can control the > download sites. > This change requires corresponding changes to the specification, api, and > tck. Here is a proposed plan to implement: > # Update the xsds and dtds in the api/resources to change the headers. > # Update the xsds and dtds in the db.apache.org/jdo/xmlns with the changes. > # Update the xsds and dtds in the tck with the changes. This step will fail > without a corresponding change to the reference implementation. > # Update the specification with the changes. A partial list of affected > sections: > ## 11.1.4 p. 122 > ## 18.24 p. 261 > ## 18.25 p. 265 > ## 18.26 p. 287, 298 > ## New C.23 Changes since 3.2 p. 404 > Open question: should we keep the version number of the xsd and dtd files as > 3.2 even though the api, tck, and specification will be updated to 3.2.1? I > would say yes, and only change the version number of the files if there is a > change to the content of the xsd and/or dtd. > My proposal is: the 3.2.1 version of JDO would still refer to the 3.2 version > of the xsd and dtd. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[ https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-806: Description: In JDO 3.2 the schemaLocation of JDO XSDs link to [http://xmlns.jcp.org/xml/ns/jdo/] where is one of jdo_3_2.xsd, jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that the 3.2 XSDs are available under this URL (see JDO-744). One idea ist might be to switch to an Apache URL, where we can control the download sites. This change requires corresponding changes to the specification, api, and tck. Here is a proposed plan to implement: # Update the xsds and dtds in the api/resources to change the headers. # Update the xsds and dtds in the db.apache.org/jdo/xmlns with the changes. # Update the xsds and dtds in the tck with the changes. This step will fail without a corresponding change to the reference implementation. # Update the specification with the changes. A partial list of affected sections: ## 11.1.4 p. 122 ## 18.24 p. 261 ## 18.25 p. 265 ## 18.26 p. 287, 298 ## New C.23 Changes since 3.2 p. 404 Open question: should we keep the version number of the xsd and dtd files as 3.2 even though the api, tck, and specification will be updated to 3.2.1? I would say yes, and only change the version number of the files if there is a change to the content of the xsd and/or dtd. My proposal is: the 3.2.1 version of JDO would still refer to the 3.2 version of the xsd and dtd. was: In JDO 3.2 the schemaLocation of JDO XSDs link to http://xmlns.jcp.org/xml/ns/jdo/ where is one of jdo_3_2.xsd, jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that the 3.2 XSDs are available under this URL (see JDO-744). One idea ist might be to switch to an Apache URL, where we can control the download sites. > Use apache URL for schemaLocation of JDO XSDs > - > > Key: JDO-806 > URL: https://issues.apache.org/jira/browse/JDO-806 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > In JDO 3.2 the schemaLocation of JDO XSDs link to > [http://xmlns.jcp.org/xml/ns/jdo/] where is one of jdo_3_2.xsd, > jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site > [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that > the 3.2 XSDs are available under this URL (see JDO-744). > One idea ist might be to switch to an Apache URL, where we can control the > download sites. > This change requires corresponding changes to the specification, api, and > tck. Here is a proposed plan to implement: > # Update the xsds and dtds in the api/resources to change the headers. > # Update the xsds and dtds in the db.apache.org/jdo/xmlns with the changes. > # Update the xsds and dtds in the tck with the changes. This step will fail > without a corresponding change to the reference implementation. > # Update the specification with the changes. A partial list of affected > sections: > ## 11.1.4 p. 122 > ## 18.24 p. 261 > ## 18.25 p. 265 > ## 18.26 p. 287, 298 > ## New C.23 Changes since 3.2 p. 404 > Open question: should we keep the version number of the xsd and dtd files as > 3.2 even though the api, tck, and specification will be updated to 3.2.1? I > would say yes, and only change the version number of the files if there is a > change to the content of the xsd and/or dtd. > My proposal is: the 3.2.1 version of JDO would still refer to the 3.2 version > of the xsd and dtd. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-807) Update schema descriptor of JDO Metadata file to use latest 3.2 xsd definition
[ https://issues.apache.org/jira/browse/JDO-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512128#comment-17512128 ] Craig L Russell commented on JDO-807: - Updating the sources to refer to jcp.org with the latest revision 3.2 seems to be a good idea. But since the speciation, api, and tck all need to be updated to be consistent using the new name space, i think we need to use a different JIRA JDO-806 to coordinate these. > Update schema descriptor of JDO Metadata file to use latest 3.2 xsd definition > -- > > Key: JDO-807 > URL: https://issues.apache.org/jira/browse/JDO-807 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > Most of the JDO metadata files (.jdo, .jdoquery, .orm) use the 3.0 schema > descrpitor: > http://java.sun.com/xml/ns/jdo/jdo; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://java.sun.com/xml/ns/jdo/jdo > [http://java.sun.com/xml/ns/jdo/jdo_3_0.xsd];> > This should be updated to use the 3.2 version: > .jdo-files: > http://xmlns.jcp.org/xml/ns/jdo/jdo; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/jdo > [http://xmlns.jcp.org/xml/ns/jdo/jdo_3_2.xsd];> > .orm-files: > http://xmlns.jcp.org/xml/ns/jdo/orm; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/orm > [http://xmlns.jcp.org/xml/ns/jdo/orm_3_2.xsd];> > .jdoquery-files > http://xmlns.jcp.org/xml/ns/jdo/jdoquery; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/jdoquery > [http://xmlns.jcp.org/xml/ns/jdo/jdoquery_3_2.xsd];> -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[ https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512123#comment-17512123 ] Craig L Russell commented on JDO-806: - There is already a fairly extensive set of documentation on the jdo web site regarding metadata. The pages associated with [https://db.apache.org/jdo/metadata.html] should be updated with links to the metadata descriptions. The specification also contains many references to the dtd and xsd which need to be updated. I now think that we should update the web site, specification, api, and tck together in the next revision of jdo: 3.2.1. > Use apache URL for schemaLocation of JDO XSDs > - > > Key: JDO-806 > URL: https://issues.apache.org/jira/browse/JDO-806 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > In JDO 3.2 the schemaLocation of JDO XSDs link to > http://xmlns.jcp.org/xml/ns/jdo/ where is one of jdo_3_2.xsd, > jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site > [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that > the 3.2 XSDs are available under this URL (see JDO-744). > One idea ist might be to switch to an Apache URL, where we can control the > download sites. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[ https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512118#comment-17512118 ] Craig L Russell commented on JDO-806: - The location for the source xsd and dtd files is now in the git repository db-jdo-site/src/main/resources/other/xmlns the contents of the directory are published to [db.apache.org/jdo/xmlns|http://db.apache.org/jdo/xmlns] It would be cleaner if the source were in db-jdo-site/src/main/resources/xmlns The files also need their headers updated from: to: https://db.apache.org/jdo/xmlns/jdo_3_2.dtd;> --> > Use apache URL for schemaLocation of JDO XSDs > - > > Key: JDO-806 > URL: https://issues.apache.org/jira/browse/JDO-806 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > In JDO 3.2 the schemaLocation of JDO XSDs link to > http://xmlns.jcp.org/xml/ns/jdo/ where is one of jdo_3_2.xsd, > jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site > [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that > the 3.2 XSDs are available under this URL (see JDO-744). > One idea ist might be to switch to an Apache URL, where we can control the > download sites. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[ https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17497695#comment-17497695 ] Craig L Russell commented on JDO-806: - Proposal: use [https://db.apache.org/jdo/xmlns|https://db.apache.org/jdo/xmlns/jdo_3_2.xsd] as the location for both dtds and xsds. > Use apache URL for schemaLocation of JDO XSDs > - > > Key: JDO-806 > URL: https://issues.apache.org/jira/browse/JDO-806 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > In JDO 3.2 the schemaLocation of JDO XSDs link to > http://xmlns.jcp.org/xml/ns/jdo/ where is one of jdo_3_2.xsd, > jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site > [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that > the 3.2 XSDs are available under this URL (see JDO-744). > One idea ist might be to switch to an Apache URL, where we can control the > download sites. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (JDO-744) XSD/DTD not published for JDO 3.1
[ https://issues.apache.org/jira/browse/JDO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell closed JDO-744. --- Fix Version/s: (was: JDO 3.2) Resolution: Won't Fix The jcp.org url has not been maintained since 2013 and there is no path to get JDO xsd and dtd schema onto it. The proposed solution is to provide JDO project URLs instead of these. > XSD/DTD not published for JDO 3.1 > - > > Key: JDO-744 > URL: https://issues.apache.org/jira/browse/JDO-744 > Project: JDO > Issue Type: Bug > Components: api >Affects Versions: JDO 3.1 >Reporter: Andy Jefferson >Assignee: Craig L Russell >Priority: Major > > Should be on > http://xmlns.jcp.org/xml/ns/jdo/jdo_3_1.xsd > http://xmlns.jcp.org/dtd/jdo_3_1.dtd > No idea how they are to get on that private server. Perhaps someone knows? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[ https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491450#comment-17491450 ] Craig L Russell commented on JDO-806: - We could use something like [https://db.apache.org/jdo/xmlns/jdo_3_2.xsd] There is no default rendering of xsd or dtd files in browsers, but a program should be able to handle them and we should be able to figure out how to publish them. In any event, the JDO Implementation will cache the known files locally so it doesn't have to load them except possibly at workspace startup, if then. > Use apache URL for schemaLocation of JDO XSDs > - > > Key: JDO-806 > URL: https://issues.apache.org/jira/browse/JDO-806 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > > In JDO 3.2 the schemaLocation of JDO XSDs link to > http://xmlns.jcp.org/xml/ns/jdo/ where is one of jdo_3_2.xsd, > jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site > [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that > the 3.2 XSDs are available under this URL (see JDO-744). > One idea ist might be to switch to an Apache URL, where we can control the > download sites. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Deleted] (JDO-802) Serup
[ https://issues.apache.org/jira/browse/JDO-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell deleted JDO-802: > Serup > - > > Key: JDO-802 > URL: https://issues.apache.org/jira/browse/JDO-802 > Project: JDO > Issue Type: Bug >Reporter: Mina Gendy >Priority: Major > Labels: AZURE, Debian, documentation, github-import, s > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Deleted] (JDO-803) api
[ https://issues.apache.org/jira/browse/JDO-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell deleted JDO-803: > api > --- > > Key: JDO-803 > URL: https://issues.apache.org/jira/browse/JDO-803 > Project: JDO > Issue Type: Sub-task >Reporter: Mina Gendy >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Deleted] (JDO-804) identifier
[ https://issues.apache.org/jira/browse/JDO-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell deleted JDO-804: > identifier > --- > > Key: JDO-804 > URL: https://issues.apache.org/jira/browse/JDO-804 > Project: JDO > Issue Type: Sub-task >Reporter: Mina Gendy >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Deleted] (JDO-801) Mgb
[ https://issues.apache.org/jira/browse/JDO-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell deleted JDO-801: > Mgb > --- > > Key: JDO-801 > URL: https://issues.apache.org/jira/browse/JDO-801 > Project: JDO > Issue Type: New Feature >Reporter: Mina Gendy >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JDO-795) Publishing the 3.2 specification
[ https://issues.apache.org/jira/browse/JDO-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-795: Description: * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to AppF-RevisionHistory.odt (done) * Added missing paragraphs about if-else expressions in JDOQL to Ch14-Query.odt (done) The following files still have change bars: (done) * AppG-XML_Schema_jdoconfig.odt * AppH-XML_Schema_jdo.odt * AppI-XML_Schema_jdoqlquery.odt * AppJ-XML_Schema_orm.odt * Ch05-LifeCycle.odt * Ch14-Query.odt (from the changes above) In Ch06 Figure 15 is missing. Change the header: Java Data Objects 3.1 -> Java Data Objects 3.2 Change the footer: March 20, 2015 -> to the JDO 3.2 date (?) - open ⌛ - in progress (/) - done (!) - removed ||Chapter||Status||Worked on by|| | 01 – Introduction|(/)| [~clr]| | 02 – Overview|(/)| [~clr]| | 03 – JDO Architecture|(/)| [~clr]| | 04 – Roles and Scenarios|(/)| [~clr]| | 05 – Life Cycle of JDO Instances|(/)| [~clr]| | 06 – The Persistent Object Model|(/)| [~tilmann]| | 07 – PersistenceCapable|(/)| [~tilmann]| | 08 – JDOHelper|(/)| [~tilmann]| | 09 – InstanceCallable|(/)| [~tilmann]| | 10 – InstanceCallbacks|(/)| [~tilmann]| | 11 – PersistenceManagerFactory|(/)| [~tilmann]| | 12 – PersistenceManager|(/)| [~tilmann]| | 13 – Transactions and Connections|(/)| [~tilmann]| | 14 – Query|(/)| [~mbo] | | 15 – Object-Relational Mapping|(/)| [~tilmann]| | 16 – Enterprise Java Beans|(/)| [~tilmann]| | 17 – JDO Exceptions|(/)| [~tilmann]| | 18 – XML Metadata |(/)| [~mbo] | | 19 – Annotations and Metadata API|(/)| [~mbo]| | 20 – Java Persistence API (JSTs 220, 317) Alignment|(/)| [~mbo]| | 21 – Extent|(/)| [~mbo] | | 22 – Portability Guidelines|(/)| [~mbo]| | 23 – JDO Reference Enhancer|(!)| [~tilmann]| | 24 – Interface StateManager|(/)| [~mbo]| | 25 – JDOPermissions|(!)| [~tilmann]| | A – References|(?)| | | B – JDOQL BNF|(/)| [~mbo]| | C – Items Deferred to the Next Release|(!)| | | D – JDO 1.0.1 Metadata|(!)| | | E – Design Decisions|(!)| | | F – Revision History -> C – Revision History|(/)| [~mbo] | | G – XML Schema for jdoconfig.xml -> D – XML Schema for jdoconfig.xml|(?)| | | H – XML Schema for jdo.xml -> E – XML Schema for jdo.xml|(?)| | | I – XML Schema for jdoquery.xml -> F – XML Schema for jdoquery.xml|(?)| | | J – XML Schema for orm.xml -> G – XML Schema for orm.xml|(?)| | | K – Standard Option and Property Names -> H – Standard Option and Property Names|(/)| [~mbo]| |Index|(?)| | was: * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to AppF-RevisionHistory.odt (done) * Added missing paragraphs about if-else expressions in JDOQL to Ch14-Query.odt (done) The following files still have change bars: (done) * AppG-XML_Schema_jdoconfig.odt * AppH-XML_Schema_jdo.odt * AppI-XML_Schema_jdoqlquery.odt * AppJ-XML_Schema_orm.odt * Ch05-LifeCycle.odt * Ch14-Query.odt (from the changes above) In Ch06 Figure 15 is missing. Change the header: Java Data Objects 3.1 -> Java Data Objects 3.2 Change the footer: March 20, 2015 -> to the JDO 3.2 date (?) - open ⌛ - in progress (/) - done (!) - removed ||Chapter||Status||Worked on by|| | 01 – Introduction|(/)| [~clr]| | 02 – Overview|(/)| [~clr]| | 03 – JDO Architecture|(/)| [~clr]| | 04 – Roles and Scenarios|(/)| [~clr]| | 05 – Life Cycle of JDO Instances|(/)| [~clr]| | 06 – The Persistent Object Model|(/)| [~tilmann]| | 07 – PersistenceCapable|(/)| [~tilmann]| | 08 – JDOHelper|(/)| [~tilmann]| | 09 – InstanceCallable|(/)| [~tilmann]| | 10 – InstanceCallbacks|(/)| [~tilmann]| | 11 – PersistenceManagerFactory|(/)| [~tilmann]| | 12 – PersistenceManager|(/)| [~tilmann]| | 13 – Transactions and Connections|(/)| [~tilmann]| | 14 – Query|(/)| [~mbo] | | 15 – Object-Relational Mapping|(/)| [~tilmann]| | 16 – Enterprise Java Beans|(/)| [~tilmann]| | 17 – JDO Exceptions|(/)| [~tilmann]| | 18 – XML Metadata |(/)| [~mbo] | | 19 – Annotations and Metadata API|(/)| [~mbo]| | 20 – Java Persistence API (JSTs 220, 317) Alignment|(/)| [~mbo]| | 21 – Extent|(/)| [~mbo] | | 22 – Portability Guidelines|(/)| [~mbo]| | 23 – JDO Reference Enhancer|(!)| [~tilmann]| | 24 – Interface StateManager|(/)| [~mbo]| | 25 – JDOPermissions|(!)| [~tilmann]| | A – References|(?)| | | B – JDOQL BNF|(/)| [~mbo]| | C – Items Deferred to the Next Release|(!)| | | D – JDO 1.0.1 Metadata|(!)| | | E – Design Decisions|(!)| | | F – Revision History -> C – Revision History|(?)| | | G – XML Schema for jdoconfig.xml -> D – XML Schema for jdoconfig.xml|(?)| | | H – XML Schema for jdo.xml -> E – XML Schema for jdo.xml|(?)| | | I – XML Schema for jdoquery.xml -> F – XML Schema for jdoquery.xml|(?)| | | J – XML Schema for orm.xml -> G – XML Schema for orm.xml|(?)| | | K – Standard Option and Property Names -> H – Standard Option and Property Names|(/)| [~mbo]| |Index|(?)| | > Publishing the 3.2 specification >
[jira] [Updated] (JDO-795) Publishing the 3.2 specification
[ https://issues.apache.org/jira/browse/JDO-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-795: Description: * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to AppF-RevisionHistory.odt (done) * Added missing paragraphs about if-else expressions in JDOQL to Ch14-Query.odt (done) The following files still have change bars: (done) * AppG-XML_Schema_jdoconfig.odt * AppH-XML_Schema_jdo.odt * AppI-XML_Schema_jdoqlquery.odt * AppJ-XML_Schema_orm.odt * Ch05-LifeCycle.odt * Ch14-Query.odt (from the changes above) In Ch06 Figure 15 is missing. Change the header: Java Data Objects 3.1 -> Java Data Objects 3.2 Change the footer: March 20, 2015 -> to the JDO 3.2 date (?) - open ⌛ - in progress (/) - done (!) - removed ||Chapter||Status||Worked on by|| | 01 – Introduction|(/)| [~clr]| | 02 – Overview|(/)| [~clr]| | 03 – JDO Architecture|(/)| [~clr]| | 04 – Roles and Scenarios|(/)| [~clr]| | 05 – Life Cycle of JDO Instances|(/)| [~clr]| | 06 – The Persistent Object Model|(/)| [~tilmann]| | 07 – PersistenceCapable|(/)| [~tilmann]| | 08 – JDOHelper|(/)| [~tilmann]| | 09 – InstanceCallable|(/)| [~tilmann]| | 10 – InstanceCallbacks|(/)| [~tilmann]| | 11 – PersistenceManagerFactory|(/)| [~tilmann]| | 12 – PersistenceManager|(/)| [~tilmann]| | 13 – Transactions and Connections|(/)| [~tilmann]| | 14 – Query|(/)| [~mbo] | | 15 – Object-Relational Mapping|(/)| [~tilmann]| | 16 – Enterprise Java Beans|(/)| [~tilmann]| | 17 – JDO Exceptions|(/)| [~tilmann]| | 18 – XML Metadata |(/)| [~mbo] | | 19 – Annotations and Metadata API|(/)| [~mbo]| | 20 – Java Persistence API (JSTs 220, 317) Alignment|(/)| [~mbo]| | 21 – Extent|(/)| [~mbo] | | 22 – Portability Guidelines|(/)| [~mbo]| | 23 – JDO Reference Enhancer|(!)| [~tilmann]| | 24 – Interface StateManager|(/)| [~mbo]| | 25 – JDOPermissions|(!)| [~tilmann]| | A – References|(?)| | | B – JDOQL BNF|(/)| [~mbo]| | C – Items Deferred to the Next Release|(!)| | | D – JDO 1.0.1 Metadata|(!)| | | E – Design Decisions|(!)| | | F – Revision History -> C – Revision History|(?)| | | G – XML Schema for jdoconfig.xml -> D – XML Schema for jdoconfig.xml|(?)| | | H – XML Schema for jdo.xml -> E – XML Schema for jdo.xml|(?)| | | I – XML Schema for jdoquery.xml -> F – XML Schema for jdoquery.xml|(?)| | | J – XML Schema for orm.xml -> G – XML Schema for orm.xml|(?)| | | K – Standard Option and Property Names -> H – Standard Option and Property Names|(/)| [~mbo]| |Index|(?)| | was: * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to AppF-RevisionHistory.odt (done) * Added missing paragraphs about if-else expressions in JDOQL to Ch14-Query.odt (done) The following files still have change bars: (done) * AppG-XML_Schema_jdoconfig.odt * AppH-XML_Schema_jdo.odt * AppI-XML_Schema_jdoqlquery.odt * AppJ-XML_Schema_orm.odt * Ch05-LifeCycle.odt * Ch14-Query.odt (from the changes above) In Ch06 Figure 15 is missing. Change the header: Java Data Objects 3.1 -> Java Data Objects 3.2 Change the footer: March 20, 2015 -> to the JDO 3.2 date (?) - open ⌛ - in progress (/) - done (!) - removed ||Chapter||Status||Worked on by|| | 01 – Introduction|(/)| [~clr]| | 02 – Overview|(/)| [~clr]| | 03 – JDO Architecture|(/)| [~clr]| | 04 – Roles and Scenarios|(/)| [~clr]| | 05 – Life Cyle of JDO Instances|⌛| [~clr]| | 06 – The Persistent Object Model|(/)| [~tilmann]| | 07 – PersistenceCapable|(/)| [~tilmann]| | 08 – JDOHelper|(/)| [~tilmann]| | 09 – InstanceCallable|(/)| [~tilmann]| | 10 – InstanceCallbacks|(/)| [~tilmann]| | 11 – PersistenceManagerFactory|(/)| [~tilmann]| | 12 – PersistenceManager|(/)| [~tilmann]| | 13 – Transactions and Connections|(/)| [~tilmann]| | 14 – Query|(/)| [~mbo] | | 15 – Object-Relational Mapping|(/)| [~tilmann]| | 16 – Enterprise Java Beans|(/)| [~tilmann]| | 17 – JDO Exceptions|(/)| [~tilmann]| | 18 – XML Metadata |(/)| [~mbo] | | 19 – Annotations and Metadata API|(/)| [~mbo]| | 20 – Java Persistence API (JSTs 220, 317) Alignment|(/)| [~mbo]| | 21 – Extent|(/)| [~mbo] | | 22 – Portability Guidelines|(/)| [~mbo]| | 23 – JDO Reference Enhancer|(!)| [~tilmann]| | 24 – Interface StateManager|(/)| [~mbo]| | 25 – JDOPermissions|(!) | [~tilmann]| | A – References|(?)| | | B – JDOQL BNF|(/)| [~mbo]| | C – Items Deferred to the Next Release|(!)| | | D – JDO 1.0.1 Metadata|(!)| | | E – Design Decisions|(!)| | | F – Revision History -> C – Revision History|(?)| | | G – XML Schema for jdoconfig.xml -> D – XML Schema for jdoconfig.xml|(?)| | | H – XML Schema for jdo.xml -> E – XML Schema for jdo.xml|(?)| | | I – XML Schema for jdoquery.xml -> F – XML Schema for jdoquery.xml|(?)| | | J – XML Schema for orm.xml -> G – XML Schema for orm.xml|(?)| | | K – Standard Option and Property Names -> H – Standard Option and Property Names|(/)| [~mbo]| |Index|(?)| | > Publishing the 3.2 specification >
[jira] [Updated] (JDO-795) Publishing the 3.2 specification
[ https://issues.apache.org/jira/browse/JDO-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-795: Description: * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to AppF-RevisionHistory.odt (done) * Added missing paragraphs about if-else expressions in JDOQL to Ch14-Query.odt (done) The following files still have change bars: (done) * AppG-XML_Schema_jdoconfig.odt * AppH-XML_Schema_jdo.odt * AppI-XML_Schema_jdoqlquery.odt * AppJ-XML_Schema_orm.odt * Ch05-LifeCycle.odt * Ch14-Query.odt (from the changes above) In Ch06 Figure 15 is missing. Change the header: Java Data Objects 3.1 -> Java Data Objects 3.2 Change the footer: March 20, 2015 -> to the JDO 3.2 date (?) - open ⌛ - in progress (/) - done ||Chapter||Status||Worked on by|| | 01 – Introduction|(/)| [~clr]| | 02 – Overview|(/)| [~clr]| | 03 – JDO Architecture|(/)| [~clr]| | 04 – Roles and Scenarios|(/)| [~clr]| | 05 – Life Cyle of JDO Instances| ⌛| [~clr]| | 06 – The Persistent Object Model| ⌛| [~tilmann]| | 07 – PersistenceCapable| ⌛| [~tilmann]| | 08 – JDOHelper| ⌛| [~tilmann]| | 09 – InstanceCallable| ⌛| [~tilmann]| | 10 – InstanceCallbacks| ⌛| [~tilmann]| | 11 – PersistenceManagerFactory| (?)| | | 12 – PersistenceManager| (?)| | | 13 – Transactions and Connections| (?)| | | 14 – Query| ⌛| [~mbo] | | 15 – Object-Relational Mapping| (?)| | | 16 – Enterprise Java Beans| (?)| | | 17 – JDO Exceptions| (?)| | | 18 – XML Metadata | (?)| | | 19 – Annotations and Metadata API| (?)| | | 20 – Java Persistence API (JSTs 220, 317) Alignment| (?)| | | 21 – Extent| (?)| | | 22 – Portability Guidelines| (?)| | | 23 – JDO Reference Enhancer| (?)| | | 24 – Interface StateManager| (?) | | | 25 – JDOPermissions| (?) | | | A – References| (?)| | | B – JDOQL BNF| (?)| | | C – Items Deferred to the Next Release| (?)| | | D – JDO 1.0.1 Metadata| (?)| | | E – Design Decisions| (?)| | | F – Revision History| (?)| | | G – XML Schema for jdoconfig.xml| (?)| | | H – XML Schema for jdo.xml| (?)| | | I – XML Schema for jdoquery.xml| (?)| | | J – XML Schema for orm.xml| (?)| | | K – Standard Option and Property Names| (?)| | |Index| (?)| | was: * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to AppF-RevisionHistory.odt (done) * Added missing paragraphs about if-else expressions in JDOQL to Ch14-Query.odt (done) The following files still have change bars: (done) * AppG-XML_Schema_jdoconfig.odt * AppH-XML_Schema_jdo.odt * AppI-XML_Schema_jdoqlquery.odt * AppJ-XML_Schema_orm.odt * Ch05-LifeCycle.odt * Ch14-Query.odt (from the changes above) In Ch06 Figure 15 is missing. Change the header: Java Data Objects 3.1 -> Java Data Objects 3.2 Change the footer: March 20, 2015 -> to the JDO 3.2 date (?) - open ⌛ - in progress (/) - done ||Chapter||Status||Worked on by|| | 01 – Introduction|(/)| [~clr]| | 02 – Overview| ⌛| [~clr]| | 03 – JDO Architecture| ⌛| [~clr]| | 04 – Roles and Scenarios| ⌛| [~clr]| | 05 – Life Cyle of JDO Instances| ⌛| [~clr]| | 06 – The Persistent Object Model| ⌛| [~tilmann]| | 07 – PersistenceCapable| ⌛| [~tilmann]| | 08 – JDOHelper| ⌛| [~tilmann]| | 09 – InstanceCallable| ⌛| [~tilmann]| | 10 – InstanceCallbacks| ⌛| [~tilmann]| | 11 – PersistenceManagerFactory| (?)| | | 12 – PersistenceManager| (?)| | | 13 – Transactions and Connections| (?)| | | 14 – Query| ⌛| [~mbo] | | 15 – Object-Relational Mapping| (?)| | | 16 – Enterprise Java Beans| (?)| | | 17 – JDO Exceptions| (?)| | | 18 – XML Metadata | (?)| | | 19 – Annotations and Metadata API| (?)| | | 20 – Java Persistence API (JSTs 220, 317) Alignment| (?)| | | 21 – Extent| (?)| | | 22 – Portability Guidelines| (?)| | | 23 – JDO Reference Enhancer| (?)| | | 24 – Interface StateManager| (?) | | | 25 – JDOPermissions| (?) | | | A – References| (?)| | | B – JDOQL BNF| (?)| | | C – Items Deferred to the Next Release| (?)| | | D – JDO 1.0.1 Metadata| (?)| | | E – Design Decisions| (?)| | | F – Revision History| (?)| | | G – XML Schema for jdoconfig.xml| (?)| | | H – XML Schema for jdo.xml| (?)| | | I – XML Schema for jdoquery.xml| (?)| | | J – XML Schema for orm.xml| (?)| | | K – Standard Option and Property Names| (?)| | |Index| (?)| | > Publishing the 3.2 specification > > > Key: JDO-795 > URL: https://issues.apache.org/jira/browse/JDO-795 > Project: JDO > Issue Type: Task > Components: specification >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > > * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to > AppF-RevisionHistory.odt (done) > * Added missing paragraphs about if-else expressions in JDOQL to > Ch14-Query.odt (done) > The following files still have change bars: (done) > * AppG-XML_Schema_jdoconfig.odt > * AppH-XML_Schema_jdo.odt > *
[jira] [Updated] (JDO-795) Publishing the 3.2 specification
[ https://issues.apache.org/jira/browse/JDO-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-795: Description: * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to AppF-RevisionHistory.odt (done) * Added missing paragraphs about if-else expressions in JDOQL to Ch14-Query.odt (done) The following files still have change bars: (done) * AppG-XML_Schema_jdoconfig.odt * AppH-XML_Schema_jdo.odt * AppI-XML_Schema_jdoqlquery.odt * AppJ-XML_Schema_orm.odt * Ch05-LifeCycle.odt * Ch14-Query.odt (from the changes above) In Ch06 Figure 15 is missing. Change the header: Java Data Objects 3.1 -> Java Data Objects 3.2 Change the footer: March 20, 2015 -> to the JDO 3.2 date (?) - open ⌛ - in progress (/) - done ||Chapter||Status||Worked on by|| | 01 – Introduction|(/)| [~clr]| | 02 – Overview| ⌛| [~clr]| | 03 – JDO Architecture| ⌛| [~clr]| | 04 – Roles and Scenarios| ⌛| [~clr]| | 05 – Life Cyle of JDO Instances| ⌛| [~clr]| | 06 – The Persistent Object Model| ⌛| [~tilmann]| | 07 – PersistenceCapable| ⌛| [~tilmann]| | 08 – JDOHelper| ⌛| [~tilmann]| | 09 – InstanceCallable| ⌛| [~tilmann]| | 10 – InstanceCallbacks| ⌛| [~tilmann]| | 11 – PersistenceManagerFactory| (?)| | | 12 – PersistenceManager| (?)| | | 13 – Transactions and Connections| (?)| | | 14 – Query| ⌛| [~mbo] | | 15 – Object-Relational Mapping| (?)| | | 16 – Enterprise Java Beans| (?)| | | 17 – JDO Exceptions| (?)| | | 18 – XML Metadata | (?)| | | 19 – Annotations and Metadata API| (?)| | | 20 – Java Persistence API (JSTs 220, 317) Alignment| (?)| | | 21 – Extent| (?)| | | 22 – Portability Guidelines| (?)| | | 23 – JDO Reference Enhancer| (?)| | | 24 – Interface StateManager| (?) | | | 25 – JDOPermissions| (?) | | | A – References| (?)| | | B – JDOQL BNF| (?)| | | C – Items Deferred to the Next Release| (?)| | | D – JDO 1.0.1 Metadata| (?)| | | E – Design Decisions| (?)| | | F – Revision History| (?)| | | G – XML Schema for jdoconfig.xml| (?)| | | H – XML Schema for jdo.xml| (?)| | | I – XML Schema for jdoquery.xml| (?)| | | J – XML Schema for orm.xml| (?)| | | K – Standard Option and Property Names| (?)| | |Index| (?)| | was: * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to AppF-RevisionHistory.odt (done) * Added missing paragraphs about if-else expressions in JDOQL to Ch14-Query.odt (done) The following files still have change bars: (done) * AppG-XML_Schema_jdoconfig.odt * AppH-XML_Schema_jdo.odt * AppI-XML_Schema_jdoqlquery.odt * AppJ-XML_Schema_orm.odt * Ch05-LifeCycle.odt * Ch14-Query.odt (from the changes above) In Ch06 Figure 15 is missing. Change the header: Java Data Objects 3.1 -> Java Data Objects 3.2 Change the footer: March 20, 2015 -> to the JDO 3.2 date (?) - open ⌛ - in progress (/) - done ||Chapter||Status||Worked on by|| | 01 – Introduction| ⌛| [~clr]| | 02 – Overview| ⌛| [~clr]| | 03 – JDO Architecture| ⌛| [~clr]| | 04 – Roles and Scenarios| ⌛| [~clr]| | 05 – Life Cyle of JDO Instances| ⌛| [~clr]| | 06 – The Persistent Object Model| ⌛| [~tilmann]| | 07 – PersistenceCapable| ⌛| [~tilmann]| | 08 – JDOHelper| ⌛| [~tilmann]| | 09 – InstanceCallable| ⌛| [~tilmann]| | 10 – InstanceCallbacks| ⌛| [~tilmann]| | 11 – PersistenceManagerFactory| (?)| | | 12 – PersistenceManager| (?)| | | 13 – Transactions and Connections| (?)| | | 14 – Query| ⌛| [~mbo] | | 15 – Object-Relational Mapping| (?)| | | 16 – Enterprise Java Beans| (?)| | | 17 – JDO Exceptions| (?)| | | 18 – XML Metadata | (?)| | | 19 – Annotations and Metadata API| (?)| | | 20 – Java Persistence API (JSTs 220, 317) Alignment| (?)| | | 21 – Extent| (?)| | | 22 – Portability Guidelines| (?)| | | 23 – JDO Reference Enhancer| (?)| | | 24 – Interface StateManager| (?) | | | 25 – JDOPermissions| (?) | | | A – References| (?)| | | B – JDOQL BNF| (?)| | | C – Items Deferred to the Next Release| (?)| | | D – JDO 1.0.1 Metadata| (?)| | | E – Design Decisions| (?)| | | F – Revision History| (?)| | | G – XML Schema for jdoconfig.xml| (?)| | | H – XML Schema for jdo.xml| (?)| | | I – XML Schema for jdoquery.xml| (?)| | | J – XML Schema for orm.xml| (?)| | | K – Standard Option and Property Names| (?)| | |Index| (?)| | > Publishing the 3.2 specification > > > Key: JDO-795 > URL: https://issues.apache.org/jira/browse/JDO-795 > Project: JDO > Issue Type: Task > Components: specification >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > > * Added A.21 Changes for 3.1 and A.22 Changes for 3.2 to > AppF-RevisionHistory.odt (done) > * Added missing paragraphs about if-else expressions in JDOQL to > Ch14-Query.odt (done) > The following files still have change bars: (done) > * AppG-XML_Schema_jdoconfig.odt > * AppH-XML_Schema_jdo.odt > *
[jira] [Resolved] (JDO-793) Decide whether to rename the 'master' branch to 'main'
[
https://issues.apache.org/jira/browse/JDO-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell resolved JDO-793.
-
Resolution: Fixed
> Decide whether to rename the 'master' branch to 'main'
> --
>
> Key: JDO-793
> URL: https://issues.apache.org/jira/browse/JDO-793
> Project: JDO
> Issue Type: Task
> Components: site and infrastructure
>Reporter: Tobias Bouschen
>Priority: Minor
> Fix For: JDO 3.2
>
>
> There still is an ongoing discussion over the use of the word 'master' in the
> context of branches in versioning systems. The most common new name is 'main'.
> If we were to change the name of the 'master' branch, the following things
> would have to be done as well:
> * (/) Adjust the references to the 'master' branch in the '.asf.yaml' files
> * (/) Adjust the references to the 'master' branch in the GitHub workflow
> files (located in '.github/workflows/')
> * Inform INFRA to change the default branch for GitHub and GitBox
> * Release instructions on how to adjust the local workspace (uses 'main' as
> the new name as an example)
> *# Rename the branch:
> {code:java}
> git branch -m master main{code}
> *# Fetch from origin:
> {code:java}
> git fetch origin{code}
> *# Set the origin for the new branch:
> {code:java}
> git branch -u origin/main main{code}
> *# Change the symbolic reference for HEAD:
> {code:java}
> git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-709. - Resolution: Fixed API, specification, implementation, and tck tests are complete. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362192#comment-17362192 ] Craig L Russell commented on JDO-709: - I've rewritten parts of Chapter 18. The slant of this chapter has been toward annotations which belong in Chapter 19. The xml specification does not have detailed descriptions of the key and value. These are described in the element, array, collection, and map elements. What follows are the proposed changes. ELEMENT converter is new; there is an extra paragraph in ELEMENT element: 6 ELEMENT converter When used with a field or property, the converter element identifies the class used with the convertible field to convert values in the field or property to and from values in the datastore. Similarly, when used with key, value, or element, it identifies the converter used to convert Map keys and values, and Collection and Array elements. The converter class must be loadable at runtime by the same class loader as the domain object. 7 ELEMENT element ... The converter attribute specifies the AttributeConverter to use for the element. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361931#comment-17361931 ] Craig L Russell commented on JDO-709: - Here's a proposed paragraph in Chapter 6 discussing Maps and Collections using converters. JDO implementations that support Maps and Collection types must support converting keys, values, and elements of supported types according to the corresponding Key, Value, or Element metadata. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361188#comment-17361188 ] Craig L Russell commented on JDO-709: - It looks like we do not need the @Target(ElementType.TYPE,...) on the @Convert annotation either. This would be useful for indicating that any use of the converted type would use the converter without a specific annotation on the field. But it is also a bit harder to figure out that a type is converted by default, and we would then need to document that behavior. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17358227#comment-17358227 ] Craig L Russell commented on JDO-709: - [~tilmannz] suggests that the term "convertible" would be clearer than "converted" when referring to the field type of a persistence-capable class. An instance of a convertible class can be constructed by converting a database value, and a database value can be constructed by converting an instance of a convertible class. This terminology change makes sense to me. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17358226#comment-17358226 ] Craig L Russell commented on JDO-709: - [~andyj] When we reviewed the metadata and annotations we found that the JDO Convert annotation differs from the JPA Convert annotation. JPA has the attribute name that is not needed if the annotation applies to a field but would be needed if the annotation applies to a class. If annotating a class, multiple Convert annotations can be used, and the attribute name is needed to tell which field is being annotated. The JDO Convert annotation doesn't have the attribute name, but it does have the multiple Converts annotation that applies to a persistent class. So it is inconsistent. To fix the inconsistency we can either remove the Converts annotation and remove the Convert applying to a class; or add the attribute name to the Convert annotation. If we add the attribute name we should probably add a test case with Converts and multiple Convert applying to multiple attributes. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343642#comment-17343642 ] Craig L Russell commented on JDO-709: - If a field is annotated with a Column annotation, it is assumed to be persistent. I believe that if a field is annotated with a Convert annotation it should be assumed to be persistent, since the only possible reason for the Convert annotation is to map values to and from the database. This should be true even if there is no Column annotation because the defaults in the Column annotation might be sufficient for the converted field. >From the proposed Chapter 18 changes: > For fields using converters, the default jdbc-type is the default jdbc-type > for the database type of the AttributeConverter for the field. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343641#comment-17343641 ] Craig L Russell commented on JDO-709: - [~andyj] > A "converted class" doesn't track changes *unless* the provider happens to > have a wrapper class for that type. There is no obligation on a JDO provider > to provide a wrapper for all possible types that a user may want to convert. I agree with this. I've removed the wording that proposed to treat converted fields as if they were fields of mutable system types. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[
https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343640#comment-17343640
]
Craig L Russell commented on JDO-709:
-
18.4.1 Element convert
The convert element identifies the converter used with the field to map values
in the class to and from values in the database. The value attribute identifies
the class that implements the AttributeConverter interface. The converter class
must be loadable at runtime by the same class loader as the domain object.
after Table 8
For fields using converters, the default jdbc-type is the default jdbc-type for
the database type of the AttributeConverter for the field.
19.1.2.1 Convert annotation
@Retention(RetentionPolicy.RUNTIME)
@Target(\{ElementType.TYPE, ElementType.METHOD, ElementType.FIELD})
@Repeatable(Converts.class)
public @interface Convert {
/**
* The \{@link AttributeConverter} to use for conversion.
* @return Converter class to use
*/
@SuppressWarnings("rawtypes")
Class value();
/**
* Whether this conversion is enabled. True by default.
* Setting this to false allows disabling conversion that was specified at PMF
level.
* @return Whether the PMF default converter is enabled
*/
boolean enabled() default true;
}
19.1.2.2 Converts annotation
@Retention(RetentionPolicy.RUNTIME)
@Target(\{ElementType.TYPE, ElementType.METHOD, ElementType.FIELD})
public @interface Converts {
/**
* The conversion specifications to be configured.
* @return Array of converters
*/
Convert[] value();
}
> Standardize field/property converters
> -
>
> Key: JDO-709
> URL: https://issues.apache.org/jira/browse/JDO-709
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Matthew T. Adams
>Assignee: Craig L Russell
>Priority: Minor
> Labels: converstion, converter, jdo, type, type-converter
> Fix For: JDO 3.2
>
> Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch
>
>
> This request is to standardize a user's ability to specify conversions of
> fields or properties of persistence-capable classes. Currently, this is left
> to vendor extensions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337682#comment-17337682 ] Craig L Russell edited comment on JDO-709 at 5/12/21, 9:30 PM: --- Here are proposed specification updates. 5.4.1 Application identity No change unless we decide to allow converted fields to be primary key fields. 6.3 Second Class Objects Second Class Objects are instances of: - immutable system classes (java.lang.Integer, java.lang.String, etc.), - JDO implementation subclasses of mutable system classes that implement the functionality of their system class (java.util.Date, java.util.HashSet, etc.) - user-defined non-persistence-capable classes that use a user-defined converter (converted classes) - persistence- capable classes. Second Class Objects of mutable system classes and persistence-capable classes track changes made to them, and notify their owning FCO that they have changed. SCO fields of converted classes are declared using metadata, either in the associated jdo metadata file or via annotation. 6.4 Field types of pc classes 6.4.3 Persistent fields Converted Types JDO implementations must support fields of user-defined types that have an associated converter that defines conversion of values between the user-defined type and a supported database type. Fields declared to have a converter default to persistent, regardless of whether the converter is declared in annotations or the xml metadata file. 14.6 Query Interface void declareParameters (String parameters); Bind the parameter statements to the query instance. This method defines the parameter types and names that will be used by a subsequent execute method. Converted types may be used as parameters. 14.6.2 Query Filter Specification Rules for constructing valid expressions follow the Java language, except for these differences: • Equality and ordering comparisons between primitives, instances of converted classes, and instances of wrapper classes are valid. • Equality and ordering comparisons between fields containing instances of converted classes use the converted values for comparison. • Arithmetic operations (addition, subtraction, multiplication, division, or modulo) on fields use the converted values as the expression terms. Methods apply to converted types. was (Author: clr): Here are proposed specification updates. 5.4.1 Application identity No change unless we decide to allow converted fields to be primary key fields. 6.3 Second Class Objects Second Class Objects are instances of: - immutable system classes (java.lang.Integer, java.lang.String, etc.), - JDO implementation subclasses of mutable system classes that implement the functionality of their system class (java.util.Date, java.util.HashSet, etc.) - user-defined non-persistence-capable classes that use a user-defined converter (converted classes) - persistence- capable classes. Second Class Objects of mutable system classes, converted classes, and persistence-capable classes track changes made to them, and notify their owning FCO that they have changed. SCO fields of converted classes are declared using metadata, either in the associated jdo metadata file or via annotation. 6.4 Field types of pc classes 6.4.3 Persistent fields Converted Types JDO implementations must support fields of user-defined types that have an associated converter that defines conversion of values between the user-defined type and a supported database type. 14.6 Query Interface void declareParameters (String parameters); Bind the parameter statements to the query instance. This method defines the parameter types and names that will be used by a subsequent execute method. Converted types may be used as parameters. 14.6.2 Query Filter Specification Rules for constructing valid expressions follow the Java language, except for these differences: • Equality and ordering comparisons between primitives, instances of converted classes, and instances of wrapper classes are valid. • Equality and ordering comparisons between instances of converted classes use the converted values for comparison. • Arithmetic operations (addition, subtraction, multiplication, division, or modulo) on fields use the converted values as the expression terms. Methods apply to converted types. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch,
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337682#comment-17337682 ] Craig L Russell commented on JDO-709: - Here are proposed specification updates. 5.4.1 Application identity No change unless we decide to allow converted fields to be primary key fields. 6.3 Second Class Objects Second Class Objects are instances of: - immutable system classes (java.lang.Integer, java.lang.String, etc.), - JDO implementation subclasses of mutable system classes that implement the functionality of their system class (java.util.Date, java.util.HashSet, etc.) - user-defined non-persistence-capable classes that use a user-defined converter (converted classes) - persistence- capable classes. Second Class Objects of mutable system classes, converted classes, and persistence-capable classes track changes made to them, and notify their owning FCO that they have changed. SCO fields of converted classes are declared using metadata, either in the associated jdo metadata file or via annotation. 6.4 Field types of pc classes 6.4.3 Persistent fields Converted Types JDO implementations must support fields of user-defined types that have an associated converter that defines conversion of values between the user-defined type and a supported database type. 14.6 Query Interface void declareParameters (String parameters); Bind the parameter statements to the query instance. This method defines the parameter types and names that will be used by a subsequent execute method. Converted types may be used as parameters. 14.6.2 Query Filter Specification Rules for constructing valid expressions follow the Java language, except for these differences: • Equality and ordering comparisons between primitives, instances of converted classes, and instances of wrapper classes are valid. • Equality and ordering comparisons between instances of converted classes use the converted values for comparison. • Arithmetic operations (addition, subtraction, multiplication, division, or modulo) on fields use the converted values as the expression terms. Methods apply to converted types. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335829#comment-17335829 ] Craig L Russell commented on JDO-709: - Great test case. For me, two questions remain: 1. should we allow fields of converted types to be used as primary keys, indexes, or optimistic concurrency fields? I can see a use for indexes but perhaps not other cases. Converting a database value that is indexed seems to be useful. Converting database primary keys has no barriers to understanding but might pose some implementation challenges. But absent a compelling use case I can understand why we might disallow it. 2. Do we need a test case for using annotation to define the converter, or are we happy with using external metadata? If we want to test annotation, that would imply another class, e.g. PCRectStringAnnotated. Same test methods but using PCRectStringAnnotated instead of PCRectString... > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331618#comment-17331618 ] Craig L Russell commented on JDO-709: - Maybe we should add a query like "where UL eq Point(1, 2)" to see if the converter can be invoked from a query. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-692) Constant string "javax.jdo.spi.PropertiesFileName" not defined in javax.jdo.Constants
[ https://issues.apache.org/jira/browse/JDO-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172585#comment-17172585 ] Craig L Russell commented on JDO-692: - Specification Chapter 11 was changed from javax.jdo.Name to javax.jdo.option.Name. > Constant string "javax.jdo.spi.PropertiesFileName" not defined in > javax.jdo.Constants > - > > Key: JDO-692 > URL: https://issues.apache.org/jira/browse/JDO-692 > Project: JDO > Issue Type: Bug > Components: api, specification >Affects Versions: JDO 3 (3.0) >Reporter: Matthew T. Adams >Assignee: Tilmann Zäschke >Priority: Minor > Fix For: JDO 3.2 > > > The JDO 3.0 specification page 103, bullet point 1 says 'the Map instance > passed to the static method will contain a property with a key of > "javax.jdo.spi.PropertiesFileName", and a value equal to the result of > calling getAbsolutePath() on the file parameter'. There is no such constant > defined in javax.jdo.Constants. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-779) Migrate JDO Homepage / Online Documentation
[ https://issues.apache.org/jira/browse/JDO-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084299#comment-17084299 ] Craig L Russell commented on JDO-779: - Infra suggests using this as a model: https://cwiki.apache.org/confluence/display/INFRA/How+Apache+Jena+migrated+from+the+CMS > Migrate JDO Homepage / Online Documentation > --- > > Key: JDO-779 > URL: https://issues.apache.org/jira/browse/JDO-779 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > > The homepage and online documentation is currently generated from xdoc (Maven > 1 doc format), located in the SVN 'site' repo. Te homepage and documentation > should be migrated to a more modern format, such as markdown, and moved to a > new repo. > Initial investigation: > * The only xdoc converter I found is > [Doxia|http://maven.apache.org/doxia/doxia-tools/doxia-converter/]. I don't > really know all the output formats, but one option may by (x)html. This maybe > useful because there exist many html to markdown converters. > * If we use 'html' as intermediate stage, it probably makes sense to > directly migrate the html version of the home page to markdown. > * There are many thml to markdown converters, such as [this PHP command line > converter|https://github.com/thephpleague/html-to-markdown]. > TODO: > # Decide on target repo and create it. Consensus appears to be to set up a > separate git repo, such as 'db-jdo-site'. Where do other projectys host their > website code? > # Decide on conversion path and target format (html -> markdown seems fine) > # Migration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JDO-781) ForeignKey constructor should be called with consistent initiallyDeferred value
[
https://issues.apache.org/jira/browse/JDO-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044794#comment-17044794
]
Craig L Russell edited comment on JDO-781 at 2/25/20 8:11 PM:
--
DataNucleus is the reference implementation for JDO. The Apache JDO project
deals with the specification, API, and TCK.
This issue is related to DataNucleus, not the JDO project. Please file a bug
report with DataNucleus.
http://www.datanucleus.org/documentation/problem_reporting.html
was (Author: clr):
This issue is related to DataNucleus, not the JDO project. Please file a bug
report with DataNucleus.
http://www.datanucleus.org/documentation/problem_reporting.html
> ForeignKey constructor should be called with consistent initiallyDeferred
> value
> ---
>
> Key: JDO-781
> URL: https://issues.apache.org/jira/browse/JDO-781
> Project: JDO
> Issue Type: Improvement
>Reporter: László Bodor
>Priority: Major
>
> https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/table/TableUtils.java#L131
> {code}
> ForeignKey fk = new ForeignKey(fieldMapping, storeMgr.getDatastoreAdapter(),
> referencedTable, true);
> {code}
> as we have reference here for the datastore adapter, initiallyDeferred=true
> parameter could be changed to:
> {code}
> storeMgr.getDatastoreAdapter().supportsOption(DatastoreAdapter.DEFERRED_CONSTRAINTS)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JDO-782) Initially deferred constraint should be removed from BaseDatastoreAdapter instead of child classes
[ https://issues.apache.org/jira/browse/JDO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044795#comment-17044795 ] Craig L Russell edited comment on JDO-782 at 2/25/20 8:11 PM: -- DataNucleus is the reference implementation for JDO. The Apache JDO project deals with the specification, API, and TCK. This issue is related to DataNucleus, not the JDO project. Please file a report with DataNucleus. [http://www.datanucleus.org/documentation/problem_reporting.html] was (Author: clr): This issue is related to DataNucleus, not the JDO project. Please file a bug report with DataNucleus. [http://www.datanucleus.org/documentation/problem_reporting.html] > Initially deferred constraint should be removed from BaseDatastoreAdapter > instead of child classes > -- > > Key: JDO-782 > URL: https://issues.apache.org/jira/browse/JDO-782 > Project: JDO > Issue Type: Improvement >Reporter: László Bodor >Priority: Major > > It seems like only Oracle supports initially deferred constraints, so it > would make sense to remove it from BaseDatastoreAdapter instead of removing > it from every single subclass, and adding it only to OracleAdapter. > My original issue was that Datanucleus generated initially deferred > constraints for MariaDB because it used BaseDatastoreAdapter. However, maybe > it makes sense to create a MariaDbAdapter (which inherits from Mysql), there > is another way to fix that (proposed above) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-781) ForeignKey constructor should be called with consistent initiallyDeferred value
[
https://issues.apache.org/jira/browse/JDO-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044794#comment-17044794
]
Craig L Russell commented on JDO-781:
-
This issue is related to DataNucleus, not the JDO project. Please file a bug
report with DataNucleus.
http://www.datanucleus.org/documentation/problem_reporting.html
> ForeignKey constructor should be called with consistent initiallyDeferred
> value
> ---
>
> Key: JDO-781
> URL: https://issues.apache.org/jira/browse/JDO-781
> Project: JDO
> Issue Type: Improvement
>Reporter: László Bodor
>Priority: Major
>
> https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/table/TableUtils.java#L131
> {code}
> ForeignKey fk = new ForeignKey(fieldMapping, storeMgr.getDatastoreAdapter(),
> referencedTable, true);
> {code}
> as we have reference here for the datastore adapter, initiallyDeferred=true
> parameter could be changed to:
> {code}
> storeMgr.getDatastoreAdapter().supportsOption(DatastoreAdapter.DEFERRED_CONSTRAINTS)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JDO-782) Initially deferred constraint should be removed from BaseDatastoreAdapter instead of child classes
[ https://issues.apache.org/jira/browse/JDO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044795#comment-17044795 ] Craig L Russell commented on JDO-782: - This issue is related to DataNucleus, not the JDO project. Please file a bug report with DataNucleus. [http://www.datanucleus.org/documentation/problem_reporting.html] > Initially deferred constraint should be removed from BaseDatastoreAdapter > instead of child classes > -- > > Key: JDO-782 > URL: https://issues.apache.org/jira/browse/JDO-782 > Project: JDO > Issue Type: Improvement >Reporter: László Bodor >Priority: Major > > It seems like only Oracle supports initially deferred constraints, so it > would make sense to remove it from BaseDatastoreAdapter instead of removing > it from every single subclass, and adding it only to OracleAdapter. > My original issue was that Datanucleus generated initially deferred > constraints for MariaDB because it used BaseDatastoreAdapter. However, maybe > it makes sense to create a MariaDbAdapter (which inherits from Mysql), there > is another way to fix that (proposed above) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-780) Potential NullPointerException in code
[
https://issues.apache.org/jira/browse/JDO-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919601#comment-16919601
]
Craig L Russell commented on JDO-780:
-
Hi Xiangzhe,
Thanks for taking the time to prepare this patch. A few comments for future
contributions.
While it is a convenient thing for IDE's to combine multiple imports from the
same package into one package.* this is not something that is done in the JDO
project. We prefer to see all of the imports, for documentation of what is
actually used in the program. I understand that many IDE's have a setting that
would allow you to *not* change these imports.
Changing white space at the same time as making a code fix does make it more
difficult to review, but it also improves the code quality overall. So please
continue this.
> Potential NullPointerException in code
> --
>
> Key: JDO-780
> URL: https://issues.apache.org/jira/browse/JDO-780
> Project: JDO
> Issue Type: Bug
> Components: tck
>Affects Versions: JDO 3.2
>Reporter: XiangzheXu
>Assignee: Michael Bouschen
>Priority: Major
> Labels: NullPointerException
> Fix For: JDO 3.2
>
> Attachments: patch-for-780.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> In class org.apache.jdo.exectck.Utilities, the method `printClasspath()`
> could throw an unexpected NullPointerException.
> The related part of that method is shown as follows.
> ```java
> public void printClasspath() {
> ClassLoader loader = ClassLoader.getSystemClassLoader();
> URL[] urls = ((URLClassLoader) loader).getURLs();
> }
> ```
> The invocation of `ClassLoader.getSystemClassLoader()` could return null in
> JDK 8, as is depicted in the Javadoc in its source code:
> @return The system ClassLoader for delegation, or
> null if none
> If that is the case, the invocation to `getURLs()` could cause a
> NullPointerException.
> Maybe we could check for null pointer here or mention the potential
> NullPointerException at the Javadoc?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904229#comment-16904229
]
Craig L Russell commented on JDO-652:
-
I'm looking at Ch14-Query.odt. Very nice.
p 35 the change around "ifgetColumnLabel" is hard to review so please check the
spacing.
p 37 "query using the query query API" query is duplicated.
p 37 to 41 we should try for consistency with the font used for java language
names (methods, interfaces, packages)
p 40 "JDOQLType query" should be {color:#00}JDOQLTypedQuery{color}
p 45 is there a missing cast for firstname to name here? "select firstname,
salary, manager as reportsTo"
Similar casts seem to be missing in several sections
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: Ch14-Query.odt, JDO-652-api-ifTheElse.txt,
> JDO-652-api-patch-Andy.txt, JDO-652-patch4.txt, typesafe.patch,
> typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834038#comment-16834038 ] Craig L Russell commented on JDO-652: - See the pull request > Provision of a typesafe refactor-friendly query capability for JDOQL > > > Key: JDO-652 > URL: https://issues.apache.org/jira/browse/JDO-652 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt, > JDO-652-patch4.txt, typesafe.patch, typesafe_manifest.patch > > > There are various querying capabilities of this type around. JPA2 has its > Criteria query API. Third party solutions like QueryDSL also exist, in its > case providing a JDOQL implementation (as well as JPQL, and HQL). We should > seriously consider introducing something along these lines in the JDO2.4 > timeframe. > There is a comparison of JPA Criteria with QueryDSL over at > http://source.mysema.com/forum/mvnforum/viewthread_thread,49 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-779) Migrate JDO Homepage / Online Documentation
[ https://issues.apache.org/jira/browse/JDO-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830447#comment-16830447 ] Craig L Russell commented on JDO-779: - The new gitbox/github repo db-jdo-site has been set up and is ready for content. > Migrate JDO Homepage / Online Documentation > --- > > Key: JDO-779 > URL: https://issues.apache.org/jira/browse/JDO-779 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > > The homepage and online documentation is currently generated from xdoc (Maven > 1 doc format), located in the SVN 'site' repo. Te homepage and documentation > should be migrated to a more modern format, such as markdown, and moved to a > new repo. > Initial investigation: > * The only xdoc converter I found is > [Doxia|http://maven.apache.org/doxia/doxia-tools/doxia-converter/]. I don't > really know all the output formats, but one option may by (x)html. This maybe > useful because there exist many html to markdown converters. > * If we use 'html' as intermediate stage, it probably makes sense to > directly migrate the html version of the home page to markdown. > * There are many thml to markdown converters, such as [this PHP command line > converter|https://github.com/thephpleague/html-to-markdown]. > TODO: > # Decide on target repo and create it. Consensus appears to be to set up a > separate git repo, such as 'db-jdo-site'. Where do other projectys host their > website code? > # Decide on conversion path and target format (html -> markdown seems fine) > # Migration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JDO-770) Switch from svn to git
[ https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-770. - Resolution: Fixed The new repository is now up and running. > Switch from svn to git > -- > > Key: JDO-770 > URL: https://issues.apache.org/jira/browse/JDO-770 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > We should consider switching from svn to git. The reason to make jdo > available via git is to remove a possible barrier to new contributors. > There are several alternatives if we decide to offer git as an alternative to > svn: > * migrating all the code to git > * creating a read-only git mirror > * creating a read-write bridge. > See [Git at Apache | https://git.apache.org/] for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-779) Migrate JDO Homepage / Online Documentation
[ https://issues.apache.org/jira/browse/JDO-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803171#comment-16803171 ] Craig L Russell commented on JDO-779: - We should use self-service to create a new gitbox repository db-jdo-site that is linked to github and contains the "current contents" of the svn repo jdo/site. We then copy some files directly like the README files and use a more current mvn plugin to generate the site from markdown and then use infra tools to publish the site. > Migrate JDO Homepage / Online Documentation > --- > > Key: JDO-779 > URL: https://issues.apache.org/jira/browse/JDO-779 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > > The homepage and online documentation is currently generated from xdoc (Maven > 1 doc format), located in the SVN 'site' repo. Te homepage and documentation > should be migrated to a more modern format, such as markdown, and moved to a > new repo. > Initial investigation: > * The only xdoc converter I found is > [Doxia|http://maven.apache.org/doxia/doxia-tools/doxia-converter/]. I don't > really know all the output formats, but one option may by (x)html. This maybe > useful because there exist many html to markdown converters. > * If we use 'html' as intermediate stage, it probably makes sense to > directly migrate the html version of the home page to markdown. > * There are many thml to markdown converters, such as [this PHP command line > converter|https://github.com/thephpleague/html-to-markdown]. > TODO: > # Decide on target repo and create it. Consensus appears to be to set up a > separate git repo, such as 'db-jdo-site'. Where do other projectys host their > website code? > # Decide on conversion path and target format (html -> markdown seems fine) > # Migration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JDO-776) Exception on Query.close()
[ https://issues.apache.org/jira/browse/JDO-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-776. - Resolution: Not A Problem To use try-with-resources the interface needs to implement AutoCloseable which throws Exception on the close() method. > Exception on Query.close() > -- > > Key: JDO-776 > URL: https://issues.apache.org/jira/browse/JDO-776 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Steve Springett >Priority: Minor > > The Query interface has an exception thrown on the close() method. This > prevents elegant use of try-with-resource and requires more complex cases > instead, such as try within try, or try-with-resource with catch. In both > cases, the code gets rather ugly when using try-with-resource. > > The closeAll() method however, does not throw an exception which allows for > simpler, more elegant code. Users should be encouraged to use modern language > constructs, but in the case of the Query interface, I prefer not to, and use > closeAll instead. > > Propose: Remove the Exception from Query.close(). If an exception is thrown > while closing it, ignore it. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-776) Exception on Query.close()
[ https://issues.apache.org/jira/browse/JDO-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780774#comment-16780774 ] Craig L Russell commented on JDO-776: - We will close this if no word from the user by next week. > Exception on Query.close() > -- > > Key: JDO-776 > URL: https://issues.apache.org/jira/browse/JDO-776 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Steve Springett >Priority: Minor > > The Query interface has an exception thrown on the close() method. This > prevents elegant use of try-with-resource and requires more complex cases > instead, such as try within try, or try-with-resource with catch. In both > cases, the code gets rather ugly when using try-with-resource. > > The closeAll() method however, does not throw an exception which allows for > simpler, more elegant code. Users should be encouraged to use modern language > constructs, but in the case of the Query interface, I prefer not to, and use > closeAll instead. > > Propose: Remove the Exception from Query.close(). If an exception is thrown > while closing it, ignore it. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-770) Switch from svn to git
[ https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774578#comment-16774578 ] Craig L Russell commented on JDO-770: - No one has admin on github except for root@. The default branch is now master. I asked on slack #asf-infra channel and they were very responsive. The url is now fixed, thanks to root@. I still need to figure out why papajdo is the committer on db-jdo. That's an old github id that I haven't used in years. > Switch from svn to git > -- > > Key: JDO-770 > URL: https://issues.apache.org/jira/browse/JDO-770 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > We should consider switching from svn to git. The reason to make jdo > available via git is to remove a possible barrier to new contributors. > There are several alternatives if we decide to offer git as an alternative to > svn: > * migrating all the code to git > * creating a read-only git mirror > * creating a read-write bridge. > See [Git at Apache | https://git.apache.org/] for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-770) Switch from svn to git
[ https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774476#comment-16774476 ] Craig L Russell commented on JDO-770: - in order to use this workspace as a known user you need to associate your apache id with your github id. default branch indeed should be master and i'm trying to get admin for everyone so we can make this change the wrong url is probably something we can change once we have admin on the workspace > Switch from svn to git > -- > > Key: JDO-770 > URL: https://issues.apache.org/jira/browse/JDO-770 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > We should consider switching from svn to git. The reason to make jdo > available via git is to remove a possible barrier to new contributors. > There are several alternatives if we decide to offer git as an alternative to > svn: > * migrating all the code to git > * creating a read-only git mirror > * creating a read-write bridge. > See [Git at Apache | https://git.apache.org/] for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-776) Exception on Query.close()
[ https://issues.apache.org/jira/browse/JDO-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16768600#comment-16768600 ] Craig L Russell commented on JDO-776: - Removing the throws clause from Query.close() would not do anything useful, since Query interface implements AutoCloseable which declares a close() method that throws Exception. > Exception on Query.close() > -- > > Key: JDO-776 > URL: https://issues.apache.org/jira/browse/JDO-776 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Steve Springett >Priority: Minor > > The Query interface has an exception thrown on the close() method. This > prevents elegant use of try-with-resource and requires more complex cases > instead, such as try within try, or try-with-resource with catch. In both > cases, the code gets rather ugly when using try-with-resource. > > The closeAll() method however, does not throw an exception which allows for > simpler, more elegant code. Users should be encouraged to use modern language > constructs, but in the case of the Query interface, I prefer not to, and use > closeAll instead. > > Propose: Remove the Exception from Query.close(). If an exception is thrown > while closing it, ignore it. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-776) Exception on Query.close()
[ https://issues.apache.org/jira/browse/JDO-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762045#comment-16762045 ] Craig L Russell commented on JDO-776: - The close() method on Query was added specifically in JDO 3.2 to be useful with try-with-resources with no catch clause. Semantically it is identical to closeAll(). JDO 3.1 does not include the close() method, to avoid confusion. The close(queryResult) method does not close the Query but closes a single result. The closeAll() method closes all results and then the Query object itself. Can you provide a simple test case that shows the error you are seeing? > Exception on Query.close() > -- > > Key: JDO-776 > URL: https://issues.apache.org/jira/browse/JDO-776 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Steve Springett >Priority: Minor > > The Query interface has an exception thrown on the close() method. This > prevents elegant use of try-with-resource and requires more complex cases > instead, such as try within try, or try-with-resource with catch. In both > cases, the code gets rather ugly when using try-with-resource. > > The closeAll() method however, does not throw an exception which allows for > simpler, more elegant code. Users should be encouraged to use modern language > constructs, but in the case of the Query interface, I prefer not to, and use > closeAll instead. > > Propose: Remove the Exception from Query.close(). If an exception is thrown > while closing it, ignore it. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-775) maven profiles to get the JDORI or IUT into the class path for both compile and exectck
[ https://issues.apache.org/jira/browse/JDO-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729841#comment-16729841 ] Craig L Russell commented on JDO-775: - Looks good. We can review in detail later but ok to check in. > maven profiles to get the JDORI or IUT into the class path for both compile > and exectck > --- > > Key: JDO-775 > URL: https://issues.apache.org/jira/browse/JDO-775 > Project: JDO > Issue Type: Improvement > Components: tck >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Critical > Fix For: JDO 3.2 > > Attachments: JDO-775-patch.txt, JDO-775-patch2.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622483#comment-16622483 ] Craig L Russell commented on JDO-652: - I very much like the current builder methods in ifThenElse patch. The builders that take literals and not class are very user-friendly. And I agree that the builder taking only class is not needed. And I like the names of the builders ifThen and elseEnd. Side question: what is the meaning of niladic sum() exp() and avg() applied to NumericExpression? > Provision of a typesafe refactor-friendly query capability for JDOQL > > > Key: JDO-652 > URL: https://issues.apache.org/jira/browse/JDO-652 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt, > JDO-652-patch3.txt, typesafe.patch, typesafe_manifest.patch > > > There are various querying capabilities of this type around. JPA2 has its > Criteria query API. Third party solutions like QueryDSL also exist, in its > case providing a JDOQL implementation (as well as JPQL, and HQL). We should > seriously consider introducing something along these lines in the JDO2.4 > timeframe. > There is a comparison of JPA Criteria with QueryDSL over at > http://source.mysema.com/forum/mvnforum/viewthread_thread,49 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16612876#comment-16612876
]
Craig L Russell commented on JDO-652:
-
{quote}Why would the builder method take 3 arguments? An "If-Else" can have
multiple "if"s and one "else". Specifying the "if-then" clauses individually
makes it more fluent IMHO.
{quote}
We can have builder methods for different use-cases. The most common is
probably one condition, with two alternative results. The builder method is on
the query object.
IfElseExpression expr =
q.ifThenElse(cand.department.name.eq("Development"), 15000.0, 25000.0)
Another example would be multiple conditions. The builder method is on the
query object, but the subsequent ifThen and ifElse methods are on the
IfElseExpression.
IfElseExpression expr =
q.ifThen(cand.department.name.eq("Development"), 15000.0)
.ifThen(cand.department.name.eq("Sales"), 65000.0)
.ifThen(cand.department.name.eq("Support"), 3000.0)
.ifElse(1.0);
Looking at the QueryDSL in DataNucleus, I'd be open to other names than
ifThenElse, ifThen and ifElse. Maybe "when" instead of ifThen, and "otherwise"
instead of ifElse.
{quote}As for naming, the reason it is called "IfElseExpression" (as opposed to
"IfThenElse") is that all expressions in that package are using the same naming
scheme ... XXXExpression. I've no problem with it being "IfThenElseExpression",
but maybe that is what Craig meant (and not calling it "IfThenElse" without the
Expression)?
{quote}
I was [confusingly] mixing the builder method with the type, which should match
the style of the other expressions, e.g. I'm fine with IfThenElseExpression or
IfElseExpression as the type. [IfThenElseExpression is probably more expressive
considering the tri-part nature of the functionality.] But imho the builder
method(s) would be more fluent if they omit the "Expression" part of the name.
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-patch-Andy.txt, JDO-652-patch3.txt,
> typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608584#comment-16608584
]
Craig L Russell commented on JDO-652:
-
I'd much prefer IfThenElse as a name to IfElseExpression.
Also, have the "constructor" take three arguments: if, then, else. This makes
queries much more fluent. e.g.
IfThenElse ifExpr =
query.ifThenElse(cand.department.name.eq("Development"), 15000.0,
25000.0); query.filter(cand.salary.gt(ifExpr));
And as Michael says, have IfThenElse extend DoubleExpression
Or have the constructor be ifThenElse(Double.class,
cand.department.name.eq("Development"), 15000.0, 25000.0
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-patch-Andy.txt, JDO-652-patch3.txt,
> typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JDO-770) Switch from svn to git
[ https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604599#comment-16604599 ] Craig L Russell commented on JDO-770: - Issue with git svn show-ignore is not a blocker. cp .svnignore .gitignore # solves the problem There is only one .svnignore file. > Switch from svn to git > -- > > Key: JDO-770 > URL: https://issues.apache.org/jira/browse/JDO-770 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > We should consider switching from svn to git. The reason to make jdo > available via git is to remove a possible barrier to new contributors. > There are several alternatives if we decide to offer git as an alternative to > svn: > * migrating all the code to git > * creating a read-only git mirror > * creating a read-write bridge. > See [Git at Apache | https://git.apache.org/] for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-770) Switch from svn to git
[ https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597518#comment-16597518 ] Craig L Russell commented on JDO-770: - Small issue with .ignore handling. cd ~/temp-db-jdo/ [MacBook-Pro-9:~/temp-db-jdo] clr% git svn show-ignore config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1 I'm not sure if this is an issue with the instructions or if there is no svn ignore rule in db/jdo. > Switch from svn to git > -- > > Key: JDO-770 > URL: https://issues.apache.org/jira/browse/JDO-770 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > We should consider switching from svn to git. The reason to make jdo > available via git is to remove a possible barrier to new contributors. > There are several alternatives if we decide to offer git as an alternative to > svn: > * migrating all the code to git > * creating a read-only git mirror > * creating a read-write bridge. > See [Git at Apache | https://git.apache.org/] for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell reassigned JDO-709: --- Assignee: Craig L Russell (was: Matthew T. Adams) > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-709: Component/s: tck > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Matthew T. Adams >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-709: Component/s: specification > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification >Reporter: Matthew T. Adams >Assignee: Matthew T. Adams >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-744) XSD/DTD not published for JDO 3.1
[ https://issues.apache.org/jira/browse/JDO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400882#comment-16400882 ] Craig L Russell commented on JDO-744: - Need credentials from Oracle to upload the xsd files. > XSD/DTD not published for JDO 3.1 > - > > Key: JDO-744 > URL: https://issues.apache.org/jira/browse/JDO-744 > Project: JDO > Issue Type: Bug > Components: api >Affects Versions: JDO 3.1 >Reporter: Andy Jefferson >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > Should be on > http://xmlns.jcp.org/xml/ns/jdo/jdo_3_1.xsd > http://xmlns.jcp.org/dtd/jdo_3_1.dtd > No idea how they are to get on that private server. Perhaps someone knows? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (JDO-744) XSD/DTD not published for JDO 3.1
[ https://issues.apache.org/jira/browse/JDO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell reassigned JDO-744: --- Assignee: Craig L Russell > XSD/DTD not published for JDO 3.1 > - > > Key: JDO-744 > URL: https://issues.apache.org/jira/browse/JDO-744 > Project: JDO > Issue Type: Bug >Affects Versions: JDO 3.1 >Reporter: Andy Jefferson >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > Should be on > http://xmlns.jcp.org/xml/ns/jdo/jdo_3_1.xsd > http://xmlns.jcp.org/dtd/jdo_3_1.dtd > No idea how they are to get on that private server. Perhaps someone knows? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-692) Constant string "javax.jdo.spi.PropertiesFileName" not defined in javax.jdo.Constants
[ https://issues.apache.org/jira/browse/JDO-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400873#comment-16400873 ] Craig L Russell commented on JDO-692: - We need to check the RI to see if any of these constants are being used, and synchronize the API with the RI. > Constant string "javax.jdo.spi.PropertiesFileName" not defined in > javax.jdo.Constants > - > > Key: JDO-692 > URL: https://issues.apache.org/jira/browse/JDO-692 > Project: JDO > Issue Type: Bug > Components: api, specification >Affects Versions: JDO 3 (3.0) >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Fix For: JDO 3.2 > > > The JDO 3.0 specification page 103, bullet point 1 says 'the Map instance > passed to the static method will contain a property with a key of > "javax.jdo.spi.PropertiesFileName", and a value equal to the result of > calling getAbsolutePath() on the file parameter'. There is no such constant > defined in javax.jdo.Constants. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Labels: concurrency delete refresh (was: concurrency delete documentation
refresh() specification)
> Behavior of delete() with multiple concurrent Transactions
> --
>
> Key: JDO-747
> URL: https://issues.apache.org/jira/browse/JDO-747
> Project: JDO
> Issue Type: Improvement
> Components: specification
>Affects Versions: JDO 3.1
>Reporter: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, refresh
> Fix For: JDO 3.2
>
> Attachments: JDO-StateTransition-logs-2015-12-04.zip,
> OptimisticCheckConsistency.java, OptimisticFailurePatch_JDO747.txt,
> StateTransitionPatch_JDO747_v6.txt
>
>
> In the Spec I could not find any statement regarding on how a transaction
> should behave if an object is deleted in a different concurrent transaction.
> Related Sections are Section 5.8 (how different methods should behave for
> different object states) and Section 12.6.1 (the behavior of refresh() and
> related methods).
> For example I wonder about the following situations. Suppose I have two
> optimistic sessions, pm1 and pm2, both access the same object. pm1 deletes
> the object and commits. Then what happens in pm2 if:
> 1. pm2 deletes the object and tries to commit, should that work? It's
>wouldn't be a real conflict if both delete it.
> 2. pm2 modifies the object (make dirty) and calls {{refresh()}}. Should I
>get an {{ObjectNotFound}} exception?
> 3. pm2 deletes the object and calls {{refresh()}}. According to the spec,
>{{refresh()}} should not change the object's state. But should it
>still fail with {{ObjectNotFound}}? If refresh should fail, how can I
>ever recover from such a situation, because I can't undelete the
>object?
> Is there a common understanding how this should work?
> IF there an external definition JDO relies on, then I think a reference to an
> external document might useful.
> If not, should the Spec define concurrent behavior?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JDO-771) Update requirement of ConnectionDriverName since JDBC 4 changed requirements
[ https://issues.apache.org/jira/browse/JDO-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-771. - Resolution: Fixed > Update requirement of ConnectionDriverName since JDBC 4 changed requirements > > > Key: JDO-771 > URL: https://issues.apache.org/jira/browse/JDO-771 > Project: JDO > Issue Type: Improvement > Components: api, specification >Affects Versions: JDO 3.1 >Reporter: Andy Jefferson >Assignee: Craig L Russell >Priority: Minor > Fix For: JDO 3.2 > > > JDBC 4.0 changed the requirement for specifying a JDBC driver name. > Previously an application had to load the class to register the driver by use > of Class.forName. > All JDBC 4.0+ drivers should register themselves. See > https://community.oracle.com/docs/DOC-983612 > This likely means that a JDO provider will not require the > javax.jdo.option.ConnectionDriverName to be supplied. > DataNucleus (v5.1.5+) certainly doesn't require it, and only previously used > it for loading the driver as per previous JDBC semantics. > This is only referred to in section 11.1 and Appendix G of the spec that I > can see. Perhaps we can omit it in JDO 3.2+, particularly as the JRE in use > will require JDBC v4+? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JDO-638) Add annotations for instance callbacks
[ https://issues.apache.org/jira/browse/JDO-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-638: Fix Version/s: (was: JDO 3.2) > Add annotations for instance callbacks > -- > > Key: JDO-638 > URL: https://issues.apache.org/jira/browse/JDO-638 > Project: JDO > Issue Type: Improvement > Components: api, specification, tck >Affects Versions: JDO 3 (3.0) >Reporter: Matthew T. Adams >Assignee: Matthew T. Adams >Priority: Minor > Attachments: InstanceCallbackAnnotations-3.patch > > > The current JDO annotations in javax.jdo.annotations do not include > annotations equivalent to instance callbacks. We should add method > annotations for each method in javax.jdo.InstanceCallback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JDO-638) Add annotations for instance callbacks
[ https://issues.apache.org/jira/browse/JDO-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-638: Attachment: (was: InstanceCallbackAnnotations-1.0.patch) > Add annotations for instance callbacks > -- > > Key: JDO-638 > URL: https://issues.apache.org/jira/browse/JDO-638 > Project: JDO > Issue Type: Improvement > Components: api, specification, tck >Affects Versions: JDO 3 (3.0) >Reporter: Matthew T. Adams >Assignee: Matthew T. Adams >Priority: Minor > Fix For: JDO 3.2 > > Attachments: InstanceCallbackAnnotations-3.patch > > > The current JDO annotations in javax.jdo.annotations do not include > annotations equivalent to instance callbacks. We should add method > annotations for each method in javax.jdo.InstanceCallback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JDO-638) Add annotations for instance callbacks
[ https://issues.apache.org/jira/browse/JDO-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-638: Attachment: (was: InstanceCallbackAnnotations-2.patch) > Add annotations for instance callbacks > -- > > Key: JDO-638 > URL: https://issues.apache.org/jira/browse/JDO-638 > Project: JDO > Issue Type: Improvement > Components: api, specification, tck >Affects Versions: JDO 3 (3.0) >Reporter: Matthew T. Adams >Assignee: Matthew T. Adams >Priority: Minor > Fix For: JDO 3.2 > > Attachments: InstanceCallbackAnnotations-3.patch > > > The current JDO annotations in javax.jdo.annotations do not include > annotations equivalent to instance callbacks. We should add method > annotations for each method in javax.jdo.InstanceCallback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-769) Revise PMFMapMapTest test cases using two class loaders
[ https://issues.apache.org/jira/browse/JDO-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347252#comment-16347252 ] Craig L Russell commented on JDO-769: - looks good > Revise PMFMapMapTest test cases using two class loaders > --- > > Key: JDO-769 > URL: https://issues.apache.org/jira/browse/JDO-769 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > Attachments: JDO-769-patch.txt, JDO-769-patch3.txt > > > The two test methods testNamedPMFWithOverridesAndTwoLoaders and > testNamedPMFWithTwoLoaders of PMFMapMapTest call JDOHelper methods > getPersistenceManagerFactory taking two class loaders: one to use for loading > resources and > the other to use for loading the PMF. The changes to fix JDO-768 made clear > that the test cases pass the same class loader for both arguments. It looks > like the tests do not test what they intended to test. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-769) Revise PMFMapMapTest test cases using two class loaders
[ https://issues.apache.org/jira/browse/JDO-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16339575#comment-16339575 ] Craig L Russell commented on JDO-769: - Perhaps we should use a different property from ConnectionDriverName to tell that the right PMF was loaded. > Revise PMFMapMapTest test cases using two class loaders > --- > > Key: JDO-769 > URL: https://issues.apache.org/jira/browse/JDO-769 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > Attachments: JDO-769-patch.txt, JDO-769-patch2.txt > > > The two test methods testNamedPMFWithOverridesAndTwoLoaders and > testNamedPMFWithTwoLoaders of PMFMapMapTest call JDOHelper methods > getPersistenceManagerFactory taking two class loaders: one to use for loading > resources and > the other to use for loading the PMF. The changes to fix JDO-768 made clear > that the test cases pass the same class loader for both arguments. It looks > like the tests do not test what they intended to test. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (JDO-771) Update requirement of ConnectionDriverName since JDBC 4 changed requirements
[ https://issues.apache.org/jira/browse/JDO-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell reassigned JDO-771: --- Assignee: Craig L Russell > Update requirement of ConnectionDriverName since JDBC 4 changed requirements > > > Key: JDO-771 > URL: https://issues.apache.org/jira/browse/JDO-771 > Project: JDO > Issue Type: Improvement > Components: specification, tck >Reporter: Andy Jefferson >Assignee: Craig L Russell >Priority: Minor > > JDBC 4.0 changed the requirement for specifying a JDBC driver name. > Previously an application had to load the class to register the driver by use > of Class.forName. > All JDBC 4.0+ drivers should register themselves. See > https://community.oracle.com/docs/DOC-983612 > This likely means that a JDO provider will not require the > javax.jdo.option.ConnectionDriverName to be supplied. > DataNucleus (v5.1.5+) certainly doesn't require it, and only previously used > it for loading the driver as per previous JDBC semantics. > This is only referred to in section 11.1 and Appendix G of the spec that I > can see. Perhaps we can omit it in JDO 3.2+, particularly as the JRE in use > will require JDBC v4+? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-771) Update requirement of ConnectionDriverName since JDBC 4 changed requirements
[ https://issues.apache.org/jira/browse/JDO-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311801#comment-16311801 ] Craig L Russell commented on JDO-771: - Looks fine to remove this property since it is now obsolete. The service loader architecture in use by DriverManager will load the drivers based on the META-INF entries in the JDBC driver jars. Still need to update the specification and API to remove the property. > Update requirement of ConnectionDriverName since JDBC 4 changed requirements > > > Key: JDO-771 > URL: https://issues.apache.org/jira/browse/JDO-771 > Project: JDO > Issue Type: Improvement > Components: specification, tck >Reporter: Andy Jefferson >Priority: Minor > > JDBC 4.0 changed the requirement for specifying a JDBC driver name. > Previously an application had to load the class to register the driver by use > of Class.forName. > All JDBC 4.0+ drivers should register themselves. See > https://community.oracle.com/docs/DOC-983612 > This likely means that a JDO provider will not require the > javax.jdo.option.ConnectionDriverName to be supplied. > DataNucleus (v5.1.5+) certainly doesn't require it, and only previously used > it for loading the driver as per previous JDBC semantics. > This is only referred to in section 11.1 and Appendix G of the spec that I > can see. Perhaps we can omit it in JDO 3.2+, particularly as the JRE in use > will require JDBC v4+? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JDO-770) Switch from svn to git
[ https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311770#comment-16311770 ] Craig L Russell commented on JDO-770: - Another question is whether there are any svn dependencies in the tooling around releases. > Switch from svn to git > -- > > Key: JDO-770 > URL: https://issues.apache.org/jira/browse/JDO-770 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen > Fix For: JDO 3.2 > > > We should consider switching from svn to git. The reason to make jdo > available via git is to remove a possible barrier to new contributors. > There are several alternatives if we decide to offer git as an alternative to > svn: > * migrating all the code to git > * creating a read-only git mirror > * creating a read-write bridge. > See [Git at Apache | https://git.apache.org/] for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JDO-771) Update requirement of ConnectionDriverName since JDBC 4 changed requirements
[ https://issues.apache.org/jira/browse/JDO-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16302965#comment-16302965 ] Craig L Russell commented on JDO-771: - The application still needs to give JDBC enough information to be able to find a suitable driver. According to https://docs.oracle.com/javase/8/docs/api/java/sql/DriverManager.html, "As part of its initialization, the DriverManager class will attempt to load the driver classes referenced in the "jdbc.drivers" system property." So simply removing the ConnectionDriverName will probably make the application fail unless the system property is set instead. I would be open to updating the JDO documentation to indicate that there are several ways to get the appropriate JDBC driver loaded. > Update requirement of ConnectionDriverName since JDBC 4 changed requirements > > > Key: JDO-771 > URL: https://issues.apache.org/jira/browse/JDO-771 > Project: JDO > Issue Type: Improvement > Components: specification, tck >Reporter: Andy Jefferson >Priority: Minor > > JDBC 4.0 changed the requirement for specifying a JDBC driver name. > Previously an application had to load the class to register the driver by use > of Class.forName. > All JDBC 4.0+ drivers should register themselves. See > https://community.oracle.com/docs/DOC-983612 > This likely means that a JDO provider will not require the > javax.jdo.option.ConnectionDriverName to be supplied. > DataNucleus (v5.1.5+) certainly doesn't require it, and only previously used > it for loading the driver as per previous JDBC semantics. > This is only referred to in section 11.1 and Appendix G of the spec that I > can see. Perhaps we can omit it in JDO 3.2+, particularly as the JRE in use > will require JDBC v4+? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JDO-767) JDO TCK lifecycle tests fail
[ https://issues.apache.org/jira/browse/JDO-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-767: Fix Version/s: JDO 3.2 > JDO TCK lifecycle tests fail > > > Key: JDO-767 > URL: https://issues.apache.org/jira/browse/JDO-767 > Project: JDO > Issue Type: Bug >Affects Versions: JDO 3.1 >Reporter: Craig L Russell > Fix For: JDO 3.2 > > > cat dsid-lifecycle-tck.txt > 10:14:11,507 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-6 (NontransactionalWriteDatastoreRollback) failed: after > datastore rollback > expected: 100 > actual: 999 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreRollback.testDatastoreRollback(NontransactionalWriteDatastoreRollback.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > 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.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:14:11,527 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-4 (NontransactionalWriteDatastoreCommitConflict) failed: > after datastore commit with conflict > expected: 999 > actual: 555 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreCommitConflict.testDatastoreCommitConflict(NontransactionalWriteDatastoreCommitConflict.java:90) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > 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.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:14:11,532 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-10 (NontransactionalWriteOptimisticRollback) failed: after > optimistic rollback > expected: 100 > actual: 999 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteOptimisticRollback.testOptimisticRollback(NontransactionalWriteOptimisticRollback.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at >
[jira] [Updated] (JDO-767) JDO TCK lifecycle tests fail
[ https://issues.apache.org/jira/browse/JDO-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell updated JDO-767: Affects Version/s: JDO 3.1 > JDO TCK lifecycle tests fail > > > Key: JDO-767 > URL: https://issues.apache.org/jira/browse/JDO-767 > Project: JDO > Issue Type: Bug >Affects Versions: JDO 3.1 >Reporter: Craig L Russell > Fix For: JDO 3.2 > > > cat dsid-lifecycle-tck.txt > 10:14:11,507 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-6 (NontransactionalWriteDatastoreRollback) failed: after > datastore rollback > expected: 100 > actual: 999 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreRollback.testDatastoreRollback(NontransactionalWriteDatastoreRollback.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > 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.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:14:11,527 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-4 (NontransactionalWriteDatastoreCommitConflict) failed: > after datastore commit with conflict > expected: 999 > actual: 555 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreCommitConflict.testDatastoreCommitConflict(NontransactionalWriteDatastoreCommitConflict.java:90) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > 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.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:14:11,532 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-10 (NontransactionalWriteOptimisticRollback) failed: after > optimistic rollback > expected: 100 > actual: 999 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteOptimisticRollback.testOptimisticRollback(NontransactionalWriteOptimisticRollback.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at >
[jira] [Created] (JDO-767) JDO TCK lifecycle tests fail
Craig L Russell created JDO-767: --- Summary: JDO TCK lifecycle tests fail Key: JDO-767 URL: https://issues.apache.org/jira/browse/JDO-767 Project: JDO Issue Type: Bug Reporter: Craig L Russell cat dsid-lifecycle-tck.txt 10:14:11,507 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A5.6.2-6 (NontransactionalWriteDatastoreRollback) failed: after datastore rollback expected: 100 actual: 999 at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) at org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreRollback.testDatastoreRollback(NontransactionalWriteDatastoreRollback.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) 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.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:14:11,527 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A5.6.2-4 (NontransactionalWriteDatastoreCommitConflict) failed: after datastore commit with conflict expected: 999 actual: 555 at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) at org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreCommitConflict.testDatastoreCommitConflict(NontransactionalWriteDatastoreCommitConflict.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) 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.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:14:11,532 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A5.6.2-10 (NontransactionalWriteOptimisticRollback) failed: after optimistic rollback expected: 100 actual: 999 at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) at org.apache.jdo.tck.lifecycle.NontransactionalWriteOptimisticRollback.testOptimisticRollback(NontransactionalWriteOptimisticRollback.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) at
[jira] [Resolved] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell resolved JDO-764.
-
Resolution: Fixed
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: duplicate-annotations.txt, jdo764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JDO-766) Support more JDBC-aware databases in JDO TCK
Craig L Russell created JDO-766: --- Summary: Support more JDBC-aware databases in JDO TCK Key: JDO-766 URL: https://issues.apache.org/jira/browse/JDO-766 Project: JDO Issue Type: New Feature Components: tck Affects Versions: JDO 3.1 Environment: non-Derby databases with RI (DataNucleus) Reporter: Craig L Russell Priority: Minor Fix For: JDO 3.2 The TCK does not support databases except for Derby, even though the RI does. The primary blocker is that the TCK uses an embedded Derby database. The proposed solution is to use a JDBC connection to the database instead of an embedded Derby database. There are a few issues: - Before running the TCK, the database will need to be started, which may involve a manual operation or a database-dependent script. And after the TCK test completes, the database will need to be shut down. - The database schema need to be created, which currently uses a Derby-specific program. This program needs to be replaced by a program that reads a SQL command file containing the SQL commands to create the schema. And the schema needs to be created manually or automatically based on metadata. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243172#comment-16243172
]
Craig L Russell commented on JDO-764:
-
clr% svn commit tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC
tck/src/java/org/apache/jdo/tck/pc/compositeAnnotation
Adding
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/DatastoreIdDiscriminatorClassNameInheritanceNew.java
Adding
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/DatastoreIdDiscriminatorClassNameInheritanceSuperclass.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCAppDepartment.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCAppEmployee.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCAppPerson.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSCompany.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSDepartment.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSEmployee.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSFullTimeEmployee.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSInsurance.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSMeetingRoom.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSPartTimeEmployee.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSPerson.java
Sending
tck/src/java/org/apache/jdo/tck/pc/companyAnnotatedFC/FCDSProject.java
Adding tck/src/java/org/apache/jdo/tck/pc/compositeAnnotation
Adding
tck/src/java/org/apache/jdo/tck/pc/compositeAnnotation/ApplicationIdDiscriminatorClassName.java
Transmitting file data ...done
Committing transaction...
Committed revision 1814545.
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: duplicate-annotations.txt, jdo764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JDO-765) TCK should fail if tests fail
[ https://issues.apache.org/jira/browse/JDO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239679#comment-16239679 ] Craig L Russell commented on JDO-765: - Patch 2 fixes the issues I saw. The only thing I'd offer is to consider different names for failEventually: failLater failSlow failGoal But the patch is good to go. > TCK should fail if tests fail > - > > Key: JDO-765 > URL: https://issues.apache.org/jira/browse/JDO-765 > Project: JDO > Issue Type: Bug >Reporter: Tilmann Zäschke >Priority: Trivial > Attachments: JDO-765-patch-v2.txt > > > Currently, TCK test failures are reported to the console and in the logs, but > the Maven build still succeeds. > The proposal is to make the behavior configurable, the default being that the > Maven build fails if any TCK tests fail. > The new configuration option would be called "-Djdo.tck.onFailure" and have > the following options: > * "failFast" will immediately abort the test run. > * "failEventually" (default) will execute the whole TCK before failing. > * "logOnly" will report failures to console and logs only but return > 'SUCCESS' to the Maven execution environment. > Attached is a patch with an implementation of the proposed changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (JDO-765) TCK should fail if tests fail
[ https://issues.apache.org/jira/browse/JDO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239315#comment-16239315 ] Craig L Russell edited comment on JDO-765 at 11/5/17 12:26 AM: --- I applied the patch and the behavior did change, but not exactly what I expected. Good: When running with -Djdo.tck.onFailure=failEventually, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Good: When running with -Djdo.tck.onFailure default, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Good: When running with -Djdo.tck.onFailure=logOnly, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then continued. Bad: When running with -Djdo.tck.onFailure=failFast, the tck test ran through all of the datastoreidentity tests before failing. I expected the test would fail right after the first failure, "Running tests for lifecycle.conf with datastoreidentity on 'derby' mapping= ... FAIL" but the tck test continued with the rest of the datastoreidentity tests. was (Author: clr): I applied the patch and the behavior did change, but not exactly what I expected. Good: When running with -Djdo.tck.onFailure=failEventually, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Good: When running with -Djdo.tck.onFailure default, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Bad: When running with -Djdo.tck.onFailure=failFast, the tck test ran through all of the datastoreidentity tests before failing. I expected the test would fail right after the first failure, "Running tests for lifecycle.conf with datastoreidentity on 'derby' mapping= ... FAIL" but the tck test continued with the rest of the datastoreidentity tests. > TCK should fail if tests fail > - > > Key: JDO-765 > URL: https://issues.apache.org/jira/browse/JDO-765 > Project: JDO > Issue Type: Bug >Reporter: Tilmann Zäschke >Priority: Trivial > Attachments: JDO-XXX-patch.txt > > > Currently, TCK test failures are reported to the console and in the logs, but > the Maven build still succeeds. > The proposal is to make the behavior configurable, the default being that the > Maven build fails if any TCK tests fail. > The new configuration option would be called "-Djdo.tck.onFailure" and have > the following options: > * "failFast" will immediately abort the test run. > * "failEventually" (default) will execute the whole TCK before failing. > * "logOnly" will report failures to console and logs only but return > 'SUCCESS' to the Maven execution environment. > Attached is a patch with an implementation of the proposed changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (JDO-765) TCK should fail if tests fail
[ https://issues.apache.org/jira/browse/JDO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239315#comment-16239315 ] Craig L Russell edited comment on JDO-765 at 11/5/17 12:02 AM: --- I applied the patch and the behavior did change, but not exactly what I expected. Good: When running with -Djdo.tck.onFailure=failEventually, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Good: When running with -Djdo.tck.onFailure default, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Bad: When running with -Djdo.tck.onFailure=failFast, the tck test ran through all of the datastoreidentity tests before failing. I expected the test would fail right after the first failure, "Running tests for lifecycle.conf with datastoreidentity on 'derby' mapping= ... FAIL" but the tck test continued with the rest of the datastoreidentity tests. was (Author: clr): I applied the patch and the behavior did change, but not exactly what I expected. Good: When running with -Djdo.tck.onFailure=failEventually, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Bad: When running with -Djdo.tck.onFailure default, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Bad: When running with -Djdo.tck.onFailure=failFast, the tck test ran through all of the datastoreidentity tests before failing. I expected the test would fail right after the first failure, "Running tests for lifecycle.conf with datastoreidentity on 'derby' mapping= ... FAIL" but the tck test continued with the rest of the datastoreidentity tests. > TCK should fail if tests fail > - > > Key: JDO-765 > URL: https://issues.apache.org/jira/browse/JDO-765 > Project: JDO > Issue Type: Bug >Reporter: Tilmann Zäschke >Priority: Trivial > Attachments: JDO-XXX-patch.txt > > > Currently, TCK test failures are reported to the console and in the logs, but > the Maven build still succeeds. > The proposal is to make the behavior configurable, the default being that the > Maven build fails if any TCK tests fail. > The new configuration option would be called "-Djdo.tck.onFailure" and have > the following options: > * "failFast" will immediately abort the test run. > * "failEventually" (default) will execute the whole TCK before failing. > * "logOnly" will report failures to console and logs only but return > 'SUCCESS' to the Maven execution environment. > Attached is a patch with an implementation of the proposed changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (JDO-765) TCK should fail if tests fail
[ https://issues.apache.org/jira/browse/JDO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239315#comment-16239315 ] Craig L Russell edited comment on JDO-765 at 11/4/17 11:58 PM: --- I applied the patch and the behavior did change, but not exactly what I expected. Good: When running with -Djdo.tck.onFailure=failEventually, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Bad: When running with -Djdo.tck.onFailure default, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Bad: When running with -Djdo.tck.onFailure=failFast, the tck test ran through all of the datastoreidentity tests before failing. I expected the test would fail right after the first failure, "Running tests for lifecycle.conf with datastoreidentity on 'derby' mapping= ... FAIL" but the tck test continued with the rest of the datastoreidentity tests. was (Author: clr): I applied the patch and the behavior did change, but not exactly what I expected. Good: When running with -Djdo.tck.onFailure=failEventually, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Good: When running with -Djdo.tck.onFailure default, the tck test ran through all of the tests for both datastoreidentity and applicationidentity, reported the two failures, and went on to the next mvn goal. Bad: When running with -Djdo.tck.onFailure=failFast, the tck test ran through all of the datastoreidentity tests before failing. I expected the test would fail right after the first failure, "Running tests for lifecycle.conf with datastoreidentity on 'derby' mapping= ... FAIL" but the tck test continued with the rest of the datastoreidentity tests. > TCK should fail if tests fail > - > > Key: JDO-765 > URL: https://issues.apache.org/jira/browse/JDO-765 > Project: JDO > Issue Type: Bug >Reporter: Tilmann Zäschke >Priority: Trivial > Attachments: JDO-XXX-patch.txt > > > Currently, TCK test failures are reported to the console and in the logs, but > the Maven build still succeeds. > The proposal is to make the behavior configurable, the default being that the > Maven build fails if any TCK tests fail. > The new configuration option would be called "-Djdo.tck.onFailure" and have > the following options: > * "failFast" will immediately abort the test run. > * "failEventually" (default) will execute the whole TCK before failing. > * "logOnly" will report failures to console and logs only but return > 'SUCCESS' to the Maven execution environment. > Attached is a patch with an implementation of the proposed changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JDO-765) TCK should fail if tests fail
[ https://issues.apache.org/jira/browse/JDO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239315#comment-16239315 ] Craig L Russell commented on JDO-765: - I applied the patch and the behavior did change, but not exactly what I expected. Good: When running with -Djdo.tck.onFailure=failEventually, the tck test ran through all of the tests, reported "Failed to execute goal org.apache.jdo:jdo-exectck:3.2-SNAPSHOT:runtck (default) on project jdo-tck: There were 2 TCK test failures" and then failed the mvn goal. Good: When running with -Djdo.tck.onFailure default, the tck test ran through all of the tests for both datastoreidentity and applicationidentity, reported the two failures, and went on to the next mvn goal. Bad: When running with -Djdo.tck.onFailure=failFast, the tck test ran through all of the datastoreidentity tests before failing. I expected the test would fail right after the first failure, "Running tests for lifecycle.conf with datastoreidentity on 'derby' mapping= ... FAIL" but the tck test continued with the rest of the datastoreidentity tests. > TCK should fail if tests fail > - > > Key: JDO-765 > URL: https://issues.apache.org/jira/browse/JDO-765 > Project: JDO > Issue Type: Bug >Reporter: Tilmann Zäschke >Priority: Trivial > Attachments: JDO-XXX-patch.txt > > > Currently, TCK test failures are reported to the console and in the logs, but > the Maven build still succeeds. > The proposal is to make the behavior configurable, the default being that the > Maven build fails if any TCK tests fail. > The new configuration option would be called "-Djdo.tck.onFailure" and have > the following options: > * "failFast" will immediately abort the test run. > * "failEventually" (default) will execute the whole TCK before failing. > * "logOnly" will report failures to console and logs only but return > 'SUCCESS' to the Maven execution environment. > Attached is a patch with an implementation of the proposed changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-764:
Attachment: (was: jdo-764.patch)
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: duplicate-annotations.txt, jdo764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-764:
Attachment: jdo764.patch
This patch adds a meta-annotation to the pc/companyAnnotatedFC classes
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: duplicate-annotations.txt, jdo764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-764:
Attachment: duplicate-annotations.txt
This patch adds a test for duplicate PersistenceCapable annotations.
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: duplicate-annotations.txt, jdo-764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JDO-745) Support bitwise operations in JDOQL
[ https://issues.apache.org/jira/browse/JDO-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192288#comment-16192288 ] Craig L Russell commented on JDO-745: - The expected results for bitwise and and or seem wrong. "4 <= id && id >= 7" should be ? "4 <= id && id <= 7" I'd also suggest that the query predicate (byteNotNull & 4) returns a bunch of bits that should be compared via equality and not order, so: "(byteNotNull & 4) != 0" > Support bitwise operations in JDOQL > --- > > Key: JDO-745 > URL: https://issues.apache.org/jira/browse/JDO-745 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson >Assignee: Michael Bouschen > Fix For: JDO 3.2 > > Attachments: JDO-745.patch, JDO-745-patch2.txt > > > The tests BooleanLogicalAND.testNegative, BooleanLogicalOR.testNegative don't > test use of a boolean logical AND/OR. They actually test for an integer being > used with the "&" and "|" operators. Sadly this means that any implementation > that attempts to provide a vendor extension of support for bitwise AND/OR > (for those RDBMS that support it) cannot pass the TCK. > Perhaps add an "optional feature" for the vendor to support bitwise > operations, and then don't run that test if so. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115170#comment-16115170
]
Craig L Russell commented on JDO-764:
-
The strategy for merging annotations can be simple, preserving your original
support for real applications, as well as extending it to what I thought was a
really good usability improvement.
When encountering an annotation for the first time, initialize all of the
target DataNucleus metadata values with default values defined in the JDO
annotations. When processing an annotation the first or subsequent time, only
process a value if it is not the default value for the annotation. Something
like:
if (!"".equals(pcAnnotation.table()) dnMetadata.table(pcAnnotation.table()));
if (!"".equals(pcAnnotation.catalog())
dnMetadata.catalog(pcAnnotation.catalog());
...
The only problem is a user error where they specify more than one non-default
value. And that is where, sadly, "unpredictable" results come from.
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: jdo-764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108151#comment-16108151
]
Craig L Russell commented on JDO-764:
-
I think there is a problem if you do not support merging annotations, in all
the annotations that take names of things and not defaults or behaviors.
In your example, @PersistenceCapable could not be used in a meta-annotation
because the table= value could not be set elsewhere.
My rationale for allowing multiple annotations is to support the test case
usage, which is based on your example, @DatastorePersistable, which could only
use the default table name strategy if @PersistenceCapable cannot be used twice.
On the implementation side, the DataNucleus code now catches multiple
annotations and issues an error message. But it seems like it is just as easy
to collect annotations and apply them to the DataNucleus metamodel. What is the
harm in processing all such annotations that are applied to an element? The
first time the DataNucleus metamodel encounters @PersistenceCapable it fills
the metamodel with the values it finds. The next time it encounters
@PersistenceCapable it fills the metamodel with additional values. The way the
specification draft is written, it is undefined what happens if multiple
annotations with conflicting values are processed, so there is no need to find
out if this is the first or nth identical annotation. If the user has a
conflict, results are unpredictable, as expected.
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: jdo-764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102479#comment-16102479
]
Craig L Russell commented on JDO-764:
-
This is the proposed text for the specification. Please review.
• Annotations can be combined and applied to user-defined compound
annotations. A user-defined annotation itself can be annotated with one or more
JDO annotations and when the user-defined annotation is applied to an element,
all of its JDO annotations will be applied to that element. Nested user-defined
annotations are also supported. If the same JDO annotations appear multiple
times in user-defined annotations, all JDO annotation values will be applied to
the target element. If the same JDO annotation value appears multiple times,
results are undefined.
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: jdo-764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
