Details
Description
This was discussed in the KTI meeting on June 3, 2009. See notes here:
https://test.kuali.org/confluence/x/ngCcCg
Since we are targeting 1.1 for compatibility, if we want to make an API change we should be doing this for the 1.1 release.
Mentioned in the KTI was that this involves more than just the service API as these sorts of things are referenced elsewhere throughout the KNS and other modules.
So, what need to be done here is some analysis on the impact of such a change and then a formal enhancement request written up that can be presented to the KTi for review.
In essence, this work will probably be to eliminate references to java.sql.Date and java.sql.Timestamp everywhere in the code (I can't, off the top of my head imagine why they would be needed). We need to verify that OJB/JPA can handle fields that are java.util.Date being mapped to the database.
Attachments
Issue Links
- discovered
-
KULRICE-6033 Document proper use of joda-time library in rice apis and with remote services
-
- Open
-
-
KULRICE-5396 Convert InactivatableFromTo to use joda-time
-
- Closed
-
- is related to
-
KULRICE-5421 ResultEvents in KRMS are trying to format DateTimes with SimpleDateFormat
-
- Closed
-
- relates to
-
KRRM-60 Modularization - Complete the API module of Rice
-
- Resolved
-
I think it's fine to continue to use these on the BO's because I don't think ojb does a great job of handling the non-sql types (without the use of "converters").
One thing we do have to consider here is our api-layer model objects. We should look into using DateTime in JODA time instead and create an appropriate XmlAdapter to convert it for JAXB. There are some other places where we are using java.util.Calendar but that presents problems with the .equals method. See Jason's explanation below:
An example of this can be found in CriteriaDateTimeValue and is specifically implemented by our EqualsAndHashCodeUtils utility class.