User: andreas Date: 00/11/16 19:23:48 Added: documentation EJX.Insights.html Log: Add new insights to EJX internals written by Simon Bordet and an index page to the EJX mini serie. Revision Changes Path 1.1 newsite/documentation/EJX.Insights.html Index: EJX.Insights.html =================================================================== <!-- saved from url=(0022)http://internet.e-mail --> <HTML> <HEAD> <META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0"> <TITLE>EJX Insights</TITLE> </HEAD> <BODY> <H1>EJX Insights</H1> EJX (created by Rickard �berg and are available at his DreamBean Website: <A href="http://www.dreambean.com">www.dreambean.com</A>) is a launcher for JavaBean plugins that are written following the Glasgow specification, in particular the Extensible Runtime Containment and Services Protocol. This document is intended for programmers that want to write plugins for EJX, and will (try to) explain the insights of the bean context hierarchy of EJX, and also classloader issues regarding this hierarchy. <H4><FONT size=4>The launcher</FONT></H4> com.dreambean.ejx.editor.Main is the launcher for EJX. It does the following: <UL> <LI>creates a new URLClassLoader, whose parent is the current context classloader <LI>all files under ../lib and ../lib/ext are added to this URLClassLoader (PENDING: really all files or only jars) <LI>the context class loader is set to this URLClassLoader <LI>the class com.dreambean.ejx.editor.EJX is instantiated using the new context class loader (ie the URLClassLoader)</LI> </UL> <P> All plugins you would like to show in the EJX framework must be under ../lib or ../lib/ext, so that their classes can be loaded through the context class loader. If this is not the case, your plugin is not even shown in the EJX first window, where you can choose, among the available plugins, which one you want to use.</P> <P> Every EJX plugin is archived in a jar and must have an entry in the manifest file that reads:</P> <P>EJX-plugin: <factory-class-name></P> <P>where <factory-class-name> is the fully qualified name of the ResourceManagerFactory implementation that can instantiate the ResourceManager implementation for that plugin.</P> <H4><FONT size=4>The bean context framework</FONT></H4> <P>Following the Glasgow specification, JavaBeans can be logically grouped in containers, called <STRONG>BeanContext</STRONG>. A BeanContext can contain other nested BeanContext, or directly <STRONG>BeanContextChild</STRONG> JavaBeans. While normal JavaBeans can be added to BeanContexts, to obtain the full potentiality of the new framework, they should implement the BeanContextChild interface. A BeanContextChild is normally a terminal child of the containment hierarchy, so it cannot have nested JavaBeans. JavaBeans, being they BeanContext or BeanContextChild can be added to or removed from a BeanContext, and notification of these events is delivered to registered membership listeners.</P> <P>A BeanContext can expose <STRONG>services</STRONG> to its children, services that can easily accessed by them simply specifying the interface that represent the wanted service. The interfaces that provides this support are <STRONG>BeanContextServices</STRONG> and <STRONG>BeanContextServiceProvider.</STRONG></P> <P>BeanContextServices is a BeanContext with the possibility to be queried for services that it hosts. BeanContextServiceProvider is the service hosted by a BeanContextServices. Services can be added or removed from a BeanContextServices, and notification of these events is delivered to registered service listeners.</P> <P>Within this framework, JavaBeans can obtain a reference to the BeanContext in which they are hosted and thus be aware of the environment in which they're running; plus they can query the BeanContext for services, if the BeanContext hosting them is a BeanContextServices. If this BeanContextServices does not have the requested service, the request goes up in the hierarchy, eventually finding the BeanContextServices that provides the service.</P> <H4><FONT size=4>The bean context root and the services</FONT></H4> <P>As you may have guessed, com.dreambean.ejx.editor.EJX is a BeanContextServices instance, and is the root of the bean context hierarchy of the application.</P> <P>It hosts 2 services: </P> <UL> <LI>a Preference service, used to store user preferences like screen size <LI>an XMLManager service, used to allow JavaBeans to read from / write to XML files.</LI> </UL> <P>Direct children EJX are the plugins, that implements the ResourceManager interface. ResourceManager extends BeanContextChild so that implementors can be directly plugged in the containment hierarchy, but normally implementors of the ResourceManager interface implements BeanContextServices, to provide plugin-specific services to their nested JavaBeans.</P> <P>PENDING: add a figure / schema of the containment tree with different colors representing services</P> <P><FONT size=4><STRONG>Where the GUI comes in ?</STRONG></FONT></P> <P>We saw the bean context hierarchy, but what you can see on the screen is not totally related to it (though there is a relationship). How can EJX show the GUI for JavaBeans component seamlessly ?</P> <P>Every JavaBean that wants to display a GUI in EJX must implement either <STRONG>BeanContextContainerProxy</STRONG> or <STRONG>BeanContextChildComponentProxy</STRONG>. </P> <P> com.dreambean.ejx.editor.EJX implements BeanContextContainerProxy and its getContainer() method expose a JDesktopPane of a JFrame (also held by com.dreambean.ejx.editor.EJX [NOTE: this JFrame is not exposed (as of 15 Nov 2000), so it is not accessible from nested JavaBeans if they want play with the menu bar. I have in mind to change this and indirectly expose the JFrame as a EJX service]).</P> <P>JDesktopPane is the specialized class that hosts JInternalFrames. Normally plugins implement the BeanContextChildComponentProxy interface returning a java.awt.Component (subclass) that can be added to a JInternalFrame and finally added to the JDesktopPane.</P> <P>The difference between BeanContextChildComponentProxy and BeanContextContainerProxy is that the former is implemented by JavaBeans whose enclosing BeanContext is responsible to call getComponent and add the resulting java.awt.Component to some existing GUI, while the latter is implemented by JavaBeans whose enclosed JavaBeans are responsible to call getContainer() and add to this java.awt.Container GUI components taken from somewhere else. The former says "I know my children, let's take their GUI components and add them here", the latter says "I know my parent, let's add this GUI components to its GUI container".</P> <P align=right><FONT size=1>Written by <A href="mailto:[EMAIL PROTECTED]">Simone Bordet</A> </FONT></P> </BODY> </HTML>
