Правильно заставили
Вся реализация - в классе. Класс + дескриптор - это, как бы, серверная часть.
Оба интерфейса - это скорее клиентская.
Поэтому всё должно быть реализовано в классе. Ну плюс файндер-методы, описанные в дескрипторе для энтити-бинов(Мне это дико не нравится, что методы из дескриптора генерятся, но ничего лучше сам придумать не смог бы )

Так, чт такое бин, дескрипторы и домашний удаленный инт-сы я разобрался, как работает тож. А может мне ктонть толково обьяснить что такое get и set методы и что такое эти файндер методы?

Я буду пока не

JavaBean - Это компонент, т.е. класс, который написан по определенным правилам.
Что бы класс стал JavaBean-ом он должен подчиняться этим правилам - Такова архитектура
JavaBeans.
Среди эти правил есть такое, что если класс имеет поле < тип ИМЯПОЛЯ > ( например String name; ), то чтобы изменить его значение,
должен существовать метод < setИМЯПОЛЯ(тип) > для установки значения этого поля и
метод < тип getИМЯПОЛЯ() > для получения значения этого поля.
например:


Таким правилам подчиняются все JavaBeans, что позволяет регламентированно их использовать. Например, добавлять новые компоненты на плитру граф редактора форм. Все компоненты Swing - это JavaBeans

Это сообщение отредактировал(а) MoonCat - 21.2.2006, 16:03

Когда у тебя есть энтити Бин - это фактически управлялка таблицей. Хотя, согласно спецификации и прочая и прочая - "это абстрактное представление данных.... и т.п."
Так вот. Твой служебный хоум интерфейс работает как бы с таблицей.
А когда с помощью create или какого-либо find ты находишь строку - то эту строку представляет свежезозданный remote интерфейс.
То есть ты десять раз вызовешь create - создастся десять записей и получишь десять ссылок на remote интерфейс.
Ещё есть обязательный метод findByPrimaryKey. Его не надо описывать. В дескрипторе лишь важно указать поле для primary key. Этот метод создастся автоматически.
Но тебе могут понадобиться методы, ищущие наборы строк или ищущие по хитрым критериям. Тогда ты описываешь этот метод в дескрипторе:


В хоуме:

Они все выбрасывают такой эксепшн. а название и список параметров должно совпасть с тем, что в дескрипторе у нас - во время деплоя это проверится.
ты получишь Collection. Проходишь итератором и преобразуешь к remote интерфейсам. Если ничего не вернёт - коллекция будет пуста.
Если возвращаемое значение укажешь не Сollection, a remote интерфейс - тогда ты уверен что поиск по имени уникален, если не найдёт ничего - бросит тебе файндер эксепшн.
От так и описываешь свои файндеры
надеюсь ты понимаешь, что раньше мы говорили о сессионных бинах и ентити, а вот эта информация - конкретно по энтити

Ради Бога простите что я такой тупой!

[q]А когда с помощью create или какого-либо find ты находишь строку -[/q]

тупик.

Насчет гет и сет все понятно но тут..

У компоненты есть 2 инт-са: удаленный и ломашний. Домашний отвечает за создание обьекта, посте create создается экземпляр и передаецца ссылка н аего удаленный инт-с эт понятно..А уже в удаленном есть методы работающие с базой данных. так что я в тупике насчет того креате ищет строку..в удаленном инт-се могут быть метода vasya_pupkin например, ведь на этапе креате нет связи еще с бином и о какой базе и строках идет речь?

зы. Ради бога не злитесь на меня..я работал и с ява и проги писал..но ежб сильно хитрожелтая весчь именно поэтому и хочу в ней разобрацца

Это хорошо, что разобраться. Я и сам,честно говоря, EJB считаю хитрокрасным. Но ведь не боги сиё намудрили


ЭЭЭ... неее.. почему нету связи ? Ты ведь криэйт откуда вызвал? Прааально... из хоума. А хоум откель взял? lookup'ом. То есть ты уже Свой Бин крепко держишь за одну оглоблю(которая хоум). А Бин давным давно(с момента деплоя) знает что он вот с этой табличкой должен работать. Тут его зовёшь криэйтом. Он обращается к базе, создаёт строку, создаёт remote интерфейс для этой строки и отдаёт его тебе на клиенте. Вот ты и дёргаешь уже конкретную строку ремоутом. Последовательность действий тебе не столь важна - все эти изменения бог знает когда в базу занесутся. А точнее - контейнер. Зачастую именно он транзакциями управляет, хотя потом про bmp почитаешь(не те что картинки, а те что bean managed persistency). Тут такой нюанс - криэйт не означает что СОЗДАЁТСЯ ссылка на ремоут-приводимый объект, означает то, что СТРОКА В БАЗЕ СОЗДАЁТСЯ. Ибо если тебе не надо создавать строку, а лишь получить имеющуюся и поработать с ней - вызываешь файндер какой-нить. Он ВЫТЯГИВАЕТ СТРОКУ(не создаёт!) и СОЗДАЁТ РЕМОУТ ИНТЕРФЕЙС(не совсем дотошное определение, но так яснее). То есть create тут означает новую строку а не создание ремоута. Ремоут тебе создастся в любом случае. Что при криэйте, что при файнде.
Чтоб легче было осмыслить, представь себе таким макаром для локального используемого класса:
- класс бина - это класс бина, который имлементит оба интерфейса (в EJB не имплементим - связь между ними и её валидация происходит динамически)
- хоум - это набор статик методов, которые управляют созданием или поиском существующих объектов данного класса.
- ремоут - это набор не статик методов для работы с конкретным объектом, созданным при помощи статика
Это всё аналогия, просто чтоб понять как выглядит лес, ибо деревья его и вправду частенько заслоняют.

тэксс...при вызове креате в зависимости от типа компонента или создаецца новая строка или вытягиваецца старая..А компоненты бывают BMP и CMP это я знаю в первых девелоперу надо самому писать все статик и нестатик методы. Во втором контейнер сам выполняет все обслуживание а девелоперу надо тока написать нестатик бизнес методы. Раз уж так то давайте углубимся . Значит как я себе представлял всю эту хрень:

1)Из жсп страницы или клиента, который знает интерфейс компонента(без реализаций)методом lookup или еще как то определяецца поиск бина по жнди имени, потом с ним устанавливаецца соединение, затем по соединению получаецца хоум интерфейс и уж потом получаецца ссылка на ремоут интерфейс методом креате и УЖ ПОТООМ вызываюцца конкретные методы через которые осущ. работа с бд.



Так, что за строка? Это строка энтити бина, который в эту строку и сохраняецца если сервер упадет(на то он и энтити), или это результат конкретного запроса к бд(непохоже)?
Создает ремоут интерфейс для этой строки это ваще круто! То есть эта строка становицца как бы обьектом и этому обьекту копируется ремоут интерфейс? И ссылка на него даецца клиенту. А БД это на случай краха.
В общем случае работа с бд по запросам там и тд происходит только из биснес методов. Я так понял. Хотя есть сомнения. И создаецца ли в этом случае строка для сессион компонент?
Спасибо.

Результат запроса ты получишь файндом А криэйтом - это будет инсерт(ну и данные инсерта-то у тебя остаются - тысызыть, селект свежевставленного).
А файндером ты можешь получить то, что в базе до тебя было - то есть банальный селект, описанный на ejb-ql в дескрипторе.


Выборки происходят только через файндеры, а файндеры - это методы ХОУМА. Их сигнатура - в хоум интерфейсе, а тело создаётся автоматически на основе того, что в дескрипторе напишешь. Файндер - суть СЕЛЕКТ. Селект имеет смысл для таблицы, а не для записи. Соответственно, Из ХОУМА ты работаешь файндерами для выборки строк(ремоутов), или криэйтом для создания строки(ремоута).
Таким образом, если быть предельно честным, то работа с БД происходит не только с помощью бизнес-методов но и хоума
Для сессион бинов строки не создаются(где и зачем им создаваться?)
Сессион бин без состояния вообще сродни джсп страничке - ему сказали что сделать - он сделал и "отцепитесь от меня, не видел я никаких ваших данных".
Тут уж действительно хоум - лишь хоум, а все бизнес методы - в ремоуте.
Так сказать, хоум - это фабрика ремоутов. То есть та аналогия, что я приводил

Ладно, теперь давайте конкретизуем это все. Можете Вы мне привести человеческий код выборки строки из бд через бин. То есть код жсп страницы-клиента. А то я загрузился. Ща попробую разргузицца. Спсибо.

Это разные вещи
код выборки будет в дескрипторе бина. он будет работать на благо какого-нить файндера. Который, в свою очередь, можно из жсп вызвать. А может и не жсп, а из толстого клиента или другого бина.
Код выборки я выше привёл
Он в xml. Между тегами <ejb-ql> и </ejb-ql>

Там рядом и метод, для которого он старается в интерфейсе ХОУМ.
После lookup'а home и приведения к своему интерфейсу хоум, у него можно дёргать этот метод - он вернёт(если такое есть в базе - иначе FinderException выбросит) ссылку на ремоут, которую к твоему ремоут надо преобразовать

Фсё! Наконец до всего допёр и со всем разобрался! структура ежб работает! осталось тока дрова ждбц. Пробовал отписацца мускулистам, ни слова, а на форумах все хитрожелтое, подскажите если не трудно: mysql odbc-jdbc дрова это джар файл или через виндовозную консоль? как их юзать? Заранее спасибо..

Товарищи, проблема соединения кацца решена, но мот ктонть обьяснит мне что это такое?

------------------------------------------------------
HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

org.apache.jasper.JasperException: null object name
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:370)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)

root cause

java.lang.IllegalArgumentException: null object name
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:494)
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:638)
org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805)
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
sun.rmi.transport.Transport$1.run(Transport.java:153)
java.security.AccessController.doPrivileged(Native Method)
sun.rmi.transport.Transport.serviceCall(Transport.java:149)
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
java.lang.Thread.run(Thread.java:595)
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:119)
org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
org.jboss.invocation.MarshallingInvokerInterceptor.invoke(MarshallingInvokerInterceptor.java:37)
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:169)
org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
$Proxy64.create(Unknown Source)
org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:70)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)

note The full stack trace of the root cause is available in the Apache Tomcat/5.5 logs.
Apache Tomcat/5.5
----------------------------------------------------------------------------------
Заранее спасибо.