Недавно мы прошли через аналогичный опыт в компании, в которой я работаю. К сожалению, мы не смогли найти какого-либо определенного руководства для процесса. То, что мы нашли, было частичными руководствами здесь и там. Я не уверен, как другие справились с этой проблемой, и я с нетерпением жду возможности опубликовать здесь какие-либо другие решения. Однако я могу рассказать вам, как мы справились с этим, и надеюсь, что вы сможете извлечь уроки из нашего опыта.
С самого начала мы знали, что хотим иметь возможность контролировать, какую версию Spring (и, в нашем случае, Hibernate) мы будем использовать. Естественно, версии, встроенные в IDE NetBeans, немного устарели, и мы хотели иметь передовые возможности при разработке кода нашего сервера.
В итоге мы создали два отдельных проекта: один для нашего серверного кода (наши службы, DAO и доменные объекты) и один для нашего клиентского приложения. Затем мы собрали код сервера, скопировали jar и его зависимости в клиентский проект и перечислили эти jar как зависимости в клиентском коде. Мы создали модуль в нашем проекте NetBeans под названием SpringHibernate, в котором размещены эти файлы jar и от которого зависит почти каждый другой модуль.
Я бы порекомендовал создать задачу ant, которая будет удалять номера версий ваших jar-файлов перед их добавлением в проект NetBeans. Это позволяет беспрепятственно обновлять файлы jar в коде сервера, и клиентский код никогда не узнает разницу. (NetBeans может показаться довольно придирчивым, когда вы начинаете удалять и повторно добавлять банки.)
Первой важной задачей является создание класса Util, который может загружать ваш applicationContext.xml и возвращать bean-компоненты из контекста. Этот процесс описан здесь .
Одной из основных проблем, с которой мы столкнулись, было создание Sessions (или EntityManager в терминах JPA). Платформа NetBeans - это многопоточная среда, и EntityManager предназначены для работы только в одном потоке. Чтобы обойти это, мы пошли по маршруту Open Session In View *. Мы создали класс, который мог бы загрузить тот же EntityManager в любой поток, который его запрашивал. Затем мы создали клиентские прокси наших служб, которые загружали бы EntityManager в его поток перед вызовом фактической службы, управляемой Spring. Дополнительным бонусом создания прокси-служб клиентов было то, что их можно было найти с помощью Lookup.getDefault().lookup(Service.class) через аннотацию @ServiceProvider.
Затем вы должны создать собственный LifeCycleManager , который может завершить работу и закрыть ваши EntityManager и EntityManagerFactory при завершении работы приложения.
Надеюсь, это поможет!
* Я знаю, что Open Session in View был помечен как AntiPattern, но если вы понимаете проблемы, связанные с ним, вы можете смягчать эти проблемы (кэшируя объекты, которые вряд ли изменятся со временем делаю умные звонки из базы и т. д.). Кроме того, я помню, что во время нашего исследования мы нашли сообщение на форуме от Гэвина Кинга, в котором говорилось, что Open Session In View является рекомендуемым маршрутом для клиентских приложений. Конечно, я не могу найти пост сейчас, но он где-то там.