Title: Webadmin
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:

- [Main](http://tomee.apache.org/images/webadmin-main.png)
- [EJB Details](http://tomee.apache.org/images/webadmin-ejbdetails.png)
- [List Logs](http://tomee.apache.org/images/webadmin-listlogs.png)
- [System Properties](http://tomee.apache.org/images/webadmin-properties.png)
- [JNDI Viewer](http://tomee.apache.org/images/webadmin-viewjndi.png)
- [EJB Viewer](http://tomee.apache.org/images/webadmin-ejbviewer.png)
- [Object and EJB Invoker](http://tomee.apache.org/images/webadmin-objectinvoker.png)

<a name="Webadmin-EnablingtheWebadminin1.0beta1"></a>
## Enabling the Webadmin in 1.0 beta 1

The 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/

<a name="Webadmin-WebAdminBeans"></a>
# WebAdmin Beans

To 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:

    <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 Plugins

Here is a project that already takes advantage of the new feature. [BeanGen|http://beangen.sourceforge.net]

# Developers guide
Below 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/{section}/\{page\}". 
Anyone could add to the Webadmin console by doing both of these things,
which is really cool as people developing EJB apps can also deploy beans
for administering those apps right in the exact same jar.  This is not only
easy for packaging but means new sections can be added/removed on the fly.

Using the described "webadmin/{section}/\{page\}" deploymentId format,
things end up automagically grouped in the JNDI tree.  There's a 'webadmin'
context we grab which will contain any number of "section" contexts
("ClientTools", "EJBGenerator", etc.).	Each of those section subcontexts
will contain several beans which we will use to make the pages.  Making the
menu is pretty easy as we just iterate over the webadmin section of the
global jndi tree.

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.
There'll be some changes to this as now we support our plain ejb protocol
over our http implementation, so the two will have to find a way to share
the URL space.	See the openejb-http module.

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
read it back out on subsequent requests then used it to get a reference to
the EJBObject again.  I'm not sure why we didn't just keep a static hashmap
and put the EJBObject right in it using an ID we could just make up like
UUID (that would have been way simpler).

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.
    
    
  - The Jndi Viewer, Class Viewer, Ejb Viewer, and Object Invoker were written by yours truly
  - The EJB Generator was written by Jeremy Whitlock
  - Everything else was written by Tim Urberg.	Tim was "WebAdmin guy" for
    a good long while.  Before Tim came along the webadmin was just some
    experimental code I had in a branch, he did more than he realizes by putting his energy
    into it -- active people attract/ create more active people.  Maybe we can
    convince him to come back and work on it ;)
    
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.