On Jan 29, 2010, at 5:17 PM, freeway wrote:
Hi David,
Yes, context.xml is the logical place to configure webapp-specific
settings
that OpenEJB needs to see. I know that OpenEJB uses (or can use)
several
other XML files located in the webapp: ejb-jar.xml, persistence.xml,
service-jar.xml. However, the first two of these files have more
specific
purposes and should probably be kept compatible with other application
server environments that use them; and my understanding of service-
jar.xml
is that it is intended to specify overrides to internal OpenEJB
processing
that most implementers should not need. The new settings concern the
'context' of how the webapp interoperates with OpenEJB, and that
fits nicely
with the purpose of context.xml.
One variation of this approach might be to use context.xml to
configure
those libraries to be scanned within the webapp, while using <Tomcat
home>/conf/openejb.xml to specify which webapps should be scanned.
Implementers could enable/disable the various webapps at a high
level and
see the settings in one central location. Fine-tuning the JARs to be
covered in each webapp would be done separately. However, this
approach has
the disadvantage of splitting what is probably in practice a single
configuration decision into several different places. So overall,
perhaps
your idea is best.
Agreed. Splitting the sources of config information is best avoided.
Too easy to lose a few days to a simple typo in the webapp name in the
"second" source of information.
Context.xml is probably the way to go.
Made a couple JIRAs for the functionality in question so you can use
the JIRA "Watch It" functionality if you like:
https://issues.apache.org/jira/browse/OPENEJB-1231
https://issues.apache.org/jira/browse/OPENEJB-1230
-David
