ok found it it is there in svn.
On 6/21/07, Manu George <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
