Best not to post attachments or patches to the mailing list.
They may get removed, mangled or just lost amongst the other messages.
It's much easier to keep track of patches via Bugzilla.
Please create a Bugzilla issue (enhancement) and attach the patch file to
that. An e-mail will automatically
There are currently two versions that are being worked on: HEAD and REL-2_0.
In both, HTTPSampler2 is the version of the sampler that uses Apache
HTTPClient rather than the default JVM HTTP protocol handlers.
I'm hoping to find some time to combine the two samplers. [In the meantime I
have been
is deliverd properly, I can always find the
latest src code.)
Thanks, Dolf
- Original Message -
From: BAZLEY, Sebastian [EMAIL PROTECTED]
To: 'JMeter Developers List' [EMAIL PROTECTED]
Sent: Thursday, July 08, 2004 13:38
Subject: RE: 2.0 branching, how to use latest sourcecode with anoncvs
You just need to check out the branch named rel-2_0.
How you do this depends on your CVS client.
S.
-Original Message-
From: Dolf Smits [mailto:[EMAIL PROTECTED]
Sent: 08 July 2004 08:47
To: JMeter Developers List; [EMAIL PROTECTED]
Subject: Re: 2.0 branching, how to use latest sourcecode
-Mike
On Thu, 2004-07-08 at 06:28, BAZLEY, Sebastian wrote:
You just need to check out the branch named rel-2_0.
How you do this depends on your CVS client.
S.
-Original Message-
From: Dolf Smits [mailto:[EMAIL PROTECTED]
Sent: 08 July 2004 08:47
To: JMeter Developers List
, when that's working right it would be a simple class
replacement.
If this approch sounds reasonable, let me know and I will start to pull
together what would have to change (and learn how the commons.net stuff does
it's IO)
Thanks
Jon.
-Original Message-
From: BAZLEY, Sebastian [mailto
It is easy enough to enhance the Sample Result class(es) to include fields
to hold the extra information, and some of it is easy to collect, e.g. the
sizes.
However, some of the timings may not be available without changes to the
underlying http protocol. This will need to be investigated - maybe
The recent JMeter Gump failures appear to be a problem with a particular
Gump installation [gump.try.sybase.com], not Jmeter, so can be ignored for
now. Other Gump builds are OK.
Sebastian
-Original Message-
From: Gump-build [mailto:[EMAIL PROTECTED]
Sent: 18 June 2004 01:47
To: [EMAIL
If this were to be adopted, it would have to be optional, and a way would
have to be found that did not involve unconditionally waiting for a set time
(e.g. use a barrier technique as described in Java Threads pub. by
O'Reilly).
There will always be startup overheads.
One way to minimize these is
OK: I saw the Gump mails already, and updated the descriptor which has
hopefully fixed the problems.
In case of interest, the two problems were:
1) Gump uses project names for dependencies, rather than jar names.
The depend reference was changed to point to the xml-batik project.
2) the
--- BAZLEY, Sebastian
[EMAIL PROTECTED] wrote:
Unfortunately, adding a new jar (or changing a
version) means updating quite
a few files:
In Jmeter project:
build.xml
and ideally:
eclipse.classpath
lib/jar_usage.txt
In Gump project:
project/jakarta-jmeter.xml
and/or
project/jakarta
Unfortunately, adding a new jar (or changing a version) means updating quite
a few files:
In Jmeter project:
build.xml
and ideally:
eclipse.classpath
lib/jar_usage.txt
In Gump project:
project/jakarta-jmeter.xml
and/or
project/jakarta-jmeter-20.xml
if the addition was to branch 2.0, which has
At present it is better to use batch mode for generating high loads.
But I agree that it would be useful if the remote mode was more efficient.
One possible work-round is to add a summariser to the agent JMeter scripts.
This will dump out the performance statistics every so often. Combine this
[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
+1
thanks!
S.
-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]
Sent: 24 May 2004 03:59
To: JMeter Developers List; [EMAIL PROTECTED]
Subject: Re: JMeter 2.0.1 released
sounds good to me.
peter
--- Michael Stover [EMAIL PROTECTED] wrote:
I've made a bug-fix release of
BTW, I'm trying to set up an extra Gump module to build the rel_2_0 branch
in addition to the latest CVS build.
After some false starts, I'm hopeful that this should soon start working.
S
-Original Message-
From: BAZLEY, Sebastian
Sent: 24 May 2004 10:22
To: 'JMeter Developers List
Looks like build.xml might need updating to fix the compilation problems.
By the way, the nag messages are currently sent as if from [EMAIL PROTECTED]
- I used this address because I knew it was subscribed. It might be better
to use an impersonal address, but I don't know which ones are
I think these new libraries will mean changes to the Gump descriptor.
I can have a go at fixing it, hopefully later today - unless anyone else is
about to do it?
S.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 20 May 2004 14:02
To: [EMAIL PROTECTED]
Subject:
responseMessage=OK responseCode=200 success=true/
sampleResult timeStamp=0 dataType= threadName=Integration Tests
Thread Group3-1 label= time=0 responseMessage= responseCode=
success=false//testResults
-Original Message-
From: BAZLEY, Sebastian
As these changes have been made in the rel 2.0 branch, they won't appear in
the Gump builds just yet.
I've uploaded the java jar file to
http://www.apache.org/~sebb/jars
I've not been able to test it, as I don't seem to get the same error.
[No guarantees that the jar will work properly...but I
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 04 April 2004 15:00
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-jmeter/src/core/org/apache/jmeter/util
JMeterVersion.java
mstover12004/04/04 06:59:53
Modified:.Tag: rel-2_0 build.xml
+1
-Original Message-
From: Michael Stover [mailto:[EMAIL PROTECTED]
Sent: 02 April 2004 16:16
To: [EMAIL PROTECTED]
Subject: [VOTE]2.0 release
To avoid any problems with JMeter's release, I plan on sending the PMC a
message that JMeter is releasing. As such, I want to have a formal
No - if the user picks up a nightly build, they get the updated manual as
part of the binary jar.
The documents need to reflwct the current release.
However, it might perhaps be worthwhile putting a copy of the latest
documents online *as well as* the current release.
Could add this to any of
-Original Message-
From: Michal Kostrzewa [mailto:[EMAIL PROTECTED]
Sent: 26 March 2004 16:59
To: JMeter Developers List
Subject: RE: update the docs
However, it might perhaps be worthwhile putting a copy of the latest
documents online *as well as* the current release.
Very good
-Original Message-
From: Michal Kostrzewa [mailto:[EMAIL PROTECTED]
Sent: 26 March 2004 17:48
To: JMeter Developers List
Subject: RE: update the docs
I'm happy to start the process off, once we've decided where
to put the
updated pages...
If it is in someone's home directory, then
-Original Message-
From: Michal Kostrzewa [mailto:[EMAIL PROTECTED]
Sent: 26 March 2004 18:17
To: JMeter Developers List
Subject: RE: update the docs
I can update the web-site to add a link - any suggestions as
to where to put
it?
perhaps
Documentation/nightly user manual
OK, I'll have a look at that later.
BTW, adding the script scanner fixed another problem - it now no longer
trips up on strings such as
img src=\/shared/images/spacer.gif\ width=1 height=8
which are often found in scripts.
This was previously being treated as a link to \, which caused
, then caching the context in each
element wouldn't be a problem.
Using ThreadLocal inside the JMeterContextService to provide the
per-thread access to contexts sounds like a good idea.
-Mike
On Mon, 2004-03-22 at 08:00, BAZLEY, Sebastian wrote:
Not sure it should be read-only.
The context
This is true of most/all test elements - they pick up the settings from the
previous instance of the kind.
I suspect that's because all the Test Elements are created in the same
thread, and presumably the properties used to populate the GUI hang around.
S.
--- [EMAIL PROTECTED] wrote:
-
Not sure it should be read-only.
The context is useful (and already used?) for communicating information
within a thread.
I recently added a version of getContext() to AbstractTestElement that
caches the context variable.
The idea being that the TestElements are all cloned per thread, and so
Forgot to say that JMeterThread initialises the context field - in the
samplers at least -before starting the test run.
S.
-Original Message-
From: BAZLEY, Sebastian
Sent: 22 March 2004 13:01
To: 'JMeter Developers List'
Subject: RE: Is JMeterContextService.getContext() thread safe
Sorry, I caused a problem with the builds when I added the HttpClient
Sampler (forgot to add the dependencies and jars to the project descriptor).
I updated the descriptor earlier today, so hopefully this will fix the build
problem.
In which case, not only can people try the new Monitor, but
HtmlParser that JMeter is using.
-Mike
On Tue, 2004-03-16 at 11:44, BAZLEY, Sebastian wrote:
For basic validation, you could use the standard Regex assertion, but I
suspect that would quickly become unwieldy...
I'd suggest having a look at the XML validator as a starting point.
Create new copies
If anyone wants to try and break the sampler, please do!
Since posting it, I've found the following:
- logging destination is not set up correctly (ideally needs to use the
existing logkit)
- Sometimes gets unretriable error using Tomcat; not sure what causes this
yet or how to fix it.
The
I did not get the impression that jakarta projects are /expected/ to
graduate.
[Incubator projects, yes.]
I think we should just leave things as they are. [Less work, after all!]
S.
-Original Message-
From: Michael Stover [mailto:[EMAIL PROTECTED]
Sent: 15 March 2004 16:31
To: [EMAIL
Yes - and the new Wiki has some very useful features:
- file attachments, and images can be displayed in-line
- automatic TOC generation (see the JMeterFAQ for an example)
- built-in vector drawing package
- lots more
Unfortunately, the leading J in JMeter causes problems in WikiWords;
references
Perhaps this needs to be raised on the infrastructure mailing list.
S.
-Original Message-
From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED]
Sent: 11 March 2004 15:26
To: JMeter Developers List
Subject: Re: [Apache JMeter Wiki] New: AddMonitoring
Unfortunately most of it gets marked
Actually, it's the Apache BSF that we use, so it's not a problem.
But anyway, JMeter CVS and the zips only USE BSF (and BeanShell, which is
not ASF) - it does not include any of the BSF or BeanShell code. This is
done using reflection where necessary.
In order to build the code that uses
in the docs.
peter lin
BAZLEY, Sebastian [EMAIL PROTECTED] wrote:
Actually, it's the Apache BSF that we use, so it's not a problem.
But anyway, JMeter CVS and the zips only USE BSF (and BeanShell, which is
not ASF) - it does not include any of the BSF or BeanShell code. This is
done using reflection
Screnshot looks good.
Perhaps worth considering a lightweight stand-alone data collector, thet
could store the data in a file for later analysis?
Also, how many XML parsers are we now using?
Should/Can we rationalise these?
S.
-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]
We'd like move the JMeter Wiki to MoinMoin.
It should probably start at
http://wiki.apache.org/jakarta-jmeter, but
http://wiki.apache.org/jmeter would do just as well.
Commit messages should go to [EMAIL PROTECTED] initially.
Anything else you need to know?
S. (sebb AT A.O)
-Original
I'm proposing to ask infrastructure for a JMeter Wiki to be set up on the
new MoinMoin Wiki farm:
http://wiki.apache.org/
as an independent Jakarta sub-project, i.e. the initial page would be
http://wiki.apache.org/jakarta-jmeter
Update messages would be sent to [EMAIL PROTECTED] - i.e. where
project's-- which has been a pain. I would
recommend to establish such a convention (don't care which one) before
starting to move pages over.
--
Salut,
Jordi.
BAZLEY, Sebastian wrote:
I'm proposing to ask infrastructure for a JMeter Wiki to be set up on the
new MoinMoin Wiki farm:
http
This was a message I put in when I updated the thread context and related
items recently.
It should not affect the running of a test, but should be fixed - I'll have
a look later as to why the context is not being set up in this case.
S.
-Original Message-
From: Jordi Salvat i Alabart
Thanks - we had the same problem a week or two ago, when we got someone
elses bug report.
In both cases, the subject line agrees with the target list, but the
contents relates to another project.
Perhaps the contents and message header are produced separately, and
incorrectly merged?
Or
: Warning message on thread start (current CVS)
Drop me a word if you need help in reproducing.
BAZLEY, Sebastian wrote:
This was a message I put in when I updated the thread
context and related
items recently.
It should not affect the running of a test, but should be
fixed - I'll have
No, that is a separate issue, I'm not sure what causes it.
[I find the behaviour useful - sometimes.]
S.
-Original Message-
From: Boylan, Crispin [mailto:[EMAIL PROTECTED]
Sent: 27 February 2004 12:00
To: 'JMeter Developers List'
Subject: RE: cvs commit:
-Original Message-
From: Boylan, Crispin [mailto:[EMAIL PROTECTED]
Sent: 26 February 2004 15:26
To: 'JMeter Developers List'
Subject: RE: Current Status Of JMeter Nightlies
ok i'll file that one.
Thanks
i've also noticed something else - its related to the
behaviour of timers in
the
it in the nightly build doesnt work, and if it was enabled in a
script in 1.9.1 then trying to disable it in the nightly
doesnt work. Is
this a known bug?
Cheers
Cris.
-Original Message-
From: BAZLEY, Sebastian [mailto:[EMAIL PROTECTED]
Sent: 26 February 2004 14:12
To: 'JMeter Developers List
The nightly builds may work perfectly well, or they may fail entirely ...
It's worth checking the Test run results - if there are a lot of failures,
steer clear!
The JUnit tests exercise quite a lot of the code, but cannot test the GUI
behaviour, and don't test client-server, nor do they
Looks like a few of the JMeter committers have not yet got CLAs on file ...
http://www.apache.org/~jim/projects.html#jakarta-jmeter
(long page, slow to load)
There are quite a few who seem to be inactive, at least in JMeter.
But I can see at least 3 regulars who have yet to be italicised!
S.
project's PMC.
The active committers without CLAs, please take note - we don't want to lose
you!
S.
-Original Message-
From: BAZLEY, Sebastian
Sent: 23 February 2004 13:43
To: 'JMeterDev'
Subject: FW: Sign those CLAs!
Looks like a few of the JMeter committers have not yet got
CLAs on file
StopThread was a bit of a hack I put into StringFromFile to allow it to stop
the thread - by throwing an exception.
The code currently does:
if (values.length = PARAM_END){// Are we processing a file sequence?
log.info(Detected end of sequence.);
All the Samplers (and indeed most/all other test elements) have individual
instances for each test thread (plus one or two others).
At the moment, they the JMeter context service to access properties specific
to the thread, but this requires obtaining the thread name and looking up
the
I've been looking at equals/hashcode following some warnings from FindBugs,
but not resolved the problems fully. Thought it would be useful to summarise
what I've found so far:
If a class over-rides equals(), it should also override hashCode(),
otherwise it cannot be used reliably in Collections
-Original Message-
From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED]
Sent: 20 February 2004 14:26
To: JMeter Developers List
Subject: Re: Possible Thread enhancements
If this how it's working?
Well, I think so -
I was thinking of having a debug flag which caused the get/set
tried removing those equals() methods?
BAZLEY, Sebastian wrote:
I've been looking at equals/hashcode following some warnings
from FindBugs,
but not resolved the problems fully. Thought it would be
useful to summarise
what I've found so far:
If a class over-rides equals(), it should also
a single page in GUI mode...
Maybe I'll get some more clues when I've worked out why the GuiTest is
changed when it is loaded.
S.
-Original Message-
From: BAZLEY, Sebastian
Sent: 20 February 2004 14:42
To: 'JMeter Developers List'
Subject: RE: [HEADS UP] Possible problems with equals
Just wondering whether NOTICE and LICENSE need to be updated to take account
of the HtmlParser code?
S.
___
This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be
-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]
Sent: 12 February 2004 15:12
To: JMeter Developers List
Subject: RE: HtmlParser code and LICENSE/NOTICE
sure thing, thanks for the reminder :) Good thing you're on the ball.
No problem. [... sometimes I am!]
==
Just re-read
Something has broken the test setup when running headless - i.e. with no
display hardware.
This may be because of something I changed; anyway, I'll try to have a look
at it later today.
By the way, one can use the test-headless Ant build target to test running
headless - I must have forgotten to
I started trying to set up for the new ASF 2.0 licence, by following in
instructions at:
http://www.apache.org/dev/apply-license.html
{see also http://www.apache.org/licenses/]
The new URLString and URLCollection classes have got the new licence headers
- I hope I've got them right!
I've not
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 09 February 2004 12:57
To: JMeter Developers List
Subject: Re: Problem with headless Gump tests
On Mon, 09 Feb 2004, Jordi Salvat i. Alabart [EMAIL PROTECTED] wrote:
BTW, any idea why Gump nags are not working?
-Original Message-
From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED]
Sent: 09 February 2004 12:32
To: JMeter Developers List
Subject: Re: Problem with headless Gump tests
I recently changed some GUI-related code in test methods. It may be
related. I'm attaching the relevant CVS
Doh!
Ignore the bit about removing JUnit - it's needed to compile the test code,
and as that is mixed in with the live code, of course it's needed ...
[unless one day all the test code is moved into separate files]
S.
-Original Message-
From: BAZLEY, Sebastian
Sent: 09 February 2004
Tha Apache ... rather than just Apache
peter lin
Jordi Salvat i Alabart [EMAIL PROTECTED] wrote:
BAZLEY, Sebastian wrote:
I started trying to set up for the new ASF 2.0 licence, by
following in
instructions at:
http://www.apache.org/dev/apply-license.html
{see also http
We could check for the presence of HTMLParser at run-time, and fall back to
JTidy or Regex (or etc.) if not present.
Some users might not like the fallback behaviour, so if the parser property
were changed to be a list of the acceptable parsers, in order of preference,
we could support as much
-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]
Sent: 05 February 2004 13:53
To: JMeter Developers List
Subject: Re: How to handle htmlparser library (was Are we ready for a
RC?)
[...]
I went through the bugs last night. I don't know enough of
those samplers to be able to
-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]
Sent: 05 February 2004 18:48
To: JMeter Developers List
Subject: Re: How to handle htmlparser library (was Are we ready for a
RC?)
tion component.
I just doubled checked and it looks, HTMLParser is the default.
private final
I'm not averse to creating a release candidate, but it would be good if we
could fix at least some of the following before release:
26605 Maj Oth All [EMAIL PROTECTED] NEW Java Config elements
override samplers
23110 Nor Oth PC [EMAIL PROTECTED] ASSI JDBC Pool not
completely cleaned up when
Can you post (or e-mail me) the exact message produced? And what platform
did you use?
I made most of the recent changes to unit tests to check that items are
being created, but I don't recall checking anything for a count of 0, just a
few checks that look for 0.
There is a timer (sleep) test
-Original Message-
From: BAZLEY, Sebastian
Sent: 04 February 2004 10:49
To: 'JMeter Developers List'
Subject: RE: Are we ready for a RC?
I made most of the recent changes to unit tests to check that items are
being created, but I don't recall checking anything for a
count of 0, just
. What else do I need and where do I get them?
-Mike
On 4 Feb 2004 at 11:48, BAZLEY, Sebastian wrote:
-Original Message-
From: BAZLEY, Sebastian
Sent: 04 February 2004 10:49
To: 'JMeter Developers List'
Subject: RE: Are we ready for a RC?
I made most of the recent changes
Why not post the article itself on the JMeter Wiki, and send the link to the
mailing lists?
S.
-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]
Sent: 28 January 2004 15:19
To: JMeter Developers List
Subject: article for users
I've started a new article on how to simulate
yes, it looks like it:
-Original Message-
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: 23 January 2004 14:15
To: [EMAIL PROTECTED]
Subject: ASF Board Summary for January 21, 2004
Happy New Year!
The Board met last Wednesday for its regular, monthly meeting. Since the
official
Twas I that added the code that uses split - all it's doing is prettyfying
the classpath, so I'll remove it unless/until the dependency can be fixed
... indeed, perhaps there should be a split() method in Jorphan to allow for
JDK 1.3 support.
But I'll do the quick fix first.
[Must remember to do
Hopefully this will fix the following Gump test error:
2004/01/21 12:51:13 ERROR - jorphan.test.AllTests: error adding test :
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
I've updated the resource tests to remove the requirement that all the keys
agree.
It now checks that
- the files exist (default/DE/NO/JA)
- there are no duplicate keys in any of the files
- there are no keys in the DE/NO/JA files that are not in the default file
I've not yet extended it to
Yes, I think a new release might be in order. Do we need to vote on this?
Perhaps we should go for a release candidate like last time.
This would give a bit of time to sort out any remaining loose ends (e.g.
documentation)
If others think it would be useful, I'll have a look at putting the CVS
In case you hadn't seen the message I posted a while back, JMeter is
normally built from CVS every night, and the Jars are zipped up in case
anyone wants to use them.
If the problem has not been fixed, please let us know here or via
Bugzilla...
There are a couple of links on the JMeter home
Just curious - how did the caching problem show up?
S.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 20 January 2004 16:41
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-jmeter/src/jorphan/org/apache/jorphan/test
AllTests.java
jsalvata2004/01/20
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 20 January 2004 17:35
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-jmeter/src/core/org/apache/jmeter/testbeans/gui
PackageTest.java
jsalvata2004/01/20 09:34:35
Added:
-Original Message-
From: Sonam Chauhan [mailto:[EMAIL PROTECTED]
Sent: 19 January 2004 08:20
To: '[EMAIL PROTECTED]'
Subject: current CVS build runtime issues on JVM 1.3
[ FYI only ]
Thanks for trying it out!
Seb wrote on Jan 7:
JMeter should now build and run on both 1.3 and 1.4.
, then.
--
Salut,
Jordi.
En/na BAZLEY, Sebastian ha escrit:
-Original Message-
From: Sonam Chauhan [mailto:[EMAIL PROTECTED]
Sent: 19 January 2004 08:20
To: '[EMAIL PROTECTED]'
Subject: current CVS build runtime issues on JVM 1.3
[ FYI only ]
Thanks for trying it out!
Seb wrote
Is the idea to move all the Bean-related properties from
messages.properties
to
classnameResourceslang.properties?
It seems to me that this will result in a lot of property files to create,
translate, test and maintain.
I can see that it is useful to be able to have more than one set of
/sourcepaths.png shows that the real
sourcepath is somewhat nested double ie there are two protocol
directories nested. Is this correct, should the wiki be adjusted?
Thanks
Jorg
BAZLEY, Sebastian wrote:
Works fine in Eclipse 2.1.
The bin directory should already have a copy of jmeter.properties
)An error
occurred: Could not read JMeter properties file
Jorg
BAZLEY, Sebastian wrote:
Unfortunately, the Wiki as it stands does not support images,
which is why
that part of the Eclipse setup is on another server, over
which we have no
control.
There are moves afoot to use a different Wiki
I'd like to propose moving the JMeter Wiki to the new MoinMoin Wiki.
Here's my
+1
If we're agreed, I'm happy to contact infrastructure in due course to get it
done.
S.
-Original Message-
From: BAZLEY, Sebastian
Sent: 08 December 2003 15:55
To: '[EMAIL PROTECTED]'
Subject: FW
A bit of explanation:
JMeter Help uses the test element title to find the appropriate section in
component_reference.html.
The titles are not fixed, as they are extracted from the appropriate
property file (they do use a fixed key).
So if a new test element is added, or the title is changed,
Sounds fine to me. Thanks for doing all the work.
==
Following a discussion on the User list, I was thinking of creating a dummy
sampler that could be used as a basis for users to write their own - perhaps
it would be a good idea to create one for the Beans approach instead (or as
well as?).
It
Works fine in Eclipse 2.1.
The bin directory should already have a copy of jmeter.properties.
Sounds like you have not populated the workspace fully.
There's some info on Eclipse in the JMeter Wiki - have you read that?
You need to add the following jars to the classpath:
bin/*.jar
Not quite sure why the sampler disappeared and reappeared - perhaps there
was a problem with the build or the packaging, though I would then not
expect the zips to be produced.
Or maybe a required library was missing - e.g. JavaMail - this should show
up in the jmeter log file.
S
-Original
are missing.
peter
BAZLEY, Sebastian [EMAIL PROTECTED] wrote:
Not quite sure why the sampler disappeared and reappeared -
perhaps there
was a problem with the build or the packaging, though I would then not
expect the zips to be produced.
Or maybe a required library was missing - e.g. JavaMail
The default values are OK, but I'm not sure that they'll work as intended -
for example, if a test plan is saved with an empty value, will the default
be re-applied? I suspect the value will be populated from the test plan.
I think it might be better to define constants (static final String) and
-Original Message-
From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED]
Sent: 07 January 2004 18:54
To: JMeter Developers List
Subject: Tons of small changes in the testbeans branch.
I will appreciate comments from anyone willing to spend the time to
synch the
Some potentially useful bug-fixes in the new ORO release - any objections to
updating JMeter CVS with this new version?
S.
-Original Message-
From: Daniel Savarese [mailto:[EMAIL PROTECTED]
Sent: 31 December 2003 05:12
To: [EMAIL PROTECTED]
Subject: [ANNOUNCEMENT] jakarta-oro v2.0.8
What version of Java are you running it with?
I just tried the same version as you (from the LSP site) and had some
problems, until I noticed that I was accidentally running JVM version 1.3.
My JAVA_HOME was set to version 1.4, but there was a copy of java.exe and
javaw.exe higher up the path...
I've changed the Gump builds so that the jakarta-jmeter module now builds as
3 separate phases (projects in Gump terminology):
build (and save jars)
test
javadoc
There are 3 new gump-name targets in build.xml to support this, and the
Gump module definition has also been updated.
Unfortunately I
I've updated SampleResult to add sampleStart and sampleEnd methods.
The idea is that samplers will:
- create the sample result
- do any necessary initilisation
- call sampleStart
- perform the actual work
- call sampleEnd
[For samplers that do the sample in stages, such as LDAP, there are
-Original Message-
From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED]
Sent: 18 December 2003 02:29
To: JMeter Developers List
Subject: Re: Is ThroughputController useful?
BTW, one reason why I believe the ByNumber option is not very
useful is
that it always runs one time
1 - 100 of 216 matches
Mail list logo
