RE: Logging suggestions

[BAZLEY, Sebastian]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 30 May 2003 13:12
> To: JMeter Developers List
> Subject: RE: Logging suggestions
> 
> 
> On 30 May 2003 at 11:41, BAZLEY, Sebastian wrote:
> 
> > For most source files, the changes to convert to Commons 
> Logging would be
> > very similar to those needed to tidy up the logging 
> categories, which is why
> > I thought it might be useful to consider.
> 
> *shrug* seems like more work than is necessary.  More jars 
> added.  Flexibility for flexibility's 
> sake, and all that.

Point taken.

> I was thinking of a GUI option, but command-line is fine too, 
> though it'll be a bit limited (how 
> many categories are you going to want to set, after all?).

True, but could be useful at the protocol level for example.
Also depends on what is set as a default - I was thinking of setting "root"
to INFO and leaving it at that.

> > 
> > By the way, LoggingManager seems to be in jorphan.jar, 
> which strikes me as a
> > bit odd.
> 
> Where else?  The jorphan stuff is all the non-jmeter specific 
> classes - stuff that might one day 
> make it to the Jakarta Commons area ideally.

My misunderstanding.
I had assumed jorphan was only for compatibility with older JREs, with the
idea of dropping it eventually.

Sebastian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Logging suggestions

[BAZLEY, Sebastian]

OK - (I don't mind if my patches are not eventually used by the
committer(s))

By the way, only 25 or so of the files call LoggingManager.getLoggerFor().
The rest call Hierarchy.getDefaultHierarchy().getLoggerFor().

So as well as replacing the strings, one needs to replace:
import org.apache.log.Hierarchy;
by
import org.apache.jorphan.logging.LoggingManager;

If only Eclipse had a batch editor ...

Sebastian
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 30 May 2003 13:33
To: JMeter Developers List
Subject: Re: Logging suggestions


On 30 May 2003 at 14:15, Jeremy Arnold wrote:

> Hello,
>[snip]
> For making changes to the call to getLoggerFor( ) for all of the 
> classes, it might be easier for one of the committers to do this 
> directly, rather than dealing with patches.  

That's very true.  

-Mike


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Logging suggestions

[mstover1]

On 30 May 2003 at 14:15, Jeremy Arnold wrote:

> Hello,
>[snip]
> For making changes to the call to getLoggerFor( ) for all of the 
> classes, it might be easier for one of the committers to do this 
> directly, rather than dealing with patches.  

That's very true.  

-Mike

> 
> BAZLEY, Sebastian wrote:
> 
> >Yes, thanks, agreed - that would simplify/rationalise the logging using
> >Avalon logkit.
> >
> >But it would not allow the use of LOG4J or Java 1.4 logging without
> >edit/recompile, AFAIK.
> >For most source files, the changes to convert to Commons Logging would be
> >very similar to those needed to tidy up the logging categories, which is why
> >I thought it might be useful to consider.
> >
> >But I am happy to stick with LogKit if everyone else is.
> >[One could always do the Commons Logging change later - it would be simple
> >using Eclipse!]
> >
> >I would like to be able to change the logging level without having to edit
> >the properties file.
> >I can contribute a patch to add a command line option to do this (calling
> >the LoggingManager method).
> >
> >I'll try and get some patches out this weekend.
> >
> >The changes to getLoggerFor() could be done as one or more patch files -
> >which is easiest for the commiters? 
> >One giant patch, one per file, or perhaps one per functional area (core,
> >protocol etc)?
> >
> >By the way, LoggingManager seems to be in jorphan.jar, which strikes me as a
> >bit odd.
> >  
> >
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 



--
Michael Stover
[EMAIL PROTECTED]
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Logging suggestions

[Jeremy Arnold]

Hello,
   I don't have a strong opinion about this, although personally I like 
Log4J.  However, my general opinion is that using Commons Logging is 
great for library code, since this makes it possible to use the same 
logging setup for several libraries used by one application.  But when 
working with a particular application, there doesn't seem to be a lot of 
benefit in being able to use multiple different logging systems -- it 
doesn't have to interoperate, so as long as it has the basic 
functionality, then the exact logging system in use doesn't matter much.

   So I don't see a big need to switch to Commons Logging for JMeter.  
But I could be convinced otherwise.

   For making changes to the call to getLoggerFor( ) for all of the 
classes, it might be easier for one of the committers to do this 
directly, rather than dealing with patches.  I would be willing to do 
this part of it if you'd like...although it may take me a few days to 
get through itmy wife and I just had a baby about a week ago 
(pictures up at http://xirr.com/~jeremy_a/family/kajsa.html), and we 
have family here and things.

Jeremy

BAZLEY, Sebastian wrote:

Yes, thanks, agreed - that would simplify/rationalise the logging using
Avalon logkit.
But it would not allow the use of LOG4J or Java 1.4 logging without
edit/recompile, AFAIK.
For most source files, the changes to convert to Commons Logging would be
very similar to those needed to tidy up the logging categories, which is why
I thought it might be useful to consider.
But I am happy to stick with LogKit if everyone else is.
[One could always do the Commons Logging change later - it would be simple
using Eclipse!]
I would like to be able to change the logging level without having to edit
the properties file.
I can contribute a patch to add a command line option to do this (calling
the LoggingManager method).
I'll try and get some patches out this weekend.

The changes to getLoggerFor() could be done as one or more patch files -
which is easiest for the commiters? 
One giant patch, one per file, or perhaps one per functional area (core,
protocol etc)?

By the way, LoggingManager seems to be in jorphan.jar, which strikes me as a
bit odd.
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Logging suggestions

[mstover1]

On 30 May 2003 at 11:41, BAZLEY, Sebastian wrote:

> Yes, thanks, agreed - that would simplify/rationalise the logging using
> Avalon logkit.
> 
> But it would not allow the use of LOG4J or Java 1.4 logging without
> edit/recompile, AFAIK.
> For most source files, the changes to convert to Commons Logging would be
> very similar to those needed to tidy up the logging categories, which is why
> I thought it might be useful to consider.

*shrug* seems like more work than is necessary.  More jars added.  Flexibility for 
flexibility's 
sake, and all that.

> 
> But I am happy to stick with LogKit if everyone else is.
> [One could always do the Commons Logging change later - it would be simple
> using Eclipse!]
> 
> I would like to be able to change the logging level without having to edit
> the properties file.
> I can contribute a patch to add a command line option to do this (calling
> the LoggingManager method).

I was thinking of a GUI option, but command-line is fine too, though it'll be a bit 
limited (how 
many categories are you going to want to set, after all?).

> 
> I'll try and get some patches out this weekend.
> 
> The changes to getLoggerFor() could be done as one or more patch files -
> which is easiest for the commiters? 
> One giant patch, one per file, or perhaps one per functional area (core,
> protocol etc)?

One per functional area seems like a good way to go.

> 
> By the way, LoggingManager seems to be in jorphan.jar, which strikes me as a
> bit odd.

Where else?  The jorphan stuff is all the non-jmeter specific classes - stuff that 
might one day 
make it to the Jakarta Commons area ideally.

-Mike

> 
> Sebastian
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 29 May 2003 20:24
> To: JMeter Developers List
> Subject: RE: Logging suggestions
> 
> 
> There is a LoggingManager class in the jorphan code that I use that's really
> simple, and it has 
> a public method you can call to change the priority for any category at
> runtime.  It just needs 
> to be made static and you have exactly what you want.
> 
> Furthermore, all classes currently have some code that looks like this:
> transient private static Logger log =
> LoggingManager.getLoggerFor("jmeter.engine");
> 
> Rather than this line of code, it could be:
> private static Logger log =
> LoggingManager.getLoggerFor(this.getClass().getName());
> 
> Replacing all the code is long and tedious, but not particularly dangerous.
> Just don't do any 
> reformatting of classes while your doing it, and you're not likely to
> interfere with anyone else 
> (and no one's particularly active right now, it seems).
> 
> Then the categories need to be adjusted in JMeter.properties to reflect
> package names.  
> There's no need to set lines in JMeter.properties for every class, but just
> some key packages 
> (since it's hierarchical and sub-packages and classes will inherit from
> parent package 
> settings), and maybe a line or two describing how to micro-manage the
> logging, for those 
> interested.
> 
> -Mike
> 
> 
> On 29 May 2003 at 18:41, BAZLEY, Sebastian wrote:
> 
> > Given that changing the logging category would mean changes to all source
> > files that use logs, it seems to me that it might be worth taking the
> > opportunity to start using the Commons Logging wrapper interface.
> > 
> > This offers more flexibility, e.g. choice of logging package at run-time.
> > 
> > But it does add an extra method call.
> > 
> > If others think it is useful, I can pursue this further (with the aim of
> > providing patches).
> > 
> > S.
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: 22 May 2003 20:09
> > To: JMeter Developers List
> > Subject: Re: Logging suggestions
> > 
> > 
> > It all sounds reasonable.  Actually, the way logging is setup now, we
> should
> > 
> > just the fully qualified classname as the logging category, because I've
> > made 
> > logging work hierarchically.  In other words, if you say logging is at the
> 
> > DEBUG level for org.apache.jmeter.engine, then it will be that for 
> > org.apache.jmeter.engine.StandardJMeterEngine as well.  But, you could
> also 
> > override the setting for individual classes, if that was your choice.  The
> > amount 
> > of change wouldn't be that much - updating the log initializers and
> changing
> > 
> > the properties file.
> > 
> > And I have no problem updating the logkit.  
> > 
> > -Mike
> > 
> > On 22 May 2003 at 17:20, BAZLEY, Sebastian wrote:
> > 
> > > Some thought on enhancements to logging - just wondering if anyone else
> > > concurs/disagrees.
> > > [If there is general agreement, I can contribute patches.]
> > > 
> > > * The log format is fixed in LoggingManager.java; recompilation is
> needed
> > to
> > > change this.
> > > 
> > > I would like at least to change %{priority} to %5.5{priority} so that
> e.g.
> > > WARN and DEBUG messages are aligned in the log file.
> > > It would be useful if

RE: Logging suggestions

[BAZLEY, Sebastian]

Yes, thanks, agreed - that would simplify/rationalise the logging using
Avalon logkit.

But it would not allow the use of LOG4J or Java 1.4 logging without
edit/recompile, AFAIK.
For most source files, the changes to convert to Commons Logging would be
very similar to those needed to tidy up the logging categories, which is why
I thought it might be useful to consider.

But I am happy to stick with LogKit if everyone else is.
[One could always do the Commons Logging change later - it would be simple
using Eclipse!]

I would like to be able to change the logging level without having to edit
the properties file.
I can contribute a patch to add a command line option to do this (calling
the LoggingManager method).

I'll try and get some patches out this weekend.

The changes to getLoggerFor() could be done as one or more patch files -
which is easiest for the commiters? 
One giant patch, one per file, or perhaps one per functional area (core,
protocol etc)?

By the way, LoggingManager seems to be in jorphan.jar, which strikes me as a
bit odd.

Sebastian
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 29 May 2003 20:24
To: JMeter Developers List
Subject: RE: Logging suggestions


There is a LoggingManager class in the jorphan code that I use that's really
simple, and it has 
a public method you can call to change the priority for any category at
runtime.  It just needs 
to be made static and you have exactly what you want.

Furthermore, all classes currently have some code that looks like this:
transient private static Logger log =
LoggingManager.getLoggerFor("jmeter.engine");

Rather than this line of code, it could be:
private static Logger log =
LoggingManager.getLoggerFor(this.getClass().getName());

Replacing all the code is long and tedious, but not particularly dangerous.
Just don't do any 
reformatting of classes while your doing it, and you're not likely to
interfere with anyone else 
(and no one's particularly active right now, it seems).

Then the categories need to be adjusted in JMeter.properties to reflect
package names.  
There's no need to set lines in JMeter.properties for every class, but just
some key packages 
(since it's hierarchical and sub-packages and classes will inherit from
parent package 
settings), and maybe a line or two describing how to micro-manage the
logging, for those 
interested.

-Mike


On 29 May 2003 at 18:41, BAZLEY, Sebastian wrote:

> Given that changing the logging category would mean changes to all source
> files that use logs, it seems to me that it might be worth taking the
> opportunity to start using the Commons Logging wrapper interface.
> 
> This offers more flexibility, e.g. choice of logging package at run-time.
> 
> But it does add an extra method call.
> 
> If others think it is useful, I can pursue this further (with the aim of
> providing patches).
> 
> S.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 22 May 2003 20:09
> To: JMeter Developers List
> Subject: Re: Logging suggestions
> 
> 
> It all sounds reasonable.  Actually, the way logging is setup now, we
should
> 
> just the fully qualified classname as the logging category, because I've
> made 
> logging work hierarchically.  In other words, if you say logging is at the

> DEBUG level for org.apache.jmeter.engine, then it will be that for 
> org.apache.jmeter.engine.StandardJMeterEngine as well.  But, you could
also 
> override the setting for individual classes, if that was your choice.  The
> amount 
> of change wouldn't be that much - updating the log initializers and
changing
> 
> the properties file.
> 
> And I have no problem updating the logkit.  
> 
> -Mike
> 
> On 22 May 2003 at 17:20, BAZLEY, Sebastian wrote:
> 
> > Some thought on enhancements to logging - just wondering if anyone else
> > concurs/disagrees.
> > [If there is general agreement, I can contribute patches.]
> > 
> > * The log format is fixed in LoggingManager.java; recompilation is
needed
> to
> > change this.
> > 
> > I would like at least to change %{priority} to %5.5{priority} so that
e.g.
> > WARN and DEBUG messages are aligned in the log file.
> > It would be useful if the format string could be over-ridden by a Jmeter
> > property or similar.
> > 
> > * Logging categories are rather broad - for example jmeter.elements 
> includes
> > lots of different classes.
> > Might it not be clearer to use the package name (without org.apache.)? 
> > [Could probably create a utility function to generate the package name
> > automatically.]
> > 
> > This would obviously entail quite a few code changes, but they could be
> > automated or introduced gradually.
> > 
> > * A more recent version (1.2) of Avalon Logkit is available - would it
> make
> > sense to use that instead of 1.0.1? {as far as I can make out, there are
> no
> > changes that would affect JMeter, but there are a few bug fixes).
> 
> 

DO NOT REPLY [Bug 20181] - Webservice that require text/xml encoding doesn't work correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20181

Webservice that require text/xml encoding doesn't work correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-05-30 05:47 ---
I wrote a basic webservice sampler using apache soap driver. I've tested it with
IIS webservice and it works. more testing is needed to make sure it works with
other webservice engines.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20181] - Webservice that require text/xml encoding doesn't work correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20181

Webservice that require text/xml encoding doesn't work correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-05-30 05:46 ---
Created an attachment (id=6565)
gui for webservice sampler

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20181] - Webservice that require text/xml encoding doesn't work correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20181

Webservice that require text/xml encoding doesn't work correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-05-30 05:46 ---
Created an attachment (id=6564)
web service sampler

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Logging suggestions

[mstover1]

There is a LoggingManager class in the jorphan code that I use that's really simple, 
and it has 
a public method you can call to change the priority for any category at runtime.  It 
just needs 
to be made static and you have exactly what you want.

Furthermore, all classes currently have some code that looks like this:
transient private static Logger log = LoggingManager.getLoggerFor("jmeter.engine");

Rather than this line of code, it could be:
private static Logger log = LoggingManager.getLoggerFor(this.getClass().getName());

Replacing all the code is long and tedious, but not particularly dangerous.  Just 
don't do any 
reformatting of classes while your doing it, and you're not likely to interfere with 
anyone else 
(and no one's particularly active right now, it seems).

Then the categories need to be adjusted in JMeter.properties to reflect package names. 
 
There's no need to set lines in JMeter.properties for every class, but just some key 
packages 
(since it's hierarchical and sub-packages and classes will inherit from parent package 
settings), and maybe a line or two describing how to micro-manage the logging, for 
those 
interested.

-Mike


On 29 May 2003 at 18:41, BAZLEY, Sebastian wrote:

> Given that changing the logging category would mean changes to all source
> files that use logs, it seems to me that it might be worth taking the
> opportunity to start using the Commons Logging wrapper interface.
> 
> This offers more flexibility, e.g. choice of logging package at run-time.
> 
> But it does add an extra method call.
> 
> If others think it is useful, I can pursue this further (with the aim of
> providing patches).
> 
> S.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 22 May 2003 20:09
> To: JMeter Developers List
> Subject: Re: Logging suggestions
> 
> 
> It all sounds reasonable.  Actually, the way logging is setup now, we should
> 
> just the fully qualified classname as the logging category, because I've
> made 
> logging work hierarchically.  In other words, if you say logging is at the 
> DEBUG level for org.apache.jmeter.engine, then it will be that for 
> org.apache.jmeter.engine.StandardJMeterEngine as well.  But, you could also 
> override the setting for individual classes, if that was your choice.  The
> amount 
> of change wouldn't be that much - updating the log initializers and changing
> 
> the properties file.
> 
> And I have no problem updating the logkit.  
> 
> -Mike
> 
> On 22 May 2003 at 17:20, BAZLEY, Sebastian wrote:
> 
> > Some thought on enhancements to logging - just wondering if anyone else
> > concurs/disagrees.
> > [If there is general agreement, I can contribute patches.]
> > 
> > * The log format is fixed in LoggingManager.java; recompilation is needed
> to
> > change this.
> > 
> > I would like at least to change %{priority} to %5.5{priority} so that e.g.
> > WARN and DEBUG messages are aligned in the log file.
> > It would be useful if the format string could be over-ridden by a Jmeter
> > property or similar.
> > 
> > * Logging categories are rather broad - for example jmeter.elements 
> includes
> > lots of different classes.
> > Might it not be clearer to use the package name (without org.apache.)? 
> > [Could probably create a utility function to generate the package name
> > automatically.]
> > 
> > This would obviously entail quite a few code changes, but they could be
> > automated or introduced gradually.
> > 
> > * A more recent version (1.2) of Avalon Logkit is available - would it
> make
> > sense to use that instead of 1.0.1? {as far as I can make out, there are
> no
> > changes that would affect JMeter, but there are a few bug fixes).
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 



--
Michael Stover
[EMAIL PROTECTED]
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

RE: Logging suggestions

[BAZLEY, Sebastian]

Given that changing the logging category would mean changes to all source
files that use logs, it seems to me that it might be worth taking the
opportunity to start using the Commons Logging wrapper interface.

This offers more flexibility, e.g. choice of logging package at run-time.

But it does add an extra method call.

If others think it is useful, I can pursue this further (with the aim of
providing patches).

S.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 22 May 2003 20:09
To: JMeter Developers List
Subject: Re: Logging suggestions


It all sounds reasonable.  Actually, the way logging is setup now, we should

just the fully qualified classname as the logging category, because I've
made 
logging work hierarchically.  In other words, if you say logging is at the 
DEBUG level for org.apache.jmeter.engine, then it will be that for 
org.apache.jmeter.engine.StandardJMeterEngine as well.  But, you could also 
override the setting for individual classes, if that was your choice.  The
amount 
of change wouldn't be that much - updating the log initializers and changing

the properties file.

And I have no problem updating the logkit.  

-Mike

On 22 May 2003 at 17:20, BAZLEY, Sebastian wrote:

> Some thought on enhancements to logging - just wondering if anyone else
> concurs/disagrees.
> [If there is general agreement, I can contribute patches.]
> 
> * The log format is fixed in LoggingManager.java; recompilation is needed
to
> change this.
> 
> I would like at least to change %{priority} to %5.5{priority} so that e.g.
> WARN and DEBUG messages are aligned in the log file.
> It would be useful if the format string could be over-ridden by a Jmeter
> property or similar.
> 
> * Logging categories are rather broad - for example jmeter.elements 
includes
> lots of different classes.
> Might it not be clearer to use the package name (without org.apache.)? 
> [Could probably create a utility function to generate the package name
> automatically.]
> 
> This would obviously entail quite a few code changes, but they could be
> automated or introduced gradually.
> 
> * A more recent version (1.2) of Avalon Logkit is available - would it
make
> sense to use that instead of 1.0.1? {as far as I can make out, there are
no
> changes that would affect JMeter, but there are a few bug fixes).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]