I can't seem to get to
http://docs.codehaus.org/display/OPENEJB/HomeBaseDiscussion
I signed up, but when I try to access I get: "Not Permitted".
Lajos
David Blevins wrote:
Since this is a fairly important topic for users as they are the ones
who are the ultimate arbiters of what is simple or complex for them, I
decided to throw some information about this in our Confluence
(i.e. our wiki)
http://docs.codehaus.org/display/OPENEJB/HomeBaseDiscussion
The interpretation of home/base is a moving target, which is
understandable as I never really documented it. My bad!
Jacek, is that an accurate description of 1.0 home/base? Feel free to
update the doc. See my example at the end of the doc linked above and
let me know what your thoughts are.
Lajos, it looks like your proposal focuses on two things: not needing
an openejb.conf file; not needing a beans directory. It also seems
that your proposal is focused on a scenario where people don't want to
use a global openejb but still want all the webapps to share the same
ejb jar files don't want any ejbs in their own. I'm not sure what the
use case is for your scenario.
Avoiding the need for an openejb.conf file is something that has come
up and would be nice to do, but i think it's out of scope for OpenEJB
1.0. One idea kicked out to the group a long while back was to have
an alternate properties-based way of configuring OpenEJB. Then you
could rely on defaults and still have the ability to configure
resource adapters and locations of deployments, among other things. I
go into some pretty good detail that idea in this email:
http://www.mail-archive.com/[email protected]/msg00090.html
Just one idea of many possible approaches. More ideas always welcome.
As far as where the ejb come from, you get what you ask for in your
openejb.conf. We don't add or remove anything. You can have as many
<Deployemt...> elements in it as you like and set them to whatever you
like.
All that said, here is my take.
I would like to see the openejb.home/openejb.base functionality of
0.9.2 go back into 1.0--don't mind if we change the names of them to
be more clear. The original vision for a per-webapp scenario is that
each webapp wants their very own ejbs and doesn't want to share
anything. The exception to that rule might be the OpenEJB libraries
themselves, but even that is not a requirement. The use case is
people offering or using hosting services where each person gets their
own webapp space completely isolated from other users on the server.
Note that it still is possible to share ejb jar *files* across
webapps, just not ejb instances.
I do see the scenario where people want to mix a global and per-webapp
setup to have some sharing of ejb instances at runtime, but also want
each webapp to be able to have some of it's own ejb instances not
shared with others. That scenario would involve some pretty tricky
classloading rules and complete familiarity with the class visibility
and packaging rules of both global and per-webapp setups.
As always comments and feedback welcome. Developer's, user's, or anyone.
-David
On Fri, Mar 11, 2005 at 03:10:07PM -0700, Lajos wrote:
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
--
--
Lajos Moczar
----------------------------------------
Open Source Support, Consulting and Training
----------------------------------------
"The Open Source Monopoly"
www.galatea.com/opensource.html
Tomcat Unleashed
(www.amazon.com/exec/obidos/tg/detail/-/0672326361)
Cocoon Developer's Handbook
(www.amazon.com/exec/obidos/tg/detail/-/0672322579)
_ _____
/ \ /
/___\ /
/ \ /____
http://www.galatea.com -- powered by AzSSL
