Использование GraniteDS с Java-клиентом

Question

Кто-нибудь использовал GraniteDS успешно с простым Java-клиентом и ленивой загрузкой (настоящий Java-клиент или приложение-сервер Java, вызывающее другой сервер)?

Нужна ли какая-либо специальная инициализация на стороне клиента? (документы ничего не говорят об этом, поэтому мы не нуждались в этом, просто взяли пример кода)

На основе документов (3.0.M2) мы создали резервный сервер Spring и клиент Java, который работает для простых POJO, но не работает когда необходимо возвращать загруженные HIBNNATE (как в версиях RemoteService, так и в Tide с теми же исключениями десериализации).

В настоящее время у нас нет файла конфигурации GraniteDS на стороне клиента, только этот код:

 
String baseURL = "http://localhost:8080/WebApp_Development_Client_Maven/"; 
URI uri = new URI(baseURL + "graniteamf/amf.txt"); 

Transport tr = new ApacheAsyncTransport(); 
tr.start(); 
AMFRemotingChannel ch = new AMFRemotingChannel(tr, "graniteamf", uri); 

RemoteService srv = new RemoteService(ch, "userService"); 
List users = (List)srv.newInvocation("listUsers").invoke().get().getData(); 

Де-сериализация исключение:

 
Caused by: java.lang.RuntimeException: The ActionScript3 class bound to limes.core.model.security.User (ie: [RemoteClass(alias="limes.core.model.security.User")]) implements flash.utils.IExternalizable but this Java class neither implements java.io.Externalizable nor is in the scope of a configured externalizer (please fix your granite-config.xml) 
    at org.granite.messaging.amf.io.AMF3Deserializer.readAMF3Object(AMF3Deserializer.java:500) 
    at org.granite.messaging.amf.io.AMF3Deserializer.readObject(AMF3Deserializer.java:130) 
    at org.granite.messaging.amf.io.AMF3Deserializer.readObject(AMF3Deserializer.java:92) 
    ... 36 more 

Контекст:

Мы имеют приложение клиент/сервер Java/Swing, которое изначально предназначено для использования внутри сети (использует Hibernate 3 как ORM). Он также работает через Интернет, но соединение с базой данных PostgreSQL очень часто ломается, что делает клиент ненадежным (случайное зависание из-за потерянного/сломанного соединения db). Это, кажется, невозможно решить правильно (простые меры, такие как ручное повторное подключение уже реализованы)

Нам нужно развернуть приложение через Интернет, и поскольку сложная логика уже реорганизована в классы обслуживания, мы хотели бы оставить графический интерфейс, в основном, не изменился и удалил классы обслуживания. Мы перемещаем слой persistence и классы обслуживания в Spring backend и хотели бы использовать GraniteDS, потому что прозрачная ленивая загрузка в основном используется в приложении, поэтому было бы очень сложно заменить ее использованием DTO и/или инициализаторами.

Я не нашел простые примеры Java-клиентов, только приложение JavaFX, которое так сильно связано с JavaFX, что кажется очень трудно преобразовать в простой Java-клиент (даже попробовать его немного проблематично в Linux с тех пор он не содержит конфигурацию Webstart).

Answer 1

Кажется, что в этой версии GraniteDS (3.0.0.M2) lazy-loading не работает с клиентом простой Java.

https://groups.google.com/forum/#!topic/graniteds/KDWNY31lG0I

В теории, она работает в среде JavaFX, но она была реализована таким образом, что простые Java-клиенты не могут использовать прозрачную отложенную загрузку.

Кроме того, GraniteDS не поддерживает ленивую загрузку на отдельные объекты, только на коллекциях, что делает ее непригодной для проектов, использующих такие отношения. Лично я считаю, что это вопиющее упущение, особенно потому, что они часто ссылаются на свою ленивую загрузку как на «полную».

К сожалению, документация ничего не говорит о ограничениях на ленивую загрузку, а также не позволяет провести различие между возможностями GraniteDS с JavaFX и простой Java.