debug level service attribute

[cjhowe]

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!

[David E Jones-2]

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!

[cjhowe]

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 <[hidden email]>
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!
>
>

[David E Jones-2]

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 <[hidden email]>
> 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!
>>
>>
>

[cjhowe]

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 <[hidden email]>
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 <[hidden email]>
> > 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!
> >>
> >>
> >
>
>

[David E Jones-2]

Sounds like fun. Do whatever works for you.

-David


On Dec 31, 2006, at 3:24 PM, Chris Howe wrote:

> 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 <[hidden email]>
> 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 <[hidden email]>
>>> 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!
>>>>
>>>>
>>>
>>
>>
>