This one time, at band camp, Edward Sumerfield said:
ES>I assume you are referencing this paragraph:
ES>
ES> Also missing from the Commons Logging system is any
ES> mechanism for configuring the various underlying logging
ES> systems. Even adjustments so basic as setting the logging
ES> threshold are impossible.
ES>
ES>The commons logging API doesn't supply a threshold setting features, but you
wouldn't want it to. If it did it would just be another API standard. Instead, it
supplies standard log writing methods with a simple threshold model. Its a thin proxy
to the locally installed logging API.
ES>
ES>In the webapp I am developing I use the JDK Logging package but all my log writes
use the commons logging API. At webapp initialization I use JDK Logging initialization
code but all the my packages and 99% of the packages I use also use commons logging.
Castor is the only one that we have to do this funky intercept class for.
ES>
ES>To dynamically change the threshold you just have to use the API supplied by your
logging facility. Since commons logging delegates all calls to your package your
changes are reflected in the output.
ES>
ES>The adapter is not ideal because it doesn't give us threshold control over caster
log messages. All messages are written with the logger.trace() method which delegates
to the JDK Logging.finest() method. If Castor used the commons logger then my logger
settings would have a more granular effect on the Caster log writes.
ES>
ES>The next problem with the adapter is that it force flushes after every write so
logging to a file is expensive. It would be better to manage the string buffer size
and only flush on some maximum.
ES>
ES>The last problem with this technique is that is that there is only one instance of
the adapter stored in one instance of a mapper and the single StringBuffer that it
wraps uses synchronized methods. Another expensive overhead.
ES>
ES>Taking on the commons logging API would delegate all these issues to the
implemented logger.
Maybe I'd be better off just using Log4J in Castor. I know that most of
the Open Source apps that I use make use of Log4J so I have no problem
with that. But we really need the ability to enable/disable logging on
a per package basis. Also, I really prefer Log4J's API. If I was to use
Log4J the only changes I'd need to make is adding the custom prefix.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
