On Jan 26, 2010, at 5:34 AM, freeway wrote:
Hi David and Jean-Louis,
First of all, I sent an earlier response to Jean-Louis that
apparently did
not make it to the forum, so I will repeat the text here.
Hi Jean-Louis,
Thanks very much for your quick response and interest in this
feature. It
is definitely a requirement for
our deployments, as OpenEJB will be supporting an application that
will
run in a shared Tomcat
environment at virtually all our customer sites.
Another benefit for many use cases would be quicker Tomcat startup
time,
and I have seen some posts
on this forum indicating that this is also important to some other
OpenEJB
users.
As to how it is implemented, I think the only firm requirement is
that it
be easily configurable at
deployment time. Off the top of my head, I would think that new
system
properties and/or openejb.xml
settings would make the most sense.
Again, let me know how I can help and what your plans are. I know
that we
would want to use this
feature to support OpenEJB deployments later this year.
David, your point about the libraries makes very good sense. In our
case,
for example, the application was consciously designed to encapsulate
all the
EJBs into a single JAR, so there would no point in having OpenEJB look
anywhere else. I haven't worked with EJBs enough to have an idea
what is
typical, but suspect that many well-packaged apps do something
similar. I
would think that this would also minimize the performance impact of
OpenEJB
on the overall environment. Our goal is to make OpenEJB as
unobstrusive a
part of the Tomcat stack as possible, affecting only those apps that
we want
it to affect.
Managing the settings in an XML file as you suggest would probably
be best.
Other things being equal, I would also prefer to extend an existing
config
file such as openejb.xml over adding a new one, in order to minimize
the
deployment complexity and number of configuration points that we
need to
worry about. One reason we have migrated our application into
Tomcat from
JBoss is to leverage the widely-used and much simpler Tomcat
environment, so
the fewer config files one needs to open in order to understand how
things
work, the better.
I wonder if some entries in the context.xml of the webapp isn't the
best way to go, a few <Parameter> entries for including/excluding jars
in the webapp or skipping the webapp altogether. Those can be defined
in Tomcat in a few different ways, IIRC. I'd have to look closer, but
I *think* we have access to those before we start doing our part of
the deployment.
Would something like that fit with your needs?
-David
