Ну, где-то в этой огромной трассировке стека есть фрагмент кода, ищущий класс org.joda.time.LocalDate
"по имени", и JVM не может его найти.
Единственный способ найти проблемуэто отладка - я бы начал с GenericConversionService.getRequiredTypeInfo()
и поискал в стеке.
Но, что касается класса модели, который вы перечислили ...
И @CreatedDate
, и @LastModifiedDate
используют (я предполагаю, что в Java 8) LocalDateTime
, который может поддерживаться Spring Data Auditing , но поскольку LocalDateTime
не хватает информации уникальности (т. е. о часовом поясе)может быть какой-то (Spring Framework) код, пытающийся преобразовать LocalDateTime
в JodaTime.
Для аудита следует использовать уникальное во всем мире значение.
Пример использования вашей модели и логика, которую я предоставил для аналогичной проблемы ... Если пользователь в Индии ( Стандартное время Индии, GMT + 5: 30 ) создает экземпляр Workflow
в 9 часовутром другой пользователь из Великобритании ( Лондон, GMT + 0 ) также создает Workflow
инстВ 9 часов утра эти два экземпляра будут разделены на 5 с половиной часов, но перечислены, например, для третьего пользователя приложением, созданным одновременно, что не соответствует действительности.
Итак,Я бы попробовал использовать что-то другое вместо LocalDateTime
, может быть проверить этот подход .
ОБНОВЛЕНИЕ
Проверка исходного кода Spring Framework полностью поддерживаемые типы дат: , но для LocalDateTime
используется преобразователь чтения / записи .