Attendees: Michelle Caisse, Michael Bouschen, Craig Russell

Agenda:

1. Query timeout in JDO / Update timeout (See latest email on the list  
from Craig)

The proposal makes it clear that we're not trying to limit resources  
in the VM but just when going to the datastore. There is no way to  
limit the entire query processing by this proposal.

How would we point people in the direction of DatastoreReadTimeout if  
they have QueryTimeout in mind?

What JDOException should be thrown in case of timeout for read, write,  
query, delete? Possibly simply a JDODatastoreException? It's a burden  
on the implementation to map all possible database result codes and  
the user might not even need to know what the specific exception is.

AI Everyone please review the proposal so we can close this last issue  
for 2.3.

2.  Support for conditional operator in JDOQL https://issues.apache.org/jira/browse/JDO-650

Timo's latest comment is that case statements might be less tricky  
than Java conditional expressions, but adding new features to JDOQL  
that aren't Java is even more tricky. AI Michael reply to Timo's JIRA  
comments.

3. Other issues

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

    [ https://issues.apache.org/jira/browse/JDO-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785812#action_12785812
] 

Timo Westkämper commented on JDO-650:
-------------------------------------

The proposed syntax gets a bit tricky with longer expressions

case
  when salary < 100 then "bronze"
  when salary < 1000 then "silver"
  when salary < 10000 then "gold"
  else "platinum"
end

becomes

salary < 100 ? "bronze" : ( salary < 1000 ? "silver" : ( salary < 10000 ? "gold"
: "platinum" )) 

Querydsl uses the case-when-else-end form.

> Support for conditional operator ? : in JDOQL
> ---------------------------------------------
>
>                 Key: JDO-650
>                 URL: https://issues.apache.org/jira/browse/JDO-650
>             Project: JDO
>          Issue Type: New Feature
>          Components: specification, tck2
>    Affects Versions: JDO 2 maintenance release 2
>            Reporter: Michael Bouschen
>            Assignee: Michael Bouschen
>
> JDOQL should support the Java conditional operator ? :, e.g. salay >= 1000.0 ? salary
: salary * 1.1
> The conditional operator can be mapped to the CASE-expression in SQL: CASE WHEN condition
THEN thenExpr ELSE elseExpr END. Are there any issues with non-SQL datastores when supporting
the conditional operator? 
> Another question: which part of a JDOQL query can include a conditional expression? I
propose the query filter, the having clause and the result specification.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hi,

We will have our regular meeting Friday, December 4 at 9 am PDT to 
discuss JDO TCK issues and status.

Dial-in numbers are:
Domestic (toll-free):  866 230-6968
International (caller-paid):  +1 213 787-0528
Access code :  294-0479#

Agenda:

1. Query timeout in JDO / Update timeout (See latest email on the list 
from Craig)
2.  Support for conditional operator in JDOQL 
https://issues.apache.org/jira/browse/JDO-650
3. Other issues

Action Items from weeks past:

-- Michelle

Hi Michael,

Good summary.

The original request for this feature was to allow queries that were  
either stuck (possible deadlock) or running away (query too complex  
for the server to complete timely).

Then, Jörg added a request for updates to time out if they were stuck.

And others wanted to know whether the timeout applied to memory  
operations or just database operations.

I'd like to propose something completely different that attempts to  
resolve all of the above issues.

Define two new properties and associated apis:  
DatastoreReadTimeoutMillis and DatastoreWriteTimeoutMillis. Get rid of  
the QueryTimeoutMillis property.

DatastoreReadTimeoutMillis applies to all operations on the datastore  
that are associated with reading data, including getObjectById,  
queries, refresh, navigation, and lazy loading of fields or properties.

DatastoreWriteTimeoutMillis applies to all operations on the datastore  
that are associated with writing data, including flush, commit, delete  
by query.

If multiple datastore operations are involved in satisfying a user  
request, the timeout applies individually to each of them.

The rules for specifying the timeout are the same as in the original  
proposal: if specified on a query, the timeout applies only to that  
query, with the default coming from the PM. If the operation is  
related to a PM operation, the timeout comes from the PM api, with the  
default coming from the PMF.

Whether there is a timeout is determined by the optional features  
property. I don't know of a datastore that supports read and write  
timeouts separately, so the feature can simply be called  
DatastoreTimeout and it either is supported or not.

Craig

On Nov 17, 2009, at 12:05 AM, Michael Bouschen wrote:

> Hi,
>
> the current spec allows specifying a query timeout on a Query, a PM  
> or a PMF. The PM defines the default for all Query instances of the  
> PM and the PMF defines the default value for all PMs of that PMF.  
> However, there are still three open issue in the query timeout area:
>
> (1) query timeout as an optional feature
> I propose to add query timeout as an optional feature. This means  
> the collection returned by the PMF method supportedOptions includes  
> the string "javax.jdo.option.QueryTimeout", if the JDO  
> implementation and the datastore bound to the PMF supports query  
> timeout. This would be a change in chapter 11.6 "Optional Feature  
> Support" of the spec.
>
> (2) Scope of the query timeout value
> I propose that a query timeout value set for a PM applies to all  
> "datastore query" operations issued by the PM. This includes  
> relationship navigation, findByObjectId and lasy loading of  
> collections.
> But how about modifying operations such as update, delete and  
> insert? Does it make sense to apply the PM's query timeout for these  
> operationsas well? I think this makes sense, but it might be less  
> obvious, because these operations are part of the transaction  
> commit. See also Jörg's recent email with subject "update timeout".  
> This would be a change in chapter 12 PersistenceManager. Today  
> chapter 12.6.3 "Query factory interface" specifies method  
> setQueryTimeout. If we broaden the scope of a query timeout set on a  
> PM, it might make sense to specify this in its own section, e.g.  
> 12.6.9 "Query Timeout".
>
> (3) Definition of query timeout: datastore operation or JDO method?
> Does the query timeout apply to the underlying datastore operation  
> or does it define the maximum execution time of the JDO method such  
> as Query.execute?
> I propose the former, meaning use the query timeout value for the  
> datastore operation. Otherwise, the JDO implementation would need to  
> calculate the timeout for the datastore operation and need o guess  
> the time needed to post-process the query result. If the datastore  
> has the JDBC standard second resolution, and there is less than 1000  
> millis left in the timeout, what should be the timeout set on the  
> datastore query statement?
>
> What do you think?
>
> Regards Michael
> -- 
> *Michael Bouschen*
> *Prokurist*
>
> akquinet tech@spree GmbH
> Bülowstr. 66, D-10783 Berlin
>
> Fon:   +49 30 235 520-33
> Fax:   +49 30 217 520-12
> Email: michael.bouschen@akquinet.de
> Url:    www.akquinet.de <http://www.akquinet.de>
>
> akquinet tech@spree GmbH, Berlin
> Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
> Amtsgericht Berlin-Charlottenburg HRB 86780 B
> USt.-Id. Nr.: DE 225 964 680
>
> -- 
> *Michael Bouschen*
> *Prokurist*
>
> akquinet tech@spree GmbH
> Bülowstr. 66, D-10783 Berlin
>
> Fon:   +49 30 235 520-33
> Fax:   +49 30 217 520-12
> Email: michael.bouschen@akquinet.de
> Url:    www.akquinet.de <http://www.akquinet.de>
>
> akquinet tech@spree GmbH, Berlin
> Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
> Amtsgericht Berlin-Charlottenburg HRB 86780 B
> USt.-Id. Nr.: DE 225 964 680
>
> -- 
> *Michael Bouschen*
> *Prokurist*
>
> akquinet tech@spree GmbH
> Bülowstr. 66, D-10783 Berlin
>
> Fon:   +49 30 235 520-33
> Fax:   +49 30 217 520-12
> Email: michael.bouschen@akquinet.de
> Url:    www.akquinet.de <http://www.akquinet.de>
>
> akquinet tech@spree GmbH, Berlin
> Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
> Amtsgericht Berlin-Charlottenburg HRB 86780 B
> USt.-Id. Nr.: DE 225 964 680

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Hi,

I filed a JIRA for adding support for a conditional operator ? : in
JDOQL: https://issues.apache.org/jira/browse/JDO-650

Regards Michael

> Hello.
>
> I am implementing the shortcut form for if-then-else (x ? y : c) in 
> Querydsl.
>
> Is there support for it in JDOQL? If not, could it be added?
>
> Br,
> Timo Westkämper.

-- 
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Url:    www.akquinet.de <http://www.akquinet.de>

akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680

Support for conditional operator ? : in JDOQL
---------------------------------------------

                 Key: JDO-650
                 URL: https://issues.apache.org/jira/browse/JDO-650
             Project: JDO
          Issue Type: New Feature
          Components: specification, tck2
    Affects Versions: JDO 2 maintenance release 2
            Reporter: Michael Bouschen
            Assignee: Michael Bouschen


JDOQL should support the Java conditional operator ? :, e.g. salay >= 1000.0 ? salary :
salary * 1.1

The conditional operator can be mapped to the CASE-expression in SQL: CASE WHEN condition
THEN thenExpr ELSE elseExpr END. Are there any issues with non-SQL datastores when supporting
the conditional operator? 

Another question: which part of a JDOQL query can include a conditional expression? I propose
the query filter, the having clause and the result specification.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

NOTE: We will take a brief hiatus for Thanksgiving break; next call  
will occur on December 4

Attendees: Michelle Caisse, Michael Bouschen, Craig Russell

Agenda:

1. Query timeout in JDO / Update timeout

a. Should we have different settings for query/read versus insert/ 
update/delete? Jorg says that *update* operations might need their own  
setting.

b. Should the timeout apply to *any* in-vm operations, or just to  
datastore operations? The original rationale for timeout was  
specifically to allow setting the underlying datastore timeout value.

c Should we rename the property/api something like DatastoreRead and  
DatastoreWrite? This might make it more clear that queries,  
getObjectById, refresh, and others are affected.

AI Craig update the JIRA with new proposal

2.  Query objects and hashCode()  + equals()

This issue looks like it has been resolved. If further action is  
necessary, please file a JIRA.

3. Dependence of RI on JPA2

Looks like this issue is moot. Based on our changes to JDO 2.3 and the  
fact that JPA2 is now in JCP vote, there are no timing issues.

4. Other issues

If-then-else support for JDOQL: It looks like JPA2 will support this;  
SQL supports it; are there any issues with non-SQL datastores?

Action Items from weeks past:

AI Nov 13 08 Michael: Take a look at what changes would be needed in  
the BNF to support for if-then-else in JDOQL, reply to the original  
email, open a JIRA

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Hi !

Michael Bouschen <mbo.tech@spree.de> wrote on 17.11.2009 09:05:24:

> query timeout in JDO
>
> Hi,
>
> the current spec allows specifying a query timeout on a Query, a PM
> or a PMF. The PM defines the default for all Query instances of the
> PM and the PMF defines the default value for all PMs of that PMF.
> However, there are still three open issue in the query timeout area:
>
> (1) query timeout as an optional feature
> I propose to add query timeout as an optional feature. This means
> the collection returned by the PMF method supportedOptions includes
> the string "javax.jdo.option.QueryTimeout", if the JDO
> implementation and the datastore bound to the PMF supports query
> timeout. This would be a change in chapter 11.6 "Optional Feature
> Support" of the spec.

Sounds fine as there might exists datastores which doesn't support these
feature.

> (2) Scope of the query timeout value
> I propose that a query timeout value set for a PM applies to all
> "datastore query" operations issued by the PM. This includes
> relationship navigation, findByObjectId and lasy loading of collections.
> But how about modifying operations such as update, delete and
> insert? Does it make sense to apply the PM's query timeout for these
> operationsas well? I think this makes sense, but it might be less
> obvious, because these operations are part of the transaction
> commit. See also Jörg's recent email with subject "update timeout".
> This would be a change in chapter 12 PersistenceManager. Today
> chapter 12.6.3 "Query factory interface" specifies method
> setQueryTimeout. If we broaden the scope of a query timeout set on a
> PM, it might make sense to specify this in its own section, e.g. 12.
> 6.9 "Query Timeout".

The "Query Timeout" shall be an option only for the JDO queries themself.
Keep in mind that the idea of JDO was to support any kind of datastore,
which means there exists implementations which don't use any kind of
datastore queries for operations like relationship navigation,
findByObjectId and lasy loading of collections.

> (3) Definition of query timeout: datastore operation or JDO method?
> Does the query timeout apply to the underlying datastore operation
> or does it define the maximum execution time of the JDO method such
> as Query.execute?
> I propose the former, meaning use the query timeout value for the
> datastore operation. Otherwise, the JDO implementation would need to
> calculate the timeout for the datastore operation and need o guess
> the time needed to post-process the query result. If the datastore
> has the JDBC standard second resolution, and there is less than 1000
> millis left in the timeout, what should be the timeout set on the
> datastore query statement?

>From the JDO idea it should be on the operation of the
Query.execute(), but from a Vendor persective i would suggest that
we allow both and it shouldn't be gurantied that this value is exact,
as the underlying datastore might have some kind of tolerance for the
timeout
or has different resolution for there timer.


cheers
Christian
---
Christian Ernst
Software Engineer

Tel: +49-40-60990 338
Fax: +49-40-60990 113
EMail: cernst@versant.com

Versant GmbH
Wiesenkamp 22b
22359 Hamburg
Germany

Think Outside the Grid!
http://www.versant.com

Versant GmbH is incorporated in Germany.
Company registration number: HRB 54723, Amtsgericht Hamburg.
Registered Office: Wiesenkamp 22b, 22359 Hamburg, Germany.
Geschäftsführer: Jochen Witte

Hi,

We will have our regular meeting Friday, November 20 at 9 am PDT to 
discuss JDO TCK issues and status.

Dial-in numbers are:
Domestic (toll-free):  866 230-6968
International (caller-paid):  +1 213 787-0528
Access code :  294-0479#

Agenda:

1. Query timeout in JDO / Update timeout
2.  Query objects and hashCode()  + equals()
3. Dependence of RI on JPA2
4. Other issues

Action Items from weeks past:
AI Nov 13 08 Michael: Take a look at what changes would be needed in the 
BNF to support for if-then-else in JDOQL, reply to the original email

-- Michelle

     [ https://issues.apache.org/jira/browse/JDO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michelle Caisse resolved JDO-644.
---------------------------------

    Resolution: Fixed

Completed with revision 882404

> Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"
> ---------------------------------------------------------------------
>
>                 Key: JDO-644
>                 URL: https://issues.apache.org/jira/browse/JDO-644
>             Project: JDO
>          Issue Type: Improvement
>          Components: api2, api2-legacy, core2, enhancer2, fostore2, model2, query2, runtime2,
tck2, tck2-legacy, util2
>    Affects Versions: JDO 2 maintenance release 3
>            Reporter: Matthew T. Adams
>         Attachments: jta-01-new.patch, jta-01.patch
>
>
> It appears that the Maven 2 artifact id for JTA 1.1 is "jta", not "transaction-api".
 The Maven 2 POM is here:
> http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.1/jta-1.1.pom
> For Maven1, the Maven 1 artifact id is "transaction-api":
> http://download.java.net/maven/1/javax.transaction/poms/transaction-api-1.1.pom
> Since most users use Maven2, this should be updated to "jta" and we, the team producing
JDO, should just manually install JTA 1.1 into our own local Maven 1 repository with the artifact
id "jta", using the Maven 2.  Without this, it is extremely annoying for users to have to
work around this.
> An alternative solution would be to upload to the Maven 1 central repo a copy of JTA
1.1 with artifact id "jta", but I don't how to do that.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hi,

I somehow got the feeling that having a single property for both query
and and update timeouts will create confusion, if I got Michael right here.

Imagine somebody wants to set an update timeout, but doesn't want to
constrain the duration of queries (or have a higher timeout for
queries). Now if he sets the update timeout on the PM level, then he'd
have to unset the timeout for each and every query issued. That's
assuming that the timeout on the PM level will apply to all Query
objects created by the PM.

I'd propose to have distinct properties for query and update timeouts.
The RI has distinct methods for creating Statement objects for queries
and updates already, so it shouldn't be hard to implement.

Regards,
Jörg

On 11/17/2009 09:05 AM, Michael Bouschen wrote:
> Hi,
>
> the current spec allows specifying a query timeout on a Query, a PM or
> a PMF. The PM defines the default for all Query instances of the PM
> and the PMF defines the default value for all PMs of that PMF.
> However, there are still three open issue in the query timeout area:
>
> (1) query timeout as an optional feature
> I propose to add query timeout as an optional feature. This means the
> collection returned by the PMF method supportedOptions includes the
> string "javax.jdo.option.QueryTimeout", if the JDO implementation and
> the datastore bound to the PMF supports query timeout. This would be a
> change in chapter 11.6 "Optional Feature Support" of the spec.
>
> (2) Scope of the query timeout value
> I propose that a query timeout value set for a PM applies to all
> "datastore query" operations issued by the PM. This includes
> relationship navigation, findByObjectId and lasy loading of collections.
> But how about modifying operations such as update, delete and insert?
> Does it make sense to apply the PM's query timeout for these
> operationsas well? I think this makes sense, but it might be less
> obvious, because these operations are part of the transaction commit.
> See also Jörg's recent email with subject "update timeout". This would
> be a change in chapter 12 PersistenceManager. Today chapter 12.6.3
> "Query factory interface" specifies method setQueryTimeout. If we
> broaden the scope of a query timeout set on a PM, it might make sense
> to specify this in its own section, e.g. 12.6.9 "Query Timeout".
>
> (3) Definition of query timeout: datastore operation or JDO method?
> Does the query timeout apply to the underlying datastore operation or
> does it define the maximum execution time of the JDO method such as
> Query.execute?
> I propose the former, meaning use the query timeout value for the
> datastore operation. Otherwise, the JDO implementation would need to
> calculate the timeout for the datastore operation and need o guess the
> time needed to post-process the query result. If the datastore has the
> JDBC standard second resolution, and there is less than 1000 millis
> left in the timeout, what should be the timeout set on the datastore
> query statement?
>
> What do you think?
>
> Regards Michael


-- 
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
UST-Id. DE 217652550

> all I could find in the docs was
> http://www.datanucleus.org/extensions/query_cache.html which is about
> caching of "query compilations". Or do you mean that it could be used to
> store query results along with a cached QueryCompilation object?

PMF prop(s)
http://www.datanucleus.org/products/accessplatform_2_0/persistence_properties.html#query

Query Cache(s)
http://www.datanucleus.org/products/accessplatform_2_0/jdo/query_cache.html

or look at the code ...

-- 
Andy
DataNucleus (http://www.datanucleus.org)

Hi Andy,

all I could find in the docs was
http://www.datanucleus.org/extensions/query_cache.html which is about
caching of "query compilations". Or do you mean that it could be used to
store query results along with a cached QueryCompilation object?

On 11/17/2009 06:19 PM, Andy Jefferson wrote:
>> Our application framework caches the results of certain queries. It does
>> not hand out the respective Query objects to application code, and it
>> does not itself invoke any mutators on these Query objects.
>>     
> DataNucleus v2.x also allows caching of query results (for non-legacy JDOQL 
> implementations). They are not cached by the "Query" object, but by a key that 
> represents the query string and the input parameters. Consequently no such map 
> lookup issues happen.
>
>
>   


-- 
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
UST-Id. DE 217652550

> Our application framework caches the results of certain queries. It does
> not hand out the respective Query objects to application code, and it
> does not itself invoke any mutators on these Query objects.

DataNucleus v2.x also allows caching of query results (for non-legacy JDOQL 
implementations). They are not cached by the "Query" object, but by a key that 
represents the query string and the input parameters. Consequently no such map 
lookup issues happen.


-- 
Andy
DataNucleus (http://www.datanucleus.org)

Hi Jörg,

that the value of hashCode must not change, once an object is stored in a 
(hashCode aware) Map, might
not be explicitly stated in the javadoc, but this is a natural 
requirement.

The behavior of equals() then can actually change, provided the general 
equals/hashCode contract is respected,
although a change of the behavior of equals() is in most cases not 
desirable.

Changing the hashCode once an object is in a Map, breaks the Map contract.

Changing equals behavior once an object is in a Map, does not break the 
Map contract, but the key
that the value is to mapped to is changed.

For tree structured, not hashCode aware maps, both can change within the 
limits of the equals/hashCode contract,
but the total ordering imposed by the Comparator or the Comparable 
implementation must remain unchanged.

The easiest implementation is basing hashCode, equals and compareTo on a 
(sub)set of the immutable fields.

Cheers,

Christian





From:
Joerg von Frantzius <joerg.von.frantzius@artnology.com>
To:
Craig L Russell <Craig.Russell@sun.com>
Cc:
jdo-dev@db.apache.org, JDO Expert Group <jdo-experts-ext@sun.com>
Date:
17.11.2009 12:55
Subject:
Re: Query objects and hashCode()  + equals()



Hi Craig,

please see below...

On 11/17/2009 12:52 AM, Craig L Russell wrote:

[..]
> Right. What I said is that for use as an element in a Set or as a key
> in a Map, the instance should return the identical hashCode and behave
> identically with respect to equals. So while the instance itself does
> not have to be immutable, hashCode and equals should act on immutable
> properties of the instance.
I didn't find a hint in the javadocs that hashCode and equals should
only act on immutable properties of the instance. But admittedly that's
just nit-picking on my side, as I do agree that the Query objects must
remain unchanged once they are put in a Set or used as a key in a HashMap.
>
> As I understand how these collections work, if you do change how
> hashCode and equals behave after construction, the instance should be
> removed from the collection and added again after the change is done.
> This is pretty tricky in terms of synchronization and order of 
operation.
That's true. So an application framework which uses Query objects as
keys in a Map must not hand out Query objects to application code (and
of course, once a Query object is put in a map, the framework must not
invoke mutators on it).

[..]

>> I wouldn't ask if datanucleus wasn't already there halfway: 
datanucleus'
>> JDO query object delegates to org.datanucleus.store.query.Query, which
>> already correctly implements equals(), hashCode() and toString().
>
>
> So does the query object change hashCode when the filter changes?
Yes, it does.
>
>> [..]
>> Just a small thing, I hope I'll find the time to fix it in datanucleus
>> myself. When that has happened, it could still be worth putting in
>> the spec?
>
> I don't yet understand the use case. Can you be specific as to what
> behavior you expect from a "proper implementation" of hashCode,
> equals, and toString, and how the implementation would be exploited by
> an application?
Generally speaking, two Query objects should be equal if they represent
the same query, i.e. they are equal if their execution at an ideally
same point in time would yield the same result. The implementation of
hashCode() should follow and fulfill the usual contract between equals()
and hashCode().

If that was given, I wouldn't have any requirements on the
implementation of toString(). Currently datanucleus returns the
single-string representation of the query, which is just great.

Our application framework caches the results of certain queries. It does
not hand out the respective Query objects to application code, and it
does not itself invoke any mutators on these Query objects. A query
result caching like that currently is hard to do when it is solely based
on the spec, because neither equals(), hashCode() or toString() can
reliably be used. It also is impossible for application (framework) code
itself to build a cache key from a given Query object, because the Query
interface does not provide any getters, e.g. for its filter etc. The
only solution would be to separately remember the properties of the
Query object when it is built.

Regards,
Jörg

>
> Regards,
>
> Craig
>>
>> Regards,
>> Jörg
>>
>> On 10/23/2009 06:57 PM, Craig L Russell wrote:
>>> Hi Jörg,
>>>
>>> On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:
>>>
>>>> Hi,
>>>>
>>>> it would be nice if the spec would mandate that implementations of
>>>> javax.jdo.Query do correctly implement hashCode() and equals().
>>>
>>> As users execute mutator methods on queries, the string representation
>>> would change. And for proper use in sets or map keys, hashCode and
>>> equals should be  immutable after construction. So I don't see how we
>>> can mandate that hashCode and equals rely in any internal state.
>>>
>>>> Alternatively, Query.toString() could be required to return the
>>>> single-string representation of the query, or some dedicated method
>>>> was
>>>> added to provide it.
>>>>
>>> Having the single-string version of a query is useful but adds
>>> implementation complexity. While there is a requirement for an
>>> implementation to parse a single string query into executable form,
>>> there's no current requirement to create the single string form from
>>> the internal form.
>>>
>>>> This would make it easier to e.g. implement some custom cache for
>>>> query
>>>> results, or, more generally, it would make it easier to put Query
>>>> objects as keys into Maps.
>>>
>>> It seems to me that if you want this functionality at the application
>>> framework layer, then the framework can mandate that the single string
>>> form be used and at the time the query is created, the single string
>>> form be used as the key into a framework map.
>>>
>>> Regards,
>>>
>>> Craig
>>>> ____________________________________________________________________
>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
>>>> UST-Id. DE 217652550
>>>>
>>>
>>> Craig L Russell
>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>>
>> -- 
>> ____________________________________________________________________
>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
>> UST-Id. DE 217652550
>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


-- 
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
UST-Id. DE 217652550

[attachment "joerg_von_frantzius.vcf" deleted by Christian 
Romberg/VERSANT] 

Hi Craig,

please see below...

On 11/17/2009 12:52 AM, Craig L Russell wrote:

[..]
> Right. What I said is that for use as an element in a Set or as a key
> in a Map, the instance should return the identical hashCode and behave
> identically with respect to equals. So while the instance itself does
> not have to be immutable, hashCode and equals should act on immutable
> properties of the instance.
I didn't find a hint in the javadocs that hashCode and equals should
only act on immutable properties of the instance. But admittedly that's
just nit-picking on my side, as I do agree that the Query objects must
remain unchanged once they are put in a Set or used as a key in a HashMap.
>
> As I understand how these collections work, if you do change how
> hashCode and equals behave after construction, the instance should be
> removed from the collection and added again after the change is done.
> This is pretty tricky in terms of synchronization and order of operation.
That's true. So an application framework which uses Query objects as
keys in a Map must not hand out Query objects to application code (and
of course, once a Query object is put in a map, the framework must not
invoke mutators on it).

[..]

>> I wouldn't ask if datanucleus wasn't already there halfway: datanucleus'
>> JDO query object delegates to org.datanucleus.store.query.Query, which
>> already correctly implements equals(), hashCode() and toString().
>
>
> So does the query object change hashCode when the filter changes?
Yes, it does.
>
>> [..]
>> Just a small thing, I hope I'll find the time to fix it in datanucleus
>> myself. When that has happened, it could still be worth putting in
>> the spec?
>
> I don't yet understand the use case. Can you be specific as to what
> behavior you expect from a "proper implementation" of hashCode,
> equals, and toString, and how the implementation would be exploited by
> an application?
Generally speaking, two Query objects should be equal if they represent
the same query, i.e. they are equal if their execution at an ideally
same point in time would yield the same result. The implementation of
hashCode() should follow and fulfill the usual contract between equals()
and hashCode().

If that was given, I wouldn't have any requirements on the
implementation of toString(). Currently datanucleus returns the
single-string representation of the query, which is just great.

Our application framework caches the results of certain queries. It does
not hand out the respective Query objects to application code, and it
does not itself invoke any mutators on these Query objects. A query
result caching like that currently is hard to do when it is solely based
on the spec, because neither equals(), hashCode() or toString() can
reliably be used. It also is impossible for application (framework) code
itself to build a cache key from a given Query object, because the Query
interface does not provide any getters, e.g. for its filter etc. The
only solution would be to separately remember the properties of the
Query object when it is built.

Regards,
Jörg

>
> Regards,
>
> Craig
>>
>> Regards,
>> Jörg
>>
>> On 10/23/2009 06:57 PM, Craig L Russell wrote:
>>> Hi Jörg,
>>>
>>> On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:
>>>
>>>> Hi,
>>>>
>>>> it would be nice if the spec would mandate that implementations of
>>>> javax.jdo.Query do correctly implement hashCode() and equals().
>>>
>>> As users execute mutator methods on queries, the string representation
>>> would change. And for proper use in sets or map keys, hashCode and
>>> equals should be  immutable after construction. So I don't see how we
>>> can mandate that hashCode and equals rely in any internal state.
>>>
>>>> Alternatively, Query.toString() could be required to return the
>>>> single-string representation of the query, or some dedicated method
>>>> was
>>>> added to provide it.
>>>>
>>> Having the single-string version of a query is useful but adds
>>> implementation complexity. While there is a requirement for an
>>> implementation to parse a single string query into executable form,
>>> there's no current requirement to create the single string form from
>>> the internal form.
>>>
>>>> This would make it easier to e.g. implement some custom cache for
>>>> query
>>>> results, or, more generally, it would make it easier to put Query
>>>> objects as keys into Maps.
>>>
>>> It seems to me that if you want this functionality at the application
>>> framework layer, then the framework can mandate that the single string
>>> form be used and at the time the query is created, the single string
>>> form be used as the key into a framework map.
>>>
>>> Regards,
>>>
>>> Craig
>>>> ____________________________________________________________________
>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
>>>> UST-Id. DE 217652550
>>>>
>>>
>>> Craig L Russell
>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>>
>> -- 
>> ____________________________________________________________________
>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
>> UST-Id. DE 217652550
>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


-- 
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
UST-Id. DE 217652550

    [ https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778780#action_12778780
] 

Andy Jefferson commented on JDO-649:
------------------------------------

But will JDO 2.3 really *depend on* JPA2 ? All I've changed here is that the RI for JDO2.3
just happens to also implement JPA2, so has references to JPA2 classes. JDO2.3 itself has
no such references to JPA2 classes, and it is only the JDO 2.3 TCK that does due to the RI.

> Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses
that now
> ---------------------------------------------------------------------------------------------
>
>                 Key: JDO-649
>                 URL: https://issues.apache.org/jira/browse/JDO-649
>             Project: JDO
>          Issue Type: Task
>          Components: tck2
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: JDO 2 maintenance release 3
>
>
> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs"
dependency. Was previously
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_3.0_spec</artifactId>
>     <version>1.0</version>
> </dependency>
> and should be
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_2.0_spec</artifactId>
>     <version>1.0-PFD2</version>
> </dependency>
> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hi,

the current spec allows specifying a query timeout on a Query, a PM or a 
PMF. The PM defines the default for all Query instances of the PM and 
the PMF defines the default value for all PMs of that PMF. However, 
there are still three open issue in the query timeout area:

(1) query timeout as an optional feature
I propose to add query timeout as an optional feature. This means the 
collection returned by the PMF method supportedOptions includes the 
string "javax.jdo.option.QueryTimeout", if the JDO implementation and 
the datastore bound to the PMF supports query timeout. This would be a 
change in chapter 11.6 "Optional Feature Support" of the spec.

(2) Scope of the query timeout value
I propose that a query timeout value set for a PM applies to all 
"datastore query" operations issued by the PM. This includes 
relationship navigation, findByObjectId and lasy loading of collections.
But how about modifying operations such as update, delete and insert? 
Does it make sense to apply the PM's query timeout for these 
operationsas well? I think this makes sense, but it might be less 
obvious, because these operations are part of the transaction commit. 
See also Jörg's recent email with subject "update timeout". This would 
be a change in chapter 12 PersistenceManager. Today chapter 12.6.3 
"Query factory interface" specifies method setQueryTimeout. If we 
broaden the scope of a query timeout set on a PM, it might make sense to 
specify this in its own section, e.g. 12.6.9 "Query Timeout".

(3) Definition of query timeout: datastore operation or JDO method?
Does the query timeout apply to the underlying datastore operation or 
does it define the maximum execution time of the JDO method such as 
Query.execute?
I propose the former, meaning use the query timeout value for the 
datastore operation. Otherwise, the JDO implementation would need to 
calculate the timeout for the datastore operation and need o guess the 
time needed to post-process the query result. If the datastore has the 
JDBC standard second resolution, and there is less than 1000 millis left 
in the timeout, what should be the timeout set on the datastore query 
statement?

What do you think?

Regards Michael
-- 
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Url:    www.akquinet.de <http://www.akquinet.de>

akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680

-- 
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Url:    www.akquinet.de <http://www.akquinet.de>

akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680

-- 
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Url:    www.akquinet.de <http://www.akquinet.de>

akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680

    [ https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778662#action_12778662
] 

Craig Russell commented on JDO-649:
-----------------------------------

This could use just a bit more discussion, since this means that JDO 2.3 *will depend* on
JPA 2.

The timing is probably right, but let's discuss this new dependency.

> Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses
that now
> ---------------------------------------------------------------------------------------------
>
>                 Key: JDO-649
>                 URL: https://issues.apache.org/jira/browse/JDO-649
>             Project: JDO
>          Issue Type: Task
>          Components: tck2
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: JDO 2 maintenance release 3
>
>
> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs"
dependency. Was previously
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_3.0_spec</artifactId>
>     <version>1.0</version>
> </dependency>
> and should be
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_2.0_spec</artifactId>
>     <version>1.0-PFD2</version>
> </dependency>
> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hi Jörg,

On Nov 16, 2009, at 8:32 AM, Joerg von Frantzius wrote:

> Hi Craig,
>
> you are absolutely right about the Query object being mutable, and  
> this
> conflicting with its use as a key in a HashMap. But telling from the
> general contracts of Map, equals() and hashCode(), I don't think that
> there exists a requirement for Map keys to be immutable.

Right. What I said is that for use as an element in a Set or as a key  
in a Map, the instance should return the identical hashCode and behave  
identically with respect to equals. So while the instance itself does  
not have to be immutable, hashCode and equals should act on immutable  
properties of the instance.

As I understand how these collections work, if you do change how  
hashCode and equals behave after construction, the instance should be  
removed from the collection and added again after the change is done.  
This is pretty tricky in terms of synchronization and order of  
operation.

> There may also
> be other purposes for comparing Query objects using equals(), or Map
> implementations that don't require immutability of keys.
>
> I wouldn't ask if datanucleus wasn't already there halfway:  
> datanucleus'
> JDO query object delegates to org.datanucleus.store.query.Query, which
> already correctly implements equals(), hashCode() and toString().

So does the query object change hashCode when the filter changes?

> The
> only thing missing is the wrapper query object to also delegate these
> methods (I guess that was simply forgotten when that additional layer
> was introduced with JPOX implementing JPA).
>
> Just a small thing, I hope I'll find the time to fix it in datanucleus
> myself. When that has happened, it could still be worth putting in  
> the spec?

I don't yet understand the use case. Can you be specific as to what  
behavior you expect from a "proper implementation" of hashCode,  
equals, and toString, and how the implementation would be exploited by  
an application?

Regards,

Craig
>
> Regards,
> Jörg
>
> On 10/23/2009 06:57 PM, Craig L Russell wrote:
>> Hi Jörg,
>>
>> On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:
>>
>>> Hi,
>>>
>>> it would be nice if the spec would mandate that implementations of
>>> javax.jdo.Query do correctly implement hashCode() and equals().
>>
>> As users execute mutator methods on queries, the string  
>> representation
>> would change. And for proper use in sets or map keys, hashCode and
>> equals should be  immutable after construction. So I don't see how we
>> can mandate that hashCode and equals rely in any internal state.
>>
>>> Alternatively, Query.toString() could be required to return the
>>> single-string representation of the query, or some dedicated  
>>> method was
>>> added to provide it.
>>>
>> Having the single-string version of a query is useful but adds
>> implementation complexity. While there is a requirement for an
>> implementation to parse a single string query into executable form,
>> there's no current requirement to create the single string form from
>> the internal form.
>>
>>> This would make it easier to e.g. implement some custom cache for  
>>> query
>>> results, or, more generally, it would make it easier to put Query
>>> objects as keys into Maps.
>>
>> It seems to me that if you want this functionality at the application
>> framework layer, then the framework can mandate that the single  
>> string
>> form be used and at the time the query is created, the single string
>> form be used as the key into a framework map.
>>
>> Regards,
>>
>> Craig
>>> ____________________________________________________________________
>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
>>> UST-Id. DE 217652550
>>>
>>
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
>
> -- 
> ____________________________________________________________________
> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
> UST-Id. DE 217652550
>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Hi Jörg,

This is a timely comment. We're just finalizing the query timeout  
issue and we should take care of this item as well for the 2.3 release.

It's possible that we could use the same query timeout value that we  
set on the PersistenceManagerFactory and PersistenceManager to apply  
to both queries and updates/deletes. This would minimize the API  
"footprint" with no loss of expressiveness.

So let's discuss the scope of the query timeout possibly to apply to  
delete and update operations as well.

I agree that it's currently not possible to get access to the  
Statement that is being executed so you can set the timeout in the  
application. It has to be a JDO setting.

Regards,

Craig

On Nov 16, 2009, at 9:27 AM, Joerg von Frantzius wrote:

> Hi,
>
> the other day we had the problem that a row lock got held indefinitely
> in a production database, probably because of the appserver not  
> properly
> committing a connection. As a consequence, the HTTP-threads of the
> appserver got blocked one after the other, during execution of an  
> UPDATE
> statement. This eventually lead to the whole appserver cluster to  
> hang,
> when all HTTP thread pools were filled with blocked threads.
>
> The consequences of a single hanging row-lock could be much less  
> drastic
> if something like an update timeout existed. I was hoping that
> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#setQueryTimeout(int)
> applies to both SELECT and UPDATE statements, so that threads  
> blocked in
> a UPDATE statement wouldn't do so forever.
>
> What do you think of having an additional  
> javax.jdo.option.UpdateTimeout
> PMF property for this?
>
> Currently there is no way for an application to access any
> java.sql.Statement object used by the JDO implementation to invoke
> setQueryTimeout() by itself, so in order to have update timeouts with
> JDO, some extension of the spec would be necessary?
>
> Regards,
> Jörg
>
> -- 
> ____________________________________________________________________
> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
> UST-Id. DE 217652550
>
> <joerg_von_frantzius.vcf>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Hi,

the other day we had the problem that a row lock got held indefinitely
in a production database, probably because of the appserver not properly
committing a connection. As a consequence, the HTTP-threads of the
appserver got blocked one after the other, during execution of an UPDATE
statement. This eventually lead to the whole appserver cluster to hang,
when all HTTP thread pools were filled with blocked threads.

The consequences of a single hanging row-lock could be much less drastic
if something like an update timeout existed. I was hoping that
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#setQueryTimeout(int)
applies to both SELECT and UPDATE statements, so that threads blocked in
a UPDATE statement wouldn't do so forever.

What do you think of having an additional javax.jdo.option.UpdateTimeout
PMF property for this?

Currently there is no way for an application to access any
java.sql.Statement object used by the JDO implementation to invoke
setQueryTimeout() by itself, so in order to have update timeouts with
JDO, some extension of the spec would be necessary?

Regards,
Jörg

-- 
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
UST-Id. DE 217652550

Hi Craig,

you are absolutely right about the Query object being mutable, and this
conflicting with its use as a key in a HashMap. But telling from the
general contracts of Map, equals() and hashCode(), I don't think that
there exists a requirement for Map keys to be immutable. There may also
be other purposes for comparing Query objects using equals(), or Map
implementations that don't require immutability of keys.

I wouldn't ask if datanucleus wasn't already there halfway: datanucleus'
JDO query object delegates to org.datanucleus.store.query.Query, which
already correctly implements equals(), hashCode() and toString(). The
only thing missing is the wrapper query object to also delegate these
methods (I guess that was simply forgotten when that additional layer
was introduced with JPOX implementing JPA).

Just a small thing, I hope I'll find the time to fix it in datanucleus
myself. When that has happened, it could still be worth putting in the spec?

Regards,
Jörg

On 10/23/2009 06:57 PM, Craig L Russell wrote:
> Hi Jörg,
>
> On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:
>
>> Hi,
>>
>> it would be nice if the spec would mandate that implementations of
>> javax.jdo.Query do correctly implement hashCode() and equals().
>
> As users execute mutator methods on queries, the string representation
> would change. And for proper use in sets or map keys, hashCode and
> equals should be  immutable after construction. So I don't see how we
> can mandate that hashCode and equals rely in any internal state.
>
>> Alternatively, Query.toString() could be required to return the
>> single-string representation of the query, or some dedicated method was
>> added to provide it.
>>
> Having the single-string version of a query is useful but adds
> implementation complexity. While there is a requirement for an
> implementation to parse a single string query into executable form,
> there's no current requirement to create the single string form from
> the internal form.
>
>> This would make it easier to e.g. implement some custom cache for query
>> results, or, more generally, it would make it easier to put Query
>> objects as keys into Maps.
>
> It seems to me that if you want this functionality at the application
> framework layer, then the framework can mandate that the single string
> form be used and at the time the query is created, the single string
> form be used as the key into a framework map.
>
> Regards,
>
> Craig
>> ____________________________________________________________________
>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
>> UST-Id. DE 217652550
>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


-- 
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
UST-Id. DE 217652550

     [ https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Jefferson resolved JDO-649.
--------------------------------

    Resolution: Fixed

SVN trunk fixes this

> Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses
that now
> ---------------------------------------------------------------------------------------------
>
>                 Key: JDO-649
>                 URL: https://issues.apache.org/jira/browse/JDO-649
>             Project: JDO
>          Issue Type: Task
>          Components: tck2
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: JDO 2 maintenance release 3
>
>
> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs"
dependency. Was previously
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_3.0_spec</artifactId>
>     <version>1.0</version>
> </dependency>
> and should be
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_2.0_spec</artifactId>
>     <version>1.0-PFD2</version>
> </dependency>
> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Jefferson updated JDO-649:
-------------------------------

    Summary: Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x
uses that now  (was: Upgrade "persistence.xml" for use with TCK to be JPA2 since DataNucleus
2.x uses that now)

> Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses
that now
> ---------------------------------------------------------------------------------------------
>
>                 Key: JDO-649
>                 URL: https://issues.apache.org/jira/browse/JDO-649
>             Project: JDO
>          Issue Type: Task
>          Components: tck2
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: JDO 2 maintenance release 3
>
>
> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs"
dependency. Was previously
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_3.0_spec</artifactId>
>     <version>1.0</version>
> </dependency>
> and should be
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_2.0_spec</artifactId>
>     <version>1.0-PFD2</version>
> </dependency>
> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Jefferson updated JDO-649:
-------------------------------

    Description: 
DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs"
dependency. Was previously

<dependency>
    <groupId>org.apache.geronimo.specs</groupId>
    <artifactId>geronimo-jpa_3.0_spec</artifactId>
    <version>1.0</version>
</dependency>

and should be

<dependency>
    <groupId>org.apache.geronimo.specs</groupId>
    <artifactId>geronimo-jpa_2.0_spec</artifactId>
    <version>1.0-PFD2</version>
</dependency>

No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...

  was:DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs"
dependency


> Upgrade "persistence.xml" for use with TCK to be JPA2 since DataNucleus 2.x uses that
now
> -----------------------------------------------------------------------------------------
>
>                 Key: JDO-649
>                 URL: https://issues.apache.org/jira/browse/JDO-649
>             Project: JDO
>          Issue Type: Task
>          Components: tck2
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: JDO 2 maintenance release 3
>
>
> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs"
dependency. Was previously
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_3.0_spec</artifactId>
>     <version>1.0</version>
> </dependency>
> and should be
> <dependency>
>     <groupId>org.apache.geronimo.specs</groupId>
>     <artifactId>geronimo-jpa_2.0_spec</artifactId>
>     <version>1.0-PFD2</version>
> </dependency>
> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Upgrade "persistence.xml" for use with TCK to be JPA2 since DataNucleus 2.x uses that now
-----------------------------------------------------------------------------------------

                 Key: JDO-649
                 URL: https://issues.apache.org/jira/browse/JDO-649
             Project: JDO
          Issue Type: Task
          Components: tck2
            Reporter: Andy Jefferson
            Assignee: Andy Jefferson
             Fix For: JDO 2 maintenance release 3


DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs"
dependency

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Attendees: Michael Bouschen, Michelle Caisse, Craig Russell

Agenda:

1. Change JTA 1.1 dependency artifact id from "transaction-api" to  
"jta" https://issues.apache.org/jira/browse/JDO-644

Patch looks good. Ship it.

2. Query timeout test https://issues.apache.org/jira/browse/JDO-623

Issues needing resolution: Should there be a documented option in case  
the JDO implementation or the underlying datastore doesn't support a  
query timeout? Does the query timeout apply to all "datastore query"  
operations including find by key, navigation, and loading lazy  
collections? If the datastore has the JDBC standard second resolution,  
and there is less than 1000 millis left in the timeout, what should be  
the timeout set on the datastore query statement? AI Michael write up  
issues with proposed solution.

3. Question re Support for if-then-else in JDOQL

This might make sense for a future release (it's probably too big to  
fit into 2.3). AI Michael take a look at what changes would be needed  
in the BNF, reply to the original email, and then discuss. The Java  
conditional expression maps to the SQL CASE ELSE END expression. More  
difficult for non-SQL datastores so it might involve an optional  
feature.

4. Other issues

none.

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

     [ https://issues.apache.org/jira/browse/JDO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michelle Caisse updated JDO-644:
--------------------------------

    Attachment: jta-01-new.patch

Per discussion at the last teleconference, propose using this new patch that modifies only
api2/pom.xml, which is the only build file used by Maven 2. This should solve the problem
with Maven 2 and avoid any issues for Maven 1 users.

> Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"
> ---------------------------------------------------------------------
>
>                 Key: JDO-644
>                 URL: https://issues.apache.org/jira/browse/JDO-644
>             Project: JDO
>          Issue Type: Improvement
>          Components: api2, api2-legacy, core2, enhancer2, fostore2, model2, query2, runtime2,
tck2, tck2-legacy, util2
>    Affects Versions: JDO 2 maintenance release 3
>            Reporter: Matthew T. Adams
>         Attachments: jta-01-new.patch, jta-01.patch
>
>
> It appears that the Maven 2 artifact id for JTA 1.1 is "jta", not "transaction-api".
 The Maven 2 POM is here:
> http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.1/jta-1.1.pom
> For Maven1, the Maven 1 artifact id is "transaction-api":
> http://download.java.net/maven/1/javax.transaction/poms/transaction-api-1.1.pom
> Since most users use Maven2, this should be updated to "jta" and we, the team producing
JDO, should just manually install JTA 1.1 into our own local Maven 1 repository with the artifact
id "jta", using the Maven 2.  Without this, it is extremely annoying for users to have to
work around this.
> An alternative solution would be to upload to the Maven 1 central repo a copy of JTA
1.1 with artifact id "jta", but I don't how to do that.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hi,

We will have our regular meeting Friday, November 13 at 9 am PDT to 
discuss JDO TCK issues and status.

Dial-in numbers are:
Domestic (toll-free):  866 230-6968
International (caller-paid):  +1 213 787-0528
Access code :  294-0479#

Agenda:

1. Change JTA 1.1 dependency artifact id from "transaction-api" to "jta" 
https://issues.apache.org/jira/browse/JDO-644
2. Query timeout test https://issues.apache.org/jira/browse/JDO-623
3. Question re Support for if-then-else in JDOQL
4. Other issues

Action Items from weeks past:

-- Michelle

Hello.

I am implementing the shortcut form for if-then-else (x ? y : c) in 
Querydsl.

Is there support for it in JDOQL? If not, could it be added?

Br,
Timo Westkämper.

-- 
Timo Westkämper <timo.westkamper@mysema.com>
Mysema Ltd, Vilhonkatu 5 A, 00100 Helsinki, Finland
Mob. +358 (0)40 591 2172 
Internet: http://www.mysema.com

Tomorrow's conference call is cancelled. We will meet again on Friday, 
November 13 at 9 am PST.

-- Michelle

If the issue is support for JDBC setQueryTimeout, it appears that at 
least PostgreSQL lacks support. Here are links to discussions of the 
issue for a few databases.

Oracle: supported, but timing issues can affect results 
http://forums.oracle.com/forums/thread.jspa?threadID=550257

PostgreSQL: apparently not supported 
http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00089.php

Derby: supported 
http://old.nabble.com/cancel-a-running-query--td19903183.html

-- Michelle

Hi,

I'm sorry, I missed the call today. I forgot that the conference call is 
one hour earlier for me, because Germany already switched back from 
daylight saving time. I checked my email to prepare for the conference 
call and found the minutes :-).

Regards Michael

> Attendees: Michelle Caisse, Craig Russell
>
> Agenda:
>
> 1. Change JTA 1.1 dependency artifact id from "transaction-api" to 
> "jta" https://issues.apache.org/jira/browse/JDO-644
>
> It seems that there is a problem with the patch. Since the only 
> artifact affected for maven 2 users is the api2/pom.xml, and maven 1 
> is used for everything else, perhaps simply updating the api2 pom 
> would be best. AI Michelle test just updating api2 pom and update the 
> JIRA.
>
> 2. Query timeout test https://issues.apache.org/jira/browse/JDO-623
>
> Still open AI's to finish the discussion of what exactly query timeout 
> means, and whether it's optional.
>
> 3. Other issues
>
> Action Items from weeks past:
>
> 16 Oct 08 AI Michelle: Investigate query timeouts as they apply to SQL 
> standard datastores.
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


-- 
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Url:    www.akquinet.de <http://www.akquinet.de>

akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680

Attendees: Michelle Caisse, Craig Russell

Agenda:

1. Change JTA 1.1 dependency artifact id from "transaction-api" to  
"jta" https://issues.apache.org/jira/browse/JDO-644

It seems that there is a problem with the patch. Since the only  
artifact affected for maven 2 users is the api2/pom.xml, and maven 1  
is used for everything else, perhaps simply updating the api2 pom  
would be best. AI Michelle test just updating api2 pom and update the  
JIRA.

2. Query timeout test https://issues.apache.org/jira/browse/JDO-623

Still open AI's to finish the discussion of what exactly query timeout  
means, and whether it's optional.

3. Other issues

Action Items from weeks past:

16 Oct 08 AI Michelle: Investigate query timeouts as they apply to SQL  
standard datastores.

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Hi,

We will have our regular meeting Friday, October 30 at 9 am PDT to 
discuss JDO TCK issues and status.

NOTE THAT THE U.S. IS STILL ON DAYLIGHT SAVINGS TIME TODAY!

Dial-in numbers are:
Domestic (toll-free):  866 230-6968
International (caller-paid):  +1 213 787-0528
Access code :  294-0479#

Agenda:

1. Change JTA 1.1 dependency artifact id from "transaction-api" to "jta" 
https://issues.apache.org/jira/browse/JDO-644
2. Query timeout test https://issues.apache.org/jira/browse/JDO-623
3. Other issues

Action Items from weeks past:

16 Oct 08 AI Michelle: Investigate query timeouts as they apply to SQL 
standard datastores.

-- Michelle

    [ https://issues.apache.org/jira/browse/JDO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769738#action_12769738
] 

Michelle Caisse commented on JDO-644:
-------------------------------------

Since the TCK can only be run with Maven 1, can we leave tck2/project.xml as is?

With the patch installed I get enhancer errors on running the TCK, whereas the api2 project
builds without error.

16:36:40,468 (main) ERROR [DataNucleus.MetaData] - Class "org.apache.jdo.tck.pc.companyListWithoutJoin.CompanyModelReader"
was not found in the CLASSPATH. Please check your specification and your CLASSPATH.
org.datanucleus.exceptions.ClassNotResolvedException: Class "org.apache.jdo.tck.pc.companyListWithoutJoin.CompanyModelReader"
was not found in the CLASSPATH. Please check your specification and your CLASSPATH.
        at org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:250)
        at org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:415)
        at org.datanucleus.metadata.MetaDataManager.loadClasses(MetaDataManager.java:436)
        at org.datanucleus.enhancer.DataNucleusEnhancer.getFileMetadataForInput(DataNucleusEnhancer.java:703)
        at org.datanucleus.enhancer.DataNucleusEnhancer.enhance(DataNucleusEnhancer.java:551)
        at org.datanucleus.jdo.JDODataNucleusEnhancer.enhance(JDODataNucleusEnhancer.java:126)
        at javax.jdo.Enhancer.run(Enhancer.java:196)
        at javax.jdo.Enhancer.main(Enhancer.java:130)

for:
org.apache.jdo.tck.pc.mylib.MylibReader
org.apache.jdo.tck.pc.companyListWithoutJoin.CompanyModelReader
org.apache.jdo.tck.pc.companyMapWithoutJoin.CompanyModelReader
org.apache.jdo.tck.pc.company.CompanyModelReader
org.apache.jdo.tck.pc.order.OrderModelReader

There are also test errors, including the runonce test.

I haven't tried to upload jta 1.1, but why would it be found for api2 and not tck2? The only
possibly relevant difference I can see is that api2 has a pom.xml and tck2 does not.




> Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"
> ---------------------------------------------------------------------
>
>                 Key: JDO-644
>                 URL: https://issues.apache.org/jira/browse/JDO-644
>             Project: JDO
>          Issue Type: Improvement
>          Components: api2, api2-legacy, core2, enhancer2, fostore2, model2, query2, runtime2,
tck2, tck2-legacy, util2
>    Affects Versions: JDO 2 maintenance release 3
>            Reporter: Matthew T. Adams
>         Attachments: jta-01.patch
>
>
> It appears that the Maven 2 artifact id for JTA 1.1 is "jta", not "transaction-api".
 The Maven 2 POM is here:
> http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.1/jta-1.1.pom
> For Maven1, the Maven 1 artifact id is "transaction-api":
> http://download.java.net/maven/1/javax.transaction/poms/transaction-api-1.1.pom
> Since most users use Maven2, this should be updated to "jta" and we, the team producing
JDO, should just manually install JTA 1.1 into our own local Maven 1 repository with the artifact
id "jta", using the Maven 2.  Without this, it is extremely annoying for users to have to
work around this.
> An alternative solution would be to upload to the Maven 1 central repo a copy of JTA
1.1 with artifact id "jta", but I don't how to do that.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/JDO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michelle Caisse resolved JDO-639.
---------------------------------

    Resolution: Fixed

Complete with revision 829438

> tck enhancement should make use of feature to enhance an entire directory
> -------------------------------------------------------------------------
>
>                 Key: JDO-639
>                 URL: https://issues.apache.org/jira/browse/JDO-639
>             Project: JDO
>          Issue Type: Improvement
>          Components: tck2
>    Affects Versions: JDO 2 maintenance release 2
>            Reporter: Michael Bouschen
>            Assignee: Michelle Caisse
>         Attachments: enhance.txt, jdo-639.txt
>
>
> The current enhancer call as part of the runtck goal takes a list of .jdo files as an
argument (see property jdo.tck.jdometadata.files in project.properties and maven.xml). The
new enhancer invocation API allows to enhance all files of a given directory. We should investigate
to make use of this feature in order to get rid of listing all the .jdo in the property jdo.tck.jdometadata.files.
> There is a similar issue with the properties jdo.tck.pcclasses.sources and jdo.tck.pcclasses.files:
> - Property jdo.tck.pcclasses.sources is used when checking whether (re)enhancing is required.
Maybe a pattern 
>    org/apache/jdo/tck/api/**/*.java, org/apache/jdo/tck/pc/**/*.java
> can be used instead of listing all the persistent capable classes explicitly.
> - Property jdo.tck.pcclasses.files is used when copying the class file into the identitytype
specific subdirectories before running the enhancer. Maybe a similar pattern could replace
the list of class files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/jira/browse/JDO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769695#action_12769695
] 

Craig Russell commented on JDO-639:
-----------------------------------

> The variables jdo.tck.paclasses.sources and jdo.tck.pcclasses.sources are always used
together (as a union of the two sets). Same for *.files. Would it be a good idea now to further
simplify things by using only one variable (pcclasses) and note in a comment that it also
contains paclasses?

Since they are always used together, I see no down side in combining them.

> tck enhancement should make use of feature to enhance an entire directory
> -------------------------------------------------------------------------
>
>                 Key: JDO-639
>                 URL: https://issues.apache.org/jira/browse/JDO-639
>             Project: JDO
>          Issue Type: Improvement
>          Components: tck2
>    Affects Versions: JDO 2 maintenance release 2
>            Reporter: Michael Bouschen
>            Assignee: Michelle Caisse
>         Attachments: enhance.txt, jdo-639.txt
>
>
> The current enhancer call as part of the runtck goal takes a list of .jdo files as an
argument (see property jdo.tck.jdometadata.files in project.properties and maven.xml). The
new enhancer invocation API allows to enhance all files of a given directory. We should investigate
to make use of this feature in order to get rid of listing all the .jdo in the property jdo.tck.jdometadata.files.
> There is a similar issue with the properties jdo.tck.pcclasses.sources and jdo.tck.pcclasses.files:
> - Property jdo.tck.pcclasses.sources is used when checking whether (re)enhancing is required.
Maybe a pattern 
>    org/apache/jdo/tck/api/**/*.java, org/apache/jdo/tck/pc/**/*.java
> can be used instead of listing all the persistent capable classes explicitly.
> - Property jdo.tck.pcclasses.files is used when copying the class file into the identitytype
specific subdirectories before running the enhancer. Maybe a similar pattern could replace
the list of class files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/jira/browse/JDO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769671#action_12769671
] 

Michelle Caisse commented on JDO-639:
-------------------------------------

The variables jdo.tck.paclasses.sources and jdo.tck.pcclasses.sources are always used together
(as a union of the two sets). Same for *.files. Would it be a good idea now to further simplify
things by using only one variable (pcclasses) and note in a comment that it also contains
paclasses?

> tck enhancement should make use of feature to enhance an entire directory
> -------------------------------------------------------------------------
>
>                 Key: JDO-639
>                 URL: https://issues.apache.org/jira/browse/JDO-639
>             Project: JDO
>          Issue Type: Improvement
>          Components: tck2
>    Affects Versions: JDO 2 maintenance release 2
>            Reporter: Michael Bouschen
>            Assignee: Michelle Caisse
>         Attachments: enhance.txt, jdo-639.txt
>
>
> The current enhancer call as part of the runtck goal takes a list of .jdo files as an
argument (see property jdo.tck.jdometadata.files in project.properties and maven.xml). The
new enhancer invocation API allows to enhance all files of a given directory. We should investigate
to make use of this feature in order to get rid of listing all the .jdo in the property jdo.tck.jdometadata.files.
> There is a similar issue with the properties jdo.tck.pcclasses.sources and jdo.tck.pcclasses.files:
> - Property jdo.tck.pcclasses.sources is used when checking whether (re)enhancing is required.
Maybe a pattern 
>    org/apache/jdo/tck/api/**/*.java, org/apache/jdo/tck/pc/**/*.java
> can be used instead of listing all the persistent capable classes explicitly.
> - Property jdo.tck.pcclasses.files is used when copying the class file into the identitytype
specific subdirectories before running the enhancer. Maybe a similar pattern could replace
the list of class files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.