> 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 suppose the easiest way to pull that off is to slurp in the
> ConfUtils.getConfResource method and modify the algorithm.
Thanks David, this really helps.
I have also thinking about it a little bit, did'nt devote too much
time. Having read some of your past posts on how the
logging.properties file is magically recreated when a user deletes it
or renames it has been kind of a blocker. Here is the reason:
To obtain the effect of magical creation of the logging.properties
file on rename or deletion, we would need to constantly poll for this
file (something similar to what we discussed with hotdeploy and the
DirectoryMonitor you wrote for that). I could not find that code
depicting this behaviour in OpenEJB for Logging. Part of the reason is
that i never really spent too much time digging into the code for
this.
Assuming the code was not in there, I considered some options:
1. Each time we obtain a Logger we check for the presence of this file
in the conf directory and make sure it has not changed . This will be
too expensive
2. Register Logging as a service started off by a separate thread,
this would then poll to check if the conf/logging.properties file
a. has changed , OR
b.has been deleted
If any of the above is true, reconfigure LogManager and also
clean up the Loggers cache to change Log Levels and appenders for
various Loggers already in cache. We could set a system property for
the poll interval and allow the user to configure it, or just hard
code the default.
3. Don't worry about 1 and 2 above and go with the strategy that if
the user changes or deletes this file, or if the file is absent in the
first place, then **on restart of the server**, the file magically
re-appears. Option 1 and 2 go with the assumption that user **does not
restart the server** .
Option 3 is comparatively the easiest and the quickest to implement ,
because I can simply update Log4jConfigUtils with the logic you
provided in your email. Actually, I am most probably going to get rid
of the Logger.init() , Logger.initialize() and Log4jConfigUtils, so
that the only interaction with the Logger is through the getInstance
and the log methods (info, error etc)
On 8/8/07, David Blevins <[EMAIL PROTECTED]> wrote:
> On Aug 4, 2007, at 10:33 PM, David Blevins wrote:
> > Just a note, seems in the standalone server most the log messages
> > wind up in system.out and not in the logs/openejb.log file. It's
> > totally cool if we have one log setup for embedded stuff (maven
> > building, etc.) and a different one for the standalone server.
>
> I applied OPENEJB-626, so we have great logging behavior for the
> embedded scenario. We still need to get a new logging setup for the
> standalone server -- they're still using the same log config.
>
>
> Fyi, to check out the server logging you can build with assemblies on
> and use the quick little 'try.sh' script that simply unpacks and
> starts the server to save some typing.
>
> $ mvn clean install -Dassemble
> $ ./assembly/openejb-standalone/try.sh
>
>
> -David
>
>
>
--
Karan Singh Malhi
