Remove EJB3 usage in JBoss 5 packaging

Using simple POJO instead of EJB on JBoss5 is the way to reach the
same tomcat performance on repository read !

Using admin center document statistics we jump from 617 to 2100 doc/s.

When using EJB the document statistics generates around 300 EJB
creation of SFSL DocumentManagerBean.

I need to run more bench on this instance to see if the memory
footprint is smaller and if the web access is faster.

Here are a list of JBoss AS 5.0.1 performance problems:

1/ A memory leak in VFS

This is a system leak the process is growing taking more and more
RSS and VSZ size, the problem can be seen using pmap and looking at
the number of chunk of 1024K.

I need to perform a long bench to see if the leak reach a limit or
not.

Anyway having lots of memory is enough as a workaround.

https://jira.jboss.org/browse/JBVFS-159
http://bugs.sun.com/view_bug.do?bug_id=6735255

2/ A very slow EJB deployment

The implementation is buggy in 5.0.1 taking a lot of memory.

Even with the latest patch it will never be as fast as JBoss4 EJB
container because it is looking for annotations on methods through
AOP and it seems very slow.

This has an impact as we have 37 EJB on Nuxeo DM.

https://jira.jboss.org/browse/EJBTHREE-1800
http://community.jboss.org/thread/104679?tstart=0

3/ A weird EJB object pool

EJB thread are the same as HTTP (or AJP), Stateless Session and
Stateful Session Beans use the ThreadLocalPool, which is backed by
an InfinitePool with no maximum size, this remove need of lock
access.

The default timeout is 10s for SLSB so I think the pool is useless
most of the time and if you have an http maxThread set to 200 (the
default) this means that you have 200 ejb pools -> buy some more ram

AFAIU there is no way to have a limited pool of EJB like in JBoss4
using StrictPool will be blocking when reaching the maximum (instead
of sharing a fixed number of object between threads).

http://docs.jboss.org/ejb3/docs/reference/build/reference/en/html/session-bean-config.html