Lajos wrote: >[...] What I would like to see >is that in the per-webapp scenario, the config loads beans from >$OPENEJB_HOME/beans first, and then loads from WEB-INF/beans second. >This would be an easy way around the problem of needing a >webapp-specific openejb.xml just so you can specify your own local bean >directory.
Please allow me to contribute some perspective to this discussion. Do we want a two-tier or three-tier approach to our EJB resources? Here is a two-tier approach: 1. openejb.home 2. WEB-INF/lib Here is a three tier approach: 1. openejb.home. 2. openejb.base. 3. WEB-INF/lib Admittedly, a three-tier approach is more complicated than two-tier, more difficult to understand, document and trouble-shoot. Possible, it is more difficult to code and debug. And yet, it may be more flexible. Today, I face the following architectural puzzle. A three-tier approach might make it easier. We have developed a suite of web applications for internal deployment. We are using J2SDK 1.4, Tomcat 4 and OpenEJB 0.9.2 on Linux and Microsoft Windows. For a number of development and performance reasons, we do not maintain one giant web application. Rather, we maintain suite of web applications. Our web applications, including web services, are designed independently, tested independently, deployed and upgraded independently and secured with SSL independently. And yet, they appear seemless from the experience of the end-user. We want each web application to have an independent EJB container for maximum isolation, along with access to a common EJB container for sharing EJBs. We want to be more certain that what works in the lab is going to work in production. Here is what we have. Our web applications look alike, include the same single sign-on client for maintaining a common session, provide the same assumptions for our JSP/EJB programmers. We push common behavior into a custom class library. Almost every web application in our suite depends upon this library. Almost every EJB depends upon this library. So, we put one copy of the library in common/lib for Tomcat 4 and one copy in openejb/lib for OpenEJB. Within our team, this is certainly not without its problems. But, our library is used by other developers, too. They build their web application. We are un-able to deploy their web application and ours on the same instance of Tomcat 4. Two suites are no longer independent. Their installer overwrites our jar; our installer overwrites theirs. We cannot insist they use our installer. I suspect that a three-tier approach might enable us to take our jar out of openejb/lib and put it in an openejb.base. Each suite could have its own openejb.base and regain its independence. We would establish one openejb.base for our suite of web applications. They would establish an openejb.base for their suite. With openejb.home, openejb.base and WEB-INF/lib, all of our web applications might get along, but without duplicating jars. I suppose I'm asking for an approach that is more scale-able. For example, one of our EJBs maintains a whole lot of information about the web application. We need multiple instances, one for each web app because the properties are different, but our entire suite uses the same implementation of the EJB, ideally one jar for each computer. But, of course, all this should be without conflicting with other development groups. Why do we need many web applications when one giant web application would do? For one thing, security is our top priority. We can't afford mistakes. Our front-line security is based upon two-way SSL. It is far more reliable to set our front-line security independently at the web application level, this authentication is more easily proved. It is easier to mount an entire web application in Apache and configure it with mod_ssl directives. In turn, fine-grained authentication, authorization and privacy is the responsibility of each web application. On the other hand, we have two troublesome web applications, developed for us by vendors using the one-giant-web-application approach. In each case, it has taken months and months to see just the welcome page of a web application because all of it has to work for any of it to work. Even the two-tier per-webapp approach of OpenEJB would have greatly simplified their deployment. Thanks,
