Howdy -
I have been working on cleaning up a few last things in OpenEJB 1.0 prior to the final build. After various discussions with David, there are a few things left to resolve regarding the two ways in which you can run OpenEJB in Tomcat. These issues affect the way openejb.home and openejb.base are defined.
Currently, we can run OpenEJB in Tomcat in one of two ways:
1) As a Tomcat-level container
In this scenario, OpenEJB is run at the Tomcat level via a special webapp. By default, and if openejb.home is specified correctly, it loads all libraries, beans and the configuration file from external $OPENEJB_HOME directory. You can also specify a separate configuration file if you want.
All webapps can access this single OpenEJB instance. All beans are visible to all webapps.
2) As a webapp-level container
In this scenario, OpenEJB is run at the webapp level. By default, and if openejb.home is specified correctly, it loads all libraries, beans and the configuration file from external $OPENEJB_HOME directory. You could specify your own configuration file and pick up beans in your WEB-INF directory structure somewhere.
When multiple webapps have their own OpenEJB instances they will share the jars from $OPENEJB_HOME but only in the sense that the individual classloaders load from the same directories. There is no classloader sharing as there is in Tomcat. In other words, no beans are visible between webapps.
David has proposed a third scearnio:
3) As a Tomcat-level container with two-tiered classloaders
In this scenario, OpenEJB is run at the Tomcat level via a special webapp. By default, and if openejb.home is specified correctly, it loads all libraries, beans and the configuration file from external $OPENEJB_HOME directory.
However, we use two classloaders. One classloader is the common classloader, and beans that will be visible to each webapp. The other classloader is webapp-specific, and loads beans visible only to the webapp itself. This is exactly the same scenario used by Tomcat.
After testing out various other options in the codebase, I have come to the conclusion that this scenario is important to have and will be understood easily by users who are already familiar with Tomcat's classloading scheme. David and I have agreed that we should push for this option in version 1.1 and not unduly delay 1.0.
However, all this brings up the issue of terminology, specifically openejb.home and openejb.base and the way this is handled in the code.
In Tomcat, $CATALINA_HOME and $CATALINA_BASE are used when you run multiple instances of Tomcat on a single machine. This allows you to share directories, in the sense that each instance loads jars from a common directory structure. It does not refer to classloading sharing.
However, in Tomcat there is a concept of classloading sharing, in which the common classloader loads from $CATALINA_HOME/common/lib and the webapp classloader loads from $CATALINA_HOME/webapp/<webappp-name>. (Yes, there is the bootstrap classloader as well but doesn't affect us).
The Tomcat classloading scheme has no special nomenclature like home/base.
So the question is: should we, for the sake of clarity, redefine openejb.home and openejb.base? Personally, even as an author of a book on Tomcat, I find the idea of $CATALINA_HOME and $CATALINA_BASE completely unintuitive and confusing. Even if they do it that way, no reason why we should continue the confusion.
<proposal>
My proposal therefore is that we rename openejb.home as openejb.install, to refer to the directory containing the OpenEJB installation - $OPENEJB_HOME, in other words.
I propose that we then rename openejb.base as openejb.local, to refer to the WEB-INF directory for a web application.
I propose that in Scenario # 2, no libraries in WEB-INF/lib can be loaded by OpenEJB - let's eliminate the possibility of loading some oe libraries from openejb.install/lib and some from openejb.local/lib.
I propose that in Scenario # 2, if no conf file is provided, $OPENEJB_HOME/conf/openejb.xml is used, and only beans in $OPENEJB_HOME/beans are loaded. If a webapp wants beans from WEB-INF/beans to be loaded, then the webapp is going to have to have its own conf file.
Alternatively, we could allow a webapp-specific OpenEJB instance to load beans from WEB-INF/beans simply by adding another parameter to web.xml: load-local-beans = true. I have already done this in the code, by the way, but not done a commit. If you want to try it out first, I'll do the commit and you can give it a spin.
</proposal>
Have at it!
Regards,
Lajos
--
