[ http://issues.apache.org/jira/browse/GRFT-72?page=comments#action_12357503 ]
Christophe Lombart commented on GRFT-72: ---------------------------------------- I don't see a bug here. The unit tests work fine. Futhermore, if I apply your patch, one unit test fails. Following the JDK doc, a Date can be converted into a long which represents the numbers of milliseconds since the standard base time known as "the epoch", namely January 1, 1970, 00:00:00. Searching on Date and Calendar is not very friendly with lucene, that's why calendar & date are converted into long values. > Bug in > org.apache.portals.graffito.jcr.persistence.atomictypeconverter.impl.UtilDateTypeConverterImpl > ----------------------------------------------------------------------------------------------------- > > Key: GRFT-72 > URL: http://issues.apache.org/jira/browse/GRFT-72 > Project: Graffito > Type: Bug > Components: JCR-Mapping > Reporter: Martin Koci > Assignee: Christophe Lombart > Attachments: UtilDateTypeConverterImpl.patch > > In this converter following line is used: > return this.getValueFactory().createValue(((java.util.Date) > propValue).getTime()); > but propValue must be converted to java.util.Calendar, not into long! > ValueFactory than converts to LongValue not DateValue as expected. > Following code works OK: > final long timeInMilis = ((java.util.Date) propValue).getTime(); > final Calendar calendar = Calendar.getInstance(); > calendar.setTimeInMillis(timeInMilis); > return this.getValueFactory().createValue( calendar ); > but I dont know better Date-> Calendar conversion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
