WebAdmin (was Re: openejb- ease of use, snapshot and maven)

[David Blevins <da...@visi.com>]

On Jun 20, 2007, at 12:30 PM, Manu George wrote:

> I will download 1.0 and have a go at porting this, looks pretty cool
> and we definitely should have it in 3.0 :).

Cool.  Here is some info to arm you in how it worked.  Knowledge  
transfer commencing in 3.. 2.. 1....

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.

As for the individual pages, I have to give a shout out to the people  
who worked on them.

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

I wrote a big long email about the service-jar.xml some time ago.  I  
think Karan knows which one I'm referring to as he had mentioned a  
couple times he'd like to add it to the website -- assuming my memory  
hasn't gone bad :)

-David

Re: WebAdmin (was Re: openejb- ease of use, snapshot and maven)

[Manu George <ma...@gmail.com>]

Thanks for the link Karan.

regards
Manu

On 6/21/07, Karan Malhi <ka...@gmail.com> wrote:
> Here is the link which talks about service-jar.xml and xbean. Still
> havent been able to get it to the website. :(
>
> http://www.nabble.com/How-is-XBean-used-in-OpenEJB-3--tf2148639.html#a5959172
>
> On 6/20/07, David Blevins <da...@visi.com> wrote:
> >
> > On Jun 20, 2007, at 12:30 PM, Manu George wrote:
> >
> > > I will download 1.0 and have a go at porting this, looks pretty cool
> > > and we definitely should have it in 3.0 :).
> >
> > Cool.  Here is some info to arm you in how it worked.  Knowledge
> > transfer commencing in 3.. 2.. 1....
> >
> > 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.
> >
> > As for the individual pages, I have to give a shout out to the people
> > who worked on them.
> >
> >    - 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.
> >
> > I wrote a big long email about the service-jar.xml some time ago.  I
> > think Karan knows which one I'm referring to as he had mentioned a
> > couple times he'd like to add it to the website -- assuming my memory
> > hasn't gone bad :)
> >
> > -David
> >
> >
> >
> >
> >
>
>
> --
> Karan Malhi
>

Re: WebAdmin (was Re: openejb- ease of use, snapshot and maven)

[Manu George <ma...@gmail.com>]

ok found it it is there in svn.

On 6/21/07, Manu George <ma...@gmail.com> wrote:
> Where do i download the source from? Is it there in svn? Currently i
> can find it in http://cwiki.apache.org/OPENEJB/download.html. Is that
> the latest
>
> Regards
> Manu
>
> On 6/21/07, Karan Malhi <ka...@gmail.com> wrote:
> > Here is the link which talks about service-jar.xml and xbean. Still
> > havent been able to get it to the website. :(
> >
> > http://www.nabble.com/How-is-XBean-used-in-OpenEJB-3--tf2148639.html#a5959172
> >
> > On 6/20/07, David Blevins <da...@visi.com> wrote:
> > >
> > > On Jun 20, 2007, at 12:30 PM, Manu George wrote:
> > >
> > > > I will download 1.0 and have a go at porting this, looks pretty cool
> > > > and we definitely should have it in 3.0 :).
> > >
> > > Cool.  Here is some info to arm you in how it worked.  Knowledge
> > > transfer commencing in 3.. 2.. 1....
> > >
> > > 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.
> > >
> > > As for the individual pages, I have to give a shout out to the people
> > > who worked on them.
> > >
> > >    - 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.
> > >
> > > I wrote a big long email about the service-jar.xml some time ago.  I
> > > think Karan knows which one I'm referring to as he had mentioned a
> > > couple times he'd like to add it to the website -- assuming my memory
> > > hasn't gone bad :)
> > >
> > > -David
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Karan Malhi
> >
>

Re: WebAdmin (was Re: openejb- ease of use, snapshot and maven)

[Manu George <ma...@gmail.com>]

Where do i download the source from? Is it there in svn? Currently i
can find it in http://cwiki.apache.org/OPENEJB/download.html. Is that
the latest

Regards
Manu

On 6/21/07, Karan Malhi <ka...@gmail.com> wrote:
> Here is the link which talks about service-jar.xml and xbean. Still
> havent been able to get it to the website. :(
>
> http://www.nabble.com/How-is-XBean-used-in-OpenEJB-3--tf2148639.html#a5959172
>
> On 6/20/07, David Blevins <da...@visi.com> wrote:
> >
> > On Jun 20, 2007, at 12:30 PM, Manu George wrote:
> >
> > > I will download 1.0 and have a go at porting this, looks pretty cool
> > > and we definitely should have it in 3.0 :).
> >
> > Cool.  Here is some info to arm you in how it worked.  Knowledge
> > transfer commencing in 3.. 2.. 1....
> >
> > 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.
> >
> > As for the individual pages, I have to give a shout out to the people
> > who worked on them.
> >
> >    - 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.
> >
> > I wrote a big long email about the service-jar.xml some time ago.  I
> > think Karan knows which one I'm referring to as he had mentioned a
> > couple times he'd like to add it to the website -- assuming my memory
> > hasn't gone bad :)
> >
> > -David
> >
> >
> >
> >
> >
>
>
> --
> Karan Malhi
>

Re: WebAdmin (was Re: openejb- ease of use, snapshot and maven)

[Karan Malhi <ka...@gmail.com>]

Here is the link which talks about service-jar.xml and xbean. Still
havent been able to get it to the website. :(

http://www.nabble.com/How-is-XBean-used-in-OpenEJB-3--tf2148639.html#a5959172

On 6/20/07, David Blevins <da...@visi.com> wrote:
>
> On Jun 20, 2007, at 12:30 PM, Manu George wrote:
>
> > I will download 1.0 and have a go at porting this, looks pretty cool
> > and we definitely should have it in 3.0 :).
>
> Cool.  Here is some info to arm you in how it worked.  Knowledge
> transfer commencing in 3.. 2.. 1....
>
> 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.
>
> As for the individual pages, I have to give a shout out to the people
> who worked on them.
>
>    - 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.
>
> I wrote a big long email about the service-jar.xml some time ago.  I
> think Karan knows which one I'm referring to as he had mentioned a
> couple times he'd like to add it to the website -- assuming my memory
> hasn't gone bad :)
>
> -David
>
>
>
>
>


-- 
Karan Malhi