> 1. For Log4J at least, the wrapper class is 'given' to the logger > implementation via a constructor argument.
No, it is passed on each call. Log4j is the easiest, it has all the support we need. > 1.a. Log.setLogWrapper/setAttribute isn't enough. Putting aside > design/style arguments, it's to late. Granted this COULD be worked around The only reason for setAttribute on Log is that if we set the wrapper on the factory, this will be 'global'. In tomcat we have 2-3 wrappers that are used - and if each will use commons-logging we'll need to do some tricks. > 2. In an environment where we have multiple components using > commons-logging, some may wrap - others may not. A Factory.setAttribute > is dangerous here (it's potentially 'global' across multiple components). > Note also the the attributes are (pre-)loaded out of a properties file. I agree. > 3. We need an analogous method (setWrapper or setAttribute) for the > Discovery mechanism. A requirement for 'setWrapper' would seem to be > fairly specific to logging, it doesn't appear to be generally useful in a > 'discovery' tool. I don't think so - this is very specific to logging, it has nothing to do with discovery. > (2) is a strong vote for 'LogFactory.getInstance(Class wrapper, > [String|Class] cat)', in addition to the current 'getInstance' methods - > and a vote against a 'setAttribute' in a singleton (global) Factory. I think setAttribute on Log would solve (2). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
