Комментарии 8
Знакомая ситуация. В свое время писал велосипед использующий PropertyDescriptor'ы. Там рекурсивно обходились поля в hibernate объекте и заменялись HibernateProxy на реализацию.
Кстати, SerializationException съело кучу времени и нервов в свое время. Хорошо когда оно выскакивает с описанием, как в вашем случае. Но часто вместо описания было просто null и приходилось вручную лопатить объекты и искать, где забыл добавить конструктор без аргументов, где забыл унаследовать Serializable а где забыл сделать внутренний тип публичным.
result = (T) ((HibernateProxy) entity)
.getHibernateLazyInitializer()
.getImplementation();
Кстати, SerializationException съело кучу времени и нервов в свое время. Хорошо когда оно выскакивает с описанием, как в вашем случае. Но часто вместо описания было просто null и приходилось вручную лопатить объекты и искать, где забыл добавить конструктор без аргументов, где забыл унаследовать Serializable а где забыл сделать внутренний тип публичным.
+1
Незнал о существовании такого способа — спасибо, позновательно. Единственное что в «Способы интеграции» первые два все таки это один, разве что перекладываение автоматизировано с помощью dozer mappings. Ах да — еще dozer умеет перекладывать не только одноименные поля как вы описали — он достаточно гибок в конфигурировании.
0
Про Dozer я в курсе. Просто решил не тратить время на разъяснения, так как статья все-таки о другом.
Возможно первые два способа и являются по механике одним. Но с точки зрения затрат времени на реализацию, структуры и возможности конфигурации код получается очень разный. По этому я и решил их разделить.
Возможно первые два способа и являются по механике одним. Но с точки зрения затрат времени на реализацию, структуры и возможности конфигурации код получается очень разный. По этому я и решил их разделить.
0
Жалко, что это LightEntity — класс. Если бы оно было trait — можно было бы не ломать свою систему наследования.
0
Ну тут уж только сам Gilead ковырять, или искать аналоги, о которых впрочем я не слышал. В принципе Gilead опенсурсный, но не думаю что будет просто пропатчить его так как нужно. Если найдется решение, пишите.
0
На самом деле заменить один абстрактный класс на котлинский или скаловский trait никакого труда не составит — но как это будет работать с GWT — я не знаю. Если это client-side — никак работать не будет ( а это, видимо, клиентсайд), потому что GWT использует свой компилятор Java.
0
Gilead уже давно не поддерживается разработчиком, поэтому настоятельно рекомендую отнестись с опаской к его применению в проекте, особенно, если это новый проект и вы вольны в выборе технологий. Лично у меня унаследованный проект и мне не раз приходилось лазить в исходниках, и перекомпилировать части Gilead.
К тому же, список возможных вариантов далеко не полон. Я вскользь интересовался темой (т.к. в планах есть отказ от Gilead в проекте), и навскидку могу предложить еще два варианта передачи DTO: Calling REST from GWT и RequestFactory. Лично я пока смотрю в сторону RequestFactory, т.к. это встроенная в GWT технология, поэтому не требуется ничего лишнего. На практике пока не пробовал.
К тому же, список возможных вариантов далеко не полон. Я вскользь интересовался темой (т.к. в планах есть отказ от Gilead в проекте), и навскидку могу предложить еще два варианта передачи DTO: Calling REST from GWT и RequestFactory. Лично я пока смотрю в сторону RequestFactory, т.к. это встроенная в GWT технология, поэтому не требуется ничего лишнего. На практике пока не пробовал.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GWT + Hibernate + Dispatch