Home | News | FAQ | Download | Lists | Issues | ||||||||
The Webadmin is a new addition to OpenEJB 1.0 and very innovative in that it lets you plug-in your own admin beans. Here are some screenshots: Enabling the Webadmin in 1.0 beta 1The Webadmin console is in the 1.0 beta 1 release. To enable it, simply move into the openejb.home directory and copy the openejb-webadmin-main.jar from the beans directory into the lib directory. Then start the server. mingus:~/ $ cd /usr/local/openejb-1.0-beta1 mingus:/usr/local/openejb-1.0-beta1 03:37:33 $ cp beans/openejb-webadmin-main.jar lib/ mingus:/usr/local/openejb-1.0-beta1 03:37:52 $ ./bin/openejb start OPENEJB_HOME = /usr/local/openejb-1.0-beta1 OpenEJB 1.0-beta1 build: 20050829-2233 http://www.openejb.org resources 1 OpenEJB ready. [init] OpenEJB Remote Server ** Starting Services ** NAME IP PORT admin thread 127.0.0.1 4200 ejbd 127.0.0.1 4201 telnet 127.0.0.1 4202 webadmin 127.0.0.1 4203 ------- Ready! Now you can open your browser to go to http://localhost:4203/ WebAdmin BeansTo create an EJB and have it included as part of the WebAdmin, simply subclass from WebAdminBean and include it in your ejb-jar.xml file as such: ejb-jar.xml <session> <description>A JNDI viewer</description> <ejb-name>webadmin/ViewJndi</ejb-name> <home>org.openejb.webadmin.HttpHome</home> <remote>org.openejb.webadmin.HttpObject</remote> <ejb-class>org.openejb.webadmin.clienttools.ViewJndiBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Bean</transaction-type> </session> The ejb-name is used to create the menus and should follow the format of 'menu-section/menu-item'. WebAdminBeans are grouped together by the 'menu-section' portion of their ejb-name. The 'menu-item' is the clickable link that causes the EJB code to be execute. Very simple and makes it possible to package administrative components with your EJB applications. WebAdmin PluginsHere is a project that already takes advantage of the new feature. BeanGen Developers guideBelow is David Blevins' email on how webadmin worked. Please have a look at the text below before you start working on porting the existing WebAdmin to version 3. Plain old stateless beans were used as the "servlets". To make a bean that would show up in the Webadmin Console you simply had to implement the HttpBean interface (i think it's now called HttpListener) and give your bean a deploymentId following this format "webadmin/ When an http request came in we just took the path part of the GET or POST request, prepended "webadmin/" and then went looking for a bean with that deployment id and invoked it via it's HttpBean (now called HttpListener) interface passing in a HttpRequest and HttpResponse objects which are trimmed down versions of similar servlet classes. To implement session state, we had a stateful session bean implementing an HttpSession interface (again, similar to the servlet equivalent) and simply wrote the internal ID of the bean instance into a Cookie sent to the browser. For some reason we would write the javax.ejb.Handle of the stateful bean's EJBObject to disk and We had a standard superclass we favored for beans that implemented the HttpBean (HttpListener) interface that did templating and the aforementioned menu construction. The templating was perhaps too tricky as we used a non-printable character to determine where to insert data. Now we could just use swizzle-stream for some pretty decent templating ability or even velocity. I'd be hesitant to endorse velocity as we already have a dep on swizzle-stream and wouldn't want to see us add another meg to our distro size if we can avoid it – we have like 3 times as many deps as 1.0 did and we should probably start tightening the belt. To serve static things like images, we had a "default" HttpBean which searched for the items in the classpath and wrote them into the response setting the mime type, etc. correctly. One thing that we never did which still needs to happen is that the bean didn't have the logic to set the modification information into the response so the "If modified since" header which would allow the browser to rely on it's cache instead of requesting the same images over and over again. That pretty much covers the way it was put together.
And of course I have to mention our own Paulo Lopes who wrote a really cool project out in SF.net (http://beangen.sourceforge.net/) which was the first plugin for the OpenEJB Webadmin. He wrote it before we even had shipped a release containing the Webadmin or had any docs at all on it, which in my mind shows just how neat the idea of using ejb's and simple conventions to do the console really is. Some notes going forward is that we have a truck load of meta-data now available via SystemInstance.get().get (OpenEjbConfiguration.class). Certainly JSR-77 is one option, but we could do far better with plain old java code. That tree is the primary source of meta-data for OpenEJB, it's what was used to construct every container, bean, resource adapter, database connector and everything in the system (well, sans the protocols). Someone new to the project can look at it and understand it without having to read any abstract specs. Something to consider. The tree is read only in it's function, however it is possible to copy then edit and make new containers, etc. based on existing definitions. Additionally, using this same data structure it's possible to show the potential services available via the service-jar.xml files in the classpath that detail containers, resource adapters, database connectors, etc. which can be configured/created at runtime. So we could also display a sort of catalogue of components (aka. services) that someone could click and deploy via the console. |
||||||||
|