That's the one area that's handicapped by sticking to the "you touch it, you maintain it" approach to developing off Ofbiz. I try to do everything without touching ofbiz's code base.
Your personal approach wouldn't help in this debug scenario because I want the log message "service xyz started" "service xyz ended" for 98% of the services that are running. The problem is the remaining 2% of the services create 98% of the log. The only way to comment out the log entry is to disable it for every service. --- David E Jones <[EMAIL PROTECTED]> wrote: > > Well, personally in development I often comment out > or add log > statements to make things easier to track down. It's > pretty easy and > quick to change, build, and run. > > -David > > > On Dec 31, 2006, at 2:28 PM, Chris Howe wrote: > > > I like the log message in general. It's probably > the > > most useful debug message when trying to figure > out > > where a problem may lie in development. It's just > > certain common services I may run a thousand or > more > > times when iterating through a list and that's > going > > to end up being 2000 lines of debug messages > (roughly > > half a meg) where I'm fairly confident the problem > > doesn't lie. If I could find a way to prevent > those > > couple of services from announcing their presence, > > life would be grand :) > > > > The environment where this is a concern, is in > > development. > > > > --- David E Jones <[EMAIL PROTECTED]> > > wrote: > > > >> > >> There should be "info" level messages and I'd say > >> turn them off in > >> production and live with them in > >> development/testing. > >> > >> Or if enough people don't like them we can always > >> get rid of them... > >> > >> -David > >> > >> > >> On Dec 31, 2006, at 1:40 PM, Chris Howe wrote: > >> > >>> I find myself using certain services quite a lot > >> (ie > >>> partyNameFromDate when iterating through a large > >> data > >>> set) and would like it not to clutter up the log > >> with > >>> all of its service start/service end log > entries. > >> At > >>> the same time, I need to be able to see when > other > >>> services start/end. > >>> > >>> I've thought of a number of ways to handle this. > >> What > >>> are your thoughts (community)? > >>> > >>> 1. attribute for service tag defining the > service > >>> start/end level > >>> 2. attribute for element calling it (in simple > >> method > >>> <call-service/> or in screens <service/>) > >>> 3. attribute for either the service or the > service > >>> call that raises or lowers (+1, -1) the level of > >>> debugging for the entire service. > >>> 4. learn to continue living with the noisy log > >>> > >>> Thanks! > >> > >> > > > >
