On Aug 8, 2007, at 3:45 AM, 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 suppose the easiest way to pull that off is to slurp in the
ConfUtils.getConfResource method and modify the algorithm.

[...]
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.

Sorry, your option 3 is what i meant -- on startup when we read the config files.

I'm attempting to document some of these behaviors here:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/assembly/ openejb-standalone/src/main/conf/README.txt

Here i manage to add "startup" but don't explicitly say only on startup. I'll fix that. Love getting this stuff documented and even refined. Our release is going to be awesome.

Hey, did you see a user created an faq wiki page that basically says "document this", no doubt he saw one of the ones you added and took the liberty to do the same. Very excellent!

http://cwiki.apache.org/confluence/display/OPENEJB/faq_openejb- jar.html

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)

That sound fine to me. I don't know how that code got so bulky. You've trimmed it down some already. After this last fix it's finally going to be lean and mean like it should be.

-David



Reply via email to