On Aug 20, 2007, at 12:54 PM, Karan Malhi wrote:
We'll probably need some logic like:
- if conf/logging.properties exists, use it
- if conf/ directory exists, install logging.properties and use it
- else assume embedded and use embedded.logging.properties
I did not use the embedded.logging.properties file because that file
writes all logging using ConsoleAppender's. So, I hard-coded the
configuration file in the Logger itself to write to
RollingFileAppender's. ConsoleAppenders are necessary for maven
builds, but I am still not comfortable with hard-coding the logging
configuration.
Could we probably have another file like build.logging.properties
which could be used by maven but not shipped in the final jar? This
way we can change embedded.logging.properties to write to the
RollingFileAppenders and the build.logging.properties could be used by
maven to write to the ConsoleAppender.
If we make the above change, then I could use ConfUtils.getResource to
get the embedded.logging.properties file and use it to generate the
defaults if the logging.properties is absent from the conf directory.
Let me know what you think?
We should just go with logging.properties for the one that will be
squirted into conf/ directory for the standalone server. For
anything embedded (could be more than just tests) we should stick
with embedded.logging.properties.
Both logging.properties and embedded.logging.properties would be text
files packed in the openejb-core.jar. Then we would follow the
proposed algorithm:
- if conf/logging.properties exists, use it
- if conf/ directory exists, install openejb-core.jar!/
logging.properties to conf/logging.properties and use it.
- else assume embedded and use openejb-core.jar!/
embedded.logging.properties
The logging.properties would be setup with file appenders similar to
the way the default.logging.properties was.
That make sense?
-David
