DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20418.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I've now experimented with the changes to the logging system.
Before submitting patches etc, may I just confirm that the proposed changes
are OK?
==
All relevant files (except LoggingManager.java) are changed as follows:
import org.apache.log.Hierarchy;
becomes
import
Yeah, I looked at this briefly and recognized the same problem with the
classnames. although 1.8 is dependent on Java 1.4, 1.8.1 is not, and neither
is 1.9, and too many have let it be known they want to use Java 1.3, so...
Alternatively, these log variables could be instance instead of static
Thanks.
OK, I'll ensure my code only uses 1.3 facilities (my O'Reilly JavaNut is
only 1.3 anyway!)
[Though I would expect that requirement to have faded somewhat now...]
Not sure what you mean by keeping a hashtable in LoggingManager.
Doesn't LogKit return the same logger instance if the same
Oh, well I didn't know - never read much of the logkit docs. If that's true, then
there's no need for the log variables to be static in the first place. Remove the
static keyword and user this.getClass().getName().
-Mike
On 2 Jun 2003 at 17:03, BAZLEY, Sebastian wrote:
Thanks.
OK,
I am trying to extend JMeter to handle creating FTP sessions (one associated with each
thread from the Thread Group), and then performing either FTP 'put' or 'get' multiple
times with the single FTP session. What is the best approach, creating a controller
and extending Entry to carry the FTP
What I would do is extend JMeterContext to help you hold arbitrary objects
(JMeterContext
keeps information that belongs to a specific thread). Then you could use it to hold
your open
session and your FTPClient could retrieve the session, use it, and forget about it.
-Mike
On 2 Jun 2003 at
