Re: [VOTE] Release JMeter 2.5.1 RC2
+1 On Sun, Sep 25, 2011 at 8:01 AM, Milamber milam...@apache.org wrote: Hello, The second release candidate for JMeter 2.5.1 has been prepared, and your votes are solicited. This release fixes mainly some bugs appeared since JMeter 2.5, but contains few improvements. Tests (load tests or functional tests) with JVM 5/6/7 on Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient 4.1 request, Http request with parallels embedded resources, View results tree, WebServices (SOAP) request, Async sample sending mode, etc) List of changes: http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs/changes.html JMeter is a Java desktop application designed to load test functional behavior and measure performance. The current version is targeted at Java 1.5+. Archives/hashes/sigs and RAT report: http://people.apache.org/~milamber/jmeter-2.5.1RC2/dist MD5 hashes of archives for this vote: abc0d327d19f3e138955de5082c000b3 *jakarta-jmeter-2.5.1.tgz 3e69786253880a1293e245519cba4ad3 *jakarta-jmeter-2.5.1.zip cdc73f4db83dee52d216c74c2a323721 *jakarta-jmeter-2.5.1_src.tgz 3f294979e6c696bba91d62c2ec5f0473 *jakarta-jmeter-2.5.1_src.zip Site Docs are here: http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC2 (r1175373) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://people.apache.org/~milamber/ N.B. To download the dependencies: ant download_jars To create the jars and test JMeter: ant package test. JMeter 2.5 requires Java 1.5 or later. Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Thanks in advance! Milamber - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.5.1 RC1
+1 On Thu, Sep 22, 2011 at 6:53 PM, Milamber milam...@apache.org wrote: Hello, The first release candidate for JMeter 2.5.1 has been prepared, and your votes are solicited. This release fixes mainly some bugs appeared since JMeter 2.5, but contains few improvements. Tests (load tests or functional tests) with JVM 5/6/7 on Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient 4.1 request, Http request with parallels embedded resources, View results tree, WebServices (SOAP) request, etc) List of changes: http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs/changes.html JMeter is a Java desktop application designed to load test functional behavior and measure performance. The current version is targeted at Java 1.5+. Archives/hashes/sigs and RAT report: http://people.apache.org/~milamber/jmeter-2.5.1RC1/dist MD5 hashes of archives for this vote: c1c63f36692ac2fd2e7cca2f2b162c6e *jakarta-jmeter-2.5.1.tgz 8345f36f769872651d53db2436eac100 *jakarta-jmeter-2.5.1.zip c232ea7259543592f56c2dca7ba5850d *jakarta-jmeter-2.5.1_src.tgz 52a2dee578fd433d286e16dfe928b6b2 *jakarta-jmeter-2.5.1_src.zip Site Docs are here: http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC1 (r1174408) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://people.apache.org/~milamber/ N.B. To download the dependencies: ant download_jars To create the jars and test JMeter: ant package test. JMeter 2.5 requires Java 1.5 or later. Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Thanks in advance! Milamber - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] JUnit sampler sample time changes
I've talked with BEA's JRockit team in the past regarding the
differences in Nano time on different platforms.
Given these issues, using nano time in JMeter is difficult at best.
From what I am told by Henrik stahl, making nano time reliable and
performant isn't trivial, so using it to measure performance isn't
really recommended. As far as I know, the only way to get reliable
high performance nano time is if the OS provides it.
On Sun, Apr 3, 2011 at 9:45 AM, sebb seb...@gmail.com wrote:
That reminds me -
Tests I've done on Windows show that nanoTime() drifts considerably
when compared with currentTimeMillis(), i.e. its clock does not appear
to run at the same rate.
Here's a simple test you can run:
public class NanoDrift {
public static void main(String[] args) throws InterruptedException {
long systemTime = System.currentTimeMillis();
long nanoTime = System.nanoTime() / 100;
long count=0;
while(true){
long systemDiff = System.currentTimeMillis() - systemTime;
long nanoDiff = System.nanoTime() / 100 - nanoTime;
long absdiff = Math.abs(systemDiff-nanoDiff);
if (absdiff 100 || (count % 60 == 0)) {
System.out.println(@:+count+ |S-N|:+absdiff+
S:+systemDiff + N: + nanoDiff);
}
Thread.sleep(1000);
count++;
}
}
}
Behaviour may depend on the JVM used; on
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)
I just got
@:0 |S-N|:0 S:0 N:0
@:60 |S-N|:0 S:60032 N:60032
@:120 |S-N|:1 S:120032 N:120033
@:180 |S-N|:2 S:180032 N:180034
@:240 |S-N|:6 S:240032 N:240038
@:300 |S-N|:7 S:300032 N:300039
@:360 |S-N|:13 S:360032 N:360045
@:420 |S-N|:14 S:420032 N:420046
@:480 |S-N|:15 S:480032 N:480047
@:540 |S-N|:16 S:540032 N:540048
@:600 |S-N|:17 S:600032 N:600049
@:660 |S-N|:18 S:660032 N:660050
@:720 |S-N|:19 S:720032 N:720051
@:780 |S-N|:20 S:780032 N:780052
@:840 |S-N|:21 S:840032 N:840053
@:900 |S-N|:22 S:900032 N:900054
@:960 |S-N|:23 S:960032 N:960055
@:1020 |S-N|:24 S:1020032 N:1020056
@:1080 |S-N|:21 S:1080063 N:1080084
@:1140 |S-N|:22 S:1140063 N:1140085
@:1200 |S-N|:23 S:1200063 N:1200086
@:1260 |S-N|:24 S:1260063 N:1260087
@:1320 |S-N|:21 S:1320172 N:1320193
@:1380 |S-N|:36 S:1380172 N:1380208
@:1440 |S-N|:37 S:1440172 N:1440209
@:1500 |S-N|:38 S:1500172 N:1500210
@:1560 |S-N|:40 S:1560172 N:1560212
@:1620 |S-N|:41 S:1620172 N:1620213
@:1680 |S-N|:42 S:1680172 N:1680214
@:1740 |S-N|:29 S:1740188 N:1740217
@:1800 |S-N|:30 S:1800188 N:1800218
@:1860 |S-N|:31 S:1860188 N:1860219
@:1920 |S-N|:31 S:1920188 N:1920219
@:1980 |S-N|:32 S:1980188 N:1980220
@:2040 |S-N|:33 S:2040188 N:2040221
@:2100 |S-N|:34 S:2100188 N:2100222
@:2160 |S-N|:35 S:2160188 N:2160223
@:2220 |S-N|:36 S:2220188 N:2220224
@:2280 |S-N|:37 S:2280188 N:2280225
@:2340 |S-N|:38 S:2340188 N:2340226
@:2400 |S-N|:39 S:2400188 N:2400227
@:2460 |S-N|:40 S:2460188 N:2460228
@:2520 |S-N|:41 S:2520188 N:2520229
However, on a FreeBSD system using
java version 1.6.0_03-p4
Java(TM) SE Runtime Environment (build 1.6.0_03-p4-root_17_dec_2010_05_08-b00)
Java HotSpot(TM) 64-Bit Server VM (build
1.6.0_03-p4-root_17_dec_2010_05_08-b00, mixed mode)
I see no drift:
@:0 |S-N|:0 S:0 N:0
@:60 |S-N|:0 S:60118 N:60118
@:120 |S-N|:0 S:120239 N:120239
@:180 |S-N|:1 S:180357 N:180358
@:240 |S-N|:0 S:240476 N:240476
@:300 |S-N|:0 S:300594 N:300594
@:360 |S-N|:0 S:360713 N:360713
@:420 |S-N|:0 S:420830 N:420830
@:480 |S-N|:1 S:480948 N:480949
@:540 |S-N|:0 S:541066 N:541066
@:600 |S-N|:0 S:601184 N:601184
@:660 |S-N|:0 S:661302 N:661302
@:720 |S-N|:0 S:721419 N:721419
@:780 |S-N|:0 S:781537 N:781537
@:840 |S-N|:0 S:841655 N:841655
@:900 |S-N|:0 S:901773 N:901773
@:960 |S-N|:1 S:961890 N:961891
@:1020 |S-N|:0 S:1022008 N:1022008
@:1080 |S-N|:0 S:1082126 N:1082126
@:1140 |S-N|:0 S:1142244 N:1142244
@:1200 |S-N|:1 S:1202361 N:1202362
@:1260 |S-N|:1 S:1262479 N:1262480
@:1320 |S-N|:0 S:1322600 N:1322600
@:1380 |S-N|:1 S:1382748 N:1382749
@:1440 |S-N|:0 S:1442879 N:1442879
@:1500 |S-N|:1 S:1502997 N:1502998
@:1560 |S-N|:0 S:1563115 N:1563115
@:1620 |S-N|:0 S:1623233 N:1623233
@:1680 |S-N|:0 S:1683351 N:1683351
@:1740 |S-N|:0 S:1743468 N:1743468
@:1800 |S-N|:0 S:1803586 N:1803586
@:1860 |S-N|:0 S:1863704 N:1863704
@:1920 |S-N|:1 S:1923838 N:1923839
@:1980 |S-N|:0 S:1983959 N:1983959
@:2040 |S-N|:1 S:2044077 N:2044078
@:2100 |S-N|:0 S:2104195 N:2104195
@:2160 |S-N|:0 S:2164313 N:2164313
@:2220 |S-N|:1 S:2224430 N:2224431
@:2280 |S-N|:1 S:2284548 N:2284549
@:2340 |S-N|:0 S:2344666 N:2344666
@:2400 |S-N|:1 S:2404784 N:2404785
@:2460 |S-N|:0 S:2464903 N:2464903
@:2520 |S-N|:0 S:2525020 N:2525020
@:2580 |S-N|:0 S:2585138 N:2585138
@:2640 |S-N|:0 S:2645256 N:2645256
On 3 April 2011 13:50, Peter Lin wool...@gmail.com wrote
Re: [JMeter] Convert to Maven based build?
well put. Far more elegant and objective than my rants! I feel so scarred by maven that I will never recover :) On Fri, Nov 26, 2010 at 11:54 AM, Phil Steitz p...@steitz.com wrote: On Thu, Nov 25, 2010 at 4:29 PM, Rahul Akolkar rahul.akol...@gmail.comwrote: On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien tobr...@discursive.com wrote: On Nov 25, 2010, at 2:29 PM, Peter Lin wool...@gmail.com wrote: even though I haven't been active in jmeter in a while, I am still a jmeter committer. Quantify a while. snip/ No need, we have archives for the curious. I'm still a committee on various projects. Would I veto a change by someone with a defined need who shows initiative? No. If Peter Lynch has the itch, why not let him experiment? This place works on initiative, not a series of subjective objections to a tool he wishes to use. This place works only if people like yourself (like myself) get out of the way of people more active than ourselves. snap/ All good above. Finally, the onus is on those who experiment to convince those who do the work here that the proposed changes are then worthy. +1 As one data point for a potential contributor, I will share the following. I have been lurking on this list for quite some time and intending to eventually propose some ideas/patches for enhancements. Seeing this thread, i thought it would be a good idea to see how hard it was for me to get set up to build the code and run the tests. The answer is it took me about 10 minutes, which is frankly less time than most maven-built projects take to get going and *way less* than any nontrivial maven build. I particularly like that there is a README as well as a building.html that clearly describe the simple steps necessary to get set up. If you follow the directions to download the dependent jars and replace the Eclipse .classpath file with eclipse.classpath, Eclipse is fully set up. I did not try to actually run anything from within Eclipse, as I find that is in general a bad idea for anything nontrivial; but the nicely documented ant build.xml worked for me out of the box. It was impressive to me that I did not have to fuss with any local property settings, given the amount of config that Jmeter and its tests use. [I did get the following test failure: [java] 1) runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError: serialization of org.apache.jmeter.functions.gui.FunctionHelper failed: java.io.NotSerializableException: com.apple.laf.AquaComboBoxUI Looks Apple-specific. I am running java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)] Two of the ten minutes were spent fussing with Eclipse because I had replaced the classpath before downloading the jars. Closing and reopening the project was not enough to get Eclipse to stop thinking the jars were missing. I had to recreate it after the jars were in place. It might be better to change the instructions to remind people to download the jars before creating the Eclipse project. I can submit a patch for that if others agree this is a good idea. So I am personally finding it hard to believe that mavenizing the build is really going to make it easier for people to get involved with Jmeter. If there are Jmeter artifacts of general usefulness, I think it would be a *good thing* to develop either Ant or Maven targets to get them published. That would be a much easier task than trying to get the full Jmeter build working in Maven. I agree strongly with Rahul and Peter Lin though that this decision belongs to them who do the work. Phil -Rahul - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] Convert to Maven based build?
I hate maven and it sucks. It does not reduce maintenance at all. I vote against changing to maven. -1 Maven is a road to he'll on my book Sent from my iPhone On Nov 25, 2010, at 1:28 PM, sebb seb...@gmail.com wrote: On 25 November 2010 17:54, Peter Lynch pe...@peterlynch.ca wrote: Hi sebb, On Thu, Nov 25, 2010 at 9:42 AM, sebb seb...@gmail.com wrote: On 25 November 2010 14:18, Peter Lynch ply...@apache.org wrote: I am wondering if there is developer support for the idea of converting JMeter's build process to be based on Maven. If there is suitable support of this idea, I was going to start writing a conversion script that would convert the project sources while maintaining as much scm history as possible. Should be possible to maintain all SCM history if done properly. Note that changes of source layout will cause a (one-off) problem for people who maintain private patches. I have outlined some of the advantages this offers in this enhancement https://issues.apache.org/bugzilla/show_bug.cgi?id=50324 https://issues.apache.org/bugzilla/show_bug.cgi?id=50324 So what do the developers think? Why do you want to build JMeter with Maven? I'd like JMeter to be accessible to as many developers as possible. I'd like the source code layout to be more standardized, to be more accessible to Java developers who want to contribute to the project. I'd like to fix problems in JMeter source code by opening the project in any IDE that supports Maven project structures and know instantly how to run tests, build and deploy. I'd like the artifacts that JMeter produces to be in a format that can be more easily reused and referenced by other projects. Is it just so that JMeter jars can be uploaded to Maven Central? If so, then there are simpler ways to achieve this. No that is not the primary reason, see above. I am familiar with how to get jars on Central using various methods - I work at Sonatype afterall ;). Is it so that you can run JMeter with Maven (assuming jars are in Central)? If so, then potentially major changes are needed to JMeter, because currently it maintains its own classpath, and expects to find jars in specific locations. For example, lib/ext is searched for JMeter components; lib is not. Since JMeter has to do quite a lot of jar scanning, it is important that this is efficient. You bring up some good points but all of this is scope creep - it may come as an eventual side effect but that is not the main goal. This is not scope creep - if the above mentioned issues are not addressed, then JMeter either won't work or will be slowed down. It may turn out that during the conversion process there is some roadblock that would prevent Maven being useful - but I doubt it. Well, the above need to be addressed for a start. I would suggest any changes converting to Maven brings affects mostly project structure, accessibility and maintainability over the long term. The layout of SVN is not particularly important to me; that can be changed to suit Maven and the Ant file modified to suit. However, I do take issue with the proposition that converting to Maven necessarily reduces maintenance. Note also that the Ant build does some work that may be tricky to implement in Maven. For example, the documentation is built twice - once for web-site, and once for the dynamic help system. The build also creates a lot of different jars. My experience of multimodule Maven builds is that they can take a lot longer than Ant, and are tricky to get working correctly. I'm not saying that JMeter can't or won't use Maven for builds, but it's not going to be at all easy to implement and maintain. I know from my participation in Apache Commons that even simple projects can spend quite a lot of time on Maven issues. It sounds like you have some valuable experience to draw upon. That's great! I'm the current release manager, and have been for several years. As long as there is not a defacto no to experimenting using Maven then I suggest to come up with a script first that does the conversion, and then discuss if the end result tradeoffs make JMeter a better project or not (... and if the changes the script applies should get committed). Rejigging the source files to fit in with Maven is a one-off effort, but before starting down this road, I think someone needs to show that JMeter will actually run OK when the jars are stored in a Maven repo. That should be possible to prove without needing to make any changes to the JMeter source layout. AIUI, it would just require copying the jars and basic POMs to a local repo, and creating a POM that depends on the JMeter jars. This work would not be wasted, as the POMs that are created will be needed later in the Mavenisation of JMeter (assuming the experiment is successful). - To
Re: [JMeter] Convert to Maven based build?
honestly, I don't remember the last time I committed changes for jmeter. it was a bug fix in something I wrote 5-6 years back. I've contributed quite a bit of stuff to jmeter in the past and still use it. For me, jmeter is a mature stable product that meets all of my needs, so I haven't needed any new features the last 3-4 years. I have no objections to stepping aside so that new people can get involved. I just question the need to change from ANT to Maven. JMeter is a stand alone app. From my own experience, people tend to use maven to make it easier to deploy a webapp to a container, which doesn't apply to jmeter. If the goal is to push jmeter jars to a maven repository, there's no need to use maven. simply create a task with ant that uploads the jars. JMeter's structure is mature and works well. If someone can convince me of the actual benefits of using maven with jmeter, I'll gladly eat crow and vote for it. As I stated earlier, I hate maven and have a strong bias from first hand experience. It's not like I came the conclusion without using it. I supported a complex project for over a year and half that used maven. In practice, maintaining maven build often degenerates to a full time job. This isn't some third hand story, I was the person stuck with maintaining a maven build. I have no desire to burden sebastian with maintaining maven build when the current ant build works well and has basically zero maintenance over head. Will moving to maven reduce maintenance cost below zero? On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien tobr...@discursive.com wrote: On Nov 25, 2010, at 2:29 PM, Peter Lin wool...@gmail.com wrote: even though I haven't been active in jmeter in a while, I am still a jmeter committer. Quantify a while. I'm still a committee on various projects. Would I veto a change by someone with a defined need who shows initiative? No. If Peter Lynch has the itch, why not let him experiment? This place works on initiative, not a series of subjective objections to a tool he wishes to use. This place works only if people like yourself (like myself) get out of the way of people more active than ourselves. wrote: This community is a Meritocracy, not a Democracy. What's the difference?, you ask. In a Democracy you have a vote, you can cast your vote for various reasons, no one asks why if you vote a certain way. There's no abstract idea of merit. At Apache you certainly have a vote in a consensus-based approach to collaboration, but no one has license to -1 without an argument on the merits. This is what makes the community a Meritocracy. If you disagree with Peter's initiative, you'll need to provide a few things for your veto to stick: 1. A detailed set of objections to which Peter should be able to respond. 2. Some justification as to why the community would reject initiative? 3. A reasonable attempt to understand the merit of a particular proposal. I think the maven is a road to hell rhetoric violates the necessary sense of decorum that enables a group of volunteers to work together. It runs counter to the ideas the Foundation (supposedly) adheres to. If you are really casting a veto on peter's initiative stand up and present a viable counter-argument. If you don't I do believe the the community should disregard you previous email. Tim O'Brien On Nov 25, 2010, at 12:46 PM, Peter Lin wool...@gmail.com wrote: I hate maven and it sucks. It does not reduce maintenance at all. I vote against changing to maven. -1 Maven is a road to he'll on my book Sent from my iPhone On Nov 25, 2010, at 1:28 PM, sebb seb...@gmail.com wrote: On 25 November 2010 17:54, Peter Lynch pe...@peterlynch.ca wrote: Hi sebb, On Thu, Nov 25, 2010 at 9:42 AM, sebb seb...@gmail.com wrote: On 25 November 2010 14:18, Peter Lynch ply...@apache.org wrote: I am wondering if there is developer support for the idea of converting JMeter's build process to be based on Maven. If there is suitable support of this idea, I was going to start writing a conversion script that would convert the project sources while maintaining as much scm history as possible. Should be possible to maintain all SCM history if done properly. Note that changes of source layout will cause a (one-off) problem for people who maintain private patches. I have outlined some of the advantages this offers in this enhancement https://issues.apache.org/bugzilla/show_bug.cgi?id=50324 https://issues.apache.org/bugzilla/show_bug.cgi?id=50324 So what do the developers think? Why do you want to build JMeter with Maven? I'd like JMeter to be accessible to as many developers as possible. I'd like the source code layout to be more standardized, to be more accessible to Java developers who want to contribute to the project. I'd like to fix problems in JMeter source code by opening the project in any IDE that supports Maven project structures and know
Re: [JMeter] Convert to Maven based build?
so far I am not convinced of the benefits of changing to maven. my vote is still -1 As I said before, my feeling is jmeter is mature and stable. JMeter isn't missing any critical features and seb has done a phenominal job of maintaining it. It's not like there's 10 critical features JMeter must have. Frankly, I don't buy the argument that jmeter will die. Given JMeter's focus is narrow, there's no point bloating it with lots of useless knobs and buttons. I also don't buy the argument of building developer community. JMeter's developer list has always been small even before I joined. I attribute this to the focused nature of jmeter. JMeter doesn't try to be the kitchen sink, butler, maid, dumb waiter, door bell, race car and bus all rolled into one. What kind of improvement are you talking about? What kind of growth are you talking about? Performance tools have a nitch and will always be that way. There's no realistic way to drastically grow jmeter's user base. Even though the traffic on the mailing list doesn't show it, the user base is much larger. Before I joined jmeter, I thought the user base was small. Once I started hearing from users directly, it became apparent the user base is much larger. For example, I know aetna uses it across their enterprise and is officially recommended by their standards and practices group. That's a huge user base in just 1 health care company. I also know the university of connecticut uses jmeter as their standard testing tool. What's the difference between running ant vs build command? What's the cost vs time benefit for switching? I won't speak for sebastian, but my experience is that maven 1 2 aren't reliable. If sebastian is ok with the change, I'm ok with it. He is the one who has been actively maintaining it and he is the one who will have to suffer maven. Long after other developer leave, sebastian will probably be the one maintaining it. My suggestion is to think of sebastian and the burden you put on him. Don't arbitrarily change the build because you happen to love maven. On Thu, Nov 25, 2010 at 9:21 PM, Peter Lynch ply...@apache.org wrote: Truthfully the main motivation for proposing to use Maven to build JMeter is to increase the chances of getting more people involved in the project, to fix bugs, to send patches and add features. Honestly do we expect the majority of potential developers to run for the hills and the project to die if JMeter project is built with Maven? On Thu, Nov 25, 2010 at 3:29 PM, Peter Lin wool...@gmail.com wrote: even though I haven't been active in jmeter in a while, I am still a jmeter committer. quite honestly, I've seen maven work first hand. 1. the claim it reduces maintenance has not truth. My first hand experience is that it creates a much bigger burden. Configuration management maintenance burden is relative to the frequency of change within the project. If what JMeter delivers in terms of final artifacts does not change, I don't expect maintaining a Maven build to somehow require change for change sake. 2. changing the directory structure of jmeter to fit maven is wrong for several reasons. due to maven's suggested structure it's common to run into path length issues on windows platforms. When i was responsible for maintaining maven builds, we often had to rename unit tests because it exceeded 255 characters. Forcing everyone to use and build on linux or unix is not acceptable in my book. Using an NTFS based Windows file system, UNC paths, path name components (ie. a file name or directory name) under 260 characters and total path length under ~32000 characters - there is no problem. Last I experienced a problem using Maven and long paths was with JDK 1.5, Windows XP and a FAT filesystem. How many developers are building JMeter on a FAT filesystem, I dunno but sounds like the chances of running into this problem on a development environment nowadays is pretty slim. 3. not everyone wants or cares to install maven. Couldn't someone say that about any tool? 4. maven 1 and 2 are both slow We cannot compare speed of the building JMeter using Maven because we have no benchmark building it with Maven yet. We create a script that converts to Maven project. Run the build actions and understand the deployment process. Compare the build time it takes to do common actions. Weigh any build time overhead with current build process and all of the other benefits and go from there. Lets say the entire Maven build takes 10 seconds longer (I have no data yet) - is it so bad that all the other benefits make it not worth it? If how to develop JMeter using IDEA, Netbeans and Eclipse remains a black art compared to just importing a Maven project into your IDE and go...is it worth it? Maybe...but lets at least deal with facts at least. The first step to do that is to try it out. 5. maven repositories are notoriously unreliable. when maven repositories go down, maven
Re: [JMeter] Convert to Maven based build?
On Fri, Nov 26, 2010 at 12:08 AM, Peter Lynch ply...@apache.org wrote: Peter Lin, On Thu, Nov 25, 2010 at 10:49 PM, Peter Lin wool...@gmail.com wrote: so far I am not convinced of the benefits of changing to maven. my vote is still -1 As I said before, my feeling is jmeter is mature and stable. JMeter isn't missing any critical features and seb has done a phenominal job of maintaining it. It's not like there's 10 critical features JMeter must have. Frankly, I don't buy the argument that jmeter will die. Given JMeter's focus is Obviously I did not suggest JMeter will die if it doesn't use Maven ?? Where in the world... narrow, there's no point bloating it with lots of useless knobs and buttons. I also don't buy the argument of building developer community. JMeter's developer list has always been small even before I joined. I attribute this to the focused nature of jmeter. JMeter doesn't try to be the kitchen sink, butler, maid, dumb waiter, door bell, race car and bus all rolled into one. What kind of improvement are you talking about? What kind of growth are you talking about? I'm just suggesting that it is convenient to load a project's sources into a modern IDE and have the IDE instantly know how to build the project without setting up anything. That I can use previous knowledge of working on other projects and reuse it with this one. That it is useful for a project to share it's artifacts with others in a standard way. That someone who wants to contribute a patch or fix a bug or write a test has a lower barrier to entry. I've already stated other benefits in previous messages and in the bugzilla issue. Don't worry - I'm not launching JMeter Inc. By modern IDE what do you mean? In eclipse atleast, maven plugin do not work. Ant works out of the box in Eclipse and netbeans. Maven seems to only work great if you use IntelliJ. I fully realize I have baggage when it comes to maven and I clearly stated my bias. I'm simply voicing my experience with maven so that others see the other side of maven. I leave the decision up to sebastian, since he is the only one that really has any say. Is it really necessary to use terms like 'road to hell', describe some ideas as 'stupid', imply suffering and burdens. Perhaps it may cause some people to ignore your experiences and opinions and focus instead on your generally poor demeanor. I'm not seeing how it helps your arguments. At the end of the day, I'm just looking to volunteer my time to add value to a project I use. I am not here to sell Maven like snake oil. I refuse to predict how great or horrible JMeter will become if it uses Maven - I'd rather spend time writing a conversion script to at least provide the option for factual evaluation. it's selfish to not think of those who are maintaining it, simply because you like maven and drank the koolaid. When I contribute to OSS projects I simply follow the established procedures and submit a patch. I don't try to change the existing setup. I just don't understand why maven proponents push it on others. I'm blunt and completely opinionated. I've seen several jakarta projects convert from ant to maven and become a pain to build. Sorry if my rants hurt your feelings, but maven tends to illicit that kind of love it or hate it response. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] Contribution to research
several years back Mike Stover and I worked on a detailed tutorial on writing plugins for JMeter. Having a list of the classes is a good thing to have, but I personally find tutorials more useful. The old tutorial is in the jmeter resources. peter On Wed, May 26, 2010 at 11:59 AM, Alberto Bacchelli alberto.bacche...@usi.ch wrote: Dear JMeter developers, I'm Alberto Bacchelli, a Ph.D. student in software engineering. We want to help new developers who join a new software system, and we believe that a good first impression would attract more contributors. Imagine a new developer joining JMeter: As a first step, he needs a high-level view of the system. Then, and this is what we want to address, he needs to know what the most important classes of the system are --the hotspots. We'd like to find *automated* methods to suggest a newbie which classes he should start to study/understand. To find the best recommendation method, we must know the important classes of the system, and you, as the system developers, are the only ones who can answer this question. If you agree to do so (and I really hope so :) ) we will create a small questionnaire for you, that will take less than 15 minutes to be completed. Thank you very much for reading this e-mail. Please, reply to this thread or send me an e-mail if you want to participate, and/or give me feedback. Cheers, Alberto PS: Since we want our work to respect the free software philosophy, if you agree, we would make all your answers public (anonymyzed if you wish) as a benchmark, so that other researchers can use your answers to propose even better techniques for this task. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.3.4 based on RC3
+1 On Wed, Jun 17, 2009 at 5:34 PM, sebbseb...@gmail.com wrote: Unfortunately JMeter 2.3.3 introduced some new bugs. I have therefore created 2.3.4RC3 which is basically a bug-fix release. [Tags RC1 and RC2 were abandoned, as I forgot to change all the versions] Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.4RC3/dist MD5 hashes of archives for this vote: cef24a84bcfc814f9b5b1f7b6a8f389f *jakarta-jmeter-2.3.4.tgz dc056ac75b43859b72fca9b413f7619d *jakarta-jmeter-2.3.4.zip 1df877d81fee18bdff0bf56eb8094f3b *jakarta-jmeter-2.3.4_src.tgz f1365878508bfad1d3c4e7a7605ff566 *jakarta-jmeter-2.3.4_src.zip Site Docs are here: http://people.apache.org/~sebb/jmeter-2.3.4RC3/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_4_RC3 (r785646) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://www.apache.org/dist/jakarta/jmeter/KEYS N.B. To rebuild JMeter or run the unit tests, you need to unpack both the binary and source archives into the same directory structure. This is because the library files are only included in the binary archive. To create the jars and test JMeter: ant package test. Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Here's my: +1 S/// - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.3.3 based on RC2
+ 1 On Tue, May 19, 2009 at 6:16 PM, sebb seb...@gmail.com wrote: The second release candidate for JMeter 2.3.3 has been prepared, and your votes are again solicited. JMeter is a Java desktop application designed to load test functional behavior and measure performance. The current version is targetted at Java 1.4+. There were some build/test problems reported with the previous release candidate, so a new version has been built. This fixes: * the I18N problems reported when testing using a French locale * a compiler warning re: illegal UTF-8 characters * a test timing issue Some documentation tweaks were also added. Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.3RC2/dist MD5 hashes of archives for this vote: f93fd88b4d91b37934233a2d9c038867 *jakarta-jmeter-2.3.3.tgz 333c4f6a9123929db22408c3d679673e *jakarta-jmeter-2.3.3.zip f71a012e2f22a333250e08011310f897 *jakarta-jmeter-2.3.3_src.tgz caccce29846949b28c2e52079c80e81d *jakarta-jmeter-2.3.3_src.zip Site Docs are here: http://people.apache.org/~sebb/jmeter-2.3.3RC2/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_3_RC2 (r776386) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://www.apache.org/dist/jakarta/jmeter/KEYS N.B. To rebuild JMeter or run the unit tests, you need to unpack both the binary and source archives into the same directory structure. This is because the library files are only included in the binary archive. To create the jars and test JMeter: ant package test. Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Here's my: +1 S/// - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.3.3 RC1
+1 on new release. thanks for tirelessly working on jmeter. peter On Sun, May 17, 2009 at 9:15 PM, sebb seb...@gmail.com wrote: On 17/05/2009, Milamber milambersp...@gmail.com wrote: Hello, +1 All build tests ok (without errors) on my linux/eclipse 3.4/jdk6 With JMeter 2.3.3RC1 from /~sebb Several test plan tested (monitor, beanshell (sampler NTP), http 1500 VU, remote test, proxy record): Ok on Linux Ubuntu 9.04/JDK 6 Ok on Windows Server 2008/JDK 6 Thanks for checking! Note: the CSV Sample script is a good thing (and a very good example). Perhaps include more samples ? like load test's web site, Beanshell (the bsh jar is now including in lib :) ), Functional test with assertion... Yes, I want to add some more examples for the next release. Milamber Le 15/05/2009 01:44, sebb a ecrit : The first release candidate for JMeter 2.3.3 has been prepared, and your votes are solicited. JMeter is a Java desktop application designed to load test functional behavior and measure performance. The current version is targetted at Java 1.4+. Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.3RC1/dist MD5 hashes of archives for this vote: dbdb62e4b64dc4cee77dd6229f8b687e *jakarta-jmeter-2.3.3.tgz f1c310eb9b3746143730e880d1aa17a8 *jakarta-jmeter-2.3.3.zip 51c20a74e90c5f61660414480e092d83 *jakarta-jmeter-2.3.3_src.tgz f8ecb89c5e6094b870b795fea7c9b460 *jakarta-jmeter-2.3.3_src.zip Site Docs are here: http://people.apache.org/~sebb/jmeter-2.3.3RC1/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_3_RC1 (r774953) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://www.apache.org/dist/jakarta/jmeter/KEYS N.B. To rebuild or test JMeter, you need to unpack both the binary and source archives into the same directory structure. This is because the library files are only included in the binary archive. To create the jars and test JMeter: ant package test Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Here's my: +1 S/// - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
Re: Refactoring JMeter
welcome back. the ideas sounds interesting. I haven't been active in a while either. peter On Sun, Apr 26, 2009 at 10:50 PM, Keith Cassell keith.cass...@ecs.vuw.ac.nz wrote: Let me re-introduce myself. I was a JMeter committer back around 2002 or so. My job responsibilities changed, so I faded away from the JMeter scene. Now, I've gone back to school to get my Ph.D. My field of interest is semi-automated refactoring. In other words, I'd like to be able to detect and fix maintainability problems with limited human interaction. One of the things I was thinking about doing was using JMeter as a testbed. I'd use various tools to locate and fix potential maintenance problems. If I liked the result, I'd submit the change to be committed. If the current committers liked the changes, the code could be checked in. I'm not averse to being an active committer again, but maybe you'd like to see the nature of my changes before you entrust me with the responsibility. :-) Cheers, Keith Cassell - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
Re: Any interest in adding MigLayout to Jmeter
I have to say the look with MigLayout is nicer. It looks like you've already patched JMeter. If you post patch in bugzilla, I can apply the changes. peter On Tue, Apr 7, 2009 at 9:27 AM, sebb seb...@gmail.com wrote: On 06/04/2009, rdonovan rdonovan2...@gmail.com wrote: Hi Guys, As you probably know MigLayout is a popular, powerful and relatively simple layout manager. And JMeter my favorite testing tool has some less than pleasing layouts which can be a bit off putting to new users Since I'm the 'show me type' I updated a number of Jmeter screens to use migLayout alignment Interestingly I found this usually cuts down a lot of the code since most of the alighment JPanels and VeriticalPanes are not needed. Examples of modified screens are: http://www.flickr.com/photos/crosswireit/3414811345/ Thread Panel (current) and http://www.flickr.com/photos/crosswireit/3414795393/ Thread Panel updated http://www.flickr.com/photos/crosswireit/3415619572/ FTP Request Sampler (current) and http://www.flickr.com/photos/crosswireit/3414797491/ Ftp Request Updated http://www.flickr.com/photos/crosswireit/3414812975/ Counter (current) and http://www.flickr.com/photos/crosswireit/3415608052/ Counter updated http://www.flickr.com/photos/crosswireit/3414812505/ JUnit Request (current) and http://www.flickr.com/photos/crosswireit/3415603274/ JUnit Request updated http://www.flickr.com/photos/crosswireit/3415619014/ Ldap Request (current) and http://www.flickr.com/photos/crosswireit/3415603028/ Ldap request updated http://www.flickr.com/photos/crosswireit/3415618510/ Tcp Sampler Config (current) and http://www.flickr.com/photos/crosswireit/3415602206/ Tcp Sampler updated http://www.flickr.com/photos/crosswireit/3415619572/ Ftp Request Sampler current and http://www.flickr.com/photos/crosswireit/3414796985/ Ftp Request Sampler updated http://www.flickr.com/photos/crosswireit/3418291019/ Web Service Soap Request current and http://www.flickr.com/photos/crosswireit/3414794935/ Web Service Sampler updated You get the basic idea. MiG Layout works with: Sun Java 1.4, 5.0, 6.0. and requires adding the MigLayout jar to the project. It is free to use for commercial and non-commercial projects and has a BSD license. I look forward to you feedback It certainly looks like an easier to use layout manager, and the license is compatible. However, although there are certainly some GUI pages that could be improved, AFAIK, they all work, and there are lots of bugs and enhancements that take priority. I suggest you create an enhancement request in Bugzilla, and maybe attach or or two sample sources and images to it. [Or use links for the images]. That will ensure that the suggestion is easier to track. Richard -- View this message in context: http://www.nabble.com/Any-interest-in-adding-MigLayout-to-Jmeter-tp22915507p22915507.html Sent from the JMeter - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
Re: JMeter Maven and JMeter TestNG contribution
I should state I am bias against maven. I believe getting jmeter to work with maven is feasible, but the cost of maintaining is going to be high. Although you can override the default directory structure, maven works best if you follow their conventions. Since I don't actively work on jmeter these days I won't vote against it, but maven doesn't live up to the hype. I find it works well for a new project with simple dependencies. JMeter is a bit complex from a build perspective, since we use some jars that are not included in the build. Also, we tend to build components in a specific order, which isn't maven's strong point. peter On Thu, Sep 18, 2008 at 12:53 PM, sebb [EMAIL PROTECTED] wrote: On 18/09/2008, Tomasz Pik [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 3:21 PM, Oleg Kalnichevski [EMAIL PROTECTED] wrote: Sebastian If you ever decide to port JMeter to Maven I will be willing to give you a helping hand with that. We could still use the existing scripts to build the distribution packages and generate the web site. It would be beneficial, though, at least in my opinion, to use Maven to manage dependencies and compile JMeter. Would it be possible to change directory structure of JMeter source tree a little, so it will be more 'maven friendly'? One change needs to be done - in directories with source code (like src/components) there should be at least one more level: src/components/java. Then there'll be natural place for pom.xml files: src/components/pom.xml src/components/java/org/apache/ Ideally, it should be src/components/src/main/java (OR components/src/main/java, with getting rid of top level src directory but I do not know if such a change would be acceptable to JMeter developers). Is there a chance to make such a change? The existing directory structure is not set in stone - it was changed a year or two ago to move the test files into a separate directory tree. However I don't think we should start on changing JMeter directory structure in SVN until we are sure that the end result will work for Maven. My personal view is that Maven should not be so picky about directory structures, but so long as JMeter can still be built and tested using Ant then I don't see a problem with moving the various chunks of the source code tree around. I just don't think it makes sense to start on that process and then find that there is some other aspect of the JMeter build process that is not supported by Maven. For example there are three output directories for jars (bin, lib, lib/ext) and lots of different jars. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JMeter 2.3.2RC7 - please!
+1 On Mon, Jun 9, 2008 at 9:26 PM, sebb [EMAIL PROTECTED] wrote: Trying yet again ... votes needed (positive or negative) - thanks! The licence issues reported by Henri have (I trust) been fixed. Also the lib/opt directory is now included in the source archives. To rebuild or test JMeter, you need to unpack both the binary and source archives in the same directory structure. This is because the library files are not duplicated in the source archive. Note that there is a bug in Java on some Linux systems that manifests itself as the follow error when running the test cases or JMeter itself. [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.2RC7/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3.2RC7/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC7 Keys are here: http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt also http://www.apache.org/dist/jakarta/jmeter/KEYS All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and create the release tag from the RC tag. Here's my: +1 S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JMeter 2.3.2RC3
+1 peter On Tue, May 27, 2008 at 7:50 PM, sebb [EMAIL PROTECTED] wrote: [Third time lucky, I hope] There is one trivial code change from RC1: * Log the property java.vm.name which shows whether the -client or -server Java flag was used when starting JMeter Otherwise the main changes relate to the way the archives are created: the tar files use LF endings for native files, and the zip files use CRLF endings. The JMX test and demo files have been updated to the new format. Some AL headers were added. As far as I can tell I've fixed all the previous test problems that were reported (and one I accidentally introduced in RC2 when the EOL settings were tidied up). Note that there is a bug in Java on some Linux systems that manifests itself as the follow error: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.2RC3/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3.2RC3/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC3 Keys are here: http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt also http://www.apache.org/dist/jakarta/jmeter/KEYS All feedback (and votes!) welcome. [ ]+1 - the release candidate is OK [ ]-1 - there is a problem (please indicate what it is) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and create the release tag from the RC3 tag. Here's my: +1 S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JMeter 2.3.2RC1
+1 peter On Mon, May 19, 2008 at 8:23 PM, sebb [EMAIL PROTECTED] wrote: It's about time (indeed overdue) for another JMeter release, so I've created JMeter 2.3.1 RC1 in the directory: http://people.apache.org/~sebb/jmeter-2.3.2/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3.2/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC1 Keys are here: http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt also http://www.apache.org/dist/jakarta/jmeter/KEYS All feedback (and votes!) welcome. [ ]+1 - the release candidate is OK [ ]-1 - there is a problem (please indicate what it is) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and create the release tag from the RC1 tag. Here's my: +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Candidate JMeter 2.3 RC3
+1 for new release peter On 7/10/07, sebb [EMAIL PROTECTED] wrote: -- Forwarded message -- From: sebb [EMAIL PROTECTED] Date: 09-Jul-2007 15:59 Subject: [VOTE] Release Candidate JMeter 2.3 RC3 To: Jakarta General List [EMAIL PROTECTED], JMeter Developers List jmeter-dev@jakarta.apache.org Following on from the helpful feedback on RC1, I've now created JMeter 2.3 RC3 in the directory: http://people.apache.org/~sebb/jmeter-2.3/dist Site documentation is here: http://people.apache.org/~sebb/jmeter-2.3/site It should now build and test OK on Unix (and in non-English Locales). [Please note that the 2 BeanShell tests require the optional beanshell jar to be downloaded from www.beanshell.org and put in the lib/opt directory.] All feedback welcome. [ ]+1 - the release candidate looks OK, proceed with releasing it [ ]-1 - there is a problem (please indicate what it is) There have been quite a few major updates since 2.2, so I think it would be prudent to release 2.3 initially as a release candidate; a full release can follow in a month or so. sebb AT apache DOT org
Re: [Jakarta-jmeter Wiki] Update of LocalBadContent by JMeterAdmin
I've fixed the stupid wiki spam. what is going on with all the bad wiki spam on jakarta. peter On 3/26/07, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-jmeter Wiki for change notification. The following page has been changed by JMeterAdmin: http://wiki.apache.org/jakarta-jmeter/LocalBadContent The comment on the change is: More bad content -- #language en ##add additional spam REs below: - dunky.info - cocoon_local_bad_content_test - Riester - vergleich-riester-rente.net - + .anime1.org + .gradhome.com + .incest1.org + .incest--stories.org + .sex-portal.us + .webcamss.com + .xxx-rape.org 00freehost.com 100freemb.com 150m.com 1accesshost.com 1sweethost.com + 24h.msn.hm + 51dragon.com 741.com 9cy.com angelcities.com + bandit.bravepages.com + blog-city.com + bodybuilding bravepages.com + chatsky.cn + chorister.o-f.com + combined.angelcities.com + condoned.00freehost.com + cowgirls.o-f.com + cvdiy.com dreamstation.com + dunky.info envy.nu + eseo.cn + eukhost.com exactpages.com fcpages.com + feeltime.cn + feeltime.com + fondest.fcpages.com freecities.com freewebpages.org freewebsitehosting.com g0g.net + gay--sex.org + gospel.9cy.com homepage.mac.com + honey99.cn + honey99.com ibnsites.com kogaryu.com + lo.lee.tv + masterjin.com + masturbate.fcpages.com + mephitical.kogaryu.com + mnsp.cn + mycv.cn + mycv.com.cn + nekoo.cn + oa8000.com.cn o-f.com + paisi.com + paisidesign.com + pinocles.dreamstation.com + radiosonde.g0g.net + ranters.dreamstation.com + Riester + rueful.freewebpages.org + scotsman.dreamstation.com + sfzone.cn + smbay.cn + soaped.angelcities.com + squealer.741.com + swelter.100freemb.com + trooped.envy.nu + u-tokyo.ac.jp + vergleich-riester-rente.net + vibrating.freewebpages.org + wm-u.com wtcsites.com + x2.top.tc + x25.us.to + yehuo.cn + yeshivoth.150m.com + zjeyu.com + zx.slave.ca + zy-image.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: server status with Jmeter
it only works with tomcat 5 and newer. also make sure you can view tomcat's status servlet before running jmeter peter On 12/28/06, ramana reddy [EMAIL PROTECTED] wrote: Hi, I want to know the server status with jmeter..in my case I added Monitor Results listener but it is always showing that Dead state. Please let me know getting the server status means whether it is dead ,healthy ,active or warning state.. Thanks, Ramana Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php
Re: JMS Point-to-point Sampler question
patches are always welcome. the current point-to-point jms sampler is pretty simple. you're correct that it wouldn't work with separate machines. the tricky part would be correlating the producer/consumer across separate machines. peter lin On 10/13/06, Jonas Lim [EMAIL PROTECTED] wrote: Hi Guys, I was looking at the JMS Point-to-point sampler and was wondering if it would be a good idea to have a seperate sampler for the producer sending the queue and the consumer consuming from it? (same as the jms publisher and jms subscriber samplers) I was looking at doing some jms performance test with the JMS broker, consumer and producer deployed on seperate machines each (trying to simulate a production environment) and I don't believe this is possible with the current design of the Point-to-point sampler. I'd like to contribute a patch for it if you guys think it's a good approach :) Regards, Jonas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMeter and radius sessions
jmeter does not support radius protocol currently. you can always write one yourself :) i don't know radius protocol, but I would imagine there's open source drivers for the protocol. peter On 9/19/06, Fabian Bieker [EMAIL PROTECTED] wrote: Hi, I want to write a jmeter plugin to stress-test a radius server. One thing i like to do is simulate a bunch of radius sessions with a duration of a few hours. A session consists of a Radius-Access-Request and a few Radius-Accounting-Start/Interum-Update/Stop Packets. Simply running the hole radius session in one call to sample() seems incorrect to me, because i do not know where to store the timing information like rtts about the different packets send/received. Is there an other way of doing this? I searched the ml-archive but was unable to find something helpful to my problem. Thanks for your help, Fabian Bieker -- Fabian Bieker, QA Netzwert AG, An den Treptowers 1, 12435 Berlin, Germany Voice: +49.30.5900800-0 Fax: +49.30.5900800-700 http://www.netzwert.ag - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMeter and radius sessions
you could try sticking it in the cookie manager. the cookie manager is just a place to hold name/value pair data. I imagine radius servers return a session id of some sort and require clients send the id. peter On 9/19/06, Fabian Bieker [EMAIL PROTECTED] wrote: Peter Lin wrote: jmeter does not support radius protocol currently. you can always write one yourself :) That's what i want to do. I already got a simple test version working. My only problem is how to deal with a hole radius session was i wrote in my first post. Fabian Bieker -- Fabian Bieker, QA Netzwert AG, An den Treptowers 1, 12435 Berlin, Germany Voice: +49.30.5900800-0 Fax: +49.30.5900800-700 http://www.netzwert.ag - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributing EJB sampler
thanks for the generous contributions. please go ahead and file bugzillas and attach the patch peter On 7/28/06, Guillaume Lasnier [EMAIL PROTECTED] wrote: Hi, I have just faxed the CCLA to the Apache Foundation and I am ready to contribute the Session Sampler to the project. There are also a few enhancements and bug fixes, some of which I have already submited through Bugzilla, that are needed to have the whole work. Let me present the Sampler in a few word. The sampler is designed as a protocol extension much like HTTP or JDBC.It allows Seamless invocation of Session Beans following the EJB 2.1 specification. It is composed of the following components - Session Bean Configuration : It is a configuration element that contains all necessary information to handle JNDI lookup/create Session Bean protocol plumbing. - Session Bean Sampler EJB Home and Remote interfaces are discovered from the classath. Session bean method invocation uses standard Java reflection APIs. Method parameters are defined by an extensible mechanism. A standard implementation allows preparation of parameter objects in a Bean Shell sampler. The GUI components that alllow to edit those controls is based on the existing testbeans mechanism. A custom editor has been introduced to allow selecting the session bean interface and method. I am looking forward to having some feed back from the community and sharing my contribution with all of you. -Message d'origine- De : sebb [EMAIL PROTECTED]@SUNGARD Envoyé : mercredi 8 février 2006 15:34 À : JMeter Developers List Objet : Re: Contributing EJB sampler Thanks! Sounds very useful. The best way to contribute patches is to create a Bugzilla issue, and then attach the files to that. == Having said that, for substantial contributions we would need to have some kind of assurance that the code is all your own work and that a suitable software grant is in place. For committers, this is handled by the CLA, see: http://www.apache.org/licenses/. I'm not entirely sure of the process where the code comes from elsewhere. == Another point to consider is whether the code uses any external libraries. If so, what are these, and what licenses apply to them? S. On 08/02/06, Guillaume Lasnier [EMAIL PROTECTED] wrote: I have developped an EJB Sampler for JMeter. It actually enables to sample request to Session Bean in a very simple way. It is working well now and I would like to offer it to the community. It was developped from the trunk branch and it includes the following : * a new ejb protocol that includes Configuration and Sampler TestElement based on the TestBean framework * few additions and correction from the core and jorphan modules How can I contribute to the project? -- Guillaume Lasnier Technical RD Phone : +33 1 55 39 18 74 Confidentiality Notice: The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Message confidentiel : Les informations contenues dans ce message sont destinées à un usage personnel et confidentiel du destinataire indiqué ci-dessus. Si le lecteur de ce message n'est pas le destinataire prévu, ou n'est pas une personne en charge de le délivrer au destinataire voulu, vous êtes par la présente informé que vous avez reçu ce document par erreur, et que tout examen, transmission, distribution ou copie de ce message est totalement interdit. Si vous avez reçu cette communication par erreur, nous vous remercions de bien vouloir nous avertir immédiatement par e-mail et de détruire le message d'origine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality Notice: The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have
Re: Is the new Report function really just a GUI with no functionality?
the Report GUI isn't done and doesn't work. Sorry for the confusion.
peter lin
On 6/19/06, itsecfan [EMAIL PROTECTED] wrote:
Hi all,
I am having trouble using the JMeter Report functionality which was newly
introduced in JMeter 2.2. I can click around and arrange things in the GUI
but it doesn't do anything if I start the report.
After having read around in the source it seems to me that this report
functionality isn't finished yet.
Take e. g. this code snippet from
org.apache.jmeter.report.gui.action.ReportStart:
public void doAction(ActionEvent e) {
if (e.getActionCommand().equals(ActionNames.ACTION_START)) {
popupShouldSave(e);
startEngine();
} else if (e.getActionCommand().equals(ActionNames.ACTION_STOP)) {
if (engine != null) {
ReportGuiPackage.getInstance
().getMainFrame().showStoppingMessage();
engine.stopTest();
engine = null;
}
} else if (e.getActionCommand().equals(ActionNames.ACTION_SHUTDOWN))
{
if (engine != null) {
ReportGuiPackage.getInstance
().getMainFrame().showStoppingMessage();
engine.askThreadsToStop();
engine = null;
}
}
}
protected void startEngine() {
_/**
* this will need to be changed
ReportGuiPackage gui = ReportGuiPackage.getInstance();
engine = new StandardJMeterEngine();
HashTree testTree = gui.getTreeModel().getTestPlan();
convertSubTree(testTree);
DisabledComponentRemover remover = new
DisabledComponentRemover(testTree);
testTree.traverse(remover);
testTree.add(testTree.getArray()[0], gui.getMainFrame());
log.debug(test plan before cloning is running version:
+ ((TestPlan) testTree.getArray
()[0]).isRunningVersion());
TreeCloner cloner = new TreeCloner(false);
testTree.traverse(cloner);
engine.configure(cloner.getClonedTree());
try {
engine.runTest();
} catch (JMeterEngineException e) {
JOptionPane.showMessageDialog(gui.getMainFrame(), e.getMessage(),
JMeterUtils
.getResString(Error Occurred),
JOptionPane.ERROR_MESSAGE);
}
log.debug(test plan after cloning and running test is running
version:
+ ((TestPlan) testTree.getArray()[0]).isRunningVersion());
*/
}
OK. This won't do anything IMHO.
Can you confirm this? Or did I miss some kind of code black magic?
What use would it be releasing something unfinished and putting it on the
New functionalities list? Wouldn't this confuse people (like me)?
Anyway, I still love JMeter. Keep up the good work.
Cheers,
Michael
-
Keine Lust auf Tippen? Rufen Sie Ihre Freunde einfach an.
Yahoo! Messenger. Jetzt installieren .
Re: [VOTE] Release JMeter 2.2RC1 (take 2)
+1 peter On 6/12/06, sebb [EMAIL PROTECTED] wrote: Not sure what happened to the previous e-mail; trying again. Here's my +1 Sebastian -- Forwarded message -- From: Sebastian Bazley (Apache) [EMAIL PROTECTED] Date: 11-Jun-2006 19:08 Subject: [VOTE] Release JMeter 2.2RC1 (take 2) To: JMeter Developers List jmeter-dev@jakarta.apache.org, Jakarta General List general@jakarta.apache.org, Jakarta Project Management Committee List [EMAIL PROTECTED] Just after voting started, a bug was raised. This has now been fixed. I also found that 2 sample files were missing from the distribution. So I've cut another release, which is now called 2.2RC1. Archives and MD5s are here: http://people.apache.org/builds/jakarta-jmeter/nightly/ Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.2RC1 Release notes here: http://people.apache.org/~sebb/jmeter-2.2RC1/changes.html The difference listing between 2.1.2RC1 and 2.2RC1 is in the file http://people.apache.org/~sebb/jmeter-2.2RC1/diff.txt Sorry for the repetition; hopefully this time it's all OK. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Candidate JMeter 2.1.2 RC1
haha I vote for 2006 :) for no reason other than it's like windows 95. peter On 6/8/06, sebb [EMAIL PROTECTED] wrote: On 09/06/06, Dion Gillard [EMAIL PROTECTED] wrote: On 6/9/06, sebb [EMAIL PROTECTED] wrote: The intention was to use this for identifying the source distribution archives. Perhaps it should be put elsewhere/renamed. Weird, I downloaded the zip, and it was included there. It's part of the build to include it in the source zip. All looks good to me, I'm +1 on the release. I'd prefer the version number to be higher, but it's not a blocker for me. OK, I'll see what others say. I'm inclining towards 2.2 myself. Or perhaps just call it JMeter 2006 ! ;-) S. On 09/06/06, Dion Gillard [EMAIL PROTECTED] wrote: Meant to send this to jmeter dev. Sorry. -- Forwarded message -- From: Dion Gillard [EMAIL PROTECTED] Date: Jun 9, 2006 11:13 AM Subject: Re: [VOTE] Release Candidate JMeter 2.1.2 RC1 To: Jakarta Project Management Committee List [EMAIL PROTECTED] Is there a reason for a 'Manifest' file, which appears to be in MANIFEST.MFformat in the jakarta-jmeter-2.1.2RC1 directory? On 6/9/06, sebb [EMAIL PROTECTED] wrote: I've created JMeter 2.1.2RC1 in the nightly directory: http://people.apache.org/builds/jakarta-jmeter/nightly/ Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.1.2RC1 http://people.apache.org/%7Esebb/jmeter-2.1.2RC1 Release notes here: http://people.apache.org/~sebb/jmeter-2.1.2RC1/changes.html http://people.apache.org/%7Esebb/jmeter-2.1.2RC1/changes.html All feedback welcome. sebb AT apache DOT org -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: JMeter 2.1.2 to drop support for Java 1.3
+1 from me on dropping 1.3 support. peter On 6/4/06, sebb [EMAIL PROTECTED] wrote: We had planned and announced that 2.1.2 would be the last release that supported Java 1.3. However it is proving tedious and time-consuming to fix JMeter so that it compiles under Java 1.3. We know from previous experience that it won't perform well under Java 1.3 - even if it can be built. So I'd like to drop the support for Java 1.3. If there are any major objections to this, please say so ASAP. However supporting Java 1.3 is likely to delay the release considerably (even more than it has been delayed already ...) S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Structure of JMeter (OO Design)
I took a quick look and it appears the GUI projects have higher dependency count. In the case of GUI's using Swing, I tend to think alot of it is due to the API design of swing. but I'm bias. peter On 6/4/06, Hayden Melton [EMAIL PROTECTED] wrote: It's just compilation dependencies that I have analysed, so dependencies due to reflection are NOT included. Quoting sebb [EMAIL PROTECTED]: Interesting reading. Just wondering if the dependency analysis takes account of reflection? S, On 04/06/06, Hayden Melton [EMAIL PROTECTED] wrote: Hi all, I am a PhD student at the University of Auckland, New Zealand. As part of my research I have performed an empirical study on a large corpus of open-source Java software. Several of the applications in the corpus (Ant, Tomcat, JMeter, POI) are from the Apache Software Foundation. If you are a developer of JMeter you might be interested to know that there are ~100 java source files all involved in a big dependency cycle (Strongly connected component). Other applications like Azureus, Soot and ArgoUML have strongly connected components involving ~1000 classes. In any case, a comparison of JMeter to all the other applications in the corpus is available on my webpage: http://www.cs.auckland.ac.nz/~hayden/corpus.htm The page also contains a graph that shows the evolution of dependencies through around 10 versions of JMeter, starting at JMeter-1.8.1. / Hayden Melton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Cactus/JMeter - testing.apache.org
+1 sebb is planning a release right now, so probably a good time to move to testing project peter On 3/24/06, Henri Yandell [EMAIL PROTECTED] wrote: If you vote +1 and want to be a part of the new Testing project, could you add your name to the proposal please. I've added my name so that I can help out with any migrational teething troubles, and to be an ASF member who is paying attention to the project [the board like to see some ASF members being aware of each project]. http://wiki.apache.org/jakarta/TLPCactusAndJMeter Felipe Leme has volunteered to be chair, though I'll let him add himself to the wiki page in place of the mysterious . So, [ ] +1 [ ] -1 because... Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Cactus/JMeter - testing.apache.org
+1 sebb is planning a release right now, so probably a good time to move to testing project peter On 3/24/06, Henri Yandell [EMAIL PROTECTED] wrote: If you vote +1 and want to be a part of the new Testing project, could you add your name to the proposal please. I've added my name so that I can help out with any migrational teething troubles, and to be an ASF member who is paying attention to the project [the board like to see some ASF members being aware of each project]. http://wiki.apache.org/jakarta/TLPCactusAndJMeter Felipe Leme has volunteered to be chair, though I'll let him add himself to the wiki page in place of the mysterious . So, [ ] +1 [ ] -1 because... Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 38681] - Include controllers do not seem to function in non-GUI mode
I wouldn't have thought of that trick myself, but glad to see you were able to find a way to get it to work in console mode. peter On 3/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38681. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38681 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2006-03-15 02:41 --- Checked a potential fix into the 2.1 branch. This is in the nightly build: 2-1.20060315 - please see if it works for you. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: listeners
there's a tutorial mike and I wrote here http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/xdocs/extending/jmeter_tutorial.pdf peter On 3/13/06, Simon De Uvarow [EMAIL PROTECTED] wrote: hello, i´m learning how extend the JMeter in case of it would necessary for some project. In the begin i was lost, but now, reading the code and examples i understand better how it works. I did a simple sampler. it executes a executable and i want to graph the response time and other things. Is there any documentation (instead of looking the code) that explain how work the diferents listeners? thanks, Simon
Re: listeners
http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleResult.java http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java Look at sample() method. sampleStart() - starts the timer setResponseData - sets the response data from the server setSuccessful - sets if the response was successful sampleEnd - stops the timer hope that helps peter On 3/13/06, Simon De Uvarow [EMAIL PROTECTED] wrote: thanks, i have read it, but it is very general. Would you be so kind as to explain me how to use the listeners? Indeed, what I really need to know is which data I need to enter into the SampleResult. Regards, Simon 2006/3/13, Peter Lin [EMAIL PROTECTED]: there's a tutorial mike and I wrote here http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/xdocs/extending/jmeter_tutorial.pdf peter On 3/13/06, Simon De Uvarow [EMAIL PROTECTED] wrote: hello, i´m learning how extend the JMeter in case of it would necessary for some project. In the begin i was lost, but now, reading the code and examples i understand better how it works. I did a simple sampler. it executes a executable and i want to graph the response time and other things. Is there any documentation (instead of looking the code) that explain how work the diferents listeners? thanks, Simon
Re: [Proposal] Make JMeter depend on Java 1.4 as a minimum
+ on 1.4 as minimum. peter On 3/4/06, sebb [EMAIL PROTECTED] wrote: Are there any objections to making JMeter depend on Java 1.4 as a minimum? At present, JMeter will run under Java 1.3. However it does not perform well, and there are some features that don't work properly. I think we should stop supporting Java 1.3 after the next release, i.e. after 2.1.2. Comments? S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r383138 - in /jakarta/jmeter/branches/rel-2-1: src/core/org/apache/jmeter/gui/action/ src/core/org/apache/jmeter/gui/util/ src/core/org/apache/jmeter/resources/ xdocs/
sweet!
that's quite useful feature to have sebb.
peter
On 3/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: sebb
Date: Sat Mar 4 07:33:52 2006
New Revision: 383138
URL: http://svn.apache.org/viewcvs?rev=383138view=rev
Log:
Add Save All As Image - saves entire JMeter screen
Modified:
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/ActionNames.java
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/SaveGraphics.java
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/util/MenuFactory.java
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/resources/messages.properties
jakarta/jmeter/branches/rel-2-1/xdocs/changes.xml
Modified:
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/ActionNames.java
URL:
http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/ActionNames.java?rev=383138r1=383137r2=383138view=diff
==
---
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/ActionNames.java
(original)
+++
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/ActionNames.java
Sat Mar 4 07:33:52 2006
@@ -65,6 +65,7 @@
public final static String SAVE_ALL_AS = save_all_as; //
$NON-NLS-1$
public final static String SAVE_AS = save_as; //
$NON-NLS-1$
public static final String SAVE_GRAPHICS= save_graphics; //
$NON-NLS-1$
+public static final String SAVE_GRAPHICS_ALL= save_graphics_all; //
$NON-NLS-1$
public static final String SSL_MANAGER = sslManager; //
$NON-NLS-1$
public static final String SUB_TREE_LOADED = sub_tree_loaded; //
$NON-NLS-1$
public static final String SUB_TREE_SAVED = sub_tree_saved; //
$NON-NLS-1$
Modified:
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/SaveGraphics.java
URL:
http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/SaveGraphics.java?rev=383138r1=383137r2=383138view=diff
==
---
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/SaveGraphics.java
(original)
+++
jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/gui/action/SaveGraphics.java
Sat Mar 4 07:33:52 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2001-2005 The Apache Software Foundation.
+ * Copyright 2001-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License); you
may not
* use this file except in compliance with the License. You may obtain a
copy
@@ -44,6 +44,7 @@
private static Set commands = new HashSet();
static {
commands.add(ActionNames.SAVE_GRAPHICS);
+commands.add(ActionNames.SAVE_GRAPHICS_ALL);
}
private static final String[] extensions
@@ -75,29 +76,39 @@
// get the JComponent from the visualizer
if (component instanceof Printable) {
comp = ((Printable)
component).getPrintableComponent();
-
- String filename;
- JFileChooser chooser =
FileDialoger.promptToSaveFile(GuiPackage.getInstance().getTreeListener()
-
.getCurrentNode().getName(), extensions);
- if (chooser == null) {
- return;
- }
- // Get the string given from the choose
and check
- // the file extension.
- filename = chooser.getSelectedFile
().getAbsolutePath();
- if (filename != null) {
- SaveGraphicsService save = new
SaveGraphicsService();
- String ext = filename.substring(
filename.length() - 4);
- String name = filename.substring(0,
filename.length() - 4);
- if (ext.equals(
SaveGraphicsService.PNG_EXTENSION)) {
- save.saveJComponent(name,
SaveGraphicsService.PNG, comp);
- } else if (ext.equals(
SaveGraphicsService.TIFF_EXTENSION)) {
- save.saveJComponent(name,
SaveGraphicsService.TIFF, comp);
- } else {
- save.saveJComponent(filename,
SaveGraphicsService.PNG, comp);
- }
- }
+saveImage(comp);
}
}
+if
Re: svn commit: r382133 - /jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/resources/messages.properties
I just noticed there's an error in the properties file distinguished seems to be mis-spelled peter On 3/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sebb Date: Wed Mar 1 11:37:32 2006 New Revision: 382133 URL: http://svn.apache.org/viewcvs?rev=382133view=rev Log: Threads = users Modified: jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/resources/messages.properties Modified: jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/resources/messages.properties URL: http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/resources/messages.properties?rev=382133r1=382132r2=382133view=diff == --- jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/resources/messages.properties (original) +++ jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/resources/messages.properties Wed Mar 1 11:37:32 2006 @@ -446,7 +446,7 @@ new=New newdn=New distinghuised name no=Norwegian -number_of_threads=Number of Threads\: +number_of_threads=Number of Threads (users)\: once_only_controller_title=Once Only Controller opcode=opCode open=Open... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 37278] - Include Controller: File Name field doesn't support variables or functions
since I wrote the IncludeController, I'm thinking it's a design flaw. I used the ModuleController as a starting point, but I think that was a mistake. Since the module controller copies test elements from the workspace to the JTree. the correct behavior probably should be to load the included module when the testElement is cloned by jmeter's engine class. peter On 2/16/06, Richard Gaywood [EMAIL PROTECTED] wrote: On 2/15/06, Oleg Gutsol [EMAIL PROTECTED] wrote: This could also fix the problem of not initializing the include module components when launched in non-gui mode. Actually, I'm looking at this issue now, maybe you can throw some light on why this is happening. Aha! I just opened a bug report about this: http://issues.apache.org/bugzilla/show_bug.cgi?id=38681 Is this a known issue, then? Does anyone have a fix for it? It's causing me some major headaches right now.
Re: DO NOT REPLY [Bug 37278] - Include Controller: File Name field doesn't support variables or functions
I just took a look at the IncludeController and it currently does the
following.
public Object clone() {
this.loadIncludedElements();
IncludeController clone = (IncludeController) super.clone();
clone.setIncludePath(this.getIncludePath());
if (this.SUBTREE != null) {
if (this.SUBTREE.keySet().size() == 1) {
Iterator itr = this.SUBTREE.keySet().iterator();
while (itr.hasNext()) {
this.SUB = (TestElement)itr.next();
}
}
clone.SUBTREE = (HashTree)this.SUBTREE.clone();
clone.SUB = (TestElement)this.SUB.clone();
}
return clone;
}
the load method does this:
protected HashTree loadIncludedElements() {
// only try to load the JMX test plan if there is one
final String includePath = getIncludePath();
if (includePath != null includePath.length() 0) {
try {
String file=prefix+includePath;
log.info(loadIncludedElements -- try to load included
module: +file);
InputStream reader = new FileInputStream(file);
this.SUBTREE = SaveService.loadTree(reader);
return this.SUBTREE;
} catch (NoClassDefFoundError ex) // Allow for missing optional
jars
{
String msg = ex.getMessage();
if (msg == null) {
msg = Missing jar file - see log for details;
log.warn(Missing jar file, ex);
}
JMeterUtils.reportErrorToUser(msg);
} catch (Exception ex) {
String msg = ex.getMessage();
if (msg == null) {
msg = Unexpected error - see log for details;
log.warn(Unexpected error, ex);
}
}
}
return this.SUBTREE;
}
my guess is that in non-gui mode, the clone method isn't getting called. a
minor change to it, might fix it.
peter
On 2/16/06, Oleg Gutsol [EMAIL PROTECTED] wrote:
Well, this is some light on the issue,
I'll see if I can do something about it - I really need this
controller working.
- Oleg.
On 16-Feb-06, at 11:33 AM, Peter Lin wrote:
since I wrote the IncludeController, I'm thinking it's a design
flaw. I used
the ModuleController as a starting point, but I think that was a
mistake.
Since the module controller copies test elements from the workspace
to the
JTree.
the correct behavior probably should be to load the included module
when the
testElement is cloned by jmeter's engine class.
peter
On 2/16/06, Richard Gaywood [EMAIL PROTECTED] wrote:
On 2/15/06, Oleg Gutsol [EMAIL PROTECTED] wrote:
This could also fix the problem of not initializing the include
module components when launched in non-gui mode.
Actually, I'm looking at this issue now, maybe you can throw some
light on why this is happening.
Aha! I just opened a bug report about this:
http://issues.apache.org/bugzilla/show_bug.cgi?id=38681
Is this a known issue, then? Does anyone have a fix for it? It's
causing
me
some major headaches right now.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 37278] - Include Controller: File Name field doesn't support variables or functions
yeah my quick and dirty implementation is way too quick and too dirty. I'll try to make some time this weekend. No promises, but I'll do what I can. peter On 2/16/06, sebb [EMAIL PROTECTED] wrote: Either way, the clone method needs to be rewritten so it only does a clone - otherwise RMI is going to have problems too ... S. On 16/02/06, sebb [EMAIL PROTECTED] wrote: On 16/02/06, Peter Lin [EMAIL PROTECTED] wrote: I just took a look at the IncludeController and it currently does the following. my guess is that in non-gui mode, the clone method isn't getting called. a minor change to it, might fix it. Could well be - there is no way to re-run a test in non-GUI mode, so maybe it does not copy the tree. In GUI mode, the tree can be changed while the test is running, so I assume JMeter needs to create a copy... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bug 35792] - No support for variable substitution in web service requests
interesting idea, that should work. the only other idea I had was to use XPath and replace the value that way. peter On 2/15/06, sebb [EMAIL PROTECTED] wrote: The external file could perhaps be read via a filter reader that did the translations. Not sure how to combine this with caching, unless perhaps the key was determined from the MD5 of the input after translation. If variables are only ever required as part of XML elements, then it might be easier (and cheaper) to update the DOM after parsing. S. --- Additional Comments From [EMAIL PROTECTED] 2006-02-15 03:19 --- I think the logic would need to be changed for it to work correctly. I believe currently, it just uses a document builder to parse the external file. to have it work, we would need to load the contents of the file as a string and allow JMeter to replace the variable. Then the sampler can parse the string content to make a DOM document. peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP?
hey sebb and mike, vote [ ] - Yes, we shall become head samurai on the campus (aka TLP) [ ] - No, the the boulder stay where it sits [ ] - neutral, the more things change the more they stay the same peter On 1/6/06, Henri Yandell [EMAIL PROTECTED] wrote: Pinging again, now I suspect people are just about back from holidays. Hen On 12/16/05, Henri Yandell [EMAIL PROTECTED] wrote: Resending this with a better subject line, easy to get lost in gmail with the old one. My fault, sorry. Hen On 12/12/05, Henri Yandell [EMAIL PROTECTED] wrote: On 8/2/05, sebb [EMAIL PROTECTED] wrote: I see no pressing need to become a TLP, but I'm not against the idea. I'd like to reopen this idea again :) I think it's time to simplify Jakarta, chiefly to: a) improve oversight by making me a middleman on less things. b) help provide Jakarta with identity by flattening Jakarta into a 'Apache Java Reusable Components' type concept. ie) Commons + other components. Some thoughts: 1) jmeter.apache.org? testing.apache.org? (or some other test thing). Would testing.apache.org contain cactus and jmeter? (obviously something to ask them too). 2) I'd like to offer to be on the new pmc mailing list to offer advice etc if you'd want me. Not that I'm starting to push or anything, but I am :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP?
On 1/6/06, Peter Lin [EMAIL PROTECTED] wrote: hey sebb and mike, vote [ ] - Yes, we shall become head samurai on the campus (aka TLP) [ ] - No, the the boulder stay where it sits [X] - neutral, the more things change the more they stay the same peter On 1/6/06, Henri Yandell [EMAIL PROTECTED] wrote: Pinging again, now I suspect people are just about back from holidays. Hen On 12/16/05, Henri Yandell [EMAIL PROTECTED] wrote: Resending this with a better subject line, easy to get lost in gmail with the old one. My fault, sorry. Hen On 12/12/05, Henri Yandell [EMAIL PROTECTED] wrote: On 8/2/05, sebb [EMAIL PROTECTED] wrote: I see no pressing need to become a TLP, but I'm not against the idea. I'd like to reopen this idea again :) I think it's time to simplify Jakarta, chiefly to: a) improve oversight by making me a middleman on less things. b) help provide Jakarta with identity by flattening Jakarta into a 'Apache Java Reusable Components' type concept. ie) Commons + other components. Some thoughts: 1) jmeter.apache.org ? testing.apache.org? (or some other test thing). Would testing.apache.org contain cactus and jmeter? (obviously something to ask them too). 2) I'd like to offer to be on the new pmc mailing list to offer advice etc if you'd want me. Not that I'm starting to push or anything, but I am :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP?
only if john belushi is our mascot :) joking aside, I'm guessing mike will be neutral also peter On 1/6/06, Henri Yandell [EMAIL PROTECTED] wrote: *grin* Dare I guess as to Mike's vote? Another option is the testing.apache.org one I threw out there. Cactus guys are sounding pretty interested in the idea. So more of a 'start a new campus' without the head samurai part. Hen On 1/6/06, Peter Lin [EMAIL PROTECTED] wrote: On 1/6/06, Peter Lin [EMAIL PROTECTED] wrote: hey sebb and mike, vote [ ] - Yes, we shall become head samurai on the campus (aka TLP) [ ] - No, the the boulder stay where it sits [X] - neutral, the more things change the more they stay the same peter On 1/6/06, Henri Yandell [EMAIL PROTECTED] wrote: Pinging again, now I suspect people are just about back from holidays. Hen On 12/16/05, Henri Yandell [EMAIL PROTECTED] wrote: Resending this with a better subject line, easy to get lost in gmail with the old one. My fault, sorry. Hen On 12/12/05, Henri Yandell [EMAIL PROTECTED] wrote: On 8/2/05, sebb [EMAIL PROTECTED] wrote: I see no pressing need to become a TLP, but I'm not against the idea. I'd like to reopen this idea again :) I think it's time to simplify Jakarta, chiefly to: a) improve oversight by making me a middleman on less things. b) help provide Jakarta with identity by flattening Jakarta into a 'Apache Java Reusable Components' type concept. ie) Commons + other components. Some thoughts: 1) jmeter.apache.org ? testing.apache.org? (or some other test thing). Would testing.apache.org contain cactus and jmeter? (obviously something to ask them too). 2) I'd like to offer to be on the new pmc mailing list to offer advice etc if you'd want me. Not that I'm starting to push or anything, but I am :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improvements in Aggregate Graph listener
sure, please open a enhancement bugzilla and add an attachment. I'll be on vacation next week, so I can check in the change then. thanks peter On 12/15/05, Quasar [EMAIL PROTECTED] wrote: Good morning, In version 2.1.1 I've changed the AxisGraph class to create fancier (IMHO) bar charts. Moreover it computes automatically the y-axis limit. I was wondering if it'd be possible to include this updated feature in future releases Thanks. Quasar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Axis and Apache SOAP
hehe, I've used SOAP, but honestly, I can't say that it's pleasurable or even good. URL - this is required by all the webservice toolkits SOAPAction - currently, this is only required and used by microsoft's .NET Parameters - there's generally 2 preferred approach for creating the SOAPEnvelop message. 1 use objects and serialize to a valid SOAPEnvelope. 2. use a DOM object. apache SOAP took the DOM route, which many people disliked, so Axis was born. that's a gross over generalization. the easiest way to use soap is to expose a class in tomcat and the Axis framework automatically generates the WSDL, which includes the XML Schema. Unlike Apache SOAP, Axis has the ability to generate classes from the WSDL using the wsdl4j, which was donated by IBM I think. My original thought was to this. 1. user enters WSDL url 2. jmeter uses Axis to generate the java classes 3. jmeter loads the jar and then provides a drop down of the soap messages 4. user selects a soap message, which tells jmeter which objects are used 5. user provides values for the object(s) 6. the objects are passed to Axis, which serializes it to the proper SOAPEnvelope the difficulty I had was figuring out an elegant way to handle 3-5. If you have some ideas, I'm all ears :) it would be nice to do it that way, but not sure how easy it would be. peter On 12/12/05, sebb [EMAIL PROTECTED] wrote: Perhaps the way to approach this is to see what what would like to see in the GUI, and progress from there? The parameters would need to include: URL Soap Action Parameters Not having used Soap in anger, I'm not sure what else would be needed/useful. S. On 12/12/05, Peter Lin [EMAIL PROTECTED] wrote: the recommended method of using Axis is to use objects directly and bypass XML documents. when I first started working on an Axis sampler last year, it was with the goal of using objects directly. I never figured out a good way to use the object approach in JMeter, so I never finished it. peter On 12/12/05, sebb [EMAIL PROTECTED] wrote: Isn't that what the current sampler does? Seems to me the Axis approach is to extract the variable parts and provide those as parameters, rather than needing to wrap it all in XML. S. On 12/12/05, Peter Lin [EMAIL PROTECTED] wrote: looks like if I use AXIS specific API, I may be able to create SOAP messages directly from XML documents. I'll try to work on it next week and see how it goes peter On 12/9/05, sebb [EMAIL PROTECTED] wrote: The WebService(SOAP) sampler currently uses Apache SOAP, which no longer seems to be maintained. Perhaps we should look at creating a new sampler that uses Apache Axis? Looks quite simple to use: http://ws.apache.org/axis/java/user-guide.html#BasicsGettingStarted It takes a different approach to building the Soap messages - as far as I can see, there is no need to mess around with XML, just need to provide the parameters and Axis takes care of the rest. Just need to decide how to provide the parameters via the GUI - I've not used Soap in earnest, so I don't know what would make sense for testing Soap. Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Axis and Apache SOAP
looks like if I use AXIS specific API, I may be able to create SOAP messages directly from XML documents. I'll try to work on it next week and see how it goes peter On 12/9/05, sebb [EMAIL PROTECTED] wrote: The WebService(SOAP) sampler currently uses Apache SOAP, which no longer seems to be maintained. Perhaps we should look at creating a new sampler that uses Apache Axis? Looks quite simple to use: http://ws.apache.org/axis/java/user-guide.html#BasicsGettingStarted It takes a different approach to building the Soap messages - as far as I can see, there is no need to mess around with XML, just need to provide the parameters and Axis takes care of the rest. Just need to decide how to provide the parameters via the GUI - I've not used Soap in earnest, so I don't know what would make sense for testing Soap. Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Axis and Apache SOAP
I looked into it a while back, but Axis is quite different than Apache SOAP. I'll investigate further and report back peter On 12/9/05, sebb [EMAIL PROTECTED] wrote: The WebService(SOAP) sampler currently uses Apache SOAP, which no longer seems to be maintained. Perhaps we should look at creating a new sampler that uses Apache Axis? Looks quite simple to use: http://ws.apache.org/axis/java/user-guide.html#BasicsGettingStarted It takes a different approach to building the Soap messages - as far as I can see, there is no need to mess around with XML, just need to provide the parameters and Axis takes care of the rest. Just need to decide how to provide the parameters via the GUI - I've not used Soap in earnest, so I don't know what would make sense for testing Soap. Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 37160] - Scalable distributed testing
ignore these bugzilla messages, when I opened deskzilla, it resent these old comments again. sorry about that. peter On 12/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37160. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37160 --- Additional Comments From [EMAIL PROTECTED] 2005-12-07 20:48 --- Do you know of alternative/additional TreeTable model implementations? Java desktop isn't open source, or atleast I don't think it is. I would rather not write a new TreeTable model if I don't have to. there's got to be an open source implementation of TreeTableModel. I found this old article from 97/98 http://java.sun.com/products/jfc/tsc/articles/treetable1/ it's easy enough to write a new one, but I'd rather not re-invent the wheel if I don't have to. peter lin -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r348514 - /jakarta/jmeter/branches/rel-2-1/bin/testfiles/
user error on my part. I selected the 2 png files, right click, team - add to svn ignore. is there some other way of doing the svn ignore? must be user error on my part with subversion peter On 11/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sebb Date: Wed Nov 23 10:46:24 2005 New Revision: 348514 URL: http://svn.apache.org/viewcvs?rev=348514view=rev Log: Update ignore for test output files Modified: jakarta/jmeter/branches/rel-2-1/bin/testfiles/ (props changed) Propchange: jakarta/jmeter/branches/rel-2-1/bin/testfiles/ -- --- svn:ignore (original) +++ svn:ignore Wed Nov 23 10:46:24 2005 @@ -1,2 +1,5 @@ + configurationTest.xml *.jmx.out +Sample_Line_Graph.png +Sample_Chart.png - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r348514 - /jakarta/jmeter/branches/rel-2-1/bin/testfiles/
haha... user error on my part. peter On 11/23/05, sebb [EMAIL PROTECTED] wrote: That is the way to do it, but you then need to commit the change ;-) S. On 23/11/05, Peter Lin [EMAIL PROTECTED] wrote: user error on my part. I selected the 2 png files, right click, team - add to svn ignore. is there some other way of doing the svn ignore? must be user error on my part with subversion peter On 11/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sebb Date: Wed Nov 23 10:46:24 2005 New Revision: 348514 URL: http://svn.apache.org/viewcvs?rev=348514view=rev Log: Update ignore for test output files Modified: jakarta/jmeter/branches/rel-2-1/bin/testfiles/ (props changed) Propchange: jakarta/jmeter/branches/rel-2-1/bin/testfiles/ -- --- svn:ignore (original) +++ svn:ignore Wed Nov 23 10:46:24 2005 @@ -1,2 +1,5 @@ + configurationTest.xml *.jmx.out +Sample_Line_Graph.png +Sample_Chart.png - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r348601 - /jakarta/jmeter/branches/rel-2-1/build.xml
oops, I was so focused on the reporting tool, I forgot to add the dependency
to the unit test task. thanks again for catching that sebb.
peter
On 11/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: sebb
Date: Wed Nov 23 16:30:38 2005
New Revision: 348601
URL: http://svn.apache.org/viewcvs?rev=348601view=rev
Log:
Test depends on reports
Modified:
jakarta/jmeter/branches/rel-2-1/build.xml
Modified: jakarta/jmeter/branches/rel-2-1/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/build.xml?rev=348601r1=348600r2=348601view=diff
==
--- jakarta/jmeter/branches/rel-2-1/build.xml (original)
+++ jakarta/jmeter/branches/rel-2-1/build.xml Wed Nov 23 16:30:38 2005
@@ -557,6 +557,7 @@
pathelement location=${build.mail}/
pathelement location=${build.monitor.components}/
pathelement location=${build.monitor.model}/
+pathelement location=${build.report}/
pathelement location=${build.tcp}/
path refid=classpath/
/classpath
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Require minimum of Java 1.4 for next release of JMeter
Given the results of the survey you took over the summer, I would think it's pretty safe. Jdk1.3.x is rather old now and supporting it is un-necessary over head. we probably should make a branch and document it on the website in case a few straggling users are forced to use jdk1.3.1. Even IBM has jdk1.4 now, so there really shouldn't be any platform stuck on jdk1.3.1. +1 on moving forward with jdk1.4 peter On 11/22/05, sebb [EMAIL PROTECTED] wrote: JMeter 2.1.1 runs using Java 1.3 or later, as do most earlier versions of JMeter. However, it is very time-consuming ensuring that JMeter will run on Java 1.3; and even though JMeter does run on 1.3, it does not perform very well. There are also some functions of JMeter that don't work properly, because of features in 1.3 that won't now be fixed. Therefore, I'd like to suggest that we stop supporting Java 1.3, and assume a minimum of Java 1.4 from now on. Comments? S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What to do about the Entry class?
actually I don't understand this part of jmeter engine, so I'm not sure what
the implications are. perhaps mike knows. I'm fine with removing it,
assuming we really don't need it.
peter
On 11/20/05, sebb [EMAIL PROTECTED] wrote:
The Entry class does not seem to be used at present.
JMeterThread does not create an Entry instance, and calls sampler.sample
(null).
So none of the samplers can use the Entry parameter at present.
Should we therefore remove it, or is there something useful that could
be done with the parameter?
==
If it is to be removed, I think it can be done without requiring any
classes to be rewritten:
Sampler Interface:
deprecate the sample(Entry) method
add the new method: public SampleResult sample();
to prevent this causing problems for Samplers, add the following to
AbstractSampler:
// @deprecated - use sample()
public SampleResult sample(Entry e){
throw new UnsupportedOperationException(Use sample() instead);
}
public SampleResult sample(){
return sample(null);
}
The sample() method is intended to be overridden by all samplers.
At some later stage, the method could be removed from the abstract
sampler.
This would then force any samplers to implement it.
Thoughts?
S.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX backwards file compatibility
I think it's ok as long as we give users a warning. I like the new format, and think it's better. There may be users who have a large set of test plans, who might want to upgrade, but would not due to incompatability in jmx format. I think it's reasonable to say starting with version x.x.x, new versions may not gaurantee backward compatability. This is assuming those with large set of testplans are fine with using older versions indefinitely. peter On 11/18/05, sebb [EMAIL PROTECTED] wrote: Is there any need to maintain backwards JMX file compatibility? It would be easier if not ... Perhaps the original (Avalon) format can be used as an common file format, as we're won't change that now. Any thoughts? S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r345368 - in /jakarta/jmeter/branches/rel-2-1: bin/jmeter.properties src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java xdocs/changes.xml
Sweet! I didn't even know httpclient had that features. thanks for
implementing it sebb
peter
On 11/17/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: sebb
Date: Thu Nov 17 15:40:54 2005
New Revision: 345368
URL: http://svn.apache.org/viewcvs?rev=345368view=rev
Log:
Slow connection emulation for HttpClient
Modified:
jakarta/jmeter/branches/rel-2-1/bin/jmeter.properties
jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java
jakarta/jmeter/branches/rel-2-1/xdocs/changes.xml
Modified: jakarta/jmeter/branches/rel-2-1/bin/jmeter.properties
URL:
http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/bin/jmeter.properties?rev=345368r1=345367r2=345368view=diff
==
--- jakarta/jmeter/branches/rel-2-1/bin/jmeter.properties (original)
+++ jakarta/jmeter/branches/rel-2-1/bin/jmeter.properties Thu Nov 17
15:40:54 2005
@@ -174,6 +174,10 @@
# Set the http version (defaults to 1.1)
#httpclient.version=1.0
+# Define characters per second 0 to emulate slow connections
+#httpclient.socket.http.cps=0
+#httpclient.socket.https.cps=0
+
# Sample logging levels for HttpClient
# Note that full category names are used, i.e. must include the org.apache
.
# Info level produces no output:
Modified:
jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java
URL:
http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java?rev=345368r1=345367r2=345368view=diff
==
---
jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java
(original)
+++
jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java
Thu Nov 17 15:40:54 2005
@@ -33,8 +33,10 @@
import org.apache.commons.httpclient.DefaultMethodRetryHandler;
import org.apache.commons.httpclient.HostConfiguration;
import org.apache.commons.httpclient.HttpConnection;
+import org.apache.commons.httpclient.HttpConstants;
import org.apache.commons.httpclient.HttpMethod;
import org.apache.commons.httpclient.HttpMethodBase;
+import org.apache.commons.httpclient.HttpRecoverableException;
import org.apache.commons.httpclient.HttpState;
import org.apache.commons.httpclient.NTCredentials;
import org.apache.commons.httpclient.methods.EntityEnclosingMethod;
@@ -48,6 +50,7 @@
import org.apache.jmeter.protocol.http.control.CookieManager;
import org.apache.jmeter.protocol.http.control.HeaderManager;
import org.apache.jmeter.protocol.http.control.Cookie;
+import org.apache.jmeter.protocol.http.util.SlowHttpClientSocketFactory;
import org.apache.jmeter.testelement.property.CollectionProperty;
import org.apache.jmeter.testelement.property.PropertyIterator;
@@ -63,19 +66,42 @@
*
*/
public class HTTPSampler2 extends HTTPSamplerBase {
- transient private static Logger log = LoggingManager.getLoggerForClass
();
+ private static final Logger log = LoggingManager.getLoggerForClass();
+
+ private static final String PROTOCOL_HTTP = http; // $NON-NLS-1$
/*
* Connection is re-used within the thread if possible
*/
transient private static ThreadLocal httpClients = null;
+ private static boolean basicAuth
+ = JMeterUtils.getPropDefault(httpsampler2.basicauth, false); //
$NON-NLS-1$
+
static {
// Set the default to Avalon Logkit, if not already defined:
if (System.getProperty(org.apache.commons.logging.Log) == null) { //
$NON-NLS-1$
System.setProperty(org.apache.commons.logging.Log // $NON-NLS-1$
, org.apache.commons.logging.impl.LogKitLogger); // $NON-NLS-1$
}
+ log.info(httpsampler2.basicauth= + basicAuth); // $NON-NLS-1$
+
+ int cps =
+ JMeterUtils.getPropDefault(httpclient.socket.http.cps, 0); //
$NON-NLS-1$
+
+ if (cps 0) {
+ log.info(Setting up HTTP SlowProtocol, cps=+cps);
+ Protocol.registerProtocol(PROTOCOL_HTTP,
+ new Protocol(PROTOCOL_HTTP,new
SlowHttpClientSocketFactory(cps),DEFAULT_HTTP_PORT));
+ }
+ cps =
+ JMeterUtils.getPropDefault(httpclient.socket.https.cps, 0); //
$NON-NLS-1$
+
+ if (cps 0) {
+ log.info(Setting up HTTPS SlowProtocol, cps=+cps);
+ Protocol.registerProtocol(PROTOCOL_HTTPS,
+ new Protocol(PROTOCOL_HTTPS,new
SlowHttpClientSocketFactory(cps),DEFAULT_HTTPS_PORT));
+ }
}
/*
@@ -86,13 +112,6 @@
private transient HttpState httpState = null;
- private static boolean basicAuth
- = JMeterUtils.getPropDefault(httpsampler2.basicauth, false); //
$NON-NLS-1$
-
- static {
- log.info(httpsampler2.basicauth= + basicAuth); // $NON-NLS-1$
- }
-
/**
* Constructor for the HTTPSampler2 object.
*/
@@ -157,14 +176,14 @@
}
}
+ // Convert \ to \\
private String encode(String value) {
StringBuffer newValue = new StringBuffer();
- char[]
[site traffic statistics] - idea
I signed up for google analytics for fun and it looks quite useful. Do we want to setup an account for jmeter and traffic our traffic stats with google analytics? peter
Re: [site traffic statistics] - idea
it does what webtrends does. with the addition that google will run nightly reports for you and provide additional details. I had to add a short javascript before /head tag on my blog and it was done. compared to what we currently have for traffic stats, it does quite a bit more. peter On 11/16/05, sebb [EMAIL PROTECTED] wrote: What does it offer? On 16/11/05, Peter Lin [EMAIL PROTECTED] wrote: I signed up for google analytics for fun and it looks quite useful. Do we want to setup an account for jmeter and traffic our traffic stats with google analytics? peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site traffic statistics] - idea
here is what apache currently has in the way of nightly stats. http://people.apache.org/~vgritsenko/stats/index.html it only covers certain projects and doesn't show jmeter level stats. peter On 11/16/05, sebb [EMAIL PROTECTED] wrote: What does it offer? On 16/11/05, Peter Lin [EMAIL PROTECTED] wrote: I signed up for google analytics for fun and it looks quite useful. Do we want to setup an account for jmeter and traffic our traffic stats with google analytics? peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help to build JMeter from source code
we need to update the docs to reflect subversion, since jmeter recently changed to subversion from CVS. peter On 11/16/05, Sam Liu [EMAIL PROTECTED] wrote: Thanks, sebb. But the cvs server connection failed, I guess this could be our company firewall blocking the connection, is there any other way to get complete source code and needed resource to build JMeter from Eclipse? -Sam -Original Message- From: sebb [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 16, 2005 6:05 AM To: JMeter Developers List Subject: Re: Need help to build JMeter from source code Have you looked at the JMeter Wiki? e.g. http://wiki.apache.org/jakarta-jmeter/JMeterAndEclipseHowTo and http://wiki.apache.org/jakarta-jmeter/DeveloperManual/JMeterAnt S. On 16/11/05, Sam Liu [EMAIL PROTECTED] wrote: Hi JMeter Dev group, We just started to use JMeter for load and some feature verification testing, and there are some new requirements come in and needs to enhancement. So, I tried to setup JMeter build environment but could not compile it. The preferred compiler environment would be Eclipse with Ant. Really appreciate that if someone can help. Sam Sam Liu WebEx Communications, Inc. phone: 408.566.7763 3979 Freedom Circle, 10th Floor Santa Clara, CA 95054 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unit tests
ahh ok. I'll give that a try peter On 11/15/05, sebb [EMAIL PROTECTED] wrote: On 15/11/05, Peter Lin [EMAIL PROTECTED] wrote: Hi sebb, I was writing an unit test for the reporting and tried to run TestSaveService, but I got some odd output in eclipse. I used the JUnit tool in eclipse and tried to run the test. the output for Setting JMeter home is bin\bin\ Can't find jmetertest.properties - trying bin directory Setting user.dir=C:\eclipse3\workspace\jmeter-21\bin Initializing Properties: bin/jmetertest.properties Setting JMeter home: C:\eclipse3\workspace\jmeter-21\bin\bin\.. java.version=1.4.2_08 java.vendor=Sun Microsystems Inc. java.home=C:\jdk1.4.2\jre user.home=C:\Documents and Settings\pete.PEGASUS user.dir=C:\eclipse3\workspace\jmeter-21\bin java.class.version=48.0 os.name=Windows XP os.version=5.1 os.arch=x86 java.class.path=/c:/eclipse3/plugins/org.eclipse.jdt.junit_3.0.1/junitsupport.jar ;/c:/eclipse3/plugins/org.eclipse.jdt.junit.runtime_3.0.2/junitruntime.jar;C:\eclipse3\workspace\jmeter-21\build;C:\eclipse3\workspace\jmeter-21\lib\xstream- 1.1.2.jar ;C:\eclipse3\workspace\jmeter-21\lib\activation.jar;C:\eclipse3\workspace\jmeter-21\lib\ant.jar;C:\eclipse3\workspace\jmeter-21\lib\avalon- framework-4.1.4.jar;C:\eclipse3\workspace\jmeter-21\lib\batik- awt-util.jar ;C:\eclipse3\workspace\jmeter-21\lib\bsf.jar;C:\eclipse3\workspace\jmeter-21\lib\bsh- 2.0b1.jar;C:\eclipse3\workspace\jmeter-21\lib\commons-collections.jar ;C:\eclipse3\workspace\jmeter-21\lib\commons-httpclient-2.0.jar ;C:\eclipse3\workspace\jmeter-21\lib\commons-logging.jar ;C:\eclipse3\workspace\jmeter-21\lib\excalibur-datasource-1.1.1.jar ;C:\eclipse3\workspace\jmeter-21\lib\excalibur-instrument-1.0.jar ;C:\eclipse3\workspace\jmeter-21\lib\excalibur-logger-1.1.jar ;C:\eclipse3\workspace\jmeter-21\lib\excalibur-pool-1.2.jar ;C:\eclipse3\workspace\jmeter-21\lib\htmlparser.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_javax_crypto.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_jce.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_jce_demo.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_ssl.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_ssl_demo.jar;C:\eclipse3\workspace\jmeter-21\lib\imap.jar;C:\eclipse3\workspace\jmeter-21\lib\jakarta- oro-2.0.8.jar;C:\eclipse3\workspace\jmeter-21\lib\jCharts-0.7.5.jar ;C:\eclipse3\workspace\jmeter-21\lib\jdom-1.0.jar ;C:\eclipse3\workspace\jmeter-21\lib\jms.jar;C:\eclipse3\workspace\jmeter-21\lib\jndi.jar;C:\eclipse3\workspace\jmeter-21\lib\jorphan.jar;C:\eclipse3\workspace\jmeter-21\lib\js.jar;C:\eclipse3\workspace\jmeter-21\lib\jsch- 0.1.19.jar ;C:\eclipse3\workspace\jmeter-21\lib\junit.jar;C:\eclipse3\workspace\jmeter-21\lib\logkit- 1.2.jar ;C:\eclipse3\workspace\jmeter-21\lib\mail.jar;C:\eclipse3\workspace\jmeter-21\lib\mailapi.jar;C:\eclipse3\workspace\jmeter-21\lib\smtp.jar;C:\eclipse3\workspace\jmeter-21\lib\soap.jar;C:\eclipse3\workspace\jmeter-21\lib\Tidy.jar;C:\eclipse3\workspace\jmeter-21\lib\velocity- 1.4-dev.jar ;C:\eclipse3\workspace\jmeter-21\lib\xalan.jar;C:\eclipse3\workspace\jmeter-21\lib\xercesImpl.jar;C:\eclipse3\workspace\jmeter-21\lib\xml- apis.jar;C:\eclipse3\workspace\jmeter-21\lib\xpp3-1.1.3.4.D.jar ;C:\eclipse3\workspace\jmeter-21\lib\xpp3_min-1.1.3.4.I.jar You know why that happens? Most of the above is normal output (though it is in the log file usually). You need to make sure the test run starts from the bin directory, as windows java does not fully support changing user.dir after the JVM has started. Perhaps I should change the JUnit setup to insist on the correct setting rather than hoping it works (it does for tests that don't try to open files). If your test uses any properties, then you need to ensure that the ApacheJMeter_core.jar is in the classpath. If you run test from the Ant script, you don't need to do any of this. S. peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unit tests
Hi sebb, I was writing an unit test for the reporting and tried to run TestSaveService, but I got some odd output in eclipse. I used the JUnit tool in eclipse and tried to run the test. the output for Setting JMeter home is bin\bin\ Can't find jmetertest.properties - trying bin directory Setting user.dir=C:\eclipse3\workspace\jmeter-21\bin Initializing Properties: bin/jmetertest.properties Setting JMeter home: C:\eclipse3\workspace\jmeter-21\bin\bin\.. java.version=1.4.2_08 java.vendor=Sun Microsystems Inc. java.home=C:\jdk1.4.2\jre user.home=C:\Documents and Settings\pete.PEGASUS user.dir=C:\eclipse3\workspace\jmeter-21\bin java.class.version=48.0 os.name=Windows XP os.version=5.1 os.arch=x86 java.class.path=/c:/eclipse3/plugins/org.eclipse.jdt.junit_3.0.1/junitsupport.jar ;/c:/eclipse3/plugins/org.eclipse.jdt.junit.runtime_3.0.2/junitruntime.jar;C:\eclipse3\workspace\jmeter-21\build;C:\eclipse3\workspace\jmeter-21\lib\xstream- 1.1.2.jar ;C:\eclipse3\workspace\jmeter-21\lib\activation.jar;C:\eclipse3\workspace\jmeter-21\lib\ant.jar;C:\eclipse3\workspace\jmeter-21\lib\avalon- framework-4.1.4.jar;C:\eclipse3\workspace\jmeter-21\lib\batik-awt-util.jar ;C:\eclipse3\workspace\jmeter-21\lib\bsf.jar;C:\eclipse3\workspace\jmeter-21\lib\bsh- 2.0b1.jar;C:\eclipse3\workspace\jmeter-21\lib\commons-collections.jar ;C:\eclipse3\workspace\jmeter-21\lib\commons-httpclient-2.0.jar ;C:\eclipse3\workspace\jmeter-21\lib\commons-logging.jar ;C:\eclipse3\workspace\jmeter-21\lib\excalibur-datasource-1.1.1.jar ;C:\eclipse3\workspace\jmeter-21\lib\excalibur-instrument-1.0.jar ;C:\eclipse3\workspace\jmeter-21\lib\excalibur-logger-1.1.jar ;C:\eclipse3\workspace\jmeter-21\lib\excalibur-pool-1.2.jar ;C:\eclipse3\workspace\jmeter-21\lib\htmlparser.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_javax_crypto.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_jce.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_jce_demo.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_ssl.jar;C:\eclipse3\workspace\jmeter-21\lib\iaik_ssl_demo.jar;C:\eclipse3\workspace\jmeter-21\lib\imap.jar;C:\eclipse3\workspace\jmeter-21\lib\jakarta- oro-2.0.8.jar;C:\eclipse3\workspace\jmeter-21\lib\jCharts-0.7.5.jar ;C:\eclipse3\workspace\jmeter-21\lib\jdom-1.0.jar ;C:\eclipse3\workspace\jmeter-21\lib\jms.jar;C:\eclipse3\workspace\jmeter-21\lib\jndi.jar;C:\eclipse3\workspace\jmeter-21\lib\jorphan.jar;C:\eclipse3\workspace\jmeter-21\lib\js.jar;C:\eclipse3\workspace\jmeter-21\lib\jsch- 0.1.19.jar ;C:\eclipse3\workspace\jmeter-21\lib\junit.jar;C:\eclipse3\workspace\jmeter-21\lib\logkit- 1.2.jar ;C:\eclipse3\workspace\jmeter-21\lib\mail.jar;C:\eclipse3\workspace\jmeter-21\lib\mailapi.jar;C:\eclipse3\workspace\jmeter-21\lib\smtp.jar;C:\eclipse3\workspace\jmeter-21\lib\soap.jar;C:\eclipse3\workspace\jmeter-21\lib\Tidy.jar;C:\eclipse3\workspace\jmeter-21\lib\velocity- 1.4-dev.jar ;C:\eclipse3\workspace\jmeter-21\lib\xalan.jar;C:\eclipse3\workspace\jmeter-21\lib\xercesImpl.jar;C:\eclipse3\workspace\jmeter-21\lib\xml- apis.jar;C:\eclipse3\workspace\jmeter-21\lib\xpp3-1.1.3.4.D.jar ;C:\eclipse3\workspace\jmeter-21\lib\xpp3_min-1.1.3.4.I.jar You know why that happens? peter
Re: [EMAIL PROTECTED]: Project jakarta-jmeter-21-svn (in module jakarta-jmeter-21) failed
oops, I'll fix this in a few hours. I forgot to check in some updates. peter On 11/9/05, Gump-build [EMAIL PROTECTED] wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-jmeter-21-svn has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-jmeter-21-svn : Pure Java load testing and performance measurement tool. ... - jakarta-jmeter-21-test : Pure Java load testing and performance measurement tool. ... Full details are available at: http://vmgump.apache.org/gump/public/jakarta-jmeter-21/jakarta-jmeter-21-svn/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [jakarta-jmeter-2_1_09112005_lib.zip] identifier set to output basename: [jakarta-jmeter-2_1_09112005_lib.zip] -DEBUG- Output [jakarta-jmeter-2_1_09112005_bin.zip] identifier set to output basename: [jakarta-jmeter-2_1_09112005_bin.zip] -DEBUG- Output [NOTICE] identifier set to output basename: [NOTICE] -DEBUG- Output [jakarta-jmeter-2_1_09112005_src.zip] identifier set to output basename: [jakarta-jmeter-2_1_09112005_src.zip] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-jmeter-21/jakarta-jmeter-21-svn/gump_work/build_jakarta-jmeter-21_jakarta-jmeter-21-svn.html Work Name: build_jakarta-jmeter-21_jakarta-jmeter-21-svn (Type: Build) Work ended in a state of : Failed Elapsed: 26 secs Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main - Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only'- Dversion.projectfile=$Revision: 330251 $' -Djmeter.version=2_1_09112005 - Dgump.run=true '-Ddate.projectfile=$Date: 2005-11-02 05:46:34 -0800 (Wed, 02 Nov 2005) $' gump-build [Working Directory: /usr/local/gump/public/workspace/jakarta-jmeter-21] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-jmeter-21/build/core:/usr/local/gump/public/workspace/jakarta-jmeter-21/build/htmlparser:/usr/local/gump/public/workspace/jakarta-jmeter-21/build/jorphan:/usr/local/gump/public/workspace/jakarta-jmeter-21/build/components:/usr/local/gump/public/workspace/jakarta-jmeter-21/build/protocol/http:/usr/local/gump/public/workspace/jakarta-jmeter-21/build/monitor/model:/usr/local/gump/public/workspace/jakarta-jmeter-21/lib/avalon-
Re: svn commit: r330428 - /jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java
ok, sounds cool :) peter On 11/3/05, sebb [EMAIL PROTECTED] wrote: Something similar happened to me. The // $NON-NLS-1$ comment appears to have been swallowed by the string. I'll remove it. The idea is to split the CVS marker $Revision: n.mm http://n.mm $ into a prefix and a suffix, so one can extract the n.mm http://n.mm (or nn in the case of SVN) but it looks like this is hitting an SVN or possibly Subclipse bug. BTW, the // $NON-NLS-1$ comment is intended to tell Eclipse that the string is non-language specific - i.e. it does not have to be translated for localisation purposes. S. On 03/11/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: woolfel Date: Wed Nov 2 19:30:20 2005 New Revision: 330428 URL: http://svn.apache.org/viewcvs?rev=330428view=rev Log: after I updated from SVN, the string appeared to be missing the closing double quote and semicolon. fixing it so it compiles peter lin Modified: jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java Modified: jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java URL: http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java?rev=330428r1=330427r2=330428view=diff == --- jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java (original) +++ jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java Wed Nov 2 19:30:20 2005 @@ -240,7 +240,7 @@ // Extract version digits from String of the form #Revision: n.mmhttp://n.mm# // (where # is actually $ above) - private static final String REVPFX = $Revision$NON-NLS-1$ + private static final String REVPFX = $Revision$NON-NLS-1$; private static final String REVSFX = $; // $NON-NLS-1$ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r330428 - /jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java
it's the wonderful part of switching to CVS. thing that used to work now get to break. peter On 11/3/05, sebb [EMAIL PROTECTED] wrote: Just tried again, and the comment is being swallowed by the string. I'll fix it by removing it, and try raising an SVN bug. S. On 03/11/05, Peter Lin [EMAIL PROTECTED] wrote: ok, sounds cool :) peter On 11/3/05, sebb [EMAIL PROTECTED] wrote: Something similar happened to me. The // $NON-NLS-1$ comment appears to have been swallowed by the string. I'll remove it. The idea is to split the CVS marker $Revision: n.mm http://n.mm http://n.mm $ into a prefix and a suffix, so one can extract the n.mm http://n.mm http://n.mm (or nn in the case of SVN) but it looks like this is hitting an SVN or possibly Subclipse bug. BTW, the // $NON-NLS-1$ comment is intended to tell Eclipse that the string is non-language specific - i.e. it does not have to be translated for localisation purposes. S. On 03/11/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: woolfel Date: Wed Nov 2 19:30:20 2005 New Revision: 330428 URL: http://svn.apache.org/viewcvs?rev=330428view=rev Log: after I updated from SVN, the string appeared to be missing the closing double quote and semicolon. fixing it so it compiles peter lin Modified: jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java Modified: jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java URL: http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java?rev=330428r1=330427r2=330428view=diff == --- jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java (original) +++ jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java Wed Nov 2 19:30:20 2005 @@ -240,7 +240,7 @@ // Extract version digits from String of the form #Revision: n.mmhttp://n.mm http://n.mm# // (where # is actually $ above) - private static final String REVPFX = $Revision$NON-NLS-1$ + private static final String REVPFX = $Revision$NON-NLS-1$; private static final String REVSFX = $; // $NON-NLS-1$ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r330428 - /jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java
you know way more about subversion than I do.. so I'll defer to your knowledge :) peter On 11/3/05, sebb [EMAIL PROTECTED] wrote: SVN definitely swallows up everything from $Revision: to the 1st $ it finds. It's not a feature of Subclipse, because I tried it on minotaur in the test repo. This may well be deliberate (*), and it's possible that CVS does this too - the problem only occured with SVN, but then I only added the // $NON-NLS-1$ marker once we had moved to SVN. (*) in the case of $Revision, it knows that there can only be spaces, digits or . between the : and the trailing $, but this is not so obvious for some of the other markers, for example $Id:, which has several fields. So it looks like my error - or at least my ignorance... S. On 03/11/05, Peter Lin [EMAIL PROTECTED] wrote: it's the wonderful part of switching to CVS. thing that used to work now get to break. peter On 11/3/05, sebb [EMAIL PROTECTED] wrote: Just tried again, and the comment is being swallowed by the string. I'll fix it by removing it, and try raising an SVN bug. S. On 03/11/05, Peter Lin [EMAIL PROTECTED] wrote: ok, sounds cool :) peter On 11/3/05, sebb [EMAIL PROTECTED] wrote: Something similar happened to me. The // $NON-NLS-1$ comment appears to have been swallowed by the string. I'll remove it. The idea is to split the CVS marker $Revision: n.mm http://n.mm http://n.mm http://n.mm $ into a prefix and a suffix, so one can extract the n.mm http://n.mm http://n.mm http://n.mm (or nn in the case of SVN) but it looks like this is hitting an SVN or possibly Subclipse bug. BTW, the // $NON-NLS-1$ comment is intended to tell Eclipse that the string is non-language specific - i.e. it does not have to be translated for localisation purposes. S. On 03/11/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: woolfel Date: Wed Nov 2 19:30:20 2005 New Revision: 330428 URL: http://svn.apache.org/viewcvs?rev=330428view=rev Log: after I updated from SVN, the string appeared to be missing the closing double quote and semicolon. fixing it so it compiles peter lin Modified: jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java Modified: jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java URL: http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java?rev=330428r1=330427r2=330428view=diff == --- jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java (original) +++ jakarta/jmeter/branches/rel-2-1/src/core/org/apache/jmeter/save/SaveService.java Wed Nov 2 19:30:20 2005 @@ -240,7 +240,7 @@ // Extract version digits from String of the form #Revision: n.mm http://n.mmhttp://n.mm http://n.mm# // (where # is actually $ above) - private static final String REVPFX = $Revision$NON-NLS-1$ + private static final String REVPFX = $Revision$NON-NLS-1$; private static final String REVSFX = $; // $NON-NLS-1$ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 37160] - Scalable distributed testing
yeah, I'll have to report the bug to deskzilla and let them know. peter On 10/31/05, sebb [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2005-10-31 04:16 --- For some reason, deskzilla resent previous comments when I started it up. Ignore the duplicate. Seems to have happened quite a few times ... S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 37160] - Scalable distributed testing
anyone know of an alternative implementation for TreeTable? if not I'll write a new one and stick it in jorphan peter On 10/26/05, Michael Stover [EMAIL PROTECTED] wrote: I'm pretty certain we're not allowed to do so. On Wed, 2005-10-26 at 09:53 +0100, sebb wrote: I'm not sure that we are allowed to include LGPL jars in Apache code. Please check with legal. S. On 26/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37160. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37160 --- Additional Comments From [EMAIL PROTECTED] 2005-10-26 07:11 --- Hello, It is indeed open source, https://jdnc.dev.java.net/ it is released under LGPL licenese, and so is the JFreeChart package: http://www.jfree.org regards Lars Krog-Jensen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing DirectoryPanel in rel-2-1 10/24/2005 (about 7:00 GMT)
doh, I'll double check that. I thought I checked it in last night. peter On 10/24/05, Henryk Paluch [EMAIL PROTECTED] wrote: Hi! Recently tried to build latest JMeter from rel-2-1, but compilation failed on: [javac] D:\JAVA\jakarta-jmeter-20051024\rel-2-1\src\reports\org\apache\jmeter\control\gui\ReportGui.java:35: cannot find symbol [javac] symbol : class DirectoryPanel [javac] location: package org.apache.jmeter.gui.util [javac] import org.apache.jmeter.gui.util.DirectoryPanel; [javac] ^ It seems that there is no DirectoryPanel in that branch. Best regards -- ---(c)-- Henryk Paluch - analytik/programator GITUS, a.s. Spitalska 2a, 190 00 Praha 9, CZ mailto: [EMAIL PROTECTED] http://www.gitus.cz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing DirectoryPanel in rel-2-1 10/24/2005 (about 7:00 GMT)
ok it should be fixed now. user error on my part. in subversion, you have to check the item to make subversion add a new class. peter lin On 10/24/05, Peter Lin [EMAIL PROTECTED] wrote: doh, I'll double check that. I thought I checked it in last night. peter On 10/24/05, Henryk Paluch [EMAIL PROTECTED] wrote: Hi! Recently tried to build latest JMeter from rel-2-1, but compilation failed on: [javac] D:\JAVA\jakarta-jmeter-20051024\rel-2-1\src\reports\org\apache\jmeter\control\gui\ReportGui.java:35: cannot find symbol [javac] symbol : class DirectoryPanel [javac] location: package org.apache.jmeter.gui.util [javac] import org.apache.jmeter.gui.util.DirectoryPanel; [javac] ^ It seems that there is no DirectoryPanel in that branch. Best regards -- ---(c)-- Henryk Paluch - analytik/programator GITUS, a.s. Spitalska 2a, 190 00 Praha 9, CZ mailto: [EMAIL PROTECTED] http://www.gitus.cz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing DirectoryPanel in rel-2-1 10/24/2005 (about 7:00 GMT)
chalk it up to user error with subversion. peter On 10/24/05, Henryk Paluch [EMAIL PROTECTED] wrote: Hi! Thanks - it builds without problem now. ok it should be fixed now. -- ---(c)-- Henryk Paluch - analytik/programator GITUS, a.s. Spitalska 2a, 190 00 Praha 9, CZ mailto: [EMAIL PROTECTED] http://www.gitus.cz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Squashing JMX file format further
sure, go for it :) peter On 10/24/05, sebb [EMAIL PROTECTED] wrote: There are quite a few l.o.n.g names still present in the new JMX format, for example: elementProp name=XX elementType=org.apache.jmeter.protocol.http.control.Cookie Also, all the TestElements have entries of the form: AuthManager stringProp name=TestElement.nameHTTP Authorization Manager/stringProp stringProp name=TestElement.gui_class org.apache.jmeter.protocol.http.gui.AuthPanel/stringProp I'd like to simplify these, to: elementProp name=XX elementType=Cookie and AuthManager name=HTTP Authorization Manager gui=AuthPanel As far as I can see it won't be difficult to maintain backward compatibility. I've already tried with TestElementPropertyConverter, and that seems to work well. The TestElementConverter would need to be able to convert between aliases and class names rather than classes, but that can easily be done by adding a reverse mapping for the saveservice properties file. [This would have the benefit that one could check for multiple aliases at the same time.] Any objections/thoughts? S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Odd code in CookieManager
I have no clue how that stuff works :)
replacing our cookie handling with apache http cookie is probably a good
thing, so I say go for it.
peter
On 10/21/05, sebb [EMAIL PROTECTED] wrote:
I've been looking at Cookie Manager, and found the following code:
/**
* Add a cookie.
*/
public void add(Cookie c) {
[snip]
JMeterContext context = getThreadContext();
getCookies().addItem(c);
if (context.isSamplingStarted()) {
context.getVariables().put(c.getName(), c.getValue());
}
}
Why is the cookie defined as a variable?
The code seems to have been added in revision 323324 back in 2003.
The comment says:
Doc updates
GUI update to User Parameters
Update to jmeter-server script files to pass command line arguments on
(allows setting proxy for server)
Just wondering whether the code is still needed?
If so, do the variables need to be deleted when the cookies are
deleted? Also, what about variable name clashes? Also it might be
better if the cookie variable names were prefixed with COOKIE. or
somesuch.
[BTW, I'm thinking of replacing the low level cookie handling with the
cookie code from Apache HTTPClient.]
Sebastian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Odd code in CookieManager
oh, that is useful. not that I do much user centric testing :) peter On 10/21/05, Michael Stover [EMAIL PROTECTED] wrote: People asked for cookie values to be available as JMeter variables, and so we made it so.
Re: svn commit: r326761 - in /jakarta/jmeter/branches/rel-2-1/src: functions/org/apache/jmeter/functions/RegexFunction.java protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
I was just about to look at the patch. you beat me to it. thanks sebb. did
we already add the user to the contributor list? I can do that if we
haven't.
peter
On 10/19/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: sebb
Date: Wed Oct 19 17:15:29 2005
New Revision: 326761
URL: http://svn.apache.org/viewcvs?rev=326761view=rev
Log:
Bug 37140 - handle encoding better
Modified:
jakarta/jmeter/branches/rel-2-1/src/functions/org/apache/jmeter/functions/RegexFunction.java
jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
Modified:
jakarta/jmeter/branches/rel-2-1/src/functions/org/apache/jmeter/functions/RegexFunction.java
URL:
http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/src/functions/org/apache/jmeter/functions/RegexFunction.java?rev=326761r1=326760r2=326761view=diff
==
---
jakarta/jmeter/branches/rel-2-1/src/functions/org/apache/jmeter/functions/RegexFunction.java
(original)
+++
jakarta/jmeter/branches/rel-2-1/src/functions/org/apache/jmeter/functions/RegexFunction.java
Wed Oct 19 17:15:29 2005
@@ -18,6 +18,7 @@
package org.apache.jmeter.functions;
import java.io.Serializable;
+import java.io.UnsupportedEncodingException;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;
@@ -132,16 +133,18 @@
List collectAllMatches = new ArrayList();
try {
PatternMatcher matcher = (PatternMatcher) localMatcher.get();
- String responseText = new String(previousResult.getResponseData());
+ String responseText = new String(previousResult.getResponseData(),
+ previousResult.getDataEncoding()); // Bug 37140
PatternMatcherInput input = new PatternMatcherInput(responseText);
while (matcher.contains(input, searchPattern)) {
MatchResult match = matcher.getMatch();
collectAllMatches.add(match);
}
- } catch (NumberFormatException e) {
+ } catch (NumberFormatException e) {//TODO: can this occur?
log.error(, e);
return defaultValue;
- } catch (Exception e) {
+ } catch (UnsupportedEncodingException e) {
+ log.error(Can't convert ResponseData, e);
return defaultValue;
} finally {
vars.put(name + _matchNr, + collectAllMatches.size());
Modified:
jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
URL:
http://svn.apache.org/viewcvs/jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java?rev=326761r1=326760r2=326761view=diff
==
---
jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
(original)
+++
jakarta/jmeter/branches/rel-2-1/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
Wed Oct 19 17:15:29 2005
@@ -729,6 +729,8 @@
totalRes.setResponseMessage(lastRes.getResponseMessage());
totalRes.setDataType(lastRes.getDataType());
totalRes.setResponseHeaders(lastRes.getResponseHeaders());
+ totalRes.setContentType(lastRes.getContentType());
+ totalRes.setDataEncoding(lastRes.getDataEncoding());
return totalRes;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Convert JMeter to Subversion
SVN works for me too. thanks peter On 10/17/05, sebb [EMAIL PROTECTED] wrote: Seems to be working fine for me - thanks again.
Re: Migration to SVN
yeah it should be now, but I'll double check just in case. peter On 10/11/05, sebb [EMAIL PROTECTED] wrote: Is the new stuff included in build.xml? S. On 10/10/05, Peter Lin [EMAIL PROTECTED] wrote: I'm cleaning up the stuff in the report directory now and making sure the copyright stuff is all there and correct. should be done with cleaning up in the next hour. peter On 10/10/05, sebb [EMAIL PROTECTED] wrote: OK, I'll progress this shortly - probably starting tomorrow evening. S. On 10/10/05, Michael Stover [EMAIL PROTECTED] wrote: Ya, go for it. -Mike On Mon, 2005-10-10 at 13:30 -0400, Peter Lin wrote: I guess now is as good as any time to migrate to SVN. peter On 10/9/05, sebb [EMAIL PROTECTED] wrote: We need to migrate to SVN in the next month or so. Best if we pick a time when there's no pressing need to update CVS, as I think updates need to be stopped for a short period during the migration. When would suit everyone? I've got no immediate plans to commit lots of updates... Seb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration to SVN
ok, the tasks for the reporting tool have been checked in to 2.1.1 branch. peter On 10/11/05, sebb [EMAIL PROTECTED] wrote: Is the new stuff included in build.xml? S. On 10/10/05, Peter Lin [EMAIL PROTECTED] wrote: I'm cleaning up the stuff in the report directory now and making sure the copyright stuff is all there and correct. should be done with cleaning up in the next hour. peter On 10/10/05, sebb [EMAIL PROTECTED] wrote: OK, I'll progress this shortly - probably starting tomorrow evening. S. On 10/10/05, Michael Stover [EMAIL PROTECTED] wrote: Ya, go for it. -Mike On Mon, 2005-10-10 at 13:30 -0400, Peter Lin wrote: I guess now is as good as any time to migrate to SVN. peter On 10/9/05, sebb [EMAIL PROTECTED] wrote: We need to migrate to SVN in the next month or so. Best if we pick a time when there's no pressing need to update CVS, as I think updates need to be stopped for a short period during the migration. When would suit everyone? I've got no immediate plans to commit lots of updates... Seb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration to SVN
I guess now is as good as any time to migrate to SVN. peter On 10/9/05, sebb [EMAIL PROTECTED] wrote: We need to migrate to SVN in the next month or so. Best if we pick a time when there's no pressing need to update CVS, as I think updates need to be stopped for a short period during the migration. When would suit everyone? I've got no immediate plans to commit lots of updates... Seb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration to SVN
I'm cleaning up the stuff in the report directory now and making sure the copyright stuff is all there and correct. should be done with cleaning up in the next hour. peter On 10/10/05, sebb [EMAIL PROTECTED] wrote: OK, I'll progress this shortly - probably starting tomorrow evening. S. On 10/10/05, Michael Stover [EMAIL PROTECTED] wrote: Ya, go for it. -Mike On Mon, 2005-10-10 at 13:30 -0400, Peter Lin wrote: I guess now is as good as any time to migrate to SVN. peter On 10/9/05, sebb [EMAIL PROTECTED] wrote: We need to migrate to SVN in the next month or so. Best if we pick a time when there's no pressing need to update CVS, as I think updates need to be stopped for a short period during the migration. When would suit everyone? I've got no immediate plans to commit lots of updates... Seb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration to SVN
ok, I finally installed subclipse and JavaSVN. I'm able to connect to apache's svn repository on windows. peter On 10/10/05, sebb [EMAIL PROTECTED] wrote: OK, I'll progress this shortly - probably starting tomorrow evening. S. On 10/10/05, Michael Stover [EMAIL PROTECTED] wrote: Ya, go for it. -Mike On Mon, 2005-10-10 at 13:30 -0400, Peter Lin wrote: I guess now is as good as any time to migrate to SVN. peter On 10/9/05, sebb [EMAIL PROTECTED] wrote: We need to migrate to SVN in the next month or so. Best if we pick a time when there's no pressing need to update CVS, as I think updates need to be stopped for a short period during the migration. When would suit everyone? I've got no immediate plans to commit lots of updates... Seb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release 2.1.1
thanks peter On 9/30/05, sebb [EMAIL PROTECTED] wrote: Looks like there's some files missing from the archives - e.g. bin/*.bshrc [These have been missing from several releases...] I'll do a comparison later, and can then see if we need to recreate the archives or whether the missing files can wait for the next release. S. On 30/09/05, Peter Lin [EMAIL PROTECTED] wrote: +1 hurray!! thanks for making the build peter On 9/29/05, sebb [EMAIL PROTECTED] wrote: I've created the package files and md5 sigs etc and uploaded them to my personal directory: http://people.apache.org/~sebb/2.1.1/ Here is my +1 for releasing JMeter 2.1.1 Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release 2.1.1
+1 hurray!! thanks for making the build peter On 9/29/05, sebb [EMAIL PROTECTED] wrote: I've created the package files and md5 sigs etc and uploaded them to my personal directory: http://people.apache.org/~sebb/2.1.1/ Here is my +1 for releasing JMeter 2.1.1 Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributed test, scalability!
perhaps mike or sebb can answer that question. I haven't looked at the remote code close enough to know. peter On 9/28/05, Krog Jensen Lars [EMAIL PROTECTED] wrote: Hello, This is indeed one solution, but the problem is that we would need buy a lot more NIC and install them into all machines. Another solution could be that the controller - load agent communication should be statistical. What I mean is the agent aggregates a summary and then sends it back at constant rate; let's say every 5 seconds or other user determined value. This would be especially useful when using an Aggregate listener, which does not display each request invocation. I downloaded the source code, but I have not figured out yet where to start look. You wouldn't know how the Aggregate listener works when running multiple load agents? Regards Lars -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: den 28 september 2005 15:47 To: JMeter Users List Subject: Re: Distributed test, scalability! what you observed is a fundamental limitation of stress testing. the only good way to deal with this is to have 2 ethernet ports on each client machine and use 2 routers. this way, all the traffic to the server is on one router and all other traffic is on the other router. this is how I have my home environment setup. peter On 9/28/05, Krog Jensen Lars [EMAIL PROTECTED] wrote: Hello, Being new to JMeter I have some questions regarding the scalability of JMeter. I am planning to load test with 10 client machines, but I am running in to scalability issues when using 2 load severs. When my test plan is running on the controller host it will generate 25 Mbps in network traffic (seen from the Win XP Task Mgr Network tab), but when I remote start a load server, the traffic is increased to 65 Mbps. From what I can tell these 40 Mbps is JMeter internal traffic. By disabling all listeners this traffic is totally removed, but even a simple listener as Simple Data Writer is generating 40 Mbps traffic. It is pretty useless running in without listeners. Another related question is whether the Aggregate Report listener really aggregate the result from all the slaves? The reason for asking is that when I start a testplan from the controller I have a throughput of ~100 pages /sec, but when I remote start a load server, I would expect to receive ~200 pages /sec. If I start JMeter locally on two client hosts each will receive ~ 100 pages / sec. Besides that, JMeter is really, really nice and useful. Best Regards Lars Krog-Jensen SIX AB Stockholm
Re: Classpath feature status
I have a flu right now, but I'll try to take a look tonight or tomorrow. I saw repeated update also, but as you saw the classloader handles it correctly. Should we keep track of the URL's and only call loader.add(URL) if the path is new? a work around for #2 is to move the code for calling NewDriver to testStarted(). I tried that originally, but moved it to the set method. Since the setTestPlanClasspath isn't called in non-gui mode. peter On 9/23/05, sebb [EMAIL PROTECTED] wrote: I've moved the user.classpath code to JMeter.start(). This seems to work OK. The TestPlan classpath processing has some issues: 1) the classpath is repeatedly updated during GUI startup, and also as the user moves around the GUI. Luckily it seems the Sun code ignores duplicate entries. 2) the path does not seem to get updated in non-GUI mode. 3) the classpath is updated too late for some purposes - e.g. I tried using it to add the beanshell jar, but the BSH sampler did not work. This is because the BSH Sampler tries to create the BSH manager before the classpath has been updated. I'll try and have a look at these later. (3) may be difficult to fix. I think 1 + 2 need to be fixed - or the code should be removed - before we release 2.1.1 S. On 22/09/05, sebb [EMAIL PROTECTED] wrote: Seems to me it would be useful to process the user.classpath property earlier than at present - it won't change during a run. Also, the code needs to handle multiple entries in the property value - at present it assumes there is only one. Presumably the separator should be the local system path separator? Also, I think it would be useful to log the path setting, and perhaps warn if any of the path segments were invalid (they should be directories or files). Not sure that it is necessary to check if the files are of type zip/jar, just that they exist. Later ... S. On 21/09/05, Michael Stover [EMAIL PROTECTED] wrote: I agree it's still a useful thing to have. It provides a simple way for people to link in their jdbc drivers and java sampler targets without having to copy/paste them into jmeter's home directories, and without having to deal with JMeter's classpath madness. -Mike On Wed, 2005-09-21 at 13:32 -0400, Peter Lin wrote: I've finally figured out the classloader issue. The basic summary is this. 1. since the TestElements are loaded in the main Classloader, it references the main CL 2. it doesn't matter if I create a new CL and set each thread to use it, since the class was already loaded. Is there a way to unload a Class? I can't think of an easy way off hand I've settled on setting the classpath in the main classloader. That works as expected and allows users to define additional classpaths. the downside is that if the classpaths change, users have to restart JMeter. If an user is just adding a path, a restart isn't needed. If a user is replacing 1 jar file with a different jar file, then a restart is needed. In light of that, I still think it is nice to have the ability to define a set of classpaths for a given testplan. this does save users time and avoid copying lots of extra jar files to jmeter/lib/ directory. if there's no objects, I'll clean up the code and check it in. peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath feature status
I fixed #2, so it works in nongui mode. I can take a look at #1 tomorrow. going to rest now. peter On 9/23/05, sebb [EMAIL PROTECTED] wrote: I've moved the user.classpath code to JMeter.start(). This seems to work OK. The TestPlan classpath processing has some issues: 1) the classpath is repeatedly updated during GUI startup, and also as the user moves around the GUI. Luckily it seems the Sun code ignores duplicate entries. 2) the path does not seem to get updated in non-GUI mode. 3) the classpath is updated too late for some purposes - e.g. I tried using it to add the beanshell jar, but the BSH sampler did not work. This is because the BSH Sampler tries to create the BSH manager before the classpath has been updated. I'll try and have a look at these later. (3) may be difficult to fix. I think 1 + 2 need to be fixed - or the code should be removed - before we release 2.1.1 S. On 22/09/05, sebb [EMAIL PROTECTED] wrote: Seems to me it would be useful to process the user.classpath property earlier than at present - it won't change during a run. Also, the code needs to handle multiple entries in the property value - at present it assumes there is only one. Presumably the separator should be the local system path separator? Also, I think it would be useful to log the path setting, and perhaps warn if any of the path segments were invalid (they should be directories or files). Not sure that it is necessary to check if the files are of type zip/jar, just that they exist. Later ... S. On 21/09/05, Michael Stover [EMAIL PROTECTED] wrote: I agree it's still a useful thing to have. It provides a simple way for people to link in their jdbc drivers and java sampler targets without having to copy/paste them into jmeter's home directories, and without having to deal with JMeter's classpath madness. -Mike On Wed, 2005-09-21 at 13:32 -0400, Peter Lin wrote: I've finally figured out the classloader issue. The basic summary is this. 1. since the TestElements are loaded in the main Classloader, it references the main CL 2. it doesn't matter if I create a new CL and set each thread to use it, since the class was already loaded. Is there a way to unload a Class? I can't think of an easy way off hand I've settled on setting the classpath in the main classloader. That works as expected and allows users to define additional classpaths. the downside is that if the classpaths change, users have to restart JMeter. If an user is just adding a path, a restart isn't needed. If a user is replacing 1 jar file with a different jar file, then a restart is needed. In light of that, I still think it is nice to have the ability to define a set of classpaths for a given testplan. this does save users time and avoid copying lots of extra jar files to jmeter/lib/ directory. if there's no objects, I'll clean up the code and check it in. peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ready for 2.1.1?
Are we ready for 2.1.1 now? I've switched back to working on the reporting tool now. It would be nice to get 2.1.1 out, so that I can move the reporting tool over to the 2.1 branch also. peter
Re: Ready for 2.1.1?
ok, I've added an explanation of the classpath feature. peter On 9/22/05, Peter Lin [EMAIL PROTECTED] wrote: I'm updating the docs now with a new screencap of testplan should be in within the next hour or so peter On 9/22/05, sebb [EMAIL PROTECTED] wrote: I think so, assuming the tests work OK. I need to check that the save config change I made recently hasn't broken non-GUI test runs, and double-check that Jmeter works under JVM 1.3 (apart from SSL, which I've not had time to fix). S. On 22/09/05, Peter Lin [EMAIL PROTECTED] wrote: Are we ready for 2.1.1 now? I've switched back to working on the reporting tool now. It would be nice to get 2.1.1 out, so that I can move the reporting tool over to the 2.1branch also. peter
Classpath feature status
I've finally figured out the classloader issue. The basic summary is this. 1. since the TestElements are loaded in the main Classloader, it references the main CL 2. it doesn't matter if I create a new CL and set each thread to use it, since the class was already loaded. Is there a way to unload a Class? I can't think of an easy way off hand I've settled on setting the classpath in the main classloader. That works as expected and allows users to define additional classpaths. the downside is that if the classpaths change, users have to restart JMeter. If an user is just adding a path, a restart isn't needed. If a user is replacing 1 jar file with a different jar file, then a restart is needed. In light of that, I still think it is nice to have the ability to define a set of classpaths for a given testplan. this does save users time and avoid copying lots of extra jar files to jmeter/lib/ directory. if there's no objects, I'll clean up the code and check it in. peter
Re: Is this a bug in webservices (SOAP) request sampler
I'm not sure how to handle it, since the current implementation simply
passes the inputStream to the DocumentBuilder. If you want to give it a
shot, I'll do what I can to help. Right now I am a bit busy with other
enhancements, so I haven't had much time to dig further.
peter
On 9/20/05, Manish Mathuria [EMAIL PROTECTED] wrote:
Hi Peter,
Any updates on this one? I saw your note that you were planning to ask
around to see how to best achieve this.
In order to create a realistic kind of load, I do need to send multiple
data files to my SOAP calls, and I see no other way than to do this
parameter substitution on a file system XML file.
please let me know, worst case, I think I can take a swing at it, but I
would like to do it only if it is not something that makes sense for you to
do.
Manish
*Manish Mathuria [EMAIL PROTECTED]* wrote:
Thanks much!
*Peter Lin [EMAIL PROTECTED]* wrote:
unfortunately no. I'll take a look within the next few hours. if it's an
easy fix, I'll work on it this weekend. no promises, but I'll take a look.
peter
On 9/16/05, Manish Mathuria [EMAIL PROTECTED] wrote:
Peter
I will log an enhancement. Meanwhile, do you know any work around?
Manish
*Peter Lin [EMAIL PROTECTED] *wrote:
the way it is currently implemented, the sampler parses the XML to a DOM
document and re-uses it. to get it to work that way would need an
enhancement. please file an enhancement and I'll take a look
thanks for reporting it
peter
On 9/16/05, Manish Mathuria [EMAIL PROTECTED] wrote:
I am trying to substitute a value in the input XML. This variable is
saved as a postprocessing parameter. Logging shows that this variable is
saved correctly.
When the input XML is part of SOAP/RPC data box like (note variable
${search_context}, things are fine, the value of the variable gets
substituted. But when this content is saved as a file and specified in
either filename or messagefolder, the value does not get substituted.
- sample content attached.
Manish
S:Envelope S:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
xmlns:S=http://schemas.xmlsoap.org/soap/envelope/
xmlns:a=http://tempuri.org/com.stratify.datahub.mdt.common.MDTServiceImpl
xmlns:XS=http://www.w3.org/2001/XMLSchema;
xmlns:XI=http://www.w3.org/2001/XMLSchema-instance;
S:Body
a:closeFetch
arg0 XI:type=XS:string${search_context}/arg0
/a:closeFetch
/S:Body
/S:Envelope
-
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
--
Yahoo! for Good
Click here to donate http://store.yahoo.com/redcross-donate3/ to the
Hurricane Katrina relief effort.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Yahoo! for Good
Click here to donate http://store.yahoo.com/redcross-donate3/ to the
Hurricane Katrina relief effort.
Re: [proposal] - add the feature to allow user classpaths
I plan to add support for adding classpath to jmeter.properties today. right now I'm thinking user.classpath as the entry name. any suggestions or alternate names for the entry? peter On 9/16/05, sebb [EMAIL PROTECTED] wrote: OK. [The actual classpath changes need to be done outside the GUI, or non-GUI runs won't work.] I think it would be useful to also have the ability to define the extra classes via a property. This could be added to the standard classpath, as it would not need to be removed. S. On 16/09/05, Peter Lin [EMAIL PROTECTED] wrote: mike and I were chatting yesterday and the testplangui seems like the best place to put the feature. this way, users can browse and select the desired jar file. I was thinking about how setting/resetting the classpath should work. I'll need to do some basic research and see if I should create a new instance of the classloader for the jars. since URLClassLoader doesn't have a removeURL method. http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLClassLoader.html I could take the servlet container approach, which would mean. 1. create a new classloader to load the jar files 2. if the user resets the classpaths, kill the Classloader instance and create a new one peter On 9/16/05, sebb [EMAIL PROTECTED] wrote: Point taken. Not sure it would make sense to have more than one classpath in a TestPlan, so perhaps the best place for it would be to add it to the TestPlan element. However ... If the extra class-path entries are only needed whilst running a test, then it should be fairly straightforward to update the CP, though one would need to make sure the CP did not grow for each test run or loop - and ideally the CP would be reset if the extra path(s) were removed or changed later. If the CP entries are needed at design or startup time, then it starts to get rather tricky to ensure that the CP is updated before it is needed. S. On 15/09/05, Serguei Belikov [EMAIL PROTECTED] wrote: Hi, I think it makes a perfect sense to keep a class paths with a test plan. In this case one will be able to open a new test plan and the class paths will be modified according to plan content. If class paths are set as a properties, one needs to restart JMeter. sebb wrote: Not sure it's necessary to have a GUI to do this. The additional classpaths are probably known before starting JMeter, so would it not be simpler to use a property to define the extra classpaths? S. On 15/09/05, Peter Lin [EMAIL PROTECTED] wrote: I'm planning on adding another feature to the 2.1 branch and provide a way for users to add classpaths to JMeter in the GUI. I was thinking of something like User Defined Classpath. Users can then select the jar files they want and the config element will add them to the classloader. Any thoughts, suggestions, ideas? peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Serguei Belikov Sr. Developer Tucows Inc. [EMAIL PROTECTED] (416) 535-0123 Ext. 1297 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] - add the feature to allow user classpaths
Related to the classpath entry in jmeter.properties is the test plan. I've mocked up the classpath in the testplan gui http://people.apache.org/~woolfel/new-testplan.png peter On 9/19/05, sebb [EMAIL PROTECTED] wrote: OK by me. It would be useful to add a comment to jmeter.properties that it is optional, and does not replace the existing classpath; also to document whether the additional entries are appended or pre-pended to the path... S On 19/09/05, Peter Lin [EMAIL PROTECTED] wrote: I plan to add support for adding classpath to jmeter.properties today. right now I'm thinking user.classpath as the entry name. any suggestions or alternate names for the entry? peter On 9/16/05, sebb [EMAIL PROTECTED] wrote: OK. [The actual classpath changes need to be done outside the GUI, or non-GUI runs won't work.] I think it would be useful to also have the ability to define the extra classes via a property. This could be added to the standard classpath, as it would not need to be removed. S. On 16/09/05, Peter Lin [EMAIL PROTECTED] wrote: mike and I were chatting yesterday and the testplangui seems like the best place to put the feature. this way, users can browse and select the desired jar file. I was thinking about how setting/resetting the classpath should work. I'll need to do some basic research and see if I should create a new instance of the classloader for the jars. since URLClassLoader doesn't have a removeURL method. http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLClassLoader.html I could take the servlet container approach, which would mean. 1. create a new classloader to load the jar files 2. if the user resets the classpaths, kill the Classloader instance and create a new one peter On 9/16/05, sebb [EMAIL PROTECTED] wrote: Point taken. Not sure it would make sense to have more than one classpath in a TestPlan, so perhaps the best place for it would be to add it to the TestPlan element. However ... If the extra class-path entries are only needed whilst running a test, then it should be fairly straightforward to update the CP, though one would need to make sure the CP did not grow for each test run or loop - and ideally the CP would be reset if the extra path(s) were removed or changed later. If the CP entries are needed at design or startup time, then it starts to get rather tricky to ensure that the CP is updated before it is needed. S. On 15/09/05, Serguei Belikov [EMAIL PROTECTED] wrote: Hi, I think it makes a perfect sense to keep a class paths with a test plan. In this case one will be able to open a new test plan and the class paths will be modified according to plan content. If class paths are set as a properties, one needs to restart JMeter. sebb wrote: Not sure it's necessary to have a GUI to do this. The additional classpaths are probably known before starting JMeter, so would it not be simpler to use a property to define the extra classpaths? S. On 15/09/05, Peter Lin [EMAIL PROTECTED] wrote: I'm planning on adding another feature to the 2.1 branch and provide a way for users to add classpaths to JMeter in the GUI. I was thinking of something like User Defined Classpath. Users can then select the jar files they want and the config element will add them to the classloader. Any thoughts, suggestions, ideas? peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Serguei Belikov Sr. Developer Tucows Inc. [EMAIL PROTECTED] (416) 535-0123 Ext. 1297 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] - add the feature to allow user classpaths
hehe... I could use table. that would make it cleaner peter On 9/19/05, sebb [EMAIL PROTECTED] wrote: I see. Looks like the entries are separated by , and new-line. Might be better to remove the , and just have one entry per line. I think the proper path separator should be added at run-time. This would make it easier to re-order the lines if necessary - though I think a table might be better here. S.
Re: cvs commit: jakarta-jmeter NOTICE
thanks for adding that. I forgot it. peter On 18 Sep 2005 23:37:51 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: sebb 2005/09/18 16:37:51 Modified: . Tag: rel-2-1 NOTICE Log: Add jcharts reference Revision Changes Path No revision No revision 1.7.4.1 http://1.7.4.1 +2 -0 jakarta-jmeter/NOTICE Index: NOTICE === RCS file: /home/cvs/jakarta-jmeter/NOTICE,v retrieving revision 1.7 retrieving revision 1.7.4.1 http://1.7.4.1 diff -u -r1.7 -r1.7.4.1 --- NOTICE 20 Jun 2004 00:32:51 - 1.7 +++ NOTICE 18 Sep 2005 23:37:51 - 1.7.4.1 http://1.7.4.1 @@ -37,3 +37,5 @@ enough to assist JMeter. === +This product includes software developed by the jCharts Project. +See http://jcharts.sourceforge.net/ \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] - add the feature to allow user classpaths
mike and I were chatting yesterday and the testplangui seems like the best place to put the feature. this way, users can browse and select the desired jar file. I was thinking about how setting/resetting the classpath should work. I'll need to do some basic research and see if I should create a new instance of the classloader for the jars. since URLClassLoader doesn't have a removeURL method. http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLClassLoader.html I could take the servlet container approach, which would mean. 1. create a new classloader to load the jar files 2. if the user resets the classpaths, kill the Classloader instance and create a new one peter On 9/16/05, sebb [EMAIL PROTECTED] wrote: Point taken. Not sure it would make sense to have more than one classpath in a TestPlan, so perhaps the best place for it would be to add it to the TestPlan element. However ... If the extra class-path entries are only needed whilst running a test, then it should be fairly straightforward to update the CP, though one would need to make sure the CP did not grow for each test run or loop - and ideally the CP would be reset if the extra path(s) were removed or changed later. If the CP entries are needed at design or startup time, then it starts to get rather tricky to ensure that the CP is updated before it is needed. S. On 15/09/05, Serguei Belikov [EMAIL PROTECTED] wrote: Hi, I think it makes a perfect sense to keep a class paths with a test plan. In this case one will be able to open a new test plan and the class paths will be modified according to plan content. If class paths are set as a properties, one needs to restart JMeter. sebb wrote: Not sure it's necessary to have a GUI to do this. The additional classpaths are probably known before starting JMeter, so would it not be simpler to use a property to define the extra classpaths? S. On 15/09/05, Peter Lin [EMAIL PROTECTED] wrote: I'm planning on adding another feature to the 2.1 branch and provide a way for users to add classpaths to JMeter in the GUI. I was thinking of something like User Defined Classpath. Users can then select the jar files they want and the config element will add them to the classloader. Any thoughts, suggestions, ideas? peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Serguei Belikov Sr. Developer Tucows Inc. [EMAIL PROTECTED] (416) 535-0123 Ext. 1297 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] - add the feature to allow user classpaths
I'm planning on adding another feature to the 2.1 branch and provide a way for users to add classpaths to JMeter in the GUI. I was thinking of something like User Defined Classpath. Users can then select the jar files they want and the config element will add them to the classloader. Any thoughts, suggestions, ideas? peter
Re: Please help Testing HTTPS to HTTP call
I don't think there's a way currently. I should be feasible with the HTTPClient sampler, but we would need to enahance it. please file an enahancement request in bugzilla peter On 9/15/05, shweta s [EMAIL PROTECTED] wrote: Hi Peter, In regard to the below problem. Is there any way that we can disable the security alert when I try an URL. Thanks in advance Shweta Peter Lin [EMAIL PROTECTED] wrote: unfortunatey, it's suppose to raise a security alert because having a https session go get http compromises security. there's probably a way around it, but I can't think of any at the moment. peter On 8/29/05, shweta s wrote: Hi All, I am trying to Set up test scripts for our application. Here the URL is https which makes a call to another server which is http enabled. Because of this I am getting a security alert whenever a call is made from https enabled server to http. How can I overcome this when setting up jmx scripts Thanks in advance Shweta - Too much spam in your inbox? Yahoo! Mail gives you the best spam protection for FREE! http://in.mail.yahoo.com - Yahoo! India Matrimony: Find your partner now.
Re: JMeter 2.1 does not compile with JDK 1.3
or as I like to say. customer often don't know what they want and ask for silly things peter On 9/14/05, sebb [EMAIL PROTECTED] wrote: As I'm sure you know, running JMeter on the same box as the web-server is fine for functional testing, but it is not advisable for performance tests with lots of threads. Customers are funny sometimes ... S. On 14/09/05, Jacques Desmazieres [EMAIL PROTECTED] wrote: Actually we have to generate automatic performance reports after install of our application on Weblogic 6.1 (I know, it old !) and the only JVM available is the Weblogic's one. And our customer does not want to install anything else on the production server, nor running the performance script from a separate station running JDK 1.4. Thanks for your reply Jacques Desmazieres -Message d'origine- De : sebb [mailto:[EMAIL PROTECTED] Envoyé : mercredi 14 septembre 2005 11:59 À : JMeter Developers List Objet : Re: JMeter 2.1 does not compile with JDK 1.3 That looks like an accident - we've been trying to maintain 1.3 compatibility. I'll have a look at fixing that for 2.1.1. However, be warned that the 1.3 JVM can have problems running JMeter scripts. 1.4 JVMs generally work much better. BTW, why can you not use 1.4? S. On 14/09/05, Jacques Desmazieres [EMAIL PROTECTED] wrote: Hello, I need to run JMeter with JDK1.3. I retrieved the src build archive and tried to compile it. But I have compilation errors in the core (jorphan) classes. These errors does not exist anymore if I just replace with Jdk 1.4. Is JMeter still supposed to be JDK 1.3 fully compliant ? Jacques Desmazieres There are 2 types of errors: [javac] Compiling 37 source files to D:\JAKART~1.1\build\jorphan [javac] D:\JAKART~1.1\src\jorphan\org\apache\jorphan\collections\Configura tionTree.j ava:75: reference to add is ambiguous, both method add(java.u til.Collection) in org.apache.jorphan.collections.HashTree and method add(java.lang.Object) in org.apache.jorphan.collections.ListedHashTree match [javac] propTree.add(keys); and [javac] D:\JAKART~1.1\src\jorphan\org\apache\jorphan\util\Converter.java:3 78: cannot resolve symbol [javac] symbol : method replaceAll (java.lang.String, java.lang.String) [javac] location: class java.lang.String [javac] return v.trim().replaceAll(\\s+, insertion); JVM version (java -version): java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMeter 2.1 does not compile with JDK 1.3
but older versions should be. peter On 9/14/05, Michael Stover [EMAIL PROTECTED] wrote: JMeter is not jdk1.3 compliant. On Wed, 2005-09-14 at 16:48 +0200, Jacques Desmazieres wrote: I agree with on that point, but the main concern is that JMeter is supposed to be fully JDK13 compliant but does not compile with that version of JDK. And unfortunately, I need to do it, even if the reasons are not good ;-) Jacques Desmazieres -Message d'origine- De : Michael Stover [mailto:[EMAIL PROTECTED] Envoyé : mercredi 14 septembre 2005 16:31 À : JMeter Dev List Objet : RE: JMeter 2.1 does not compile with JDK 1.3 You should explain to your customer that running JMeter on the production server just means the results will be meaningless, so there's no need to even bother with it. On Wed, 2005-09-14 at 12:12 +0200, Jacques Desmazieres wrote: Actually we have to generate automatic performance reports after install of our application on Weblogic 6.1 (I know, it old !) and the only JVM available is the Weblogic's one. And our customer does not want to install anything else on the production server, nor running the performance script from a separate station running JDK 1.4. Thanks for your reply Jacques Desmazieres -Message d'origine- De : sebb [mailto:[EMAIL PROTECTED] Envoyé : mercredi 14 septembre 2005 11:59 À : JMeter Developers List Objet : Re: JMeter 2.1 does not compile with JDK 1.3 That looks like an accident - we've been trying to maintain 1.3 compatibility. I'll have a look at fixing that for 2.1.1. However, be warned that the 1.3 JVM can have problems running JMeter scripts. 1.4 JVMs generally work much better. BTW, why can you not use 1.4? S. On 14/09/05, Jacques Desmazieres [EMAIL PROTECTED] wrote: Hello, I need to run JMeter with JDK1.3. I retrieved the src build archive and tried to compile it. But I have compilation errors in the core (jorphan) classes. These errors does not exist anymore if I just replace with Jdk 1.4. Is JMeter still supposed to be JDK 1.3 fully compliant ? Jacques Desmazieres There are 2 types of errors: [javac] Compiling 37 source files to D:\JAKART~1.1\build\jorphan [javac] D:\JAKART~1.1\src\jorphan\org\apache\jorphan\collections\Configura tionTree.j ava:75: reference to add is ambiguous, both method add(java.u til.Collection) in org.apache.jorphan.collections.HashTree and method add(java.lang.Object) in org.apache.jorphan.collections.ListedHashTree match [javac] propTree.add(keys); and [javac] D:\JAKART~1.1\src\jorphan\org\apache\jorphan\util\Converter.java:3 78: cannot resolve symbol [javac] symbol : method replaceAll (java.lang.String,java.lang.String) [javac] location: class java.lang.String [javac] return v.trim().replaceAll(\\s+, insertion); JVM version (java -version): java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
