Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
В настоящий момент спецификация JavaBeans (Версия 1.0) не содержит ни соглашений, описывающих иерархию или логическую структуру JavaBeans, ни соглашений для тех JavaBeans к рандеву с, или получите произвольные службы или средства от, среда выполнения, в пределах которой инстанцировали JavaBean.
Это является требуемым, чтобы и обеспечить логическое, проходимое, иерархию JavaBeans, и далее обеспечить общий механизм, посредством чего объект, инстанцирующий произвольного JavaBean, может предложить то множество JavaBean служб, или вставить себя между базовой системной службой и JavaBean стандартным способом.
В других компонентных моделях там существует понятие отношения между Компонентом и его средой, или Контейнером, в чем недавно инстанцированному Компоненту предоставляют ссылку на ее Контекст Контейнера или Встраивания.
Контейнер, или Контекст Встраивания не только устанавливает иерархию или логическую структуру, но и также действия как сервис провайдер, которого могут опросить Компоненты, чтобы определить, и впоследствии использовать, услуги, предоставленные их Контекстом.
Это предложение определяет такой протокол, который поддерживает расширяемые механизмы что:
hierarchal структура и общие средства BeanContext предусматриваются следующим образом:
public interface java.beans.beancontext.BeanContext extends java.beans.beancontext.BeanContextChild, java.util.Collection, java.beans.DesignMode, java.beans.Visibility { Object instantiateChild(String beanName) throws IOException, ClassNotFoundException; public InputStream getResourceAsStream(String name, BeanContextChild requestor ); public java.net.URL getResource(String name, BeanContextChild requestor ); void addBeanContextMembershipListener( BeanContextMembershipListener bcml ); void removeBeanContextMembershipListener{ BeanContextMembershipListener bcml ); public static final Object globalHierarchyLock; }
Уведомления об изменениях в членстве BeanContext моделируются следующим образом:
public interface BeanContextMembershipListener extends java.util.Listener { void childrenAdded(BeanContextMembershipEvent bcme); void childrenRemoved(BeanContextMembershipEvent bcme); }
Базовый класс всего BeanContext связанные События определяется:
public abstract class BeanContextEvent extends java.util.EventObject { public BeanContext getBeanContext(); public synchronized void setPropagatedFrom(BeanContext bc); public synchronized BeanContext getPropagatedFrom(); public synchronized boolean isPropagated() }
BeanContextMembershipEvent определяется как:
public class BeanContextMembershipEvent extends BeanContextEvent { public BeanContextMembershipEvent(BeanContext bc, Object[] deltas); public BeanContextMembershipEvent(BeanContext bc, Collection deltas); public int size(); public boolean contains(Object child); public Object[] toArray(); public Iterator iterator(); }
Одна из ролей BeanContext должна представить понятие иерархического вложения или структуру экземпляров BeanContext и JavaBean. Чтобы смоделировать эту структуру, BeanContext должен представить API, который определяет отношения в структуре или иерархии.
BeanContext представляет свою сверхструктуру посредством реализации java.beans.beancontext. Интерфейс BeanContextChild (как описано позже). Этот интерфейс позволяет открытие и манипулирование вложением BeanContext BeanContext, и таким образом представляет средство, чтобы создать иерархию BeanContexts.
BeanContext представляет свою подструктуру через многие интерфейсные методы, смоделированные java.util. Семантика интерфейса набора
BeanContexts обязаны реализовывать весь обязательный API Набора, со следующей определенной семантикой для добавляют () и удаляют ():.
Добавление () метод может быть вызван, чтобы вложить новый Объект, BeanContextChild, или BeanContext в пределах целевого BeanContext. Совместимое добавляет (), реализация обязана придерживаться следующей семантики:
Делая, таким образом, BeanContext может контролировать свой дочерний элемент и может обнаружить, когда такие дочерние элементы удаляются 3-ьей стороной (обычно другой BeanContext) вызывающий setBeanContext (). BeanContext может наложить вето на такое изменение 3-ьей стороной, если это решает, что дочерний элемент не находится в состоянии, чтобы отбыть из членства тогда.
Удаление () метод может быть вызван, чтобы удалить существующий дочерний элемент Джейвэбина или BeanContext изнутри целевого BeanContext. Совместимое удаляет (), реализация обязана придерживаться следующей семантики:
Впоследствии, если targetChild реализует java.beans.beancontext. Интерфейс BeanContextChild (или BeanContextProxy, см. позже для deatils), BeanContext должен вызвать setBeanContext () с null1 значением BeanContext, чтобы уведомить, что дочерний элемент, что это больше не вкладывается в пределах BeanContext.
Если определенный BeanContextChild находится в состоянии, где он не в состоянии быть невложенным от его вложения BeanContext, он может бросить PropertyVetoException, по получении этого, BeanContext должен отменить удалить работу для этого экземпляра и бросить IllegalStateException. Чтобы избежать бесконечной рекурсии, дочерним элементам не разрешают неоднократно наложить вето последующий, удаляют уведомления. Практически, дочерний элемент должен попытаться разрешить условие (если временный), который устраняет, это - удаление от, это - текущее вложение BeanContext.
Отметьте, что время жизни любого дочернего элемента вложения BeanContext, по крайней мере, для продолжительности включения того дочернего элемента в пределах данного BeanContext. Для простых JavaBeans, которые не знают об их включении в пределах BeanContext, это обычно подразумевает, что JavaBean должен существовать для, по крайней мере, времени жизни вложения BeanContext.
BeanContext не обязаны реализовывать любого addAll (), removeAll (), retainAll () или четкий () дополнительные методы, определенные java.util. API набора, однако если они, они должны реализовать определенную семантику на объект, поскольку оба добавляют () и удаляют () выше. В случаях отказа эти методы должны отменить любые частично примененные изменения, чтобы возвратить BeanContext состоянию, в котором это было до вызываемой работы составного объекта сбоя, никакой BeanContextEvents не должен быть уволен в случай отказа, как является непротиворечивым с определением, добавляют () и удаляют () выше.
BeanContextMembershipListeners может быть добавлен и удален через вызовы addBeanContextMembershipListener () и removeBeanContextMembershipListener ().
toArray (), метод должен возвратить копию текущего набора экземпляров JavaBean или BeanContext, вложенных в пределах целевого BeanContext, и iterator (), метод должен предоставить java.util. Iterator возражают по тому же самому набору дочерних элементов.
Содержание () метод должен возвратить true, если определенный объект будет в настоящий момент дочерним элементом BeanContext.
Размер () метод возвращает текущее число вложенных дочерних элементов.
isEmpty () метод возвращает true, если у BeanContext нет никаких дочерних элементов.
Отметьте, что все методы Collection, все требуют надлежащей синхронизации друг между другом данной реализацией, чтобы функционировать правильно в многопоточной среде, то есть, чтобы гарантировать, что любые изменения к членству набора JavaBeans, вложенного в пределах данного BeanContext, применяются атомарно. Все реализации обязаны, синхронизировал их реализации этих методов с BeanContext.globalHierarchyLock.
В некоторых ситуациях добавьте () и удалите () (или разновидность этого), операции могут произойти вложенные, который является многократными возникновениями, может появиться на стеке вызывающего потока одновременно, например: когда BeanContextChild, A, добавляется (или удаляется), это - setBeanContext (), метод также добавляет (или удаляет), другой BeanContextChild, B. Определенная реализация BeanContext может хотеть увольнять любые два BeanContextMembershipListener, которые уведомления, один для каждого добавляют ()/, удаляют () работу B тогда (в этом порядке, так как B успешно добавляется прежде A), или объединяют их в единственное уведомление, содержащее и A, и Б. Ноута, который должен A быть неспособным быть добавленным или удаленным по любой причине, которую это не должно выполнять, или отмена, любой добавляет или удаляет операции на B как побочный эффект до броска PropertyVetoException, чтобы указать на это условие, то есть, это должно избежать или отменить любые изменения членства побочного эффекта до отклонения любых изменений к его собственному членскому статусу.
instantiateChild () метод является методом удобства, который может быть вызван, чтобы инстанцировать нового экземпляра JavaBean как дочернего элемента целевого BeanContext. Реализация JavaBean получается из значения beanName фактического параметра, и определяется java.beans. Beans.instantiate () метод.
Как правило, это должно быть реализовано, вызывая соответствующий java.beans. Beans.instantiate () метод, используя ClassLoder целевого BeanContext. Однако определенная реализация BeanContext может вставить побочные эффекты на инстанцировать работе в их реализации этого метода.
BeanContextEvent является абстрактным корневым классом EventObject для всех Событий, имеющих отношение к изменениям в состоянии определенной семантики BeanContext. Этот абстрактный корневой класс определяет BeanContext, который является источником уведомления, и также представляет механизм, чтобы позволить распространение подклассов BeanContextEvent через иерархию BeanContexts. setPropagatedFrom () и getPropagatedFrom () методы позволяют BeanContext идентифицировать себя как источник распространенного События к BeanContext, к которому это впоследствии распространяет Событие к. Это - общий механизм распространения и должно использоваться с заботой, поскольку у нее есть существенные импликации производительности когда распространено через большие иерархии.
BeanContextMembershipEvent описывает изменения, которые происходят в членстве определенного экземпляра BeanContext. Это событие инкапсулирует список дочерних элементов, или добавленных к, или удаленный из, членство определенного экземпляра BeanContext, то есть дельта в наборе членства.
Всякий раз, когда успешное добавляет (), удаляет (), addAll (), retainAll (), removeAll (), или четкий () вызывается на определенный экземпляр BeanContext, BeanContextMembershipEvent увольняется, описывая дочерние элементы, произведенные работой.
BeanContext определяет два метода; getResourceAsStream () и getResource (), которые походят на те методы, найденные на java.lang. ClassLoder. Экземпляры BeanContextChild, вложенные в пределах BeanContext, должны вызвать методы на свое вложение BeanContext в предпочтении тем на ClassLoder, чтобы позволить реализации BeanContext увеличивать семантику, вставляя поведение между дочерним элементом и базовой семантикой ClassLoder.
Услуги службы BeanContext предоставляются следующим образом:
public interface BeanContextServices extends BeanContext,BeanContextServicesListener { boolean addService(Class serviceClass, BeanContextServiceProvider service); boolean revokeService(Class serviceClass, BeanContextServiceProvider bcsp, boolean revokeNow ); boolean hasService(Class serviceClass); Object getService(BeanContextChild bcc, Object requestor. Class serviceClass, Object serviceSelector, BeanContextServicesRevokedListener sl ) throws TooManyListenersException; void releaseService(BeanContextChild bcc, Object requestor, Object service); Iterator getCurrentServiceClasses(); public Iterator getCurrentServiceSelectors(Class sc); addBeanContextServicesListener( BeanContextServicesListener bcsl ); removeBeanContextServicesListener( BeanContextServicesListener bcsl ); }
Интерфейс BeanContextServiceProvider определяется следующим образом:
public interface BeanContextServiceProvider {
Object getService(BeanContext bc,
Object requestor,
Class serviceCls,
Object serviceSelector);
void releaseService(BeanContext bc,
Object requestor,
Object service);
Iterator getCurrentServiceSelectors(BeanContext bc,
Class serviceCls);
}
The BeanContextServiceRevokedListener is defined as follows:
public interface BeanContextServiceRevokedListener
extends java.util.EventListener {
void serviceRevoked(
BeanContextServiceRevokedEvent bcsre
);
}
BeanContextServicesListener определяется следующим образом:
public interface BeanContextServicesListener extends BeanContextServiceRevokedListener { void serviceAvailable( BeanContextServiceAvailableEvent bcsae ); }
BeanContextServiceAvailableEvent определяется следующим образом:
public class BeanContextServiceAvailableEvent extends BeanContextEvent { public BeanContextServiceAvailableEvent( BeanContextServices bcs, Class sc ); BeanContextServices getSourceAsBeanContextServices(); public Class getServiceClass(); public boolean isServiceClass(Class serviceClass); public Iterator getCurrentServiceSelectors(); }
BeanContextServiceRevokedEvent определяется следующим образом:
public class BeanContextServiceRevokedEvent extends BeanContextEvent { public BeanContextServiceRevokedEvent( BeanContextServices bcs, Class sc, boolean invalidNow ); public BeanContextServices getSourceAsBeanContextServices(); public Class getServiceClass(); public boolean isServiceClass(Class service); public boolean isCurrentServiceInvalidNow(); }
BeanContextServiceProviderBeanInfo определяется следующим образом:
public interface BeanContextServicesProviderBeanInfo extends java.beans.BeanInfo { java.beans.BeanInfo[] getServicesBeanInfo(); }
Кроме обеспечения структурированной иерархии, другая главная роль BeanContext должна обеспечить стандартный механизм для компонента JavaBean, чтобы получить зависящие от контекста средства или службы от его среды.
Служба, представленная объектом Класса, обычно является ссылкой или на интерфейс, или на реализацию, которая не является публично instantiable. Этот Класс определяет интерфейсный протокол или контракт между BeanContextServiceProvider, фабрикой службы, и произвольным объектом, связанным с BeanContextChild, который в настоящий момент вкладывается в пределах BeanContext, в котором регистрируется служба. Обычно такие протоколы инкапсулируют некоторое зависящее от контекста или чувствительное поведение, которое изолирует реализацию BeanContextChild от таких зависимостей, таким образом приводящих к более простым реализациям, большей функциональной совместимости и мобильности.
BeanContextServiceProvider, "фабрика" для одной или более служб. Это регистрирует себя в определенном BeanContextServices через, это - adService () метод, если служба уже не регистрируется в BeanContextServices, BeanContextServices связывает службу, определенную с BeanContextServiceProvider, и увольняет BeanContextServiceAvailableEvent через serviceAvailable () метод к тем BeanContextServicesListeners, в настоящий момент зарегистрированным, то возвращает true, иначе ложь, указывающая, что служба уже регистрируется для того BeanContextServices.
После того, как зарегистрированный, и пока не отменяющийся, служба доступна через BeanContextServices getService () метод.
hasService () метод может использоваться, чтобы протестировать присутствие определенной службы, и getCurrentServices (), метод возвращает iterator по в настоящий момент доступным службам для того BeanContextServices.
BeanContextChild или любой произвольный объект, связанный с BeanContextChild, могут получить ссылку на в настоящий момент зарегистрированную службу от ее вложения BeanContextServices через вызов getService () метод. getService () метод определяет; BeanContextChild, связанный проситель, Класс службы, которую требуют, служба, зависимый параметр (известный как сервис Селектор), и BeanContextServicesRevokedListener имел обыкновение впоследствии уведомлять просителя, что класс службы был отменен BeanContextServiceProvider. Слушатель регистрируется автоматически с одноадресным источником события на просителя и класс службы и автоматически незарегистрирован, когда проситель оставляет все ссылки данного класса службы, или как побочный эффект службы, " насильственно отменяемой” обеспечивающим BeanContextServiceProvider.
BeanContextServices передает этот getService () вызов на связанный BeanContextServiceProvider (если любой), чтобы быть удовлетворенным через вызов его getService () метод. BeanContextServiceProvider передают BeanContext, Класс службы если, служба зависимый параметр службы (Селектор Службы) и ссылка на объект, запрашивающий службу.
Ссылка на BeanContext предназначается, чтобы позволить BeanContextServiceProvider отличить запросы на обслуживание от многократных источников. BeanContextServiceProvider только разрешают сохранить слабую ссылку на любой BeanContext, столь полученный.
Параметр Селектора Службы является службой зависимое значение, используемое просителем службы для определенной службы, чтобы параметризовать службу, которая будет обеспечена для этого BeanContextServiceProvider. Некоторые примеры его использования; параметр конструктору для класса реализации службы; значение для свойства определенной службы, или как ключ в карту существующих реализаций.
Ссылка на просителя предназначается, чтобы разрешить BeanContextServiceProvider опрашивать состояние просителя, чтобы выполнить любую настройку или параметризацию службы, поэтому эта ссылка должна быть обработана как неизменная BeanContextServicesProvider. Дополнительно BeanContextServiceProvider разрешают сохранить только слабую и неизменную ссылку и на просителя и на BeanContextChild после возврата из getService () вызов.
BeanContextServiceProvider может удовлетворить запрос, возвращая ссылку на экземпляр Класса требуемой службы (так, что, возвращенная ссылка должна привести к выражению: <serviceRefence> instanceof <serviceClass> быть истиной), возвратите нуль, или выдайте исключение непроверенное.
В случае, когда вложенный BeanContextServices требуют на определенную службу, что у этого нет никакого BeanContextServiceProvider для, тогда BeanContextServices может делегировать службу, которую требуют к ее собственному вложению BeanContextServices, чтобы быть удовлетворенным. Таким образом запросы делегации могут распространить от листа BeanContextServices к корневому BeanContextServices.
BeanContextChild может запросить определенный BeanContextServices для списка в настоящий момент доступных Классов Службы (через getCurrentServiceClasses () метод) и любые связанные Селекторы Службы, если определенный Класс службы реализует конечный список значений apriori для Класса Службы через его вложение BeanContextServices.getCurrentServiceSelectors () метод, который поочередно получает в настоящий момент доступные Селекторы Службы (если любой) через BeanContextServiceProvider.getCurrentServiceSelectors () метод.
Если рассматриваемая служба не реализует конечное множество значений apriori для набора допустимых Селекторов Службы, то это должно возвратить нуль.
Ссылка, полученная BeanContextChild через getService (), допустима, пока ссылка не выпускается BeanContextChild через вызов его вложения BeanContextServices releaseService () метод, кроме в случае, где BeanContextServices увольняет BeanContextServiceRevokedEvent и что isCurrentServiceInvalidNow События () метод возвращает true, в этом случае BeanContextServices и/или BeanContextServiceProvider, который предоставлял услугу, решили, что текущие ссылки службы были сразу лишены законной силы, или “насильственно отменял” (это обычно происходит в следующей ситуации).
Когда экземпляры BeanContextChild будут удалены из определенного экземпляра BeanContextServices, они должны отбросить все ссылки на любые службы, которые они получили изо что BeanContextServices соответствующими вызовами releaseService (). Если невложение, BeanContextChild является также экземпляром BeanContextServices, и если какая-либо из этих ссылок службы была представлена невложению собственные элементы BeanContextServices в результате делегированного getService () запрос как определено выше, BeanContextServiecs, должно уволить BeanContextServiceRevokedEvent, чтобы уведомить его вложенные дочерние элементы, что служба (ы) “насильственно отменяется”. Это непосредственное аннулирование текущих ссылок на делегированные службы при невложении должно гарантировать, что службы, которые зависят от структуры иерархии, не используются просителями после того, как их расположение в структуре изменилось.
Экземпляры BeanContextChild, получающие “forcable аннулирование” Класса Службы, не должны вызывать releaseService () для любых ссылок, которые это может содержать того типа, с тех пор в этом случае, BeanContextServiceProvider или BeanContextServices, который обеспечил ссылку службы на то, что BeanContextChild уже лишил законной силы все ссылки на ту службу от их имени.
BeanContextServiceProvider может отменить Класс Службы в любое время после того, как он зарегистрировал это в BeanContextServices, вызывая его revokeService () метод. Как только BeanContextServices уволил BeanContextServiceRevokedEvent, уведомляющий в настоящий момент зарегистрированный BeanContextServiceRevokedListeners и BeanContextServicesListeners, что служба теперь недоступна, это больше не должно удовлетворять новые запросы на обслуживание на отменяемую службу до (если вообще), что Класс Службы повторно регистрируется. Ссылки, полученные просителями BeanContextChild к службе до того, что это было отменяемым, остаются допустимыми, и поэтому служба должна остаться допустимой, чтобы удовлетворить те существующие ссылки, пока все ссылки на ту службу не будут выпущены, если при исключительных обстоятельствах BeanContextServiceProvider, или BeanContextServices, отменяя службу, не хочет сразу завершить службу ко всем текущим ссылкам. Это непосредственное аннулирование достигается, вызывая BeanContextServices.revokeService () метод с фактическим значением параметра revokeNow == истина. Последующий за непосредственным аннулированием текущих ссылок службы реализация службы может бросить службу определенное исключение непроверенное в ответ на любые попытки продолжать использовать отменяемую службу просителями службы, которые ошибочно сохранили ссылки на службу, игнорируя более раннее непосредственное уведомление об аннулировании.
Отметьте, что, чтобы функционировать правильно (делегируя запросы на обслуживание) в многопоточной среде, реализации BeanContextServices обязаны синхронизировать свои реализации; addService (), hasService (), getCurrentServiceClasses (), getCurrentServiceSelectors (), getService (), releaseService () и revokeService () с BeanContext.globalHierarhyLock.
BeanContextServicesProvider может представить BeanInfo для Классов Службы, для которых это обеспечивает реализации, обеспечивая класс BeanInfo, который реализует BeanContextServicesProviderBeanInfo. Таким образом представляя массив BeanInfo, один для каждого Класса Службы поддерживается. Инструменты разработчика могут, например, использовать этот infomation, чтобы предоставить разработчикам приложений палитру Классов Servlice для включения в приложение.
Так как одна из основных ролей BeanContext должна представить логическую вложенную структуру компонента JavaBean и иерархий экземпляра BeanContext, естественно ожидать, что во многих сценариях, что иерархия должна быть персистентной, то есть что BeanContext должен участвовать в механизмах персистентности, в частности любой java.io. Сериализуемый или java.io. Externalizable (Если последний BeanContext ответственен за действие как контейнер персистентности для подграфа дочерних элементов, кодируя и декодируя информацию о классе, и поддерживая эквивалентность подграфа после десериализации, в основном функция (и), предусматривают сериализацию ObjectOutputStream и ObjectInputStream).
В определенном BeanContexts сохраню и восстановлю их текущие дочерние элементы, которые реализуют соответствующие интерфейсы персистентности, когда сами они делаются персистентными или впоследствии восстановленными.
В результате вышеупомянутого требования персистентные реализации BeanContextChild обязаны не сохранять ссылки или на их вложение BeanContext, или любым Делегатам, полученным через его вложение BeanContextServices.
BeanContexts должен быть, когда восстановление экземпляра BeanContextChild от его состояния персистентности, быть обязанным выполнять эквивалент вызова добавит () на недавно инстанцированном BeanContextChild, чтобы уведомить недавно восстановленный экземпляр относительно его вложения BeanContext, таким образом признавая что BeanContextChild, чтобы полностью восстановить его зависимости от его среды.
Также отметьте, что начиная с BeanContext реализует java.beans.beancontext. BeanContextChild это должно повиноваться требованиям персистентности, определенным ниже для конструкторов того интерфейса.
Хотя не требуемый, много BeanContexts могут быть связаны в пределах иерархии представления java.awt. Контейнеры и java.awt. Компоненты. Контейнер не может реализовать BeanContext directly2, но может быть связан с одним, реализовывая интерфейс BeanContextProxy, описанный здесь.
Для экземпляров классов, которые не делают (или не может в случае Компонента или подклассов этого) непосредственно реализуют интерфейс BeanContext, но связываются с экземпляром такой реализации, (через делегацию), такие экземпляры могут представить эту ассоциацию, реализовывая интерфейс BeanContextProxy. Делая так, это включает произвольным 3-ьим сторонам, таким как инструменты разработчика, чтобы опросить и обнаружить, что BeanContext, связанный с такими объектами в целях или объектов вложения в пределах этого, связал BeanContext, наблюдая изменения в членстве, или получая службы этого.
Это также разрешает многократные отличные объекты (например: Контейнеры), чтобы совместно использовать единственный BeanContext. [Отметьте, хотя это в этом случае совместно используемый BeanContext не должен реализовывать BeanContextContainerProxy, так как это - одноранговое отношение между единственным BeanContext и Контейнером, реализовывая тот интерфейс]
Значение, возвращенное из getBeanContext (), является постоянным для времени жизни экземпляра реализации, который является отношением между BeanContextProxy, и это связалось, BeanContext статичен и таким образом, возможно, не изменяется для времени жизни ни одного участника.
Никакой класс не может реализовать обоих BeanContext (или BeanContextChild) и интерфейсы BeanContextProxy, они являются взаимоисключающими.
Некоторые конструкторы BeanContextProxy могут также реализовать java.util. Набор, или некоторый другой подобный набору API (например, java.awt. Контейнер), в дополнение к, и возможно отличный от, поддерживая BeanContext базируемый Набор.
В таких случаях возможно добавить, или удалить, элементы или из BeanContext, через это - API Набора, или конструктор BeanContextProxy, использующий свой собственный подобный набору API (например: общедоступная булевская переменная java.awt. Container.add (Компонент)). Это является зависящим от реализации, добавляются ли объекты, добавленные или удаленные или из Набора BeanContext, или из набора конструктора BeanContextProxy также, или удаляются из набора соответствующего объекта (то есть: должен Container.add () также выводит BeanContext.add () и vica-versa?) . В таких ситуациях оба участника (конструктор BeanContextProxy и BeanContext непосредственно) обязаны; 1) реализуйте то же самое, добавляет/удаляет семантика как другой (то есть: если у x.add (o) есть побочный эффект x.getBeanContext ().add (o) тогда x.getBeanContext ().add (o), должен также иметь побочный эффект x.add (o)), и 2) прежде, чем добавить/удалить объект к другому набору участников, это должно протестировать (синхронизировался), если тот объект не является элементом другого набора участников перед продолжением рассматриваемой работы (это должно избежать бесконечной рекурсии между операциями набора на обоих участниках) (то есть: x.add (o) не должен вызвать x.getBeanContext ().add (o), если x.getBeanContext ().contains (o) является истиной и vica-versa).
Важно отметить что, если объект, который реализует BeanContextProxy, добавляется к, или удаляется из, BeanContext, что в дополнение к работе, выполняемой на том объекте, та же самая работа должна быть выполнена на BeanContext, возвращенном из BeanContextProxy.getBeanContext (). Это - конструктор BeanContextProxy, буду обработан, как если бы он непосредственно реализовывал BeanContext любым вложением BeanContext. (и vica-versa, если работа применяется к BeanContext, должен также быть применен к соответствующему BeanContextProxy),
Следующий интерфейс определяется, чтобы позволить BeanContext представлять ссылку на связанный Контейнер, чтобы включить, это - элементы BeanContextChild, чтобы добавить, или удалить, их связанный Компонент возражает против того Контейнера или осмотреть некоторое состояние на Контейнере.
Когда BeanContextChild со связанным Компонентом добавляется к BeanContext со связанным Контейнером есть три модели взаимодействия, которое может произойти относительно вложения Компонента в Контейнере в результате:
ИЛИ
Таким образом для самой большой функциональной совместимости BeanContextChild должен всегда проверять, является ли родитель его Компоана Контейнером BeanContext, и если это не, тогда это может добавить себя если приспособлено. Таким образом BeanContextChild может функционировать правильно согласно всем сценариям.
BeanContextChild ответственен за начальный заставление себя к имеющему право быть выведенным на экран через вызов шоу () [отмечают, что BeanContextChild может также впоследствии неоднократно скрываться () и шоу () непосредственно].
Вложение, которое BeanContext, или его связанный Контейнер, может впоследствии скрыть () или шоу () Компонент BeanContextChild произвольно, но строго рекомендуется, чтобы это обработало тот Компонент как неизменный во всех других отношениях за исключением регистрирующихся Слушателей, чтобы получить уведомления о событии, или где другой Компонент/Контейнер определенные протоколы разрешает или требует, чтобы Контейнер изменил состояние своего Компонента containees. Пример такого разрешенного взаимодействия был бы то, где свойство, такое как цвет фона или цвет переднего плана было распространено от Контейнера до Компонента.
Как только BeanContextChild был невложен от, это - BeanContext, это связалось, Компонент (если кто-либо) должен быть удален из того, что Контейнер BeanContext как побочный эффект работы удаления, это - ответственность BeanContext (обычно, если BeanContextChild был перемещен в другой BeanContext со связанным Контейнером через вызов, это - setBeanContext () метод, Компонент будет уже повторно порожден как побочный эффект той работы к тому времени, когда исходный BeanContext уведомляется относительно изменения через PropertyChangeEvent от дочернего элемента, однако проверка должна быть осуществлена и Компонент, удаленный, если это уже не произошло).
Чтобы избежать бесконечной рекурсии, и BeanContext и BeanContextChild, которые также связываются с отношением вложения Контейнера и Компонента, должны избежать отменять любые изменения, которым применяется к Компонент другая сторона в отношении. Вообще BeanContext ответственен за появление, видимость и относительное расположение Компонента BeanContextChild, и BeanContextChild ответственен за состояние Компонента и контент, имеющий отношение к функциональности приложения, которую это реализует.
Значение, возвращенное из getContainer (), метод является постоянным для времени жизни реализации BeanContext, который является отношением между BeanContext, и Контейнер статичен для времени жизни обоих участников.
Кроме того, следующий интерфейс также определяется:
BeanContext или BeanContextChild могут реализовать этот интерфейс, чтобы представить Компонент GUI, с которым это связывается с, это - вложение BeanContext. BeanContext может использовать этот метод, чтобы установить отношение между ссылками на экземпляры Компонента и BeanContextChild, которые известны этому, где BeanContextChild и Компонент не реализуются тем же самым объектным экземпляром (который является делегатами BeanContextChild его Компонентная реализация к отличному объекту вместо того, чтобы наследоваться от Компонента]. BeanContext может опросить Компонентную ссылку, которую он получает из вложенного BeanContextChild, чтобы определить его состояние, и он может также зарегистрировать Слушателей для определенных событий, однако строго рекомендуется, чтобы BeanContext обработали ссылку как обычно неизменную, чтобы избежать изменять Компонентное состояние.
Значение, возвращенное из getComponent () метод, является константой для времени жизни того BeanContextChild.
В ситуации, где BeanContext имеет связанный Контейнер, но не хочет представлять тот Контейнер, реализовывая интерфейс BeanContextContainerProxy, но хочет обработать вложение связанного Компонента произвольного BeanContextChild (представленный BeanContextChild или реализовывая интерфейс BeanContextChildComponentProxy или как прямой подкласс Компонента), BeanContext разрешают добавить/удалить что Компонент к его связанному Контейнеру. В таких случаях связались BeanContextChild и это, Компонентная реализация не должна вмешиваться в это действие.
Если класс реализует и BeanContextChildComponentProxy и BeanContextContainerProxy тогда объект, возвращенный обоими, то getComponent () и getContainer () должен быть тем же самым объектом.
Простые JavaBeans, которые не требуют никакой поддержки или знания их среды, должны продолжать функционировать, как они делают сегодня. Однако и JavaBeans, которые хотят использовать их содержание BeanContext, и BeanContexts, который может быть вложен, требуют, чтобы реализовать механизм, который включает распространению ссылки на включение BeanContext через к осведомленному JavaBeans и вкладывал BeanContexts, предложенный интерфейс:
public interface java.beans.beancontext.BeanContextChild { void setBeanContext(BeanContext bc) throws PropertyVetoException; BeanContext getBeanContext(); void addPropertyChangeListener (String name, PropertyChangeListener pcl); void removePropertyChangeListener (String name, PropertyChangeListener pcl); void addVetoableChangeListener (String name, VetoableChangeListener pcl); void removeVetoableChangeListener (String name, VetoableChangeListener pcl); }
Ожидаемое использование состоит в том, что некоторая 3-ья сторона должна вызвать один из соответствующих методов, определенных на BeanContext (на основании его наследования от Набора), чтобы добавить BeanContextChild к членству целевого BeanContext. Как следствие BeanContext должен попытаться установить “beanContext” свойство BeanContextChild, вызывая его метод метода set, setBeanContext (). Только BeanContext может вызвать setBeanContext BeanContextChild () метод, так как это - механизм, который BeanContext использование, чтобы уведомить дочерний элемент, что это теперь, сделал, чтобы новый BeanContext оценил. Так как это свойство не непосредственно устанавливаемо или настраиваемо пользователем в контексте инструмента конструкции приложения, BeanInfo для BeanContextChild должен установить скрытое состояние для этого свойства для инструментов разработчика, чтобы избежать представлять свойство пользователю для настройки.
Объект BeanContextChild может бросить PropertyVetoException, чтобы уведомить вложение BeanContext, что это неспособно функционировать / вложенное в пределах того определенного BeanContext. Такое вето должно интерпретироваться BeanContext как индикация, что BeanContextChild решил, что это является неспособным функционировать в том определенном BeanContext и является заключительным.
Во время невложения BeanContextChild от его BeanContext для дочернего элемента, или 3-ьей стороны, слушая “beanContext” свойство дочернего элемента для PropertyVetoEvents, возможно бросить PropertyVetoException, чтобы уведомить вызывающую сторону, что это не находится в состоянии, которое будет невложено. Чтобы к связанному это взаимодействие BeanContextChild, или 3-ья сторона, может наложить вето на начальное уведомление невложения, но, возможно, не накладывает вето ни на какие последующие уведомления, и, по получении таких уведомлений, должен исправить его состояние соответственно, чтобы подготовиться, чтобы быть впоследствии невложенным.
Отметьте, что классы, которые реализуют этот интерфейс, также действуют как Источник события для (sub) интерфейса (ов) java.beans. PropertyChangeListener, и обязаны обновлять свое состояние соответственно и впоследствии запускать соответствующий java.beans. PropertyChangeEvent с propertyName = “beanContext”, oldValue = ссылка на предыдущее вложение BeanContext, и newValue = ссылка на новое вложение BeanContext, чтобы уведомить любых Слушателей, что его вложение BeanContext изменило значение.
Экземпляры BeanContextChild, или вложенный BeanContexts в процессе завершения, должны вызвать удаление () метод на их вложении BeanContext, чтобы отозвать себя из иерархии до завершения.
Экземпляры BeanContextChild, вложенного в пределах BeanContext, будут обычно определять поля или переменные экземпляра, которые будут содержать ссылки на их вложение экземпляр BeanContext, и возможно службы, полученные изо что экземпляр BeanContextServices через его getService () метод.
Чтобы гарантировать, что действие создания такого персистентного экземпляра ошибочно не сохраняет объекты от среды вложения экземпляров, такие экземпляры должны быть обязаны определять такие поля, или переменные экземпляра или как переходный процесс, или реализовывать пользовательские методы персистентности, которые избегают сохранять такое состояние.
Это требование крайне важно начиная с операций, таких как сокращение, и вставка объектных экземпляров через буфер обмена через объектную сериализацию не будет функционировать правильно, если действие сериализации целевого объекта также сериализирует большую часть всей исходной среды, это вкладывается в пределах.
С тех пор java.beans.instantiate () текущий механизм для (ре) инстанцирование JavaBeans, мы должны расширить или перегрузить синтаксис и семантику этого метода, чтобы разместить введение абстракции BeanContext. Предложенное расширение:
Этот метод ведет себя, имеет это, в настоящий момент определяется в спецификации JavaBeans, но в дополнение к ним существующая семантика, когда ненулевой BeanContext определяется тогда, метод вызывает добавление () метод на beanContext фактическом параметре со значением targetChild фактического параметра = ссылка на недавно инстанцированный компонент 4 JavaBean
Текущая реализация java.beans.instantiate () содержит минимальную поддержку инстанцирования JavaBeans, которые являются также Апплетами. В частности этот метод в настоящий момент создаст AppletContext и AppletStub для недавно инстанцированного JavaBean, установит тупик на недавно инстанцированном Апплете, и init () Апплет, если это не было уже вызвано.
К сожалению, это не оказывает достаточную поддержку, чтобы позволить большинству Апплетов быть полностью функциональным, так как AppletContext и AppletStub, создаваемый java.beans.instantiate (), без операций в секунду. Это - прямое следствие нехватки достаточной спецификации того, как создать реализации AppletContext и AppletStub в существующем API Апплета. Кроме того, даже если бы такие спецификации существовали, то мы потребовали бы API, который распространил много атрибутов Апплета, таких как его Кодовая база, Параметры, AppletContext, и Documentbase в java.beans.instantiate () для этого, чтобы впоследствии инстанцировать соответственно инициализированных объектов.
Так как ключ к поддержке полностью функциональных Апплетов должен предоставить им полностью функциональные экземпляры AppletContext и AppletStub, цель проекта состоит в том, чтобы обеспечить механизм, чтобы обеспечить это состояние, чтобы инстанцировать () так, чтобы это могло выполнить соответствующую инициализацию и binding5, поэтому предложенный интерфейс:
public static Object instantiate(ClassLoader cl, String beanName, BeanContext bCtxt, AppletInitializer ai ); public interface AppletInitializer { void initialize(Applet newApplet, BeanContext bCtxt); void activate(Applet newApplet); }
Если недавно инстанцированный компонент JavaBean является экземпляром java.applet. Апплет тогда новый созданный Апплет, (Боб) передадут к AppletInitializer через вызов, чтобы инициализировать ().
Совместимые реализации AppletInitializer.initialize () должны быть:
Совместимые реализации AppletInitializer.activate () должны отметить Апплет как активный, и могут дополнительно также вызвать запуск Апплета () метод.
Отметьте что, если недавно инстанцированный JavaBean не является экземпляром Апплета, то интерфейс AppletInitializer игнорируется.
Технология InfoBus является стандартным пакетом расширения, который предназначается, чтобы облегчить рандеву и обмен динамическими сам описание данных, основанных на том, чтобы публиковать и подписать абстракцию, между Компонентами JavaBean в пределах единственной виртуальной машины Java.
BeanContext, который представляет InfoBus его вложенному BeanContextChild, должен сделать так, представляя службу через hasService () и getService () методы типа javax.infobus. InfoBus.
Таким образом реализации BeanContextChild могут определить местоположение общей реализации InfoBus для своего текущего BeanContext при использовании этого механизма к рандеву с тем экземпляром InfoBus.
Infobus 1.2 спецификации должен определить механизм удобства, обеспеченный классом InfoBus, чтобы упростить механизм открытия для экземпляров BeanContextChild, вложенных в пределах определенного экземпляра BeanContextServices.
BeanContext, который хочет представить средства печати ее потомкам, может делегировать ссылку java.awt типа (sub). PrintJob.
Поскольку Сеть Java, Печатающая Интерфейс, развивается, дополнительные спецификации будут обеспечены, чтобы представить, это - средства через механизм служб.
JavaBeans поддерживают понятие "проекта" - режим, когда JavaBeans управляют и составляются разработчиком в Разработчике приложений или IDE, и "Выполнении" - режим, когда получающиеся JavaBeans инстанцируют во время выполнения как часть Апплета, Приложения или некоторой другой исполнимой абстракции.
В первой версии спецификации, "режима" или состояния, которое является "проектом", разовым или "выполненным" разовый, был глобальный атрибут JVM. Это недостаточно с тех пор, например, в среде Разработчика приложений, могут быть JavaBeans, которые функционируют, в "выполненном" - режим, как часть среды Разработчика приложений непосредственно, так же как JavaBeans, которые функционируют, в "проекте" - режим, в стадии строительства разработчиком, использующим Разработчика приложений, чтобы составить приложение.
Поэтому мы требуем возможности определить контекст этого "режима" при гранулярности ниже той из глобальной переменной JVM.
Абстракция BeanContext, как "Контейнер" или "Контекст" для одного или более JavaBeans обеспечивает соответствующий механизм, чтобы лучше определить контекст этого "режима".
Таким образом BeanContext, которые хотят представить и распространить этот "режим" его потомкам, могут делегировать ссылку типа java.beans. DesignMode:
public interface java.beans.DesignMode {
void setDesignTime(boolean isDesignTime);
boolean isDesignTime();
}
Дополнительно, BeanContexts, делегирующий такую ссылку, должен быть обязан запускать соответствующий java.beans.propertyChangeEvent, с propertyName = "время проектирования", с соответствующими значениями для oldValue и newValue, когда "режим" изменит значение.
Отметьте, что это недопустимо для экземпляров BeanContextChild, чтобы вызвать setDesignTime () на экземплярах BeanContext, в пределах которого они вкладываются.
JavaBeans со связанным представлением, или GUI, можно инстанцировать в средах, где возможность представить тот GUI любой не физически возможна (когда аппаратные средства не присутствуют), или не является соответствующим под текущими положениями (работающий в контексте сервера вместо клиента).
Первая версия Спецификации JavaBeans, представленной java.beans. Интерфейс видимости, чтобы предоставить механизм JavaBeans, чтобы иметь их "видимое" состояние, или возможность представить GUI, которым управляют от их среды.
BeanContexts, которые хотят осуществить определенную политику относительно возможности их дочерних элементов представить GUI, должны использовать java.beans. Интерфейс видимости, чтобы управлять их дочерними элементами.
BeanContexts можно было связать локаль с ними, чтобы связать и распространить этот важный атрибут через JavaBeans, вложенный там.
Поэтому, BeanContexts, буду обязан запускать соответствующий java.beans. PropertyChangeEvent, с propertyName = "локаль", oldValue = ссылка на предыдущее значение делегата Локали, и newValue = ссылка на новое значение делегата Локали, чтобы уведомить ее Слушателей любого изменения в Локали.
Установка и получение значения Локали на BeanContext являются зависящими от реализации.
Чтобы ослабить реализацию этого относительно сложного протокола "помощник", классы обеспечиваются; java.beans.beancontext.BeanContextChildSupport, java.beans.beancontext.BeanContextSupport, и java.beans.beancontext.BeanContextServicesSupport. Эти классы разрабатываются, чтобы или быть разделенными на подклассы, или делегированными неявно другим объектом, и обеспечивает полностью совместимые (расширяемые) реализации протоколов, воплощенных здесь.
| Содержание |
