Я пытаюсь нарисовать a DateMidnight
в LocalDate
, используя orika. Но независимо от того, что я пытаюсь получить, я получаю эту ошибку ma.glasnost.orika.MappingException: No concrete class mapping defined for source class org.joda.time.chrono.ISOChronology
. Но он только терпит неудачу на сервере jenkins (unix), а не локально (выигрывает).Орика картирование jodatime DateMidnight
Отображение из DateMidnight
в LocaleDate
настроен так:
public LocaleDate convert(DateMidnight source, Type<? extends LocaleDate> destinationType) {
if (source == null) { return null; }
return new LocaleDate(source);
}
Во всяком случае, я пытался добавив конкретные сопоставления между хронологией найденных в jodatime.
например
ISOChronology
->ISOChronology
ISOChronology
->Chronology
Chronology
->ISOChronology
Chronology
->Chronology
с использованием registerClassMap
, как показано быть низкая:
mapperFactory.registerClassMap(mapperFactory.classMap(ISOChronology.class, ISOChronology.class).byDefault().toClassMap());
ISOChronology
->ISOChronology
exception while creating object factory for org.joda.time.chrono.ISOChronology
дает мне.
Любая помощь будет принята с благодарностью
EDIT - решение и детали
Итак, я нашел решение после первой регистрации ObjectFactory
для Chronology
с помощью MapperFactory.registerObjectFactory
.
Код с ошибкой с исключением объясняет, как 280 не было допустимым значением для hoursInDay
при создании LocaleDateTime
. Теперь все картографы были созданы на карту от DateMidnight
до LocaleDate
, почему бы это попробовать инициализировать объект LocaleDateTIme
... Ниже Period
класса он пытается сопоставить (написанный с памяти)
public class Period {
public final LocaleDate from;
public final LocaleDate to;
public Period() {}//Rank: 0
public Period(LocaleDate from, LocaleDate to) {//Rank: 2000
this.from = from;
this.to = to;
}
public Period(LocaleDateTime from, LocaleDateTime to) {//Rank: 2000
this.from = from.toLocaleDate();
this.to = to.toLocaleDate();
}
}
mapper от XMLPeriod
до Period
field("fom", "from")
и field("to", "to")
.
Оказалось, что стратегия разрешения конструктора Орика основана на эвристике, пытающейся найти конструктор с наибольшим количеством аргументов, которые он может выполнить. Однако эвристика не учитывает, какие карты или преобразователи вы зарегистрировали, и просто смотрит на имена параметров.
Поскольку последние два конструктора имеют одинаковый ранг. Затем он игнорирует конструктор с использованием LocaleDate
и пытается использовать инициализацию LocaleDateTime
. И тогда не может жестоко, так как он не имеет ни малейшего понятия о упорядочении аргументов для LocaleDateTime
(и также не из-за ISOChonology
существо синглтон-как, но это было фиксировано)
Итак ... решение всех моих проблем. ..
//DONT change wtf name, orika-mappings will break.
public Period(LocaleDateTime from, LocaleDateTime wtf) {
this.from = from.toLocaleDate();
this.to = wtf.toLocaleDate();
}
Да, переименовав аргумент решил проблему ...
PS. Вероятно, это не лучшее решение этой проблемы. Но это решение. Если кто-нибудь знает, как это можно решить лучше, пожалуйста, дайте мне знать.
Как вы регистрации 'DateMidnight' ->' LocalDate' конвертер? Можете ли вы показать бобы и отображения? Код конвертера выглядит нормально, поэтому Орика не должна пытаться получить доступ к хронологии внутри него ... –
Я могу найти его. Только так мы можем потенциально помочь будущим пользователям. Однако мне удалось что-то понять. Классы 'Chronology' были частью сопоставления между' XMLPeriod' и 'Period'. 'XMLPeriod' использовал' DateMidnight', а 'Period' хотел' LocaleDate'. Тем не менее, он также принял 'LocaleDateTime' с теми же именами параметров и спецификой. Поскольку конструктор, принимающий 'LocaleDateTime', был процессом после constuctor с' LocaleDate', он использовал этот конструктор вместо этого и поэтому пропустил отображение из 'DateMidnight' в' LocaleDate' и попытался решить его с отражением, – atomman
Добавил подробное объяснение что, казалось, вызывало проблему. Но все же, если вы знаете о лучшем решении, я был бы очень доволен. Когда имена аргументов внезапно имеют это неявное связывание, ну, вещь, связанная с тем, что она заканчивается в обслуживании - черт с длинным отладочным сеансом. – atomman