RE: Deprecation of setTime()

["BAZLEY, Sebastian" <se...@atosorigin.com>]

[This is really a JMeter Development question, so replying there.]

One reason for doing this was to centralise all the time handling in one
place.
So if there was a more accurate timer available, this could be used instead
of the default system timer.

It also means that samplers did not have to do the time calculations, and it
made it easy to switch between using initial and final time-stamps.

There are no plans to remove the method.

S.
-----Original Message-----
From: Finch, Sam [mailto:SFinch@espeed.co.uk]
Sent: 25 May 2004 14:03
To: 'JMeter Users List'
Subject: Deprecation of setTime()


Hi

What's the logic behind deprecating this method in JMeter 2.0.0?

   void org.apache.jmeter.samplers.SampleResult.setTime(long elapsed)

I use it in circumstances where the elapsed time is returned by an object
several calls deeper in the stack.  Using sampleStart() / sampleEnd() would
cause a distortion in this case.  I would prefer not to use SampleResult
deeper in the call stack as I am trying to decouple JMeter from the core
logic of out test framework.

I realise that this creates a disparity between sample times and throughput
but this is acceptable for us.

TIA for any help.

Sam


http://www.espeed.co.uk
CONFIDENTIAL: This e-mail, including its contents and attachments, if any,
are confidential. If you are not the named recipient please notify the
sender and immediately delete it. You may not disseminate, distribute, or
forward this e-mail message or disclose its contents to anybody else.
Copyright and any other intellectual property rights in its contents are the
sole property of eSpeed, Inc and its affiliates.

This e-mail was issued by eSpeed International Limited ("eSpeed").  eSpeed
is a limited liability company incorporated under the laws of England
(company number 3809189 and VAT registration number 577 406809).  eSpeed's
registered office is at One America Square, London EC3N 2LS.  For any issues
arising from this email please reply to the sender.

E-mail transmission cannot be guaranteed to be secure or error-free. The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.

Although we routinely screen for viruses, addressees should check this
e-mail and any attachments for viruses. We make no representation or
warranty as to the absence of viruses in this e-mail or any attachments.
Please note that to ensure regulatory compliance and for the protection of
our customers and business, we may monitor and read e-mails sent to and from
our server(s). 


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


___________________________________________________________________________

This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail in
error, please notify the sender immediately and destroy it. As its integrity
cannot be secured on the Internet, the Atos Origin group liability cannot be
triggered for the message content. Although the sender endeavours to maintain
a computer virus-free network, the sender does not warrant that this
transmission is virus-free and will not be liable for any damages resulting
from any virus transmitted. 
___________________________________________________________________________


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org