On Thu, Feb 24, 2005 at 02:39:39PM +0100, Jacek Laskowski wrote: > David Blevins wrote: > > >The idea is that when having one OpenEJB per-webapp you end up with this: > > > >WEB-INF/lib > >WEB-INF/classes > >WEB-INF/beans > > > >Where the beans directory holds the EJBs for your web app. So you can > >pack your ejbs in your war file like other libraries. Really nice for > >people doing virtual hosting or housing multiple apps for multiple people. > >OpenEJB and your EJBs are loaded in your webapp's classloader and all the > >config files are relative to your webapp. Everyone gets their own setup > >and one bothers anyone else. > > Hi Dave, > > Not necessarily. The idea of setting OPENEJB_BASE was to *add* to the > resources that are in OPENEJB_HOME. It's like in Tomcat where whatever > it's in CATALINA_BASE overwrites the counterparts in CATALINA_HOME.
Ok. The original code for openejb.base basicaly treated your base as yours, no inheriting, and used OPENEJB_HOME to find OpenEJB system libraries. The primary motive was avoiding having to copy OpenEJB system libraries all over the place--upgrade hell. In OpenEJB 0.9.2, this is what it does, though I don't think anyone is using it. It is possible to copy all the lib from OPENEJB_HOME/lib into WEB-INF/lib and just set OPENEJB_HOME to your webapp dir and forget about OPENEJB_BASE. It seems that having openejb.base aggregate from openejb.home this way implies to people that whatever they put in their webapp (openejb.base) is available just to them and anything in openejb.home is available to all webapps as is the case in a one OpenEJB for all webapps installation. When this isn't the case, the running EJB container is available only to the webapp. On this note, I'll say we actually could support the scenrio above, e.g. mixing global and per-webapp, but it seems that would really hurt people's brains. Maybe when people get very comfortable with the differences between global and per-webapp rules we might put that in. If we did, we'd either have to come up with new terminology for home/base or change the meaning of home/base. Anyway, what do users want? -David > > I wonder if people would appreciate if they could configure if > OPENEJB_HOME resources should be initialized, too. So, when > OPENEJB_BASE/lib exists, no OPENEJB_HOME/lib jars would be touched. > > >If you threw in something like Derby as an embedded database, you should > >be able to have your own mini-J2EE setup anywhere that offered Tomcat > >hosting. > > > >So to compare the two ways to use OpenEJB in Tomcat: > > > >SYSTEM = OpenEJB is loaded into Tomcat's common classloader. All webapps > >share the same EJB instances and have access to all the EJBs deployed in > >the system. There is one openejb.conf for the whole server. Webapps must > >not pack the EJB classes in their archive. EJBs cannot see the classes in > >your WEB-INF/lib and WEB-INF/classes directory, shared libraries must be > >put in Tomcat's common or system classloaders to be used by EJBS. > > > >WEBAPP = OpenEJB is loaded into the webapp classloader. Each webapp has > >it's own openejb.conf, EJBs, and EJB container. No other webapp can > >affect another's EJBs or EJB container. Webapps must pack the EJB jars in > >their archive. EJB's can access the libraries in your WEB-INF/classes and > >WEB-INF/lib directories. > > Few minutes ago I added a change so that OPENEJB_BASE behaves as the one > in Tomcat. > > As stated above, it's also possible to add support for specifing whether > the libs in OPENEJB_HOME should be taken into account, too. > > >A very nice aspect of the one OpenEJB per-webapp is that the EJB's become > >part of your webapp, so when your webapp is > >deployed/undeployed/redeployed, so are your EJBs. No hocus-pocus required > >stemming from managing ejbs and servlets seperately. > > > >Our existing docs refer the original way to load OpenEJB into Tomcat > > I made sure they reflect the current state of art. The > OPenEJB-per-webapp was tested against Tomcat 5.5.8-alpha with Java 5.0 > whereas OpenEJB was built with Java 1.4. A little mess is to ensure we > don't rely on a specific part of the runtime environment. > > >-David > > Jacek
