Basic Logging
All logging in OpenEJB is done using the org.apache.openejb.util.Logger . This Logger is currently a wrapper around the Log4j Logger. You can obtain a Logger instance by calling its static getInstance(String category, String resource) method.
- This first argument to this method is a category. If you specify a category, make sure it starts with OpenEJB. So for example, one could have categories like OpenEJB.startup, or OpenEJB.startup.config.
- The second argument is the name of the package which contains the Messages.properties file. For example, below is a line showing how to obtain a Logger instance.
Logger logger = Logger.getInstance("OpenEJB.startup", "org.apache.openejb.util.resources");
The second argument specifies to look for Messages.properties file under org.apache.openejb.util.resources package.
Current Structure
Here is an extract from another email from David Blevins
Each module has a file called default.logging.conf. This file contains the definition of all Loggers, their appenders and warning levels. However, we do not use default.logging.conf first. The basic idea is that first we look for say conf/logging.conf in the openejb.base directory. If we don't find it there, we look for default.logging.conf in the classpath. If we did find default.logging.conf (which we should) and there is an openejb.base/conf/ directory then expand the default.logging.conf to openejb.base/conf/logging.conf where we expected to find the file in the first place. If there was no openejb.base/conf/ directory, then it's safe to assume we're running embedded (in a test case perhaps) and just use the default.logging.conf and do no extra work.
We have default.logging.conf which we use this way as well as default.openejb.conf and now more recently users.properties and groups.properties. We search on disk for the resource in openejb.base/conf/ if we don't find them we unpack the default one we stuffed in openejb-core jar and extract it to disk in the openejb.base/conf directory if there is one -- if there isn't one we just use the default file.
The basic ideas behind the pattern are that:
1. If you've messed up your configuration, just delete or rename the respective files in your conf/ directory and new (working) ones will magically appear.
2. When upgrading its nice that our zip file won't overwrite any existing files in conf/
3. If you're running embedded you don't have to setup any directories or have any config files, we can run on defaults.
The ConfUtils.getConfResource utility to do that pattern generically , but so far we're only using it for the users.properties and groups.properties files. We should be using it everywhere. Having the code in multiple places has lead to some inconsistencies such as we expand the default.openejb.conf file to conf/openejb.xml (not even the same file extension). We really don't need the "default" part in our file names and the lingering usage of the "conf" file extension is something that needs to go bye-bye -- we should use properties for properties files and xml for xml files, etc.
Back on the logging thing we added one extra complication, doFallbackConfiguration. At some point the regular measures stopped working in some situations and we added the "doFallbackConfiguration" which attempts to force at least a minimal configuration in the event of total failure. It's fine to have such a thing, but it's being used in situations where a logging file *should* be available.
