Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java EE (J2EE) и Spring > @ManyToOne c бином из другого EAR

Автор: Maverick 12.3.2007, 17:59

Доброго дня... Уважаемые, существует два бина из разных EAR- приложений... Адрес в одном приложении... Код @Entity @Table(name="Address") public class AddressEJB implements Serializable {     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;           private String houseAddress;     private String apartmentAddress;          @ManyToOne     private     StreetEJB streetEJB; Банк в другом приложении... Код @Entity @Table(name="Bank") public class BankEJB implements Serializable {          @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;          private String codeBank;     private String fiscodeBank;     private String fullnameBank;     private String smallnameBank;          @ManyToOne     private AddressEJB addressEJB; В Банке существует связь с адресом Код @ManyToOne     private AddressEJB addressEJB;      Если бы оба бина сидели в одном EAR - проблем бы не было... а так на попытку продеплоится - выдает ошибку...  Код @OneToOne or @ManyToOne on bankEJB.BankEJB.addressEJB references an unknown entity: addressEJB.AddressEJB При компиляции проблем нет - я просто указал проект-jar Адреса как библиотеку Банков... Есть ли корректный способ решить эту проблему?? Добавлено @ 18:11    то есть основной вопрос - можно ли использовать эти самы связи между удаленными бинами... если нет - то как правильно организовывать ее через удаленные интерфейсы...??

Автор: Mikamj 12.3.2007, 22:37

EntityManager связан только одним persistence context. Набор объектов, которые могут управляться данным экземпляром EntityManager, определяется persistence unit'ом, который определяет набор всех классов, связанных или сгруппированных приложением (т.е. EAR-файлом), и которые должны отображаться на одну и ту же базу данных.

Автор: Maverick 13.3.2007, 09:08

То есть это невозможно? Так получается нельзя разнести бины по разным серверам? Тут, например, банки работают, а там, на другом сервере, адреса...? Не заманчиво.... А если придется потом остановить  что-нить для обновления или профилактики? Например, чтобы обновить банки - придется гасить все огромное приложение?? (Хотя ерунду говорю - если они так будут связаны, все равно остановятся)... Ну хорошо - связь прямую сделать невозможно?? Как же правильно поступить?? Вызвать удаленный интерфейс и ручками растыкать все данные в setter и getter? Где это более правильно сделать? В самом бине? или в его сессионном фасаде?

Автор: ecologist 13.3.2007, 10:06

Видимо придется делать такие бины не связанными - просто два разных бина могут общаться друг с другом, получая списки или отдельные объекты. И связи между ними на уровне сервера приложений уже не делать - только логическая связь внутри самих бинов. Что-то других мыслей нет пока.

Автор: Maverick 13.3.2007, 10:10

где это правильно намутить? в самом бине или его сессионном фасаде?

Автор: Maverick 13.3.2007, 11:59

Вопросы растут как ком снежный... В каком виде тогда представлять адрес в банке?? Просто в виде числового идентификатора-указателя на адрес в таблице адресов? Судя по всему EJB3 тоже не сильно распространен??

Автор: chief39 13.3.2007, 15:38

Если это два разных еара, которые могут функционировать на разных машинах и, посему, вроде бы как немного независимы логически - тогда лучше сделать связку на уровне фасадов. Вот только , если банк будет часто дёргаться и адреса подтягиваться - может нет смысла их по разным еаркам? Или адреса будут использоваться не только для банков? Типа "словарь данных"? Тогда через фасад - получение банком адреса унифицированым методом. Для скорости(если понадобится) - кэш адресов на стороне банков(в логике фасада) Добавлено @ 15:39  Цитата(Maverick @  13.3.2007,  11:59 ) Вопросы растут как ком снежный... В каком виде тогда представлять адрес в банке?? Просто в виде числового идентификатора-указателя на адрес в таблице адресов?  Таки да. Почему бы и нет? Опиши структуру данных и логикик. Почему банки с адресами в разных еарках должны очутиться?

Автор: Maverick 13.3.2007, 15:50

Дело в том, что адреса эти будут привязаны ко многим задачам - и отдел кадров (сотрудники), и правонарушители, и клиенты, и офисы, и регистрация авто, контрагенты, и контракты, поставки.... короче, туча задач - и везде одни и те же адреса... соответственно, пытаемся выделить такие важные задачи в отдельные EAR, чтобы при остановке одной задачи - остальные крутились...    Цитата(chief39 @  13.3.2007,  15:38 ) Тогда через фасад - получение банком адреса унифицированым методом. что такое унифицированный метод?? не хочу изобретать велосипед - все хожу по цепи кругом...  Структуры данных максимально простые пока - только бы понять как правильно сделать...  Вот есть Банк - идентификатор, наименование... это будет бин... к нему сессионный фасад с EntityManager... У этого фасада два интерфейса - локальный и удалённый (мутим все, до чего дотягиваемся)... Аналогично, есть Адрес - идентификатор, название улицы... с теми же фасадом и интерфейсом...  Как сделать так, чтобы Банк автоматом писал изменения в своём Адресе?? Вот и вся задача...  Я уже в третий раз пол-проекта переписываю... EJB1, EJB2, теперь вот EJB3...

Автор: chief39 13.3.2007, 17:59

Цитата(Maverick @  13.3.2007,  15:50 ) Дело в том, что адреса эти будут привязаны ко многим задачам - и отдел кадров (сотрудники), и правонарушители, и клиенты, и офисы, и регистрация авто, контрагенты, и контракты, поставки.... короче, туча задач - и везде одни и те же адреса... соответственно, пытаемся выделить такие важные задачи в отдельные EAR, чтобы при остановке одной задачи - остальные крутились...  Аха... таки "словарь данных" Цитата(Maverick @  13.3.2007,  15:50 ) что такое унифицированный метод?? не хочу изобретать велосипед - все хожу по цепи кругом...  То есть?  Это не термин - это я так выразился. Это означает, что метод будет возвращать Value Object по параметру с айди адреса. И этот метод будет использоваться как банками так и всеми остальными частями системы. Цитата(Maverick @  13.3.2007,  15:50 ) есть Адрес - идентификатор, название улицы... с теми же фасадом и интерфейсом...  То есть с тем же фасадом?  Сделай фасад Banks и фасад Addresses Когда вызываешь Banks.getBankByName("Bank of Taiwan")  - в этом методе фасада вытягивается банк из энтити, получается айди адреса, вызывается метод Adresses.getAddressById(45454), получаешь ValueObject адреса, перегоняешь из него данные в объект BankValueObject(туда же данные из бина банк). Вуаля - все данные по банку - в одном объекте - можно отдавать "на клиента".  BankValueObject можно кэшировать для скорости в фасаде

Автор: Maverick 15.3.2007, 10:36

А нельзя в качестве ValueObject использовать тот же самый Entity? Ведь какой смысл создавать такой же класс только без аннотации? Добавлено @ 10:38  Фасады, естественно, разные.. "те же" в смысле аналогичные...

Автор: chief39 15.3.2007, 15:06

Цитата(Maverick @  15.3.2007,  10:36 ) А нельзя в качестве ValueObject использовать тот же самый Entity? Ведь какой смысл создавать такой же класс только без аннотации? Честно говоря, до еджиби 3 ещё никак руки не дойдут - всё дела да дела... Если верно помню - то именно так и обстоят дела. И это одна из фич - "бин = трансфер обжект". Но это поищи у сана на сайте.

Автор: Maverick 15.3.2007, 15:07

Ага... значится, мысль правильная...

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)