[jira] [Created] (JDO-844) Add SampleReadQuery test methods with variables of type String
Michael Bouschen created JDO-844:
Summary: Add SampleReadQuery test methods with variables of type
String
Key: JDO-844
URL: https://issues.apache.org/jira/browse/JDO-844
Project: JDO
Issue Type: Improvement
Components: tck
Affects Versions: JDO 3.2.1
Reporter: Michael Bouschen
A query variable of type String in a JDOQLTypedQuery must be declared using
method
{color:#00}JDOQLTypedQuery{color}.variable. For variables of a persistence
capable type there is a varaible method in teh genareted meta-model Q class e.g.
{{{color:#0033b3} public static {color}{color:#00}QEmployee
{color}{color:#00627a}variable{color}({color:#00}String name{color})}}
For type String there is no such meta-model Q class, so method
{color:#00}JDOQLTypedQuery{color}.variable must be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (JDO-844) Add SampleReadQuery test methods with variables of type String
[
https://issues.apache.org/jira/browse/JDO-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen reassigned JDO-844:
Assignee: Michael Bouschen
> Add SampleReadQuery test methods with variables of type String
> --
>
> Key: JDO-844
> URL: https://issues.apache.org/jira/browse/JDO-844
> Project: JDO
> Issue Type: Improvement
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Assignee: Michael Bouschen
>Priority: Major
>
> A query variable of type String in a JDOQLTypedQuery must be declared using
> method
> {color:#00}JDOQLTypedQuery{color}.variable. For variables of a
> persistence capable type there is a varaible method in teh genareted
> meta-model Q class e.g.
> {{{color:#0033b3} public static {color}{color:#00}QEmployee
> {color}{color:#00627a}variable{color}({color:#00}String name{color})}}
> For type String there is no such meta-model Q class, so method
> {color:#00}JDOQLTypedQuery{color}.variable must be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JDO-844) Add SampleReadQuery test methods with variables of type String
[
https://issues.apache.org/jira/browse/JDO-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-844:
-
Fix Version/s: JDO 3.3
> Add SampleReadQuery test methods with variables of type String
> --
>
> Key: JDO-844
> URL: https://issues.apache.org/jira/browse/JDO-844
> Project: JDO
> Issue Type: Improvement
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.3
>
>
> A query variable of type String in a JDOQLTypedQuery must be declared using
> method
> {color:#00}JDOQLTypedQuery{color}.variable. For variables of a
> persistence capable type there is a varaible method in teh genareted
> meta-model Q class e.g.
> {{{color:#0033b3} public static {color}{color:#00}QEmployee
> {color}{color:#00627a}variable{color}({color:#00}String name{color})}}
> For type String there is no such meta-model Q class, so method
> {color:#00}JDOQLTypedQuery{color}.variable must be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JDO-842) Q class specification of candidate() method
[ https://issues.apache.org/jira/browse/JDO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894032#comment-17894032 ] Craig L Russell commented on JDO-842: - Changes are in github repositories: [https://github.com/clr-apache/jdo-specification/tree/JDO-842] [https://github.com/apache/db-jdo/blob/JDO-842/api/src/main/java/javax/jdo/JDOQLTypedQuery.java] > Q class specification of candidate() method > --- > > Key: JDO-842 > URL: https://issues.apache.org/jira/browse/JDO-842 > Project: JDO > Issue Type: Bug > Components: specification >Affects Versions: JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > > The specification does not clearly specify the behavior of the Q classes in > Section "14.10 Typesafe Query Construction" > The examples in section "14.11 Examples" use the following methods of > generated Q-classes: > * candidate() > * candidate(String) > * variable(String) > Both candidate methods are used in the query examples, but they are not > specified as part of the typesafe query support. > Specific points that we should possibly mention: > * These methods should allow Q classes to be used concurrently. > Specifically, they should all return *new* instances. The current > specification allows returning shared multiple instances which causes > problems when used concurrently. (the reference implementation currently does > this for 'candidate()'). > * The reference implementation also has a 'parameter(String)' method. We may > want to add this to the spec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JDO-843) JDOQLTypedQuery: issue with candidate("this") method
[
https://issues.apache.org/jira/browse/JDO-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen reassigned JDO-843:
Assignee: Michael Bouschen
> JDOQLTypedQuery: issue with candidate("this") method
>
>
> Key: JDO-843
> URL: https://issues.apache.org/jira/browse/JDO-843
> Project: JDO
> Issue Type: Bug
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Assignee: Michael Bouschen
>Priority: Major
>
> TCK Class {color:#00}SampleReadQueries implements the sample queries from
> the JDO specification chapter 14.11.{color}
> {color:#00}Methods testQuery15f and testQuery16f implement the typesafe
> query version. The code uses QFullTimeEmployee.candidate() to access
> instances of the candidate class. The query returns a wrong query result,
> When replacing the call
> {color}{color:#00}QFullTimeEmployee.candidate() by
> QFullTimeEmployee.candidate("this")
> The expected query result consist of three
> {color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
> instance (testQuery15f) or {color}EmpInfo instance
> ({color:#00}testQuery16f{color}). Instead the
> {color:#00}FullTimeEmployee instance is null that gets wrappe into a
> EmpWrapper/EmpInfo.{color}
> {color:#00}The generated SQL does not differ depending on which candidate
> method is used.{color}
> {color:#00}Junit Test results when running the test Methods with
> QFullTimeEmployee.candidate("this"):{color}
> {color:#00}{} JUnit Jupiter:JDO843Test:testQuery15f(){}
> {} MethodSource [className =
> 'org.apache.jdo.tck.query.api.JDO843Test', methodName = 'testQuery15f',
> methodParameterTypes = '']{}
> => org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
> failed:
> {}Wrong query result: {}
> {}query: select into
> org.apache.jdo.tck.query.api.SampleReadQueries$EmpWrapper from
> org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal{}
> {}expected: java.util.ArrayList of size 3{}
> [EmpWrapper(FullTimeEmployee:name = Michael),
> EmpWrapper(FullTimeEmployee:name = Craig), EmpWrapper(FullTimeEmployee:name =
> Tillmann)]
> {}got: java.util.ArrayList of size 3{}
> [EmpWrapper(FullTimeEmployee:null), EmpWrapper(FullTimeEmployee:null),
> EmpWrapper(FullTimeEmployee:null)]
> {} JUnit Jupiter:JDO843Test:testQuery16f(){}
> {} MethodSource [className =
> 'org.apache.jdo.tck.query.api.JDO843Test', methodName = 'testQuery16f',
> methodParameterTypes = '']{}
> => org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
> failed:
> {}Wrong query result: {}
> {}query: select into
> org.apache.jdo.tck.query.api.SampleReadQueries$EmpInfo from
> org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal{}
> {}expected: java.util.ArrayList of size 3{}
> [EmpInfo(worker:Michael), EmpInfo(worker:Craig), EmpInfo(worker:Tillmann)]
> {}got: java.util.ArrayList of size 3{}
> [EmpInfo(worker:null), EmpInfo(worker:null), EmpInfo(worker:null)]{color}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JDO-843) JDOQLTypedQuery: issue with candidate("this") method
[
https://issues.apache.org/jira/browse/JDO-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen resolved JDO-843.
--
Fix Version/s: JDO 3.2.2
Resolution: Fixed
Version 5.2.11 of datanucleus-api-jdo fixes the problem.
> JDOQLTypedQuery: issue with candidate("this") method
>
>
> Key: JDO-843
> URL: https://issues.apache.org/jira/browse/JDO-843
> Project: JDO
> Issue Type: Bug
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2.2
>
>
> TCK Class {color:#00}SampleReadQueries implements the sample queries from
> the JDO specification chapter 14.11.{color}
> {color:#00}Methods testQuery15f and testQuery16f implement the typesafe
> query version. The code uses QFullTimeEmployee.candidate() to access
> instances of the candidate class. The query returns a wrong query result,
> When replacing the call
> {color}{color:#00}QFullTimeEmployee.candidate() by
> QFullTimeEmployee.candidate("this")
> The expected query result consist of three
> {color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
> instance (testQuery15f) or {color}EmpInfo instance
> ({color:#00}testQuery16f{color}). Instead the
> {color:#00}FullTimeEmployee instance is null that gets wrappe into a
> EmpWrapper/EmpInfo.{color}
> {color:#00}The generated SQL does not differ depending on which candidate
> method is used.{color}
> {color:#00}Junit Test results when running the test Methods with
> QFullTimeEmployee.candidate("this"):{color}
> {color:#00}{} JUnit Jupiter:JDO843Test:testQuery15f(){}
> {} MethodSource [className =
> 'org.apache.jdo.tck.query.api.JDO843Test', methodName = 'testQuery15f',
> methodParameterTypes = '']{}
> => org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
> failed:
> {}Wrong query result: {}
> {}query: select into
> org.apache.jdo.tck.query.api.SampleReadQueries$EmpWrapper from
> org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal{}
> {}expected: java.util.ArrayList of size 3{}
> [EmpWrapper(FullTimeEmployee:name = Michael),
> EmpWrapper(FullTimeEmployee:name = Craig), EmpWrapper(FullTimeEmployee:name =
> Tillmann)]
> {}got: java.util.ArrayList of size 3{}
> [EmpWrapper(FullTimeEmployee:null), EmpWrapper(FullTimeEmployee:null),
> EmpWrapper(FullTimeEmployee:null)]
> {} JUnit Jupiter:JDO843Test:testQuery16f(){}
> {} MethodSource [className =
> 'org.apache.jdo.tck.query.api.JDO843Test', methodName = 'testQuery16f',
> methodParameterTypes = '']{}
> => org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
> failed:
> {}Wrong query result: {}
> {}query: select into
> org.apache.jdo.tck.query.api.SampleReadQueries$EmpInfo from
> org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal{}
> {}expected: java.util.ArrayList of size 3{}
> [EmpInfo(worker:Michael), EmpInfo(worker:Craig), EmpInfo(worker:Tillmann)]
> {}got: java.util.ArrayList of size 3{}
> [EmpInfo(worker:null), EmpInfo(worker:null), EmpInfo(worker:null)]{color}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JDO-843) JDOQLTypedQuery: issue with candidate("this") method
[
https://issues.apache.org/jira/browse/JDO-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881844#comment-17881844
]
Michael Bouschen commented on JDO-843:
--
To reprocude the issue please checkout branch JDO-843 of the Apache JDO
repository [https://github.com/apache/db-jdo/tree/JDO-843]. The branch includes
the test class JDO843Test that just has the failing methods testQuery15f and
testQuery16f.
Please run the following command:
{{mvn -Djdo.tck.cfglist=JDO843.conf clean install}}
You find the results in the directory tck/target/logs/ files
app-JDO843-junit.txt or dsid-JDO843-junit.txt.
Please note, that with the latest checkin there are diffrent testcases for
success (testQuery15fSuccess / testQuery16fSuccess) and failure
(testQuery15fFailure / testQuery16fFailure).
Please also note, I put the JUnit @Test annotation in comments for the two
success methods. When running the success methods together with the failure
methods all 4 methods return the expected result. When running the failure
mthods w/o the success methods the twi failure methods return the unexpected
result.
> JDOQLTypedQuery: issue with candidate("this") method
>
>
> Key: JDO-843
> URL: https://issues.apache.org/jira/browse/JDO-843
> Project: JDO
> Issue Type: Bug
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Priority: Major
>
> TCK Class {color:#00}SampleReadQueries implements the sample queries from
> the JDO specification chapter 14.11.{color}
> {color:#00}Methods testQuery15f and testQuery16f implement the typesafe
> query version. The code uses QFullTimeEmployee.candidate() to access
> instances of the candidate class. The query returns a wrong query result,
> When replacing the call
> {color}{color:#00}QFullTimeEmployee.candidate() by
> QFullTimeEmployee.candidate("this")
> The expected query result consist of three
> {color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
> instance (testQuery15f) or {color}EmpInfo instance
> ({color:#00}testQuery16f{color}). Instead the
> {color:#00}FullTimeEmployee instance is null that gets wrappe into a
> EmpWrapper/EmpInfo.{color}
> {color:#00}The generated SQL does not differ depending on which candidate
> method is used.{color}
> {color:#00}Junit Test results when running the test Methods with
> QFullTimeEmployee.candidate("this"):{color}
> {color:#00}{} JUnit Jupiter:JDO843Test:testQuery15f(){}
> {} MethodSource [className =
> 'org.apache.jdo.tck.query.api.JDO843Test', methodName = 'testQuery15f',
> methodParameterTypes = '']{}
> => org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
> failed:
> {}Wrong query result: {}
> {}query: select into
> org.apache.jdo.tck.query.api.SampleReadQueries$EmpWrapper from
> org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal{}
> {}expected: java.util.ArrayList of size 3{}
> [EmpWrapper(FullTimeEmployee:name = Michael),
> EmpWrapper(FullTimeEmployee:name = Craig), EmpWrapper(FullTimeEmployee:name =
> Tillmann)]
> {}got: java.util.ArrayList of size 3{}
> [EmpWrapper(FullTimeEmployee:null), EmpWrapper(FullTimeEmployee:null),
> EmpWrapper(FullTimeEmployee:null)]
> {} JUnit Jupiter:JDO843Test:testQuery16f(){}
> {} MethodSource [className =
> 'org.apache.jdo.tck.query.api.JDO843Test', methodName = 'testQuery16f',
> methodParameterTypes = '']{}
> => org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
> failed:
> {}Wrong query result: {}
> {}query: select into
> org.apache.jdo.tck.query.api.SampleReadQueries$EmpInfo from
> org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal{}
> {}expected: java.util.ArrayList of size 3{}
> [EmpInfo(worker:Michael), EmpInfo(worker:Craig), EmpInfo(worker:Tillmann)]
> {}got: java.util.ArrayList of size 3{}
> [EmpInfo(worker:null), EmpInfo(worker:null), EmpInfo(worker:null)]{color}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JDO-843) JDOQLTypedQuery: issue with candidate("this") method
[
https://issues.apache.org/jira/browse/JDO-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-843:
-
Description:
TCK Class {color:#00}SampleReadQueries implements the sample queries from
the JDO specification chapter 14.11.{color}
{color:#00}Methods testQuery15f and testQuery16f implement the typesafe
query version. The code uses QFullTimeEmployee.candidate() to access instances
of the candidate class. The query returns a wrong query result, When replacing
the call
{color}{color:#00}QFullTimeEmployee.candidate() by
QFullTimeEmployee.candidate("this")
The expected query result consist of three
{color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
instance (testQuery15f) or {color}EmpInfo instance
({color:#00}testQuery16f{color}). Instead the
{color:#00}FullTimeEmployee instance is null that gets wrappe into a
EmpWrapper/EmpInfo.{color}
{color:#00}The generated SQL does not differ depending on which candidate
method is used.{color}
{color:#00}Junit Test results when running the test Methods with
QFullTimeEmployee.candidate("this"):{color}
{color:#00}{} JUnit Jupiter:JDO843Test:testQuery15f(){}
{} MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery15f', methodParameterTypes = '']{}
=> org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
failed:
{}Wrong query result: {}
{}query: select into
org.apache.jdo.tck.query.api.SampleReadQueries$EmpWrapper from
org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal{}
{}expected: java.util.ArrayList of size 3{}
[EmpWrapper(FullTimeEmployee:name = Michael), EmpWrapper(FullTimeEmployee:name
= Craig), EmpWrapper(FullTimeEmployee:name = Tillmann)]
{}got: java.util.ArrayList of size 3{}
[EmpWrapper(FullTimeEmployee:null), EmpWrapper(FullTimeEmployee:null),
EmpWrapper(FullTimeEmployee:null)]
{} JUnit Jupiter:JDO843Test:testQuery16f(){}
{} MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery16f', methodParameterTypes = '']{}
=> org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
failed:
{}Wrong query result: {}
{}query: select into org.apache.jdo.tck.query.api.SampleReadQueries$EmpInfo
from org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal{}
{}expected: java.util.ArrayList of size 3{}
[EmpInfo(worker:Michael), EmpInfo(worker:Craig), EmpInfo(worker:Tillmann)]
{}got: java.util.ArrayList of size 3{}
[EmpInfo(worker:null), EmpInfo(worker:null), EmpInfo(worker:null)]{color}
was:
TCK Class {color:#00}SampleReadQueries implements the sample queries from
the JDO specification chapter 14.11.{color}
{color:#00}Methods testQuery15f and testQuery16f implement the typesafe
query version. The code uses QFullTimeEmployee.candidate() to access instances
of the candidate class. The query returns a wrong query result, When replacing
the call
{color}{color:#00}QFullTimeEmployee.candidate() by
QFullTimeEmployee.candidate("this")
The expected query resukt consist of three
{color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
instance (testQuery15f) or {color}EmpInfo instance
({color:#00}testQuery16f{color}). Instead the
{color:#00}FullTimeEmployee instance is null that gets wrappe into a
EmpWrapper/EmpInfo.{color}
{color:#00}Junit Test results when running the test Methods with
QFullTimeEmployee.candidate("this"):{color}
{color:#00} JUnit Jupiter:JDO843Test:testQuery15f()
MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery15f', methodParameterTypes = '']
=> org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
failed:
Wrong query result:
query: select into
org.apache.jdo.tck.query.api.SampleReadQueries$EmpWrapper from
org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal
expected: java.util.ArrayList of size 3
[EmpWrapper(FullTimeEmployee:name = Michael), EmpWrapper(FullTimeEmployee:name
= Craig), EmpWrapper(FullTimeEmployee:name = Tillmann)]
got: java.util.ArrayList of size 3
[EmpWrapper(FullTimeEmployee:null), EmpWrapper(FullTimeEmployee:null),
EmpWrapper(FullTimeEmployee:null)]
JUnit Jupiter:JDO843Test:testQuery16f()
MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery16f', methodParameterTypes = '']
=> org.opentest4j.AssertionFailedError: Assertion (SampleQueries)
failed: }}}
[jira] [Updated] (JDO-843) JDOQLTypedQuery: issue with candidate("this") method
[
https://issues.apache.org/jira/browse/JDO-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-843:
-
Description:
TCK Class {color:#00}SampleReadQueries implements the sample queries from
the JDO specification chapter 14.11.{color}
{color:#00}Methods testQuery15f and testQuery16f implement the typesafe
query version. The code uses QFullTimeEmployee.candidate() to access instances
of the candidate class. The query returns a wrong query result, When replacing
the call
{color}{color:#00}QFullTimeEmployee.candidate() by
QFullTimeEmployee.candidate("this")
The expected query resukt consist of three
{color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
instance (testQuery15f) or {color}EmpInfo instance
({color:#00}testQuery16f{color}). Instead the
{color:#00}FullTimeEmployee instance is null that gets wrappe into a
EmpWrapper/EmpInfo.{color}
{color:#00}Junit Test results when running the test Methods with
QFullTimeEmployee.candidate("this"):{color}
{color:#00}{{ JUnit Jupiter:JDO843Test:testQuery15f()}}
{{ MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery15f', methodParameterTypes = '']}}
{{ => org.opentest4j.AssertionFailedError: Assertion (SampleQueries) failed:
}}
{{Wrong query result: }}
{{query: select into org.apache.jdo.tck.query.api.SampleReadQueries$EmpWrapper
from org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal}}
{{expected: java.util.ArrayList of size 3}}
[EmpWrapper(FullTimeEmployee:name = Michael), EmpWrapper(FullTimeEmployee:name
= Craig), EmpWrapper(FullTimeEmployee:name = Tillmann)]
{{got: java.util.ArrayList of size 3}}
[EmpWrapper(FullTimeEmployee:null), EmpWrapper(FullTimeEmployee:null),
EmpWrapper(FullTimeEmployee:null)]
{{ JUnit Jupiter:JDO843Test:testQuery16f()}}
{{ MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery16f', methodParameterTypes = '']}}
{{ => org.opentest4j.AssertionFailedError: Assertion (SampleQueries) failed:
}}
{{Wrong query result: }}
{{query: select into org.apache.jdo.tck.query.api.SampleReadQueries$EmpInfo
from org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal}}
{{expected: java.util.ArrayList of size 3}}
[EmpInfo(worker:Michael), EmpInfo(worker:Craig), EmpInfo(worker:Tillmann)]
{{got: java.util.ArrayList of size 3}}
[EmpInfo(worker:null), EmpInfo(worker:null), EmpInfo(worker:null)]{color}
was:
TCK Class {color:#00}SampleReadQueries implements the sample queries from
the JDO specification chapter 14.11.{color}
{color:#00}Methods testQuery15f and testQuery16f implement the typesafe
query version. The code uses QFullTimeEmployee.candidate() to access instances
of the candidate class. The query returns a wrong query result, When replacing
the call
{color}{color:#00}QFullTimeEmployee.candidate() by
QFullTimeEmployee.candidate("this")
The expected query resukt consist of three
{color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
instance (testQuery15f) or {color}EmpInfo instance
({color:#00}testQuery16f{color}). Instead the
{color:#00}FullTimeEmployee instance is null that gets wrappe into a
EmpWrapper/EmpInfo.{color}
{color:#00}Junit Test results when running the test Methods with
QFullTimeEmployee.candidate("this"):{color}
{color:#00} JUnit Jupiter:JDO843Test:testQuery15f()
MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery15f', methodParameterTypes = '']
=> org.opentest4j.AssertionFailedError: Assertion (SampleQueries) failed:
Wrong query result:
query: select into org.apache.jdo.tck.query.api.SampleReadQueries$EmpWrapper
from org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal
expected: java.util.ArrayList of size 3
[EmpWrapper(FullTimeEmployee:name = Michael), EmpWrapper(FullTimeEmployee:name
= Craig), EmpWrapper(FullTimeEmployee:name = Tillmann)]
got: java.util.ArrayList of size 3
[EmpWrapper(FullTimeEmployee:null), EmpWrapper(FullTimeEmployee:null),
EmpWrapper(FullTimeEmployee:null)]
JUnit Jupiter:JDO843Test:testQuery16f()
MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery16f', methodParameterTypes = '']
=> org.opentest4j.AssertionFailedError: Assertion (SampleQueries) failed:
Wrong query result:
query: select into org.apache.jdo.tck.query.api.SampleReadQueries$EmpInfo from
org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal
expected: java.util.ArrayList of size 3
[EmpInfo(worker:Michael), EmpInfo(worker:Craig), EmpInfo(worker:
[jira] [Updated] (JDO-843) JDOQLTypedQuery: issue with candidate("this") method
[
https://issues.apache.org/jira/browse/JDO-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-843:
-
Description:
TCK Class {color:#00}SampleReadQueries implements the sample queries from
the JDO specification chapter 14.11.{color}
{color:#00}Methods testQuery15f and testQuery16f implement the typesafe
query version. The code uses QFullTimeEmployee.candidate() to access instances
of the candidate class. The query returns a wrong query result, When replacing
the call
{color}{color:#00}QFullTimeEmployee.candidate() by
QFullTimeEmployee.candidate("this")
The expected query resukt consist of three
{color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
instance (testQuery15f) or {color}EmpInfo instance
({color:#00}testQuery16f{color}). Instead the
{color:#00}FullTimeEmployee instance is null that gets wrappe into a
EmpWrapper/EmpInfo.{color}
{color:#00}Junit Test results when running the test Methods with
QFullTimeEmployee.candidate("this"):{color}
{color:#00} JUnit Jupiter:JDO843Test:testQuery15f()
MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery15f', methodParameterTypes = '']
=> org.opentest4j.AssertionFailedError: Assertion (SampleQueries) failed:
Wrong query result:
query: select into org.apache.jdo.tck.query.api.SampleReadQueries$EmpWrapper
from org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal
expected: java.util.ArrayList of size 3
[EmpWrapper(FullTimeEmployee:name = Michael), EmpWrapper(FullTimeEmployee:name
= Craig), EmpWrapper(FullTimeEmployee:name = Tillmann)]
got: java.util.ArrayList of size 3
[EmpWrapper(FullTimeEmployee:null), EmpWrapper(FullTimeEmployee:null),
EmpWrapper(FullTimeEmployee:null)]
JUnit Jupiter:JDO843Test:testQuery16f()
MethodSource [className = 'org.apache.jdo.tck.query.api.JDO843Test',
methodName = 'testQuery16f', methodParameterTypes = '']
=> org.opentest4j.AssertionFailedError: Assertion (SampleQueries) failed:
Wrong query result:
query: select into org.apache.jdo.tck.query.api.SampleReadQueries$EmpInfo from
org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal
expected: java.util.ArrayList of size 3
[EmpInfo(worker:Michael), EmpInfo(worker:Craig), EmpInfo(worker:Tillmann)]
got: java.util.ArrayList of size 3
[EmpInfo(worker:null), EmpInfo(worker:null), EmpInfo(worker:null)]{color}
was:
TCK Class {color:#00}SampleReadQueries implements the sample queries from
the JDO specification chapter 14.11.
{color}
{color:#00}Methods testQuery15f and testQuery16f implement the typesafe
query version. The code uses QFullTimeEmployee.candidate() to access instances
of the candidate class. The query returns a wrong query result, When replacing
the call
{color}{color:#00}QFullTimeEmployee.candidate() by
QFullTimeEmployee.candidate("this")
The expected query resukt consist of three
{color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
instance (testQuery15f) or {color}EmpInfo instance
({color:#00}testQuery16f{color}). Instead the
{color:#00}FullTimeEmployee instance is null that gets wrappe into a
EmpWrapper/EmpInfo.{color}
> JDOQLTypedQuery: issue with candidate("this") method
> ----
>
> Key: JDO-843
> URL: https://issues.apache.org/jira/browse/JDO-843
> Project: JDO
> Issue Type: Bug
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Priority: Major
>
> TCK Class {color:#00}SampleReadQueries implements the sample queries from
> the JDO specification chapter 14.11.{color}
> {color:#00}Methods testQuery15f and testQuery16f implement the typesafe
> query version. The code uses QFullTimeEmployee.candidate() to access
> instances of the candidate class. The query returns a wrong query result,
> When replacing the call
> {color}{color:#00}QFullTimeEmployee.candidate() by
> QFullTimeEmployee.candidate("this")
> The expected query resukt consist of three
> {color}{color:#00}FullTimeEmployee instances wrapped into a EmpWrapper
> instance (testQuery15f) or {color}EmpInfo instance
> ({color:#00}testQuery16f{color}). Instead the
> {color:#00}FullTimeEmployee instance is null that gets wrappe into a
> EmpWrapper/EmpInfo.{color}
> {color:#00}Junit Test results when running the test Methods with
> QFullTimeEmployee.candidate("this"):{color}
> {color:#00} JUnit Jupiter:JDO843Test:testQuery15f()
> MethodSource [className =
[jira] [Commented] (JDO-842) Q class specification of candidate() method
[ https://issues.apache.org/jira/browse/JDO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879028#comment-17879028 ] Craig L Russell commented on JDO-842: - The public functions of JDOQLTypedQuery candidate and variable should be deprecated. In order to use them, the results must be cast to the appropriate metadata (Q-class), and casting does not work for persistent subclasses. The candidate and variable methods of the Q-class should require a String parameter and return a new instance. There is no reason to return a shared instance because the multi-threaded behavior of these instances when used in queries is not defined. If users want access to metadata outside the scope of queries, they can set up their own shared instances without relying on specified behavior. > Q class specification of candidate() method > --- > > Key: JDO-842 > URL: https://issues.apache.org/jira/browse/JDO-842 > Project: JDO > Issue Type: Bug > Components: specification >Affects Versions: JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > > The specification does not clearly specify the behavior of the Q classes in > Section "14.10 Typesafe Query Construction" > The examples in section "14.11 Examples" use the following methods of > generated Q-classes: > * candidate() > * candidate(String) > * variable(String) > Both candidate methods are used in the query examples, but they are not > specified as part of the typesafe query support. > Specific points that we should possibly mention: > * These methods should allow Q classes to be used concurrently. > Specifically, they should all return *new* instances. The current > specification allows returning shared multiple instances which causes > problems when used concurrently. (the reference implementation currently does > this for 'candidate()'). > * The reference implementation also has a 'parameter(String)' method. We may > want to add this to the spec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-841) Spec should clarify typesafe query Q class static fields and methods
[
https://issues.apache.org/jira/browse/JDO-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen resolved JDO-841.
--
Resolution: Duplicate
> Spec should clarify typesafe query Q class static fields and methods
> -
>
> Key: JDO-841
> URL: https://issues.apache.org/jira/browse/JDO-841
> Project: JDO
> Issue Type: Improvement
> Components: specification
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Priority: Major
>
> The current generated typesafe query Q class has a static methods:
>
> {code:java}
> public static QFullTimeEmployee candidate(String name)
> public static QFullTimeEmployee candidate() {code}
>
> The current spec does not specify these methods but uses them in the query
> examples.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JDO-842) Q class specification of candidate() method
[ https://issues.apache.org/jira/browse/JDO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-842: - Description: The specification does not clearly specify the behavior of the Q classes in Section "14.10 Typesafe Query Construction" The examples in section "14.11 Examples" use the following methods of generated Q-classes: * candidate() * candidate(String) * variable(String) Both candidate methods are used in the query examples, but they are not specified as part of the typesafe query support. Specific points that we should possibly mention: * These methods should allow Q classes to be used concurrently. Specifically, they should all return *new* instances. The current specification allows returning shared multiple instances which causes problems when used concurrently. (the reference implementation currently does this for 'candidate()'). * The reference implementation also has a 'parameter(String)' method. We may want to add this to the spec. was: The specification does not clearly specify the behavior of the Q classes in Section "14.10 Typesafe Query Construction" The examples in section "14.11 Examples" use the following methods of generated Q-classes: * candidate() * candidate(String) * variable(String) Specific points that we should possibly mention: * These methods should allow Q classes to be used concurrently. Specifically, they should all return *new* instances. The current specification allows returning shared multiple instances which causes problems when used concurrently. (the reference implementation currently does this for 'candidate()'). * The reference implementation also has a 'parameter(String)' method. We may want to add this to the spec. > Q class specification of candidate() method > --- > > Key: JDO-842 > URL: https://issues.apache.org/jira/browse/JDO-842 > Project: JDO > Issue Type: Bug > Components: specification >Affects Versions: JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > > The specification does not clearly specify the behavior of the Q classes in > Section "14.10 Typesafe Query Construction" > The examples in section "14.11 Examples" use the following methods of > generated Q-classes: > * candidate() > * candidate(String) > * variable(String) > Both candidate methods are used in the query examples, but they are not > specified as part of the typesafe query support. > Specific points that we should possibly mention: > * These methods should allow Q classes to be used concurrently. > Specifically, they should all return *new* instances. The current > specification allows returning shared multiple instances which causes > problems when used concurrently. (the reference implementation currently does > this for 'candidate()'). > * The reference implementation also has a 'parameter(String)' method. We may > want to add this to the spec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-842) Q class specification of candidate() method
Tilmann Zäschke created JDO-842: --- Summary: Q class specification of candidate() method Key: JDO-842 URL: https://issues.apache.org/jira/browse/JDO-842 Project: JDO Issue Type: Bug Components: specification Affects Versions: JDO 3.2.1 Reporter: Tilmann Zäschke The specification does not clearly specify the behavior of the Q classes in Section "14.10 Typesafe Query Construction" The examples in section "14.11 Examples" use the following methods of generated Q-classes: * candidate() * candidate(String) * variable(String) Specific points that we should possibly mention: * These methods should allow Q classes to be used concurrently. Specifically, they should all return *new* instances. The current specification allows returning shared multiple instances which causes problems when used concurrently. (the reference implementation currently does this for 'candidate()'). * The reference implementation also has a 'parameter(String)' method. We may want to add this to the spec. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-841) Spec should clarify typesafe query Q class static fields and methods
Michael Bouschen created JDO-841:
Summary: Spec should clarify typesafe query Q class static fields
and methods
Key: JDO-841
URL: https://issues.apache.org/jira/browse/JDO-841
Project: JDO
Issue Type: Improvement
Components: specification
Affects Versions: JDO 3.2.1
Reporter: Michael Bouschen
The current generated typesafe query Q class has a static methods:
{code:java}
public static QFullTimeEmployee candidate(String name)
public static QFullTimeEmployee candidate() {code}
The current spec does not specify these methods but uses them in the query
examples.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JDO-840) Fix changes links on JDO news site
[ https://issues.apache.org/jira/browse/JDO-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-840: - Fix Version/s: (was: JDO 3.2.2) > Fix changes links on JDO news site > -- > > Key: JDO-840 > URL: https://issues.apache.org/jira/browse/JDO-840 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > > The current JDO site lists the JDO release on the start page. For each > release there is a link to the Jira version listing all the changes for the > particular release. For the releases older than JDO 3.2 you must be logged in > into Jira to see the list of changes. For the releases JDO 3.2.1 and JDO 3.2 > this is not necessary. > * Change the link for the older release such that it is not necessary to be > logged into Jira to see the list. > * Releases older than 3.2 may not be downloaded anymore, so th etext "You > can download the release from ..." is misleading and shoudl be skipped. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JDO-840) Fix changes links on JDO news site
[ https://issues.apache.org/jira/browse/JDO-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen closed JDO-840. > Fix changes links on JDO news site > -- > > Key: JDO-840 > URL: https://issues.apache.org/jira/browse/JDO-840 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > > The current JDO site lists the JDO release on the start page. For each > release there is a link to the Jira version listing all the changes for the > particular release. For the releases older than JDO 3.2 you must be logged in > into Jira to see the list of changes. For the releases JDO 3.2.1 and JDO 3.2 > this is not necessary. > * Change the link for the older release such that it is not necessary to be > logged into Jira to see the list. > * Releases older than 3.2 may not be downloaded anymore, so th etext "You > can download the release from ..." is misleading and shoudl be skipped. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-840) Fix changes links on JDO news site
[ https://issues.apache.org/jira/browse/JDO-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen resolved JDO-840. -- Resolution: Fixed > Fix changes links on JDO news site > -- > > Key: JDO-840 > URL: https://issues.apache.org/jira/browse/JDO-840 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2 > > > The current JDO site lists the JDO release on the start page. For each > release there is a link to the Jira version listing all the changes for the > particular release. For the releases older than JDO 3.2 you must be logged in > into Jira to see the list of changes. For the releases JDO 3.2.1 and JDO 3.2 > this is not necessary. > * Change the link for the older release such that it is not necessary to be > logged into Jira to see the list. > * Releases older than 3.2 may not be downloaded anymore, so th etext "You > can download the release from ..." is misleading and shoudl be skipped. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-840) Fix changes links on JDO news site
Michael Bouschen created JDO-840: Summary: Fix changes links on JDO news site Key: JDO-840 URL: https://issues.apache.org/jira/browse/JDO-840 Project: JDO Issue Type: Improvement Components: site and infrastructure Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen The current JDO site lists the JDO release on the start page. For each release there is a link to the Jira version listing all the changes for the particular release. For the releases older than JDO 3.2 you must be logged in into Jira to see the list of changes. For the releases JDO 3.2.1 and JDO 3.2 this is not necessary. * Change the link for the older release such that it is not necessary to be logged into Jira to see the list. * Releases older than 3.2 may not be downloaded anymore, so th etext "You can download the release from ..." is misleading and shoudl be skipped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JDO-840) Fix changes links on JDO news site
[ https://issues.apache.org/jira/browse/JDO-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen reassigned JDO-840: Assignee: Michael Bouschen > Fix changes links on JDO news site > -- > > Key: JDO-840 > URL: https://issues.apache.org/jira/browse/JDO-840 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > > The current JDO site lists the JDO release on the start page. For each > release there is a link to the Jira version listing all the changes for the > particular release. For the releases older than JDO 3.2 you must be logged in > into Jira to see the list of changes. For the releases JDO 3.2.1 and JDO 3.2 > this is not necessary. > * Change the link for the older release such that it is not necessary to be > logged into Jira to see the list. > * Releases older than 3.2 may not be downloaded anymore, so th etext "You > can download the release from ..." is misleading and shoudl be skipped. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-840) Fix changes links on JDO news site
[ https://issues.apache.org/jira/browse/JDO-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-840: - Fix Version/s: JDO 3.2.2 > Fix changes links on JDO news site > -- > > Key: JDO-840 > URL: https://issues.apache.org/jira/browse/JDO-840 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2 > > > The current JDO site lists the JDO release on the start page. For each > release there is a link to the Jira version listing all the changes for the > particular release. For the releases older than JDO 3.2 you must be logged in > into Jira to see the list of changes. For the releases JDO 3.2.1 and JDO 3.2 > this is not necessary. > * Change the link for the older release such that it is not necessary to be > logged into Jira to see the list. > * Releases older than 3.2 may not be downloaded anymore, so th etext "You > can download the release from ..." is misleading and shoudl be skipped. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-836) TCK: QueryCancel Test class fails
[ https://issues.apache.org/jira/browse/JDO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17823326#comment-17823326 ] Michael Bouschen commented on JDO-836: -- New branch JDO-836: * Added cancel.conf configuration file * Added log Statements in QueryCancel TCK class * Disabled second test method in QueryCancel to avaoid parallel threads > TCK: QueryCancel Test class fails > - > > Key: JDO-836 > URL: https://issues.apache.org/jira/browse/JDO-836 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Attachments: cancel.conf > > > The TCK test class QueryCancel fails. It is not part of any test > configuration so it is never executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JDO-836) TCK: QueryCancel Test class fails
[
https://issues.apache.org/jira/browse/JDO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820861#comment-17820861
]
Michael Bouschen edited comment on JDO-836 at 2/27/24 7:20 PM:
---
I added some log statements to check that query cancel is called after
query.execute has been called:
22:14:11,040 (Query Executor) INFO [org.apache.jdo.tck] - Start query execute
1708809251037
22:14:12,038 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - Start
query cancel 1708809252038
22:14:12,039 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - End query
cancel 1708809252039
22:15:00,860 (Query Executor) INFO [org.apache.jdo.tck] - End query execute
1708809300860
22:15:00,861 (Query Executor) INFO [org.apache.jdo.tck] - query execute took
49823ms
You can use the attched configuration cancel.conf to run the QueryCancel TCK
test.
Copy the file cancel.conf to tck/src/main/resources/conf {{and}}
call mvn -Djdo.tck.cfglist=cancel.conf clean install in the tck subdirectory.
was (Author: mbo):
I added some log statements to check that query cancel is called after
query.execute has been called:
22:14:11,040 (Query Executor) INFO [org.apache.jdo.tck] - Start query execute
1708809251037
22:14:12,038 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - Start
query cancel 1708809252038
22:14:12,039 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - End query
cancel 1708809252039
22:15:00,860 (Query Executor) INFO [org.apache.jdo.tck] - End query execute
1708809300860
22:15:00,861 (Query Executor) INFO [org.apache.jdo.tck] - query execute took
49823ms
You can use the attched configuration cancel.conf to run the QueryCancel TCK
test.
Copy the file cancel.conf to tck/src/main/resources/conf {{and}}
call mvn -Djdo.tck.cfglist=cancel.conf clean install
> TCK: QueryCancel Test class fails
> -
>
> Key: JDO-836
> URL: https://issues.apache.org/jira/browse/JDO-836
> Project: JDO
> Issue Type: Task
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Priority: Major
> Attachments: cancel.conf
>
>
> The TCK test class QueryCancel fails. It is not part of any test
> configuration so it is never executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JDO-836) TCK: QueryCancel Test class fails
[
https://issues.apache.org/jira/browse/JDO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820861#comment-17820861
]
Michael Bouschen edited comment on JDO-836 at 2/27/24 7:19 PM:
---
I added some log statements to check that query cancel is called after
query.execute has been called:
22:14:11,040 (Query Executor) INFO [org.apache.jdo.tck] - Start query execute
1708809251037
22:14:12,038 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - Start
query cancel 1708809252038
22:14:12,039 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - End query
cancel 1708809252039
22:15:00,860 (Query Executor) INFO [org.apache.jdo.tck] - End query execute
1708809300860
22:15:00,861 (Query Executor) INFO [org.apache.jdo.tck] - query execute took
49823ms
You can use the attched configuration cancel.conf to run the QueryCancel TCK
test.
Copy the file cancel.conf to tck/src/main/resources/conf {{and}}
call mvn -Djdo.tck.cfglist=cancel.conf clean install
was (Author: mbo):
I added some lof statement to check that query cancel is called after
query.execute has been called:
22:14:11,040 (Query Executor) INFO [org.apache.jdo.tck] - Start query execute
1708809251037
22:14:12,038 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - Start
query cancel 1708809252038
22:14:12,039 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - End query
cancel 1708809252039
22:15:00,860 (Query Executor) INFO [org.apache.jdo.tck] - End query execute
1708809300860
22:15:00,861 (Query Executor) INFO [org.apache.jdo.tck] - query execute took
49823ms
You can use the attched configuration cancel.conf to run the QueryCancel TCK
test.
Copy the file cancel.conf to tck/src/main/resources/conf {{and}}
call mvn -Djdo.tck.cfglist=cancel.conf clean install
> TCK: QueryCancel Test class fails
> -
>
> Key: JDO-836
> URL: https://issues.apache.org/jira/browse/JDO-836
> Project: JDO
> Issue Type: Task
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Priority: Major
> Attachments: cancel.conf
>
>
> The TCK test class QueryCancel fails. It is not part of any test
> configuration so it is never executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JDO-836) TCK: QueryCancel Test class fails
[
https://issues.apache.org/jira/browse/JDO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820861#comment-17820861
]
Michael Bouschen edited comment on JDO-836 at 2/27/24 7:18 PM:
---
I added some lof statement to check that query cancel is called after
query.execute has been called:
22:14:11,040 (Query Executor) INFO [org.apache.jdo.tck] - Start query execute
1708809251037
22:14:12,038 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - Start
query cancel 1708809252038
22:14:12,039 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - End query
cancel 1708809252039
22:15:00,860 (Query Executor) INFO [org.apache.jdo.tck] - End query execute
1708809300860
22:15:00,861 (Query Executor) INFO [org.apache.jdo.tck] - query execute took
49823ms
You can use the attched configuration cancel.conf to run the QueryCancel TCK
test.
Copy the file cancel.conf to tck/src/main/resources/conf {{and}}
call mvn -Djdo.tck.cfglist=cancel.conf clean install
was (Author: mbo):
I added some lof statement to check thta query cancel is called after
query.execute has been called:
22:14:11,040 (Query Executor) INFO [org.apache.jdo.tck] - Start query execute
1708809251037
22:14:12,038 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - Start
query cancel 1708809252038
22:14:12,039 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - End query
cancel 1708809252039
22:15:00,860 (Query Executor) INFO [org.apache.jdo.tck] - End query execute
1708809300860
22:15:00,861 (Query Executor) INFO [org.apache.jdo.tck] - query execute took
49823ms
You can use the attched configuration cancel.conf to run the QueryCancel TCK
test.
Copy the file cancel.conf to {{tck/src/main/resources/conf }}and call {{mvn
-Djdo.tck.cfglist=cancel.conf clean install}}
> TCK: QueryCancel Test class fails
> -
>
> Key: JDO-836
> URL: https://issues.apache.org/jira/browse/JDO-836
> Project: JDO
> Issue Type: Task
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Priority: Major
> Attachments: cancel.conf
>
>
> The TCK test class QueryCancel fails. It is not part of any test
> configuration so it is never executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JDO-838) Clarify doc for query cancel()/cancelAll()
[ https://issues.apache.org/jira/browse/JDO-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke resolved JDO-838. - Resolution: Fixed > Clarify doc for query cancel()/cancelAll() > -- > > Key: JDO-838 > URL: https://issues.apache.org/jira/browse/JDO-838 > Project: JDO > Issue Type: Improvement > Components: api, specification >Affects Versions: JDO 3.2, JDO 3.2.1 >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > Fix For: JDO 3.2.2 > > > The documentation (javadoc + spec) should be updated to clarify what the > argument of cancel() is and what cancelAll() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JDO-838) Clarify doc for query cancel()/cancelAll()
[ https://issues.apache.org/jira/browse/JDO-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke reassigned JDO-838: --- Assignee: Tilmann Zäschke > Clarify doc for query cancel()/cancelAll() > -- > > Key: JDO-838 > URL: https://issues.apache.org/jira/browse/JDO-838 > Project: JDO > Issue Type: Improvement > Components: api, specification >Affects Versions: JDO 3.2, JDO 3.2.1 >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > Fix For: JDO 3.2.2 > > > The documentation (javadoc + spec) should be updated to clarify what the > argument of cancel() is and what cancelAll() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-836) TCK: QueryCancel Test class fails
[
https://issues.apache.org/jira/browse/JDO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820861#comment-17820861
]
Michael Bouschen commented on JDO-836:
--
I added some lof statement to check thta query cancel is called after
query.execute has been called:
22:14:11,040 (Query Executor) INFO [org.apache.jdo.tck] - Start query execute
1708809251037
22:14:12,038 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - Start
query cancel 1708809252038
22:14:12,039 (ForkJoinPool-1-worker-19) INFO [org.apache.jdo.tck] - End query
cancel 1708809252039
22:15:00,860 (Query Executor) INFO [org.apache.jdo.tck] - End query execute
1708809300860
22:15:00,861 (Query Executor) INFO [org.apache.jdo.tck] - query execute took
49823ms
You can use the attched configuration cancel.conf to run the QueryCancel TCK
test.
Copy the file cancel.conf to {{tck/src/main/resources/conf }}and call {{mvn
-Djdo.tck.cfglist=cancel.conf clean install}}
> TCK: QueryCancel Test class fails
> -
>
> Key: JDO-836
> URL: https://issues.apache.org/jira/browse/JDO-836
> Project: JDO
> Issue Type: Task
> Components: tck
>Affects Versions: JDO 3.2.1
>Reporter: Michael Bouschen
>Priority: Major
> Attachments: cancel.conf
>
>
> The TCK test class QueryCancel fails. It is not part of any test
> configuration so it is never executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JDO-836) TCK: QueryCancel Test class fails
[ https://issues.apache.org/jira/browse/JDO-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-836: - Attachment: cancel.conf > TCK: QueryCancel Test class fails > - > > Key: JDO-836 > URL: https://issues.apache.org/jira/browse/JDO-836 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Attachments: cancel.conf > > > The TCK test class QueryCancel fails. It is not part of any test > configuration so it is never executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-831) tck: improve tck tests for performance
[ https://issues.apache.org/jira/browse/JDO-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen resolved JDO-831. -- Resolution: Fixed TCK query test cases have been optimzed. > tck: improve tck tests for performance > -- > > Key: JDO-831 > URL: https://issues.apache.org/jira/browse/JDO-831 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The performance of the tck test suite might be improved by using: > * multi-threading > * parallel execution of tests that do not change the database > * setup/teardown optimization for tests that do not change the database -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-838) Clarify doc for query cancel()/cancelAll()
[ https://issues.apache.org/jira/browse/JDO-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820392#comment-17820392 ] Eric Zoerner commented on JDO-838: -- I would change "that run in the specified thread" to "that are running in the specified thread". Otherwise, looks good to me – but I'm not actually a contributor so can't comment on your PR or approve it. > Clarify doc for query cancel()/cancelAll() > -- > > Key: JDO-838 > URL: https://issues.apache.org/jira/browse/JDO-838 > Project: JDO > Issue Type: Improvement > Components: api, specification >Affects Versions: JDO 3.2, JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > Fix For: JDO 3.2.2 > > > The documentation (javadoc + spec) should be updated to clarify what the > argument of cancel() is and what cancelAll() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-838) Clarify doc for query cancel()/cancelAll()
[ https://issues.apache.org/jira/browse/JDO-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818970#comment-17818970 ] Tilmann Zäschke commented on JDO-838: - I added a change for cancel(Thread). Could you have a look? > Clarify doc for query cancel()/cancelAll() > -- > > Key: JDO-838 > URL: https://issues.apache.org/jira/browse/JDO-838 > Project: JDO > Issue Type: Improvement > Components: api, specification >Affects Versions: JDO 3.2, JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > Fix For: JDO 3.2.2 > > > The documentation (javadoc + spec) should be updated to clarify what the > argument of cancel() is and what cancelAll() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-839) Lock at XML parser factory settings
[ https://issues.apache.org/jira/browse/JDO-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke resolved JDO-839. - Resolution: Fixed > Lock at XML parser factory settings > --- > > Key: JDO-839 > URL: https://issues.apache.org/jira/browse/JDO-839 > Project: JDO > Issue Type: Bug > Components: api >Affects Versions: JDO 3.2, JDO 3.2.1 >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > Fix For: JDO 3.2.2 > > > Automatic code scanning reported the following problem: > https://github.com/apache/db-jdo/security/code-scanning/1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-838) Clarify doc for query cancel()/cancelAll()
[
https://issues.apache.org/jira/browse/JDO-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818206#comment-17818206
]
Eric Zoerner commented on JDO-838:
--
The current javadoc for cancelAll() does sound like it cancels _all_ queries,
not just executions for this instance of Query. The spec is not any clearer
than the javadocs.
It looks like the reference implementation (datanucleus) only cancels
executions of _this_ {_}query{_}, both for cancelAll() and cancel(Thread). So I
agree with your change to the javadocs. There also should probably be a
clarification in cancel(Thread)
> Clarify doc for query cancel()/cancelAll()
> --
>
> Key: JDO-838
> URL: https://issues.apache.org/jira/browse/JDO-838
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.2, JDO 3.2.1
>Reporter: Tilmann Zäschke
>Priority: Major
> Fix For: JDO 3.2.2
>
>
> The documentation (javadoc + spec) should be updated to clarify what the
> argument of cancel() is and what cancelAll() does.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JDO-838) Clarify doc for query cancel()/cancelAll()
[ https://issues.apache.org/jira/browse/JDO-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818195#comment-17818195 ] Tilmann Zäschke commented on JDO-838: - After some consideration, I actually propose to *not* change the javadoc, it now seems quite clear to me. What do others think? I still created the PR, see link [here|https://github.com/apache/db-jdo/pull/92] > Clarify doc for query cancel()/cancelAll() > -- > > Key: JDO-838 > URL: https://issues.apache.org/jira/browse/JDO-838 > Project: JDO > Issue Type: Improvement > Components: api, specification >Affects Versions: JDO 3.2, JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > Fix For: JDO 3.2.2 > > > The documentation (javadoc + spec) should be updated to clarify what the > argument of cancel() is and what cancelAll() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-839) Lock at XML parser factory settings
Tilmann Zäschke created JDO-839: --- Summary: Lock at XML parser factory settings Key: JDO-839 URL: https://issues.apache.org/jira/browse/JDO-839 Project: JDO Issue Type: Bug Components: api Affects Versions: JDO 3.2.1, JDO 3.2 Reporter: Tilmann Zäschke Assignee: Tilmann Zäschke Fix For: JDO 3.2.2 Automatic code scanning reported the following problem: https://github.com/apache/db-jdo/security/code-scanning/1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-838) Clarify doc for query cancel()/cancelAll()
Tilmann Zäschke created JDO-838: --- Summary: Clarify doc for query cancel()/cancelAll() Key: JDO-838 URL: https://issues.apache.org/jira/browse/JDO-838 Project: JDO Issue Type: Improvement Components: api, specification Affects Versions: JDO 3.2.1, JDO 3.2 Reporter: Tilmann Zäschke Fix For: JDO 3.2.2 The documentation (javadoc + spec) should be updated to clarify what the argument of cancel() is and what cancelAll() does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-837) TCK: add a JDO flag to enable/disable parallel execution
[ https://issues.apache.org/jira/browse/JDO-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809131#comment-17809131 ] Michael Bouschen commented on JDO-837: -- The flag jdo.tck.parallel.execution ist added to the branch JDO-831 > TCK: add a JDO flag to enable/disable parallel execution > > > Key: JDO-837 > URL: https://issues.apache.org/jira/browse/JDO-837 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > > Add a flag to RunTCK to enable/disable parallel execution of the test methods > in TCK test classes: > jdo.tck.parallel.execution=false|true default true > The flag is used to set the flag junit.jupiter.execution.parallel.enabled -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-837) TCK: add a JDO flag to enable/disable parallel execution
Michael Bouschen created JDO-837: Summary: TCK: add a JDO flag to enable/disable parallel execution Key: JDO-837 URL: https://issues.apache.org/jira/browse/JDO-837 Project: JDO Issue Type: Task Components: tck Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen Add a flag to RunTCK to enable/disable parallel execution of the test methods in TCK test classes: jdo.tck.parallel.execution=false|true default true The flag is used to set the flag junit.jupiter.execution.parallel.enabled -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JDO-837) TCK: add a JDO flag to enable/disable parallel execution
[ https://issues.apache.org/jira/browse/JDO-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen reassigned JDO-837: Assignee: Michael Bouschen > TCK: add a JDO flag to enable/disable parallel execution > > > Key: JDO-837 > URL: https://issues.apache.org/jira/browse/JDO-837 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > > Add a flag to RunTCK to enable/disable parallel execution of the test methods > in TCK test classes: > jdo.tck.parallel.execution=false|true default true > The flag is used to set the flag junit.jupiter.execution.parallel.enabled -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-836) TCK: QueryCancel Test class fails
Michael Bouschen created JDO-836: Summary: TCK: QueryCancel Test class fails Key: JDO-836 URL: https://issues.apache.org/jira/browse/JDO-836 Project: JDO Issue Type: Task Components: tck Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen The TCK test class QueryCancel fails. It is not part of any test configuration so it is never executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-835) TCK: Check ResultClassRequirementsMap when running multithreaded
Michael Bouschen created JDO-835: Summary: TCK: Check ResultClassRequirementsMap when running multithreaded Key: JDO-835 URL: https://issues.apache.org/jira/browse/JDO-835 Project: JDO Issue Type: Task Components: tck Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen The test cases of ResultClassRequirementsMap return wrong results when running multithreaded, see source code for details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-830) tck: Migrate JUnit tests to version 5
[ https://issues.apache.org/jira/browse/JDO-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen resolved JDO-830. -- Resolution: Fixed > tck: Migrate JUnit tests to version 5 > - > > Key: JDO-830 > URL: https://issues.apache.org/jira/browse/JDO-830 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > The tck tests in the tck subproject are using JUnit 4 and are written in a > JUnit 3.8.1 style. The tests should be migrated to JUnit 5. > Links: > * [https://junit.org/junit5/docs/current/user-guide/] > * [https://www.baeldung.com/junit-5] > * [https://www.baeldung.com/junit-5-migration] > * > [https://stackoverflow.com/questions/47158583/executing-junit-4-and-junit-5-tests-in-a-same-build] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-834) Consider moving files instead of copying
[ https://issues.apache.org/jira/browse/JDO-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke resolved JDO-834. - Resolution: Fixed > Consider moving files instead of copying > > > Key: JDO-834 > URL: https://issues.apache.org/jira/browse/JDO-834 > Project: JDO > Issue Type: Improvement > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Minor > Fix For: JDO 3.3 > > > The RunTck class copies log and configuration files. Look into moving them > instead of copying. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-834) Consider moving files instead of copying
[ https://issues.apache.org/jira/browse/JDO-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke updated JDO-834: Priority: Minor (was: Major) > Consider moving files instead of copying > > > Key: JDO-834 > URL: https://issues.apache.org/jira/browse/JDO-834 > Project: JDO > Issue Type: Improvement > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Minor > Fix For: JDO 3.3 > > > The RunTck class copies log and configuration files. Look into moving them > instead of copying. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-830) tck: Migrate JUnit tests to version 5
[ https://issues.apache.org/jira/browse/JDO-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-830: - Fix Version/s: (was: JDO 3.2.2) > tck: Migrate JUnit tests to version 5 > - > > Key: JDO-830 > URL: https://issues.apache.org/jira/browse/JDO-830 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > The tck tests in the tck subproject are using JUnit 4 and are written in a > JUnit 3.8.1 style. The tests should be migrated to JUnit 5. > Links: > * [https://junit.org/junit5/docs/current/user-guide/] > * [https://www.baeldung.com/junit-5] > * [https://www.baeldung.com/junit-5-migration] > * > [https://stackoverflow.com/questions/47158583/executing-junit-4-and-junit-5-tests-in-a-same-build] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-834) Consider moving files instead of copying
Tilmann Zäschke created JDO-834: --- Summary: Consider moving files instead of copying Key: JDO-834 URL: https://issues.apache.org/jira/browse/JDO-834 Project: JDO Issue Type: Improvement Components: tck Affects Versions: JDO 3.2.1 Reporter: Tilmann Zäschke Assignee: Tilmann Zäschke Fix For: JDO 3.3 The RunTck class copies log and configuration files. Look into moving them instead of copying. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JDO-822) Verify compatibility with JDK 21
[ https://issues.apache.org/jira/browse/JDO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780029#comment-17780029 ] Andy Jefferson edited comment on JDO-822 at 11/1/23 7:58 AM: - FYI, DataNucleus v6.0.6 has latest ASM (v9.6), so supports up to and including Java 22. Plugins needed for TCK are (minimum) datanucleus-core 6.0.6, datanucleus-api-jdo 6.0.1, datanucleus-api-jpa 6.0.1, datanucleus-rdbms 6.0.6 See [https://github.com/datanucleus/datanucleus-core/issues/495] and [https://github.com/datanucleus/datanucleus-core/issues/499] was (Author: andy): FYI, DataNucleus GitHub master (unreleased) has latest ASM, so should "support" Java 21. https://github.com/datanucleus/datanucleus-core/issues/495 > Verify compatibility with JDK 21 > > > 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 > Fix For: JDO 3.2.2 > > > JDK 21 reached [General > Availability|https://openjdk.org/projects/jdk8/milestones#General_Availability] > on 19 September 2023, so we should go for JDK 21 instaed of JDK 20. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-822) Verify compatibility with JDK 21
[ https://issues.apache.org/jira/browse/JDO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bouschen updated JDO-822: Fix Version/s: JDO 3.2.2 (was: JDO 3.3) > Verify compatibility with JDK 21 > > > 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 > Fix For: JDO 3.2.2 > > > JDK 21 reached [General > Availability|https://openjdk.org/projects/jdk8/milestones#General_Availability] > on 19 September 2023, so we should go for JDK 21 instaed of JDK 20. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-822) Verify compatibility with JDK 21
[ https://issues.apache.org/jira/browse/JDO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bouschen updated JDO-822: Fix Version/s: JDO 3.3 > Verify compatibility with JDK 21 > > > 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 > Fix For: JDO 3.3 > > > JDK 21 reached [General > Availability|https://openjdk.org/projects/jdk8/milestones#General_Availability] > on 19 September 2023, so we should go for JDK 21 instaed of JDK 20. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-822) Verify compatibility with JDK 21
[ https://issues.apache.org/jira/browse/JDO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bouschen resolved JDO-822. - Resolution: Fixed > Verify compatibility with JDK 21 > > > 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 > > JDK 21 reached [General > Availability|https://openjdk.org/projects/jdk8/milestones#General_Availability] > on 19 September 2023, so we should go for JDK 21 instaed of JDK 20. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-830) tck: Migrate JUnit tests to version 5
[ https://issues.apache.org/jira/browse/JDO-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781491#comment-17781491 ] Michael Bouschen commented on JDO-830: -- First version of JUnit 5 migration: https://github.com/apache/db-jdo/tree/JDO-830 > tck: Migrate JUnit tests to version 5 > - > > Key: JDO-830 > URL: https://issues.apache.org/jira/browse/JDO-830 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The tck tests in the tck subproject are using JUnit 4 and are written in a > JUnit 3.8.1 style. The tests should be migrated to JUnit 5. > Links: > * [https://junit.org/junit5/docs/current/user-guide/] > * [https://www.baeldung.com/junit-5] > * [https://www.baeldung.com/junit-5-migration] > * > [https://stackoverflow.com/questions/47158583/executing-junit-4-and-junit-5-tests-in-a-same-build] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-822) Verify compatibility with JDK 21
[ https://issues.apache.org/jira/browse/JDO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780029#comment-17780029 ] Andy Jefferson commented on JDO-822: FYI, DataNucleus GitHub master (unreleased) has latest ASM, so should "support" Java 21. https://github.com/datanucleus/datanucleus-core/issues/495 > Verify compatibility with JDK 21 > > > 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 > > JDK 21 reached [General > Availability|https://openjdk.org/projects/jdk8/milestones#General_Availability] > on 19 September 2023, so we should go for JDK 21 instaed of JDK 20. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-822) Verify compatibility with JDK 21
[ https://issues.apache.org/jira/browse/JDO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-822: - Description: JDK 21 reached [General Availability|https://openjdk.org/projects/jdk8/milestones#General_Availability] on 19 September 2023, so we should go for JDK 21 instaed of JDK 20. Summary: Verify compatibility with JDK 21 (was: Verify compatibility with JDK 20) > Verify compatibility with JDK 21 > > > 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 > > JDK 21 reached [General > Availability|https://openjdk.org/projects/jdk8/milestones#General_Availability] > on 19 September 2023, so we should go for JDK 21 instaed of JDK 20. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JDO-830) tck: Migrate JUnit tests to version 5
[ https://issues.apache.org/jira/browse/JDO-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen reassigned JDO-830: Assignee: Michael Bouschen > tck: Migrate JUnit tests to version 5 > - > > Key: JDO-830 > URL: https://issues.apache.org/jira/browse/JDO-830 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The tck tests in the tck subproject are using JUnit 4 and are written in a > JUnit 3.8.1 style. The tests should be migrated to JUnit 5. > Links: > * [https://junit.org/junit5/docs/current/user-guide/] > * [https://www.baeldung.com/junit-5] > * [https://www.baeldung.com/junit-5-migration] > * > [https://stackoverflow.com/questions/47158583/executing-junit-4-and-junit-5-tests-in-a-same-build] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-833) Use automated release infra for JDO releases
[ https://issues.apache.org/jira/browse/JDO-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-833: - Description: Signing releases using automated release infra is a possibility for us to use for the next release. See https://infra.apache.org/release-signing.html#automated-release-signing was:Signing releases using automated release infra is a possibility for us to use for the next release. > Use automated release infra for JDO releases > > > Key: JDO-833 > URL: https://issues.apache.org/jira/browse/JDO-833 > Project: JDO > Issue Type: Task > Components: site and infrastructure >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > Signing releases using automated release infra is a possibility for us to use > for the next release. > See https://infra.apache.org/release-signing.html#automated-release-signing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-833) Use automated release infra for JDO releases
Michael Bouschen created JDO-833: Summary: Use automated release infra for JDO releases Key: JDO-833 URL: https://issues.apache.org/jira/browse/JDO-833 Project: JDO Issue Type: Task Components: site and infrastructure Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen Signing releases using automated release infra is a possibility for us to use for the next release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-833) Use automated release infra for JDO releases
[ https://issues.apache.org/jira/browse/JDO-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-833: - Fix Version/s: JDO 3.2.2 JDO 3.3 > Use automated release infra for JDO releases > > > Key: JDO-833 > URL: https://issues.apache.org/jira/browse/JDO-833 > Project: JDO > Issue Type: Task > Components: site and infrastructure >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > Signing releases using automated release infra is a possibility for us to use > for the next release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-832) Remove RunTCK option jdo.tck.skipJndi
[ https://issues.apache.org/jira/browse/JDO-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen resolved JDO-832. -- Resolution: Fixed > Remove RunTCK option jdo.tck.skipJndi > - > > Key: JDO-832 > URL: https://issues.apache.org/jira/browse/JDO-832 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > With JDO-827 the TCK comes with its own JNDI mock implementation. > Without an JNDI implemention we needed to skip the JNDI TCK test cases when > running the tck from an automatic build. This is not necessary anymore, so we > do not need the option jdo.tck.skipJndi anymore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-827) Consider (re-)moving JNDI support
[
https://issues.apache.org/jira/browse/JDO-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke resolved JDO-827.
-
Fix Version/s: JDO 3.2.2
JDO 3.3
Assignee: Tilmann Zäschke
Resolution: Fixed
> Consider (re-)moving JNDI support
> -
>
> Key: JDO-827
> URL: https://issues.apache.org/jira/browse/JDO-827
> Project: JDO
> Issue Type: Improvement
> Components: api
>Affects Versions: JDO 3.2, JDO 3.2.1
>Reporter: Tilmann Zäschke
>Assignee: Tilmann Zäschke
>Priority: Major
> Fix For: JDO 3.2.2, JDO 3.3
>
>
> The JDO API has two JNDI dependencies:
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context)}} and
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context, ClassLoader loader)}}
> The JNDI dependency complicates building and running the TCK (because of the
> non-free nature of the implementation). It is also the only part of the API
> that stops it being compatible with Android. The CI runs currently have all
> tests disabled that depend on JNDI (TBD, how does it compile without the
> classes???).
> There are many options for simplifying this issue:
> * Drop JNDI support? Is JNDI still used? Probably yes, see JDBC, JPA, EJB,
> JMS.
> * Move the two methods into a separate JDOJNDIHelper. This would (probably)
> allow us to more easily exclude it from builds when desired, for example
> using Java 9 modules.
> * Provide a dummy implementation of the JNDI classes. This would allow
> compiling the API without problems (also on Android), but we would still need
> to exclude it from tests.
> * Switch to a free leightweight implementation, e.g.
> [https://github.com/h-thurow/Simple-JNDI] or
> https://github.com/dattack/standalone-jndi
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JDO-832) Remove RunTCK option jdo.tck.skipJndi
Michael Bouschen created JDO-832: Summary: Remove RunTCK option jdo.tck.skipJndi Key: JDO-832 URL: https://issues.apache.org/jira/browse/JDO-832 Project: JDO Issue Type: Task Components: tck Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen Assignee: Michael Bouschen Fix For: JDO 3.2.2, JDO 3.3 With JDO-827 the TCK comes with its own JNDI mock implementation. Without an JNDI implemention we needed to skip the JNDI TCK test cases when running the tck from an automatic build. This is not necessary anymore, so we do not need the option jdo.tck.skipJndi anymore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-829) api: Migrate JUnit tests to version 5
[ https://issues.apache.org/jira/browse/JDO-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen resolved JDO-829. -- Resolution: Fixed > api: Migrate JUnit tests to version 5 > - > > Key: JDO-829 > URL: https://issues.apache.org/jira/browse/JDO-829 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The unit tests in the api subproject are using JUnit 4 and are written in a > JUnit 3.8.1 style. The tests should be migrated to JUnit 5. > Links: > * [https://junit.org/junit5/docs/current/user-guide/] > * [https://www.baeldung.com/junit-5] > * https://www.baeldung.com/junit-5-migration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-830) tck: Migrate JUnit tests to version 5
[ https://issues.apache.org/jira/browse/JDO-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-830: - Description: The tck tests in the tck subproject are using JUnit 4 and are written in a JUnit 3.8.1 style. The tests should be migrated to JUnit 5. Links: * [https://junit.org/junit5/docs/current/user-guide/] * [https://www.baeldung.com/junit-5] * [https://www.baeldung.com/junit-5-migration] * [https://stackoverflow.com/questions/47158583/executing-junit-4-and-junit-5-tests-in-a-same-build] was: The tck tests in the tck subproject are using JUnit 4 and are written in a JUnit 3.8.1 style. The tests should be migrated to JUnit 5. Links: * [https://junit.org/junit5/docs/current/user-guide/] * [https://www.baeldung.com/junit-5] * https://www.baeldung.com/junit-5-migration > tck: Migrate JUnit tests to version 5 > - > > Key: JDO-830 > URL: https://issues.apache.org/jira/browse/JDO-830 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The tck tests in the tck subproject are using JUnit 4 and are written in a > JUnit 3.8.1 style. The tests should be migrated to JUnit 5. > Links: > * [https://junit.org/junit5/docs/current/user-guide/] > * [https://www.baeldung.com/junit-5] > * [https://www.baeldung.com/junit-5-migration] > * > [https://stackoverflow.com/questions/47158583/executing-junit-4-and-junit-5-tests-in-a-same-build] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-831) tck: improve tck tests for performance
[ https://issues.apache.org/jira/browse/JDO-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-831: - Description: The performance of the tck test suite might be improved by using: * multi-threading * parallel execution of tests that do not change the database * setup/teardown optimization for tests that do not change the database was: The performance of the tck test suite might be improved by using: * multi-threading * parallel execution of tests that do not change the database * setup/teardown optimization for tests that do not change the database https://stackoverflow.com/questions/47158583/executing-junit-4-and-junit-5-tests-in-a-same-build > tck: improve tck tests for performance > -- > > Key: JDO-831 > URL: https://issues.apache.org/jira/browse/JDO-831 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The performance of the tck test suite might be improved by using: > * multi-threading > * parallel execution of tests that do not change the database > * setup/teardown optimization for tests that do not change the database -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-831) tck: improve tck tests for performance
[ https://issues.apache.org/jira/browse/JDO-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-831: - Fix Version/s: JDO 3.2.2 JDO 3.3 > tck: improve tck tests for performance > -- > > Key: JDO-831 > URL: https://issues.apache.org/jira/browse/JDO-831 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The performance of the tck test suite might be improved by using: > * multi-threading > * parallel execution of tests that do not change the database > * setup/teardown optimization for tests that do not change the database > https://stackoverflow.com/questions/47158583/executing-junit-4-and-junit-5-tests-in-a-same-build -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-831) tck: improve tck tests for performance
Michael Bouschen created JDO-831: Summary: tck: improve tck tests for performance Key: JDO-831 URL: https://issues.apache.org/jira/browse/JDO-831 Project: JDO Issue Type: Task Components: tck Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen The performance of the tck test suite might be improved by using: * multi-threading * parallel execution of tests that do not change the database * setup/teardown optimization for tests that do not change the database https://stackoverflow.com/questions/47158583/executing-junit-4-and-junit-5-tests-in-a-same-build -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-830) tck: Migrate JUnit tests to version 5
Michael Bouschen created JDO-830: Summary: tck: Migrate JUnit tests to version 5 Key: JDO-830 URL: https://issues.apache.org/jira/browse/JDO-830 Project: JDO Issue Type: Task Components: tck Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen Fix For: JDO 3.2.2, JDO 3.3 The tck tests in the tck subproject are using JUnit 4 and are written in a JUnit 3.8.1 style. The tests should be migrated to JUnit 5. Links: * [https://junit.org/junit5/docs/current/user-guide/] * [https://www.baeldung.com/junit-5] * https://www.baeldung.com/junit-5-migration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-829) api: Migrate JUnit tests to version 5
[ https://issues.apache.org/jira/browse/JDO-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-829: - Description: The unit tests in the api subproject are using JUnit 4 and are written in a JUnit 3.8.1 style. The tests should be migrated to JUnit 5. Links: * [https://junit.org/junit5/docs/current/user-guide/] * [https://www.baeldung.com/junit-5] * https://www.baeldung.com/junit-5-migration was:The unit tests in the api subproject are using JUnit 4 and are written in a JUnit 3.8.1 style. The tests should be migrated to JUnit 5. > api: Migrate JUnit tests to version 5 > - > > Key: JDO-829 > URL: https://issues.apache.org/jira/browse/JDO-829 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The unit tests in the api subproject are using JUnit 4 and are written in a > JUnit 3.8.1 style. The tests should be migrated to JUnit 5. > Links: > * [https://junit.org/junit5/docs/current/user-guide/] > * [https://www.baeldung.com/junit-5] > * https://www.baeldung.com/junit-5-migration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JDO-829) api: Migrate JUnit tests to version 5
[ https://issues.apache.org/jira/browse/JDO-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen reassigned JDO-829: Assignee: Michael Bouschen > api: Migrate JUnit tests to version 5 > - > > Key: JDO-829 > URL: https://issues.apache.org/jira/browse/JDO-829 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The unit tests in the api subproject are using JUnit 4 and are written in a > JUnit 3.8.1 style. The tests should be migrated to JUnit 5. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-829) api: Migrate JUnit tests to version 5
[ https://issues.apache.org/jira/browse/JDO-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-829: - Fix Version/s: JDO 3.2.2 JDO 3.3 > api: Migrate JUnit tests to version 5 > - > > Key: JDO-829 > URL: https://issues.apache.org/jira/browse/JDO-829 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.2.2, JDO 3.3 > > > The unit tests in the api subproject are using JUnit 4 and are written in a > JUnit 3.8.1 style. The tests should be migrated to JUnit 5. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-829) api: Migrate JUnit tests to version 5
Michael Bouschen created JDO-829: Summary: api: Migrate JUnit tests to version 5 Key: JDO-829 URL: https://issues.apache.org/jira/browse/JDO-829 Project: JDO Issue Type: Task Components: api Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen The unit tests in the api subproject are using JUnit 4 and are written in a JUnit 3.8.1 style. The tests should be migrated to JUnit 5. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-827) Consider (re-)moving JNDI support
[
https://issues.apache.org/jira/browse/JDO-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-827:
-
Description:
The JDO API has two JNDI dependencies:
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
context)}} and
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context context,
ClassLoader loader)}}
The JNDI dependency complicates building and running the TCK (because of the
non-free nature of the implementation). It is also the only part of the API
that stops it being compatible with Android. The CI runs currently have all
tests disabled that depend on JNDI (TBD, how does it compile without the
classes???).
There are many options for simplifying this issue:
* Drop JNDI support? Is JNDI still used? Probably yes, see JDBC, JPA, EJB, JMS.
* Move the two methods into a separate JDOJNDIHelper. This would (probably)
allow us to more easily exclude it from builds when desired, for example using
Java 9 modules.
* Provide a dummy implementation of the JNDI classes. This would allow
compiling the API without problems (also on Android), but we would still need
to exclude it from tests.
* Switch to a free leightweight implementation, e.g.
[https://github.com/h-thurow/Simple-JNDI] or
https://github.com/dattack/standalone-jndi
was:
The JDO API has two JNDI dependencies:
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
context)}} and
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context context,
ClassLoader loader)}}
The JNDI dependency complicates building and running the TCK (because of the
non-free nature of the implementation). It is also the only part of the API
that stops it being compatible with Android. The CI runs currently have all
tests disabled that depend on JNDI (TBD, how does it compile without the
classes???).
There are many options for simplifying this issue:
* Drop JNDI support? Is JNDI still used? Probably yes, see JDBC, JPA, EJB, JMS.
* Move the two methods into a separate JDOJNDIHelper. This would (probably)
allow us to more easily exclude it from builds when desired, for example using
Java 9 modules.
* Provide a dummy implementation of the JNDI classes. This would allow
compiling the API without problems (also on Android), but we would still need
to exclude it from tests.
* Switch to a free leightweight implementation, e.g.
https://github.com/h-thurow/Simple-JNDI
> Consider (re-)moving JNDI support
> -
>
> Key: JDO-827
> URL: https://issues.apache.org/jira/browse/JDO-827
> Project: JDO
> Issue Type: Improvement
> Components: api
>Affects Versions: JDO 3.2, JDO 3.2.1
>Reporter: Tilmann Zäschke
>Priority: Major
>
> The JDO API has two JNDI dependencies:
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context)}} and
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context, ClassLoader loader)}}
> The JNDI dependency complicates building and running the TCK (because of the
> non-free nature of the implementation). It is also the only part of the API
> that stops it being compatible with Android. The CI runs currently have all
> tests disabled that depend on JNDI (TBD, how does it compile without the
> classes???).
> There are many options for simplifying this issue:
> * Drop JNDI support? Is JNDI still used? Probably yes, see JDBC, JPA, EJB,
> JMS.
> * Move the two methods into a separate JDOJNDIHelper. This would (probably)
> allow us to more easily exclude it from builds when desired, for example
> using Java 9 modules.
> * Provide a dummy implementation of the JNDI classes. This would allow
> compiling the API without problems (also on Android), but we would still need
> to exclude it from tests.
> * Switch to a free leightweight implementation, e.g.
> [https://github.com/h-thurow/Simple-JNDI] or
> https://github.com/dattack/standalone-jndi
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JDO-828) Set up automated mail subjects for GitHub action responses
[ https://issues.apache.org/jira/browse/JDO-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bouschen resolved JDO-828. - Resolution: Fixed > Set up automated mail subjects for GitHub action responses > -- > > Key: JDO-828 > URL: https://issues.apache.org/jira/browse/JDO-828 > Project: JDO > Issue Type: Task > Components: site and infrastructure >Reporter: Tobias Bouschen >Assignee: Tobias Bouschen >Priority: Minor > Fix For: JDO 3.2.2, JDO 3.3 > > > On the general Apache community page, a range of email subjects for automated > email created for different actions on GitHub have been suggested: > [https://community.apache.org/contributors/mailing-lists#configuring-the-subject-lines-of-the-emails-being-sent] > These settings should be applied to the JDO repositories. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (JDO-828) Set up automated mail subjects for GitHub action responses
[ https://issues.apache.org/jira/browse/JDO-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bouschen reopened JDO-828: - > Set up automated mail subjects for GitHub action responses > -- > > Key: JDO-828 > URL: https://issues.apache.org/jira/browse/JDO-828 > Project: JDO > Issue Type: Task > Components: site and infrastructure >Reporter: Tobias Bouschen >Assignee: Tobias Bouschen >Priority: Minor > Fix For: JDO 3.2.2, JDO 3.3 > > > On the general Apache community page, a range of email subjects for automated > email created for different actions on GitHub have been suggested: > [https://community.apache.org/contributors/mailing-lists#configuring-the-subject-lines-of-the-emails-being-sent] > These settings should be applied to the JDO repositories. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JDO-828) Set up automated mail subjects for GitHub action responses
[ https://issues.apache.org/jira/browse/JDO-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bouschen closed JDO-828. --- Resolution: Fixed > Set up automated mail subjects for GitHub action responses > -- > > Key: JDO-828 > URL: https://issues.apache.org/jira/browse/JDO-828 > Project: JDO > Issue Type: Task > Components: site and infrastructure >Reporter: Tobias Bouschen >Assignee: Tobias Bouschen >Priority: Minor > Fix For: JDO 3.2.2, JDO 3.3 > > > On the general Apache community page, a range of email subjects for automated > email created for different actions on GitHub have been suggested: > [https://community.apache.org/contributors/mailing-lists#configuring-the-subject-lines-of-the-emails-being-sent] > These settings should be applied to the JDO repositories. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-828) Set up automated mail subjects for GitHub action responses
[ https://issues.apache.org/jira/browse/JDO-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-828: - Fix Version/s: JDO 3.2.2 JDO 3.3 > Set up automated mail subjects for GitHub action responses > -- > > Key: JDO-828 > URL: https://issues.apache.org/jira/browse/JDO-828 > Project: JDO > Issue Type: Task > Components: site and infrastructure >Reporter: Tobias Bouschen >Assignee: Tobias Bouschen >Priority: Minor > Fix For: JDO 3.2.2, JDO 3.3 > > > On the general Apache community page, a range of email subjects for automated > email created for different actions on GitHub have been suggested: > [https://community.apache.org/contributors/mailing-lists#configuring-the-subject-lines-of-the-emails-being-sent] > These settings should be applied to the JDO repositories. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-828) Set up automated mail subjects for GitHub action responses
[ https://issues.apache.org/jira/browse/JDO-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-828: - Component/s: site and infrastructure > Set up automated mail subjects for GitHub action responses > -- > > Key: JDO-828 > URL: https://issues.apache.org/jira/browse/JDO-828 > Project: JDO > Issue Type: Task > Components: site and infrastructure >Reporter: Tobias Bouschen >Assignee: Tobias Bouschen >Priority: Minor > > On the general Apache community page, a range of email subjects for automated > email created for different actions on GitHub have been suggested: > [https://community.apache.org/contributors/mailing-lists#configuring-the-subject-lines-of-the-emails-being-sent] > These settings should be applied to the JDO repositories. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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&focusedCommentId=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] [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&focusedCommentId=17729106#comment-17729106 ] Tobias Bouschen commented on JDO-822: - I adjusted the matrix build on my fork to run with JDK 20 and the build still succeeds: [https://github.com/tobous/db-jdo/actions/runs/5170691272/jobs/9313757782] Please keep in mind that this only changes the JDK version and not the actual build target. JDO is currently still always built against the language level of Java 8. As JDK 20 is not LTS (JDK 21 will be the next LTS release), I would suggest keeping the matrix build on the main repo as it is and then jumping to JDK 21 once it is out. > 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] [Created] (JDO-828) Set up automated mail subjects for GitHub action responses
Tobias Bouschen created JDO-828: --- Summary: Set up automated mail subjects for GitHub action responses Key: JDO-828 URL: https://issues.apache.org/jira/browse/JDO-828 Project: JDO Issue Type: Task Reporter: Tobias Bouschen Assignee: Tobias Bouschen On the general Apache community page, a range of email subjects for automated email created for different actions on GitHub have been suggested: [https://community.apache.org/contributors/mailing-lists#configuring-the-subject-lines-of-the-emails-being-sent] These settings should be applied to the JDO repositories. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-827) Consider (re-)moving JNDI support
[
https://issues.apache.org/jira/browse/JDO-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-827:
Description:
The JDO API has two JNDI dependencies:
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
context)}} and
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context context,
ClassLoader loader)}}
The JNDI dependency complicates building and running the TCK (because of the
non-free nature of the implementation). It is also the only part of the API
that stops it being compatible with Android. The CI runs currently have all
tests disabled that depend on JNDI (TBD, how does it compile without the
classes???).
There are many options for simplifying this issue:
* Drop JNDI support? Is JNDI still used? Probably yes, see JDBC, JPA, EJB, JMS.
* Move the two methods into a separate JDOJNDIHelper. This would (probably)
allow us to more easily exclude it from builds when desired, for example using
Java 9 modules.
* Provide a dummy implementation of the JNDI classes. This would allow
compiling the API without problems (also on Android), but we would still need
to exclude it from tests.
* Switch to a free leightweight implementation, e.g.
https://github.com/h-thurow/Simple-JNDI
was:
The JDO API has two JNDI dependencies:
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
context)}} and
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context context,
ClassLoader loader)}}
The JNDI dependency complicates building and running the TCK (because of the
non-free nature of the implementation). It is also the only part of the API
that stops it being compatible with Android. The CI runs currently have all
tests disabled that depend on JNDI (TBD, how does it compile without the
classes???).
There are many options for simplifying this issue:
* Drop JNDI support? Is JNDI still used?
* Move the two methods into a separate JDOJNDIHelper. This would (probably)
allow us to more easily exclude it from builds when desired, for example using
Java 9 modules.
* Provide a dummy implementation of the JNDI classes. This would allow
compiling the API without problems (also on Android), but we would still need
to exclude it from tests.
* Switch to a free leightweight implementation, e.g.
https://github.com/h-thurow/Simple-JNDI
> Consider (re-)moving JNDI support
> -
>
> Key: JDO-827
> URL: https://issues.apache.org/jira/browse/JDO-827
> Project: JDO
> Issue Type: Improvement
> Components: api
>Affects Versions: JDO 3.2, JDO 3.2.1
>Reporter: Tilmann Zäschke
>Priority: Major
>
> The JDO API has two JNDI dependencies:
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context)}} and
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context, ClassLoader loader)}}
> The JNDI dependency complicates building and running the TCK (because of the
> non-free nature of the implementation). It is also the only part of the API
> that stops it being compatible with Android. The CI runs currently have all
> tests disabled that depend on JNDI (TBD, how does it compile without the
> classes???).
> There are many options for simplifying this issue:
> * Drop JNDI support? Is JNDI still used? Probably yes, see JDBC, JPA, EJB,
> JMS.
> * Move the two methods into a separate JDOJNDIHelper. This would (probably)
> allow us to more easily exclude it from builds when desired, for example
> using Java 9 modules.
> * Provide a dummy implementation of the JNDI classes. This would allow
> compiling the API without problems (also on Android), but we would still need
> to exclude it from tests.
> * Switch to a free leightweight implementation, e.g.
> https://github.com/h-thurow/Simple-JNDI
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JDO-827) Consider (re-)moving JNDI support
[
https://issues.apache.org/jira/browse/JDO-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-827:
Description:
The JDO API has two JNDI dependencies:
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
context)}} and
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context context,
ClassLoader loader)}}
The JNDI dependency complicates building and running the TCK (because of the
non-free nature of the implementation). It is also the only part of the API
that stops it being compatible with Android. The CI runs currently have all
tests disabled that depend on JNDI (TBD, how does it compile without the
classes???).
There are many options for simplifying this issue:
* Drop JNDI support? Is JNDI still used?
* Move the two methods into a separate JDOJNDIHelper. This would (probably)
allow us to more easily exclude it from builds when desired, for example using
Java 9 modules.
* Provide a dummy implementation of the JNDI classes. This would allow
compiling the API without problems (also on Android), but we would still need
to exclude it from tests.
* Switch to a free leightweight implementation, e.g.
https://github.com/h-thurow/Simple-JNDI
was:
The JDO API has two JNDI dependencies:
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
context)}} and
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context context,
ClassLoader loader)}}
The JNDI dependency complicates building and running the TCK (because of the
non-free nature of the implementation). It is also the only part of the API
that stops it being compatible with Android. The CI runs currently have all
tests disabled that depend on JNDI (TBD, how does it compile without the
classes???).
There are many options for simplifying this issue:
* Drop JNDI support? Is JNDI still used?
* Move the two methods into a separate JDOJNDIHelper. This would (probably)
allow us to more easily exclude it from builds when desired, for example using
Java 9 modules.
* Provide a dummy implementation of the JNDI classes. This would allow
compiling the API without problems (also on Android), but we would still need
to exclude it from tests.
> Consider (re-)moving JNDI support
> -
>
> Key: JDO-827
> URL: https://issues.apache.org/jira/browse/JDO-827
> Project: JDO
> Issue Type: Improvement
> Components: api
>Affects Versions: JDO 3.2, JDO 3.2.1
>Reporter: Tilmann Zäschke
>Priority: Major
>
> The JDO API has two JNDI dependencies:
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context)}} and
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context, ClassLoader loader)}}
> The JNDI dependency complicates building and running the TCK (because of the
> non-free nature of the implementation). It is also the only part of the API
> that stops it being compatible with Android. The CI runs currently have all
> tests disabled that depend on JNDI (TBD, how does it compile without the
> classes???).
> There are many options for simplifying this issue:
> * Drop JNDI support? Is JNDI still used?
> * Move the two methods into a separate JDOJNDIHelper. This would (probably)
> allow us to more easily exclude it from builds when desired, for example
> using Java 9 modules.
> * Provide a dummy implementation of the JNDI classes. This would allow
> compiling the API without problems (also on Android), but we would still need
> to exclude it from tests.
> * Switch to a free leightweight implementation, e.g.
> https://github.com/h-thurow/Simple-JNDI
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JDO-827) Consider (re-)moving JNDI support
Tilmann Zäschke created JDO-827:
---
Summary: Consider (re-)moving JNDI support
Key: JDO-827
URL: https://issues.apache.org/jira/browse/JDO-827
Project: JDO
Issue Type: Improvement
Components: api
Affects Versions: JDO 3.2.1, JDO 3.2
Reporter: Tilmann Zäschke
The JDO API has two JNDI dependencies:
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
context)}} and
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context context,
ClassLoader loader)}}
The JNDI dependency complicates building and running the TCK (because of the
non-free nature of the implementation). It is also the only part of the API
that stops it being compatible with Android. The CI runs currently have all
tests disabled that depend on JNDI (TBD, how does it compile without the
classes???).
There are many options for simplifying this issue:
* Drop JNDI support? Is JNDI still used?
* Move the two methods into a separate JDOJNDIHelper. This would (probably)
allow us to more easily exclude it from builds when desired, for example using
Java 9 modules.
* Provide a dummy implementation of the JNDI classes. This would allow
compiling the API without problems (also on Android), but we would still need
to exclude it from tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JDO-826) @Convert Javadoc indicates support for @Target(ElementType.TYPE,...)
[
https://issues.apache.org/jira/browse/JDO-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke closed JDO-826.
---
Assignee: Tilmann Zäschke
Resolution: Fixed
> @Convert Javadoc indicates support for @Target(ElementType.TYPE,...)
>
>
> Key: JDO-826
> URL: https://issues.apache.org/jira/browse/JDO-826
> Project: JDO
> Issue Type: Bug
> Components: api
>Affects Versions: JDO 3.2
>Reporter: Tilmann Zäschke
>Assignee: Tilmann Zäschke
>Priority: Major
> Fix For: JDO 3.2.2
>
>
> The javadoc of the @Convert annotation claims that it can be placed on types,
> e.g.
> {code:java}
> @Convert(value = ConvertiblePointToStringConverter.class)
> public class ConvertiblePoint {
> ...
> }
> {code}
> While this feature is desirable, there is currently no implementation of it
> in the reference implementation.
> For now, the javadoc should be fixed by removing the section about
> @Target(ElementType.TYPE,...).
> Once the implementation is resourced (volunteers welcome!) the section can be
> put back in place.
>
> Context:
> * Original discussion:
> [JDO-709|https://issues.apache.org/jira/browse/JDO-709], starting 2022-10-17
> * PR by original problem reporter: [https://github.com/apache/db-jdo/pull/60]
> * Copy of original PR with additional TCK test:
> [https://github.com/apache/db-jdo/pull/61]
> * Tickets with problem description on reference implementation:
> [https://github.com/datanucleus/datanucleus-api-jdo/issues/127]
--
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&focusedCommentId=17709870#comment-17709870 ] Tilmann Zäschke commented on JDO-709: - The discussion about @Target(ElementType.TYPE,...) has been moved to a separate ticket, concluding that we remove it from the javadoc until an implementation is available: [JDO-826|https://issues.apache.org/jira/browse/JDO-826] > 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] [Created] (JDO-826) @Convert Javadoc indicates support for @Target(ElementType.TYPE,...)
Tilmann Zäschke created JDO-826:
---
Summary: @Convert Javadoc indicates support for
@Target(ElementType.TYPE,...)
Key: JDO-826
URL: https://issues.apache.org/jira/browse/JDO-826
Project: JDO
Issue Type: Bug
Components: api
Affects Versions: JDO 3.2
Reporter: Tilmann Zäschke
Fix For: JDO 3.2.2
The javadoc of the @Convert annotation claims that it can be placed on types,
e.g.
{code:java}
@Convert(value = ConvertiblePointToStringConverter.class)
public class ConvertiblePoint {
...
}
{code}
While this feature is desirable, there is currently no implementation of it in
the reference implementation.
For now, the javadoc should be fixed by removing the section about
@Target(ElementType.TYPE,...).
Once the implementation is resourced (volunteers welcome!) the section can be
put back in place.
Context:
* Original discussion:
[JDO-709|https://issues.apache.org/jira/browse/JDO-709], starting 2022-10-17
* PR by original problem reporter: [https://github.com/apache/db-jdo/pull/60]
* Copy of original PR with additional TCK test:
[https://github.com/apache/db-jdo/pull/61]
* Tickets with problem description on reference implementation:
[https://github.com/datanucleus/datanucleus-api-jdo/issues/127]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JDO-825) Improve exectck classes
Michael Bouschen created JDO-825: Summary: Improve exectck classes Key: JDO-825 URL: https://issues.apache.org/jira/browse/JDO-825 Project: JDO Issue Type: Task Components: tck Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen Some exectck classes may be improved: * AbstractTCKMojo, PropertyUtils, Utilites: close reader or stream in a try-with-resource * PropertyUtils: remove unused methods * AbstractTCKMojo, Enhance, RunTCK: Replace the type specification in the constructoir call with the diamond operator (<>) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JDO-825) Improve exectck classes
[ https://issues.apache.org/jira/browse/JDO-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen reassigned JDO-825: Assignee: Michael Bouschen > Improve exectck classes > --- > > Key: JDO-825 > URL: https://issues.apache.org/jira/browse/JDO-825 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > > Some exectck classes may be improved: > * AbstractTCKMojo, PropertyUtils, Utilites: close reader or stream in a > try-with-resource > * PropertyUtils: remove unused methods > * AbstractTCKMojo, Enhance, RunTCK: Replace the type specification in the > constructoir call with the diamond operator (<>) -- 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&focusedCommentId=17681744#comment-17681744 ] Tilmann Zäschke commented on JDO-709: - To keep this thread somewhat up to date, there have been three PRs/tickets concerning @Convert on types: * PR by original problem reporter: [https://github.com/apache/db-jdo/pull/60|https://github.com/apache/db-jdo/pull/60] * Copy or original PR with additional TCK test: [https://github.com/apache/db-jdo/pull/61|https://github.com/apache/db-jdo/pull/61] * Tickets with problem description on reference implementation: [https://github.com/datanucleus/datanucleus-api-jdo/issues/127|https://github.com/datanucleus/datanucleus-api-jdo/issues/127] > 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] [Closed] (JDO-824) JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores Throwable
[ https://issues.apache.org/jira/browse/JDO-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke closed JDO-824. --- Resolution: Won't Fix It is not clear why this was implemented. However, changing this may break implementations. This is undesirable, and since we don't know the original rationale for this catch-all, we chose to leave it be. > JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores Throwable > -- > > Key: JDO-824 > URL: https://issues.apache.org/jira/browse/JDO-824 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2, JDO 3.2.1 >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > > The method JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores all thrown > Exceptions of type Throwable. > This should probably be changed to be more specific, in the current state it > would even ignore > OutOfMemoryException, which is probably not what is intended here. > All occurrences: > * nonBinaryCompatibleGet() > * nonBinaryCompatibleIs() > * nonBinaryCompatibleMakeDirty() > Otherwise we should document why this okay. > I am currently unsure why ignoring *any* exception is okay here? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JDO-824) JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores Throwable
[ https://issues.apache.org/jira/browse/JDO-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke reassigned JDO-824: --- Assignee: Tilmann Zäschke > JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores Throwable > -- > > Key: JDO-824 > URL: https://issues.apache.org/jira/browse/JDO-824 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2, JDO 3.2.1 >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > > The method JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores all thrown > Exceptions of type Throwable. > This should probably be changed to be more specific, in the current state it > would even ignore > OutOfMemoryException, which is probably not what is intended here. > All occurrences: > * nonBinaryCompatibleGet() > * nonBinaryCompatibleIs() > * nonBinaryCompatibleMakeDirty() > Otherwise we should document why this okay. > I am currently unsure why ignoring *any* exception is okay here? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-824) JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores Throwable
[ https://issues.apache.org/jira/browse/JDO-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke updated JDO-824: Fix Version/s: (was: JDO 3.2.2) Description: The method JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores all thrown Exceptions of type Throwable. This should probably be changed to be more specific, in the current state it would even ignore OutOfMemoryException, which is probably not what is intended here. All occurrences: * nonBinaryCompatibleGet() * nonBinaryCompatibleIs() * nonBinaryCompatibleMakeDirty() Otherwise we should document why this okay. I am currently unsure why ignoring *any* exception is okay here? was: The method JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores all thrown Exceptions of type Throwable. This should probably be changed to be more specific, in the current state it would even ignore OutOfMemoryException, which is probably not what is intended here. > JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores Throwable > -- > > Key: JDO-824 > URL: https://issues.apache.org/jira/browse/JDO-824 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2, JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > > The method JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores all thrown > Exceptions of type Throwable. > This should probably be changed to be more specific, in the current state it > would even ignore > OutOfMemoryException, which is probably not what is intended here. > All occurrences: > * nonBinaryCompatibleGet() > * nonBinaryCompatibleIs() > * nonBinaryCompatibleMakeDirty() > Otherwise we should document why this okay. > I am currently unsure why ignoring *any* exception is okay here? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-824) JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores Throwable
Tilmann Zäschke created JDO-824: --- Summary: JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores Throwable Key: JDO-824 URL: https://issues.apache.org/jira/browse/JDO-824 Project: JDO Issue Type: Task Components: api Affects Versions: JDO 3.2.1, JDO 3.2 Reporter: Tilmann Zäschke Fix For: JDO 3.2.2 The method JDOImplHelper.nonBinaryCompatibleMakeDirty() ignores all thrown Exceptions of type Throwable. This should probably be changed to be more specific, in the current state it would even ignore OutOfMemoryException, which is probably not what is intended here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-823) Fix sonarcloud issues of type Code Smells
[ https://issues.apache.org/jira/browse/JDO-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-823: - Fix Version/s: JDO 3.3 > Fix sonarcloud issues of type Code Smells > - > > Key: JDO-823 > URL: https://issues.apache.org/jira/browse/JDO-823 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > The latest sonalcloud run lists 311 issues in the category Maintainability > (Code Smells). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JDO-823) Fix sonarcloud issues of type Code Smells
Michael Bouschen created JDO-823: Summary: Fix sonarcloud issues of type Code Smells Key: JDO-823 URL: https://issues.apache.org/jira/browse/JDO-823 Project: JDO Issue Type: Task Components: api Affects Versions: JDO 3.2.1 Reporter: Michael Bouschen The latest sonalcloud run lists 311 issues in the category Maintainability (Code Smells). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JDO-821) Fix sonarcloud issues of type Bugs and Security Hotspots
[ https://issues.apache.org/jira/browse/JDO-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen resolved JDO-821. -- Resolution: Fixed The issues in the categories Reliability (= Bugs) and Security Review (= Security Hotspots) are fixed now. > Fix sonarcloud issues of type Bugs and Security Hotspots > > > Key: JDO-821 > URL: https://issues.apache.org/jira/browse/JDO-821 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > The latest sonarcloud run lists 20 bugs in the category Reliability. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JDO-821) Fix sonarcloud issues of type Bugs and Security Hotspots
[ https://issues.apache.org/jira/browse/JDO-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-821: - Summary: Fix sonarcloud issues of type Bugs and Security Hotspots (was: Fix sonarcloud issues of type Bugs) > Fix sonarcloud issues of type Bugs and Security Hotspots > > > Key: JDO-821 > URL: https://issues.apache.org/jira/browse/JDO-821 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > The latest sonarcloud run lists 20 bugs in the category Reliability. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-821) Fix sonarcloud issues of type Bugs
[ https://issues.apache.org/jira/browse/JDO-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652249#comment-17652249 ] Michael Bouschen commented on JDO-821: -- Fixed 18 issues in the category Reliability marked as Bugs * JDOException: javadoc sentence was flagged as code in comments because of an semikolon. * JDOException: Redefined method missed a synchronized keyxword * JDOException: printStackTrace removed synchronized method qualifier, because method body is already synchronized. * package.html: missing doctype in javadoc * package.html: missing language spec in html element of javadoc * package.html: replaced by * SingleFieldIdentity: added synchronized keyword to setter because corresponding getter was already synchronized * Adapted jdo-signature.txt because of the above synchronized changes. > Fix sonarcloud issues of type Bugs > -- > > Key: JDO-821 > URL: https://issues.apache.org/jira/browse/JDO-821 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > The latest sonarcloud run lists 20 bugs in the category Reliability. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JDO-821) Fix sonarcloud issues of type Bugs
[ https://issues.apache.org/jira/browse/JDO-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648243#comment-17648243 ] Tilmann Zäschke edited comment on JDO-821 at 12/15/22 8:56 PM: --- Fixed 12 issues labelled as "security". They all involve calling printStackTrace() on an Exception ([java:S4507|https://sonarcloud.io/organizations/apache/rules?open=java%3AS4507&rule_key=java%3AS4507]). * 8 Issues where inside 'exectck' so they can be ignored (not part of production code) * 2 issues were inside 'LegacyJava' and have been removed. * 2 Issues were in 'javax/jdo.Enhance' and are considered "safe" (I labelled them as "safe" in SonarCloud). Rationale: The Enhancer is executed before any data comes into the application so there is no risk of leaking sensitive data such as passwords. The risk of leaking domain class names is real but deemed acceptable. See [PR #66|https://github.com/apache/db-jdo/pull/66] was (Author: tilmannz): Fixed 12 issues labelled as "security". They all involve calling printStackTrace() on an Exception ([java:S4507|https://sonarcloud.io/organizations/apache/rules?open=java%3AS4507&rule_key=java%3AS4507]). * 8 Issues where inside 'exectck' so they can be ignored (not part of production code) * 2 issues were inside 'LegacyJava' and have been removed. * 2 Issues were in 'javax/jdo.Enhance' and are considered "safe" (I labelled them as "safe" in SonarCloud). Rationale: The Enhancer is executed before any data comes into the application so there is no risk of leaking sensitive data such as passwords. The risk of leaking domain class names is real but deemed acceptable. See [PR|https://github.com/apache/db-jdo/pull/66] > Fix sonarcloud issues of type Bugs > -- > > Key: JDO-821 > URL: https://issues.apache.org/jira/browse/JDO-821 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen > Priority: Major > Fix For: JDO 3.3 > > > The latest sonarcloud run lists 20 bugs in the category Reliability. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JDO-821) Fix sonarcloud issues of type Bugs
[ https://issues.apache.org/jira/browse/JDO-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648243#comment-17648243 ] Tilmann Zäschke edited comment on JDO-821 at 12/15/22 8:56 PM: --- Fixed 12 issues labelled as "security". They all involve calling printStackTrace() on an Exception ([java:S4507|https://sonarcloud.io/organizations/apache/rules?open=java%3AS4507&rule_key=java%3AS4507]). * 8 Issues where inside 'exectck' so they can be ignored (not part of production code) * 2 issues were inside 'LegacyJava' and have been removed. * 2 Issues were in 'javax/jdo.Enhance' and are considered "safe" (I labelled them as "safe" in SonarCloud). Rationale: The Enhancer is executed before any data comes into the application so there is no risk of leaking sensitive data such as passwords. The risk of leaking domain class names is real but deemed acceptable. See [PR|https://github.com/apache/db-jdo/pull/66] was (Author: tilmannz): Fixed 12 issues labelled as "security". They all involve calling printStackTrace() on an Exception (java:S4507). * 8 Issues where inside 'exectck' so they can be ignored (not part of production code) * 2 issues were inside 'LegacyJava' and have been removed. * 2 Issues were in 'javax/jdo.Enhance' and are considered "safe" (I labelled them as "safe" in SonarCloud). Rationale: The Enhancer is executed before any data comes into the application so there is no risk of leaking sensitive data such as passwords. The risk of leaking domain class names is real but deemed acceptable. See [PR|https://github.com/apache/db-jdo/pull/66] > Fix sonarcloud issues of type Bugs > -- > > Key: JDO-821 > URL: https://issues.apache.org/jira/browse/JDO-821 > Project: JDO > Issue Type: Task > Components: api >Affects Versions: JDO 3.2.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen > Priority: Major > Fix For: JDO 3.3 > > > The latest sonarcloud run lists 20 bugs in the category Reliability. -- This message was sent by Atlassian Jira (v8.20.10#820010)
