I have completed the work of moving DAS RBD logging to use log4J as it's logging framework and a patch was attached to TUSCANY-441. I have also completed the performance enhancements where all logging is preceed by a check if log is currently turned on, to avoid creating unecessary objects/string objects on the server.
I still have two things left to complete : - check how i can wire das log4j usage with a log4j config file - document in our wiki how log works and how users can turn on/off or add new appenders Luciano On 8/25/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
Yes. I aggree, and this goes to our logging "policy" and patterns. Luciano Resende wrote: > Also, as we are planning to change our DAS logging code, we should also > consider performance enhancements on that area. Today, I see various > places > where we are doing log like this: > > DebugUtil.debugln(getClass(), debug, "Adding table/column: " + > typeName + > "/" + propertyName); > > And I would recommend having something like this : > > if( logger.isDebugEnabled) > logger.debugln(getClass(), debug, "Adding table/column: " + > typeName > + "/" + propertyName); > > The problem with current code related to performance and garbage > collection, > is that, even if debug is not enabled, lot's of strings are created > (e.g"Adding table/column: " + typeName + "/" + propertyName) and will > need to be > garbage collected slowing server performance. > > This is a good tip for all other areas of Tuscany, altough I haven't > investigated other areas in detail. > > - Luciano > > > On 8/24/06, Kevin Williams <[EMAIL PROTECTED]> wrote: > >> >> My poor choice of wording. I really meant "any concerns" rather than >> "any objections". Thanks again! >> >> Jim Marino wrote: >> >> > >> > On Aug 23, 2006, at 8:05 PM, Kevin Williams wrote: >> > >> >> Thanks for your input. I enjoyed the "evils of common logging" link. >> >> >> >> So, if we avoid JCL then my next suggestion would be to use either >> >> Java logging or log4j directly and our users will need to deal with >> >> the -- possibly -- separate logging system. Are there any >> >> objections to this route? >> >> >> > Hopefully you didn't think I was "objecting" to using clogging (it's >> > the DAS peoples' decision) but was just trying to save you the pain I >> > had using that. Not knowing all of the requirements I would probably >> > do one of the following: >> > >> > 1. Use log4j and for people that wanted to use DAS with another >> > logging solution have them add an appender that pipes the information >> > somewhere else >> > >> > 2. Externalize logging like SCA. The bootstrap would provide a >> > MonitorFactory implementation that would be responsible for creating >> > implementations of a specific logging interface. You could create an >> > environment property that points to the factory impl to instantiate >> > and have a constructor that takes an instance. The factory could then >> > delegate to something else and you could have a default that uses >> > reflection and sends everything to Log4J. This has the advantage of >> > allowing for strongly typed logging as well as not forcing things to >> > go through log4j (which may not be that big of a deal). Each >> > subsystem would be responsible for using the monitor factory to >> > create monitor implementations for particular components. >> > >> > Jim >> > >> >> Thanks, >> >> >> >> --Kevin >> >> >> >> >> >> Jim Marino wrote: >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> > >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ----------------------------------------------------- Luciano Resende SOA Opensource - Apache Tuscany -----------------------------------------------------
