Re: Contribution to Documentation of InfluxDBClient

[Graham Russell]

There is a tiny bit of documentation for the raw one here
https://jmeter.apache.org/usermanual/component_reference.html#Backend_Listener

But I think updating the real time results page is a great idea. I'm happy
to help review any PR you may create.

Thanks

Graham

On Sat, 2 Jan 2021, 17:02 Frank Thomas (jmeter), 
wrote:

> Hi,
>
> I realized that the documentation at
> https://jmeter.apache.org/usermanual/realtime-results.html is a bit
> outdated and seems to be based on what has been done for the
> GraphiteBackendListenerClient, but what is exposed in
> InfluxDBBackendListenerClient is a bit different. And the
> InfluxDBRawBackendListenerClient that has been introduced in 5.4 doesn’t
> seem to be documented at all.
> Currently I haven’t found an issue on this in bugzilla.
> I’m willing to update the documentation.
> But before just opening an issue and a PR as described in
> https://jmeter.apache.org/building.html I thought I’ll better double
> check here.
> Any objections or recommendations?
>
> Thanks
> Frank
>
>
>

Re: Setting better defaults for HTTP request

[Graham Russell]

I agree, setting those as defaults is much better than infinite and less
concerning than 10s/60s.

They probably won't do much to stop people complaining about JMeter hanging
on shutdown,
was this lack of default timeout the root cause of those complaints or is
there something else we can do with that issue?

On Sun, 20 Dec 2020, 13:02 Philippe Mouawad, 
wrote:

> Hello,
> Let’s do that
>
> Thanks for feedback
>
> On Sunday, December 20, 2020, Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
> > Am Samstag, den 19.12.2020, 17:10 +0100 schrieb Philippe Mouawad:
> > > Hello
> > >
> > > Currently we don't set neither connect nor read timeout which means
> > > they
> > > default to infinite.
> > > I don't think those are good defaults and users frequently think
> > > JMeter is
> > > hanging.
> > >
> > > Shouldn't we set better defaults ?
> > >
> > > - Connect  to 10s
> > > - Read to 60s
> >
> > I generally like the idea of setting a default timeout, as infinity is
> > a long time to wait for. The times are great, if you know, that
> > timeouts are set, but what about the old settings, where the plan
> > didn't take those into account?
> >
> > I think we can be a bit more generous on those timeouts, especially for
> > the read timeout. For a non-interactive site, those might be a bit
> > short.
> >
> > In my firefox's about:config the values for connection and response
> > timeout are 90 s and 300 s respectively. (I took
> > network.http.connection-timeout and network.http.response.timeout)
> >
> > I think those values should be conservative enough for most of our
> > users.
> >
> >
> > Felix
> >
> > >
> > > WDYT ?
> > > Thanks
> >
> >
>
> --
> Cordialement.
> Philippe Mouawad.
>

Re: Setting better defaults for HTTP request

[Graham Russell]

I think it's a good idea, as long as we make it very obvious how to change
it in the UI and failure/error message.

Would it affect existing scripts? I can imagine some existing (and indeed
new) tests might start failing with a 60s read timeout due to some slow
calls.

Graham


On Sat, 19 Dec 2020, 16:10 Philippe Mouawad, 
wrote:

> Hello
>
> Currently we don't set neither connect nor read timeout which means they
> default to infinite.
> I don't think those are good defaults and users frequently think JMeter is
> hanging.
>
> Shouldn't we set better defaults ?
>
> - Connect  to 10s
> - Read to 60s
>
> WDYT ?
> Thanks
> --
> Regards
> Philippe M.
>

Re: [VOTE] Release JMeter 5.4 RC1

[Graham Russell]

A small thing from me, I noticed that the Raw InfluxDB Backend
Listener (https://github.com/apache/jmeter/pull/544) wasn't mentioned
in the change log.
Could someone add it before the RC2?

Thanks!

Graham

On Wed, 25 Nov 2020 at 17:46, Milamber  wrote:
>
> Hello,
>
> Please ping me when I can start the RC2.
>
> Milamber
>
> On 11/25/20 4:59 PM, Felix Schumacher wrote:
> > Am 24.11.20 um 22:58 schrieb Vladimir Sitnikov:
> >> I wonder why all those plugins depend on LoggingManager.
> > I think that is a lot of historical baggage. The plugins from
> > jmeter-plugins repository are all cleaned up and will be released
> > sometime in the future.
> >
> >> Given the number of usages, we would have to keep the class forever, so we
> >> might want to add the related javadoc.
> > We can keep them, should we still mark those as deprecated?
> >> If the third-party plugins use the class for logging purposes, then we
> >> might even want to heal the class (e.g. divert all the logging calls to the
> >> current slf4j)
> > I think the healing will depend on the jars that the
> > plugin/plugin-manager brings to the table. If it uses our implementation
> > of LoggingManager it will get a LogKit-adapter that delegates all log
> > messages to SLF4J, does'nt it?
> >> It is sad I did not check the usages outside of JMeter :-(
> > No problem, I am happy, that we found this before we released a new version.
> >
> > Felix
> >
> >> Vladimir
> >>
>

Re: Screenshots: documentation, pull requests

[Graham Russell]

Great idea. There is a lot of room for improvement here.

Is there somewhere we can host them, like netlify or S3, instead of git?

What about the custom highlights around specific parts of the screenshot,
is that easy to automate too, but maybe not essential?

Graham

On Wed, 25 Mar 2020, 21:42 Vladimir Sitnikov, 
wrote:

> Hi,
>
> JMeter heavily relies on the UI, and would probably be nice if we could
> have machinery for automated screenshot generation.
>
> I see the following issues with the current screenshots:
> 1) They are often out of date
> 2) Image quality is not always good (e.g. LowDPI image does not work for
> HiDPI screen)
> 3) Image themes are not consistent. One screenshot can be dark, another can
> be light, and so on :(
>
> What do you think if we replace screenshots with automatically generated
> ones?


> I've created a draft PR: https://github.com/apache/jmeter/pull/574
> I implement a small class that instantiates GUI components and generates
> PNG files out of it.
>
> So far my findings are:
> a) The full set of screenshots takes ~7 megabytes (or ~3.5 after pngquant).
> We would probably want to keep screenshots in another repository.
> Otherwise, we could pollute the main source repository with images quite
> fast.
> b) Different operating systems have slightly different rendering because
> the default fonts are different
> c) If we use a different repository for storing screenshots, then we could
> render even multiple themes and add "preferred theme" switch to the website
> d) A single component might need more than one screenshot (e.g. HTTP
> request have multiple tabs)
>
>
> Any thoughts?
>
> Vladimir
>

Send raw results to InfluxDB?

[Graham Russell]

Hi all

Is it possible to send raw results to InfluxDB?

When I've read the docs and looked at the current BackendListeners it seems
we only send summary stats (despite summaryStats=false)

I've created a PR which achieves largely what I expected the InfluxDB
listner to do https://github.com/apache/jmeter/pull/544 but happy to
discuss details here or on the PR.

Thanks

Re: JMeter 4.0RC... is still at http://home.apache.org/~milamber/jmeter-...

[Graham Russell]

I think we should, https should improve search rankings.

On Wed, 2 Oct 2019 at 19:34, Philippe Mouawad
 wrote:
>
> Hello,
> Yes we should
>
> Also I am wondering if we should not ask Infra to redirect http to https
> with 301.
>
> Regards
>
> On Wed, Oct 2, 2019 at 8:29 PM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > Hi,
> >
> > Every time I search on JMeter I end up opening Milamber's page.
> > Should we ask Milamber to drop old website RC from /~milamber/ or at least
> > put robots.txt to prevent it from being indexed "as the official website"?
> >
> > The sad thing is jmeter.apache.org is not among the first 5 results.
> >
> > PS. "precise throughput timer site:jmeter.apache.org"  works, however, it
> > is a workaround.
> >
> > [image: google_jmeter_milamber.png]
> >
> >
> > Vladimir
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: JUnit5 vs JUnit4

[Graham Russell]

Sounds good to me too, and if any are stubborn, or would look better
as Spock tests, perhaps we can re-write them?

I can attempt this tonight if no-one else has currently started it?

Graham

On Wed, 2 Oct 2019 at 17:24, Philippe Mouawad
 wrote:
>
> Ok by me
>
> On Wed, Oct 2, 2019 at 4:12 PM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > Hi,
> >
> > What do you think if we migrate existing JUnit4 tests to JUnit5, and
> > somehow forbid adding new JUnit4 tests?
> > For instance, we can add Spotless formatting step that automatically
> > replaces "import org.junit.Test" with "org.junit.jupiter.api.Test" within
> > java files :)
> >
> > In most of the cases, the migration is as simple as replacing
> > org.junit.Test with org.junit.jupiter.api.Test.
> >
> > In my point of view, the removal of JUnit4-based tests would simplify
> > maintenance as it would reduce (at least temporary) the number of different
> > test styles.
> >
> > Any thoughts?
> >
> > Vladimir
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Eclipse and hamcrest

[Graham Russell]

If we were looking at replacements I like Google Truth, it's like AssertJ
but often with better error messages and with both the code reads more
naturally than Hamcrest imo e.g.

assertThat(result).isEmpty();

Almost as good as Spock ;)

result.isEmpty()

On Sat, 28 Sep 2019, 17:30 Felix Schumacher, <
felix.schumac...@internetallee.de> wrote:

>
> Am 28.09.19 um 17:46 schrieb Vladimir Sitnikov:
> >> duplicate classpath entries (
> https://github.com/gradle/gradle/issues/10393
> > ).
> >
> > Is it fixed in Gradle 5.6.2?
> > Should we update then?
>
> I think it is fixed in 5.6.2. And when I change the properties to
> gradle/wrapper/gradle-wrapper.properties, it seems to generate the
> classpath entries only once.
>
> Felix
>
> >
> > Vladimir
> >
>

Re: Replacing nashorn

[Graham Russell]

Option 4, also deprecate and remove support for JS and provide a guide on
how to migrate to Groovy?

Graham

On Wed, 24 Jul 2019, 07:11 Jmeter Tea,  wrote:

> Hello,
> There's GraalVM JavaScript with optional "Nashorn compatibility mode"
>
> https://github.com/graalvm/graaljs/blob/master/docs/user/NashornMigrationGuide.md
>
> FYI
>
> On Wed, Jul 24, 2019 at 12:07 AM Philippe Mouawad <
> p.moua...@ubik-ingenierie.com> wrote:
>
> > Hello,
> > When running under jdk12, we see the warning about nashorn being dropped
> in
> > the future.
> >
> > What shall we do to handle it?
> >
> > - drop it and revert back to rhino as default  which does not seem very
> > active
> > - replace it with an alternative, I didn’t find one yet
> >
> > Regards
> > Philippe
> >
> >
> > --
> >
> >
> > [image: logo Ubik Ingenierie]  Philippe
> > Mouawad
> > Senior Performance Expert
> > 320914981 <+33320914981> | p.moua...@ubik-ingenierie.com
> > [image: ubik-ingenierie.com] ubik-ingenierie.com
> >  | [image: 03.20.91.49.81]
> 03.20.91.49.81
> > <+33320914981> | [image: 23 rue du chemin de fer , 59100 , Roubaix] 23
> rue
> > du chemin de fer, 59100, Roubaix
> > 
> >
>

Re: [VOTE] GitHub: disable merge button?

[Graham Russell]

+1

Vladimir, thank you for all your work on migrating to git.

I generally prefer "squash and merge". Especially when there is a lot of
"noise" in the PR commit history:
e.g. "fixed CI", "opps, really fixed CI" etc. Also if the PR is small, a
single commit is easier to understand (and even remove if required).

I don't mind "rebase and merge" if the history is valuable e.g. it's a
large PR with a few different almost standalone changes.

Thanks

On Mon, 17 Jun 2019, 18:58 Vladimir Sitnikov, 
wrote:

> Hi,
>
> We have migrated to GitBox, and now committers have enough grants to merge
> PRs right from GitHub UI.
> With great power comes great responsibility.
>
> Unfortunately, the button defaults to "create merge commit".
> It makes Git history non-linear which might be painful to analyze.
> Non-linear histories might be helpful, however I think we don't really need
> those from GitHub UI.
>
> Other options are
> "squash and merge" (==pretend the PR was developed as a single commit on
> top of the current master)
> "rebase and merge" (==pretend all the commits in PR were developed on top
> of the current master)
>
> Both options more or less resemble the way we used to work with SVN.
> "Create merge commit from GitHub UI" is something new, and I suggest to
> disable it.
> Note: merge commits could still be created though command line, and it is a
> completely different topic.
>
> I suggest to make a formal vote about it:
>
> +1 [ ] Let's disable "merge commit" button in GitHub UI
> +0 [ ] I don't care, but it is fine
> -1 [ ] Please keep "merge commit" button in GitHub UI because...
>
> My vote is
> +1 Let's disable "merge commit" button in GitHub UI
>
> Vladimir
>

Re: Migrating build system to Gradle

[Graham Russell]

I like the direction the Gradle work is going. Thank you for all your
time and effort Vladimir!
It's great when I can simply point to one file, with no other steps
(documented or not) and have everything import, download, build and
run tests via the IDE (IntelliJ for me but I would imagine it's the
same for Eclipse?).
I also like the use of Kotlin instead of Groovy (I've only recently
discovered Kotlin but love it already).

I support the move of files around, version control should cope and it
will soon be a minor historical blip.
However, I agree with Sebb in that it is difficult to review and
mistakes will likely be made due to the other
changes happening on trunk (sorry some were me).

May I suggest that we try to move the source files in trunk (and of
course get ant to work but I don't know how hard that might be)?
This should be far easier to develop this Gradle PR and merge it when
the time comes.

But, going even further, to prevent a lot of work (and effort and good
will), separate to trunk, potentially being discarded, can we get both
Ant and Gradle working together in trunk?
We can continue to develop Gradle in small, tested, iterative steps,
while still being able to fall back to Ant if required (or preferred)
until we are all happy Gradle does all the things we need it to do?
This seems too large a task not to do in a CI fashion?
I'm worried that as the bulid.xml file is 3000 lines long and we are
trying to replace it without rationalising what is and isn't required
this seems risky.

May I suggest that we have a clear set of goals that, once Gradle can
do, we are happy to switch?
e.g.
- Compile
- Mange dependencies
- Run Unit Test (Spock and JUnit)
- Run Unit Tests from IDE (I was working on an improvement for this as
some of the JMeterSpec and JmeterTestCase look for properties files in
relative locations, which with the new source structure is different)
- Run batch tests (ideally in parallel, unlike the current ant scripts)
- Run checkstyle
- Make sure tests are run with coverage enabled/reported
- Package and sign a release (maybe this could be a separate script
which does the co-ordination and singing etc.)
- Documentation
(Sebb for details on what each one you mentioned below does, can we
look in the ant build script?)
- Generate Javadocs
- Printable docs
- website docs
- Staging
- Release promotion
- Generation of Maven artifacts

Thanks

Graham

On Wed, 27 Feb 2019 at 18:52, sebb  wrote:
>
> On Wed, 27 Feb 2019 at 18:15, Vladimir Sitnikov
>  wrote:
> >
> > sebb>I did not ask for an exhaustive list, but some clue as to what you
> > sebb>have run so others can repeat the tests on diferent hosts.
> >
> > Well, I have already suggested to check if the project builds and/or if it 
> > loads into IDE, code navigation, autocomplete, etc, and other typical 
> > developers' tasks.
> > It is by far the most significant improvement which Gradle brings.
> >
> > I could answer questions, however it should "just work".
> > I do not intend to write an exhaustive documentation on how Gradle should 
> > be used.
>
> Again, I am not asking for extensive explanations.
> Just list a few Gradle commands that should be tried.
>
> For example, in the Ant case, I would suggest people try:
> Ant clean
> Ant package
> Ant test
> Ant junit -Dtest.case=xxx
> Ant printable-docs
>
> etc
>
> > Gradle should work transparently behind the scenes, so regular 
> > Google/StackOverflow should answer all the typical questions immediately.
>
> > sebb>See below for further technical reasons
> >
> > I'm sure the questions you list do not qualify as technical justification 
> > for the veto, however I'm not going to explain that further at the moment.
> > My point is:
> > A) There's nothing to veto yet
> > B) I would prefer spend time on implementing features rather than arguing 
> > with you
> > C) As the build script is ready, you might happen to allow it to be 
> > committed. If that happens, we all save the time in the first place
>
> Not sure what build script you are referring to.
>
> > D) Only in case you (or someone else) happen to claim a veto, then we would 
> > have an interesting conversation.
> >
> > Of course I would appreciate comments (e.g. Graham Russell noted I add 
> > duplicate lines in .gitignore), however I do not see how I could apply 
> > opinions like "I think".
> >
> > sebb> So what is ready for testing?
> >
> > 1) Building the project
>
> Does it create the jars, or just the classes?
>
> > 2) Loading code to IDE
>
> Which IDEs have you tried?
>
> > 3) Running tests (certain tests fail still)
>
> How many tests are r

Re: Migrating build system to Gradle

[Graham Russell]

I agree, using https://stackoverflow.com/a/34327202 seems the best to
me where we just use a customised Ivy repo.

Thanks for sharing that info about freemaker!


On Sat, 23 Feb 2019 at 17:20, Woonsan Ko  wrote:
>
> On Sat, Feb 23, 2019 at 12:05 PM Woonsan Ko  wrote:
> >
> > On Sat, Feb 23, 2019 at 11:49 AM Philippe Mouawad
> >  wrote:
> > >
> > > On Sat, Feb 23, 2019 at 5:24 PM Graham Russell  wrote:
> > >
> > > > Sebb:
> > > > I will try again on a new VM and write them up, perhaps on Monday.
> > > >
> > > > I doubt it would have done it automatically, but it probably would
> > > > have been quicker to solve.
> > > > i.e. add: compile 'org.openjfx:javafx-controls:11' to dependencies and
> > > > Gradle + IDE automatically then work.
> > > > Rather than: finding the required jar, copying it to the lib folder
> > > > and manually adding it to the IntelliJ project.
> > > >
> > > > Philippe:
> > > > I do not think it would be able to handle the dependency management
> > > > without also doing the compilation (but I could be wrong).
> > > > For Darcula, there are options https://stackoverflow.com/a/34327202 or
> > > >
> > > > https://stackoverflow.com/questions/17123606/how-to-download-external-files-in-gradle
> > > >
> > > > However, the more we dig the more we might have to change the status
> > > > quo, it seems the git discussion is similar, i.e. now that we might
> > > > want to use a different tool we should probably use it in the way it
> > > > was intended to solve our problems rather than simply use the same
> > > > ways of working.
> > > >
> > > I agree, did I meant something else for you (in which answer ?) ?
> > > It is just that Darcula is just not available in Maven Central.
> > > I just wanted to highlight this specificity to have it mind when 
> > > migrating.
> >
> > Should be possible with a either flatDir (after download) or custom
> > repository setting:
> > - https://docs.gradle.org/current/userguide/repository_types.html
>
> And, after searching on the internet, I found two approaches to
> download files in Groovy DSL: (a) use Ant! [1] ;-), (b) another AL'ed
> download helper module [2].
>
> BTW, also take a look at FreeMarker v3 (not released yet, still in
> dev) branch's README about IDE setup instructions (probably many
> already knew, but might be useful...):
> - https://github.com/apache/freemarker/tree/3#ide-setup
> (FreeMarker has a very complex setup in its Ant build in v2 the
> official one, including JavaCC, separate unit tests with different
> incompatible JVM or dependencies, ...), but FM3 has migrated from Ant
> to Gradle, which works fine even if we are not done yet regarding
> Apache Release artifacts generations.)
>
> Regards,
>
> Woonsan
>
> [1] 
> https://stackoverflow.com/questions/23023069/gradle-download-and-unzip-file-from-url/34327202
> [2] https://github.com/michel-kraemer/gradle-download-task
>
> >
> > Woonsan
> >
> > >
> > >
> > > Thus, unfortunately, making these even more difficult than just the
> > > > initial technical challenge, but, in my mind they will be well worth
> > > > it in the long term.
> > > >
> > > Agreed
> > >
> > > >
> > > >
> > > > Graham
> > > >
> > > > On Sat, 23 Feb 2019 at 14:59, Philippe Mouawad
> > > >  wrote:
> > > > >
> > > > > Thanks Graham for those very interesting insights.
> > > > >
> > > > > Is gradle able within its dependency management to handle case where
> > > > > dependency is not a Maven nor Ivy one ?
> > > > >
> > > > >-
> > > > >
> > > > https://docs.gradle.org/current/userguide/introduction_dependency_management.html
> > > > >
> > > > > I guess it would be possible to do it with custom coding (download
> > > > artifact
> > > > > and put it in local maven repository, but if it's built-in it would be
> > > > > better.
> > > > >
> > > > > We have Darcula which is in this case.
> > > > >
> > > > > Regarding your proposal, do you think it would be feasible as a first
> > > > step
> > > > > to delegate dependencies management to Gradle ?
> > > > > I think it would possibly improve

Re: Migrating build system to Gradle

[Graham Russell]

Sebb:
I will try again on a new VM and write them up, perhaps on Monday.

I doubt it would have done it automatically, but it probably would
have been quicker to solve.
i.e. add: compile 'org.openjfx:javafx-controls:11' to dependencies and
Gradle + IDE automatically then work.
Rather than: finding the required jar, copying it to the lib folder
and manually adding it to the IntelliJ project.

Philippe:
I do not think it would be able to handle the dependency management
without also doing the compilation (but I could be wrong).
For Darcula, there are options https://stackoverflow.com/a/34327202 or
https://stackoverflow.com/questions/17123606/how-to-download-external-files-in-gradle

However, the more we dig the more we might have to change the status
quo, it seems the git discussion is similar, i.e. now that we might
want to use a different tool we should probably use it in the way it
was intended to solve our problems rather than simply use the same
ways of working.
Thus, unfortunately, making these even more difficult than just the
initial technical challenge, but, in my mind they will be well worth
it in the long term.


Graham

On Sat, 23 Feb 2019 at 14:59, Philippe Mouawad
 wrote:
>
> Thanks Graham for those very interesting insights.
>
> Is gradle able within its dependency management to handle case where
> dependency is not a Maven nor Ivy one ?
>
>-
>
> https://docs.gradle.org/current/userguide/introduction_dependency_management.html
>
> I guess it would be possible to do it with custom coding (download artifact
> and put it in local maven repository, but if it's built-in it would be
> better.
>
> We have Darcula which is in this case.
>
> Regarding your proposal, do you think it would be feasible as a first step
> to delegate dependencies management to Gradle ?
> I think it would possibly improve already developer experience.
>
> Thanks
>
>
> On Sat, Feb 23, 2019 at 11:50 AM Graham Russell  wrote:
>
> > +1 to move to Gradle.
> >
> > I think the biggest benefit of moving to Gradle is that it will lead to
> > more contributions.
> >
> > People will no longer have to fight to get the code to import into an IDE
> > (i.e. IntelliJ), compile and successfully run tests.
> > I've just got a new laptop and it took me too long to get JMeter just to
> > import and compile in IntelliJ, there were at least 5 different,
> > non-standard steps to get it to work. One of them was manually including
> > JavaFx as it's no longer part of OpenJDK and not download as part of ant
> > download_jars.
> >
> > The other benefit is that it should improve the speed at which we can
> > build, test and therefore make changes.
> >
> > I think, regardless if we move to Gradle, that a few people with a good
> > knowledge of ant and our current build.xml should make it easier to
> > understand and optimise it:
> > 1. comment anything which might not be obvious to someone new to ant and
> > 2. remove (or simplify) anything which is no longer required
> >
> > We could switch JMeter to Gradle right now by using
> > https://docs.gradle.org/current/userguide/ant.html
> > e.g. using a build.gradle file with
> >
> > ant.importBuild("build.xml")
> > ant.lifecycleLogLevel = AntBuilder.AntMessagePriority.INFO
> >
> > Then start to move the actions into the Gradle file, although it seems
> > things are too interconnected for this to be an easy job.
> >
> > A separate release script like Kafka is a very good idea. It doesn't bloat
> > the build file and encourages automation and even simplification of the
> > important release process.
> >
> > Thanks
> >
> > Graham
> >
> > On Sat, 23 Feb 2019, 03:25 Vladimir Sitnikov,  > >
> > wrote:
> >
> > > Apache Kafka might be relevant for the inspiration.
> > > They somehow release Apache-compatible artifacts, and they use Git,
> > Gradle.
> > >
> > > https://github.com/apache/kafka
> > > https://github.com/apache/kafka/blob/trunk/release.py
> > >
> > > Vladimir
> > >
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Build failed in Jenkins: JMeter-trunk #7103

[Graham Russell]

Great, thanks.

Also, thank you for the rapid PR merge!

On Sat, 23 Feb 2019 at 15:32, Philippe Mouawad
 wrote:
>
> Yes, I fixed it.
> Jenkins should complete successfully now.
>
> On Sat, Feb 23, 2019 at 4:28 PM Graham Russell  wrote:
>
> > This might be caused by having both 1.0 and 1.2 in the lib folder, are
> > old jars removed from the Jenkins job?
> >
> > The tests pass on my machine at current trunk.
> >
> >
> > On Sat, 23 Feb 2019 at 15:19, Apache Jenkins Server
> >  wrote:
> > >
> > > See <https://builds.apache.org/job/JMeter-trunk/7103/display/redirect>
> > >
> > > --
> > > [...truncated 281.50 KB...]
> > >  [java] java.lang.IllegalStateException: Did not find call #0 on
> > stack. Invalid call of record method?
> > >  [java] at org.apache.jmeter.services.FileServerSpec.reading
> > lines loops to start once last line is read(FileServerSpec.groovy:86)
> > >  [java] 90) closing reserved file after reading
> > resets(org.apache.jmeter.services.FileServerSpec)
> > >  [java] java.lang.IllegalStateException: Did not find call #0 on
> > stack. Invalid call of record method?
> > >  [java] at org.apache.jmeter.services.FileServerSpec.closing
> > reserved file after reading resets(FileServerSpec.groovy:106)
> > >  [java] 91) closeFiles() prevents reading of reserved
> > file(org.apache.jmeter.services.FileServerSpec)
> > >  [java] java.lang.IllegalStateException: Did not find call #0 on
> > stack. Invalid call of record method?
> > >  [java] at
> > org.apache.jmeter.services.FileServerSpec.closeFiles() prevents reading of
> > reserved file(FileServerSpec.groovy:119)
> > >  [java] 92) baseDir is the
> > defaultBasedir(org.apache.jmeter.services.FileServerSpec)
> > >  [java] java.lang.IllegalStateException: Did not find call #0 on
> > stack. Invalid call of record method?
> > >  [java] at org.apache.jmeter.services.FileServerSpec.baseDir is
> > the defaultBasedir(FileServerSpec.groovy:125)
> > >  [java] 93) setBaseDir doesn't error when no files are
> > open(org.apache.jmeter.services.FileServerSpec)
> > >  [java] java.lang.IllegalStateException: Did not find call #0 on
> > stack. Invalid call of record method?
> > >  [java] at org.apache.jmeter.services.FileServerSpec.setBaseDir
> > doesn't error when no files are open(FileServerSpec.groovy:132)
> > >  [java] 94) setting base to #file gives getBaseDirRelative ==
> > #expectedBaseDirRelative(org.apache.jmeter.services.FileServerSpec)
> > >  [java] java.lang.IllegalArgumentException: Method
> > '$spock_feature_1_13prov1([])' can't be called with parameters '[[<
> > https://builds.apache.org/job/JMeter-trunk/ws/trunk/bin,> <
> > https://builds.apache.org/job/JMeter-trunk/ws/trunk,> <
> > https://builds.apache.org/job/JMeter-trunk/ws/trunk/abcd/defg.jmx,> <
> > https://builds.apache.org/job/JMeter-trunk/ws/trunk/bin/abcd/defg.jmx]]'!>
> > >  [java] at
> > org.spockframework.util.ReflectionUtil.validateArguments(ReflectionUtil.java:212)
> > >  [java] at
> > org.spockframework.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:199)
> > >  [java] at
> > org.spockframework.runtime.model.MethodInfo.invoke(MethodInfo.java:113)
> > >  [java] at org.junit.runners.Suite.runChild(Suite.java:128)
> > >  [java] at org.junit.runners.Suite.runChild(Suite.java:27)
> > >  [java] at
> > org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> > >  [java] at
> > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> > >  [java] at
> > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> > >  [java] at
> > org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> > >  [java] at
> > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> > >  [java] at
> > org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> > >  [java] at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> > >  [java] at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> > >  [java] at
> > org.apache.jorphan.test.AllTests.main(AllTests.java:219)
> > >  [java] 95) non-existent filename to reserveFile will throw
> > exception(org.apache.jmeter.services.FileServerSpec)
> > >

Re: Build failed in Jenkins: JMeter-trunk #7103

[Graham Russell]

This might be caused by having both 1.0 and 1.2 in the lib folder, are
old jars removed from the Jenkins job?

The tests pass on my machine at current trunk.


On Sat, 23 Feb 2019 at 15:19, Apache Jenkins Server
 wrote:
>
> See 
>
> --
> [...truncated 281.50 KB...]
>  [java] java.lang.IllegalStateException: Did not find call #0 on stack. 
> Invalid call of record method?
>  [java] at org.apache.jmeter.services.FileServerSpec.reading lines 
> loops to start once last line is read(FileServerSpec.groovy:86)
>  [java] 90) closing reserved file after reading 
> resets(org.apache.jmeter.services.FileServerSpec)
>  [java] java.lang.IllegalStateException: Did not find call #0 on stack. 
> Invalid call of record method?
>  [java] at org.apache.jmeter.services.FileServerSpec.closing reserved 
> file after reading resets(FileServerSpec.groovy:106)
>  [java] 91) closeFiles() prevents reading of reserved 
> file(org.apache.jmeter.services.FileServerSpec)
>  [java] java.lang.IllegalStateException: Did not find call #0 on stack. 
> Invalid call of record method?
>  [java] at org.apache.jmeter.services.FileServerSpec.closeFiles() 
> prevents reading of reserved file(FileServerSpec.groovy:119)
>  [java] 92) baseDir is the 
> defaultBasedir(org.apache.jmeter.services.FileServerSpec)
>  [java] java.lang.IllegalStateException: Did not find call #0 on stack. 
> Invalid call of record method?
>  [java] at org.apache.jmeter.services.FileServerSpec.baseDir is the 
> defaultBasedir(FileServerSpec.groovy:125)
>  [java] 93) setBaseDir doesn't error when no files are 
> open(org.apache.jmeter.services.FileServerSpec)
>  [java] java.lang.IllegalStateException: Did not find call #0 on stack. 
> Invalid call of record method?
>  [java] at org.apache.jmeter.services.FileServerSpec.setBaseDir 
> doesn't error when no files are open(FileServerSpec.groovy:132)
>  [java] 94) setting base to #file gives getBaseDirRelative == 
> #expectedBaseDirRelative(org.apache.jmeter.services.FileServerSpec)
>  [java] java.lang.IllegalArgumentException: Method 
> '$spock_feature_1_13prov1([])' can't be called with parameters 
> '[[ 
>  
>  
> 
>  [java] at 
> org.spockframework.util.ReflectionUtil.validateArguments(ReflectionUtil.java:212)
>  [java] at 
> org.spockframework.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:199)
>  [java] at 
> org.spockframework.runtime.model.MethodInfo.invoke(MethodInfo.java:113)
>  [java] at org.junit.runners.Suite.runChild(Suite.java:128)
>  [java] at org.junit.runners.Suite.runChild(Suite.java:27)
>  [java] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>  [java] at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>  [java] at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>  [java] at 
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>  [java] at 
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>  [java] at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>  [java] at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>  [java] at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
>  [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:219)
>  [java] 95) non-existent filename to reserveFile will throw 
> exception(org.apache.jmeter.services.FileServerSpec)
>  [java] java.lang.IllegalStateException: Did not find call #0 on stack. 
> Invalid call of record method?
>  [java] at org.apache.jmeter.services.FileServerSpec.non-existent 
> filename to reserveFile will throw exception(FileServerSpec.groovy:181)
>  [java] 96) reserving a file with no header will throw an exception if 
> the header is expected(org.apache.jmeter.services.FileServerSpec)
>  [java] java.lang.IllegalStateException: Did not find call #0 on stack. 
> Invalid call of record method?
>  [java] at org.apache.jmeter.services.FileServerSpec.reserving a file 
> with no header will throw an exception if the header is 
> expected(FileServerSpec.groovy:193)
>  [java] 97) resolvedFile returns absolute and relative 
> files(org.apache.jmeter.services.FileServerSpec)
>  [java] java.lang.IllegalStateException: Did not find call #0 on stack. 
> Invalid call of record method?
>  [java] at org.apache.jmeter.services.FileServerSpec.resolvedFile 
> returns absolute and relative files(FileServerSpec.groovy:201)
>  [java] 98) resolvedFile returns relative files wi

Re: Migrating build system to Gradle

[Graham Russell]

+1 to move to Gradle.

I think the biggest benefit of moving to Gradle is that it will lead to
more contributions.

People will no longer have to fight to get the code to import into an IDE
(i.e. IntelliJ), compile and successfully run tests.
I've just got a new laptop and it took me too long to get JMeter just to
import and compile in IntelliJ, there were at least 5 different,
non-standard steps to get it to work. One of them was manually including
JavaFx as it's no longer part of OpenJDK and not download as part of ant
download_jars.

The other benefit is that it should improve the speed at which we can
build, test and therefore make changes.

I think, regardless if we move to Gradle, that a few people with a good
knowledge of ant and our current build.xml should make it easier to
understand and optimise it:
1. comment anything which might not be obvious to someone new to ant and
2. remove (or simplify) anything which is no longer required

We could switch JMeter to Gradle right now by using
https://docs.gradle.org/current/userguide/ant.html
e.g. using a build.gradle file with

ant.importBuild("build.xml")
ant.lifecycleLogLevel = AntBuilder.AntMessagePriority.INFO

Then start to move the actions into the Gradle file, although it seems
things are too interconnected for this to be an easy job.

A separate release script like Kafka is a very good idea. It doesn't bloat
the build file and encourages automation and even simplification of the
important release process.

Thanks

Graham

On Sat, 23 Feb 2019, 03:25 Vladimir Sitnikov, 
wrote:

> Apache Kafka might be relevant for the inspiration.
> They somehow release Apache-compatible artifacts, and they use Git, Gradle.
>
> https://github.com/apache/kafka
> https://github.com/apache/kafka/blob/trunk/release.py
>
> Vladimir
>

Re: Migrate SVN -> Git

[Graham Russell]

+1 for moving to git.

I think the biggest benefit to move to git is that it will make the
merging of all the PRs we get on the github mirror easier ;)
Which might then lead to more people more willing to do it and
therefore lead to more contributions.

Does anyone know the ratio of Github PRs to patches via BZ in the last
few releases?

Both SVN/Ant and git/Gradle "work", so it comes down to developer
experience of using but also finding help and getting support.

Graham

On Thu, 21 Feb 2019 at 20:15, Philippe Mouawad
 wrote:
>
> Hi Vladimir,
>
> As initially discussed, I thought you would do at least one of the two, the
> Gradle being prioritary IMO.
> But it looks like you won't be able to in the end ?
>
> Volunteers are welcome in this case, although you looked like having
> interesting experience in Gradle that would have been very useful.
>
> Bon courage for your talks and preparations.
>
> Regards
>
> On Thu, Feb 21, 2019 at 8:11 PM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > I've studied a couple of recent INFRA tickets, and it looks like creating
> > Git repositories is handled via https://selfserve.apache.org/
> >
> > So Git->SVN migration boils down to creating an empty repository, pushing
> > code there. Then we should ask Infra to make SVN read-only, and things like
> > that.
> >
> > At this point I think it makes sense to just create a side Git repository
> > (e.g. a throw-away on GitHub), migrate JMeter code from SVN there, apply
> > Ant to Gradle converter, and then check how it turns out.
> >
> > I don't really see much sense in migrating to Gradle before Git conversion
> > (there are VCS-specific build steps).
> >
> > I don't really see much benefit from migrating to Git in a hurry either.
> > There are build/release tasks like "site update", and I think we might want
> > to have separate Git repository to serve the site contents.
> > At this point I don't know how JMeter site works, so I don't know it should
> > be mapped to Git/Gradle.
> >
> > I think I could handle the conversion, however it would be great if someone
> > volunteers.
> > The thing is I prepare a talk for https://jpoint.ru/en/ , and I help to
> > organize https://heisenbug-piter.ru/en/ this spring, so Git/Gradle is not
> > my priority at the moment.
> >
> > Vladimir
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Test Results Analyzer isn't working

[Graham Russell]

I agree.

The batch tests are so slow, partly because they run in sequence. It would
be good to make sure they are actually useful tests and add/remove as
necessary.

I was looking into running them in parallel, and found it easier with
gradle. Gradle can also import the existing ant script and seems to work,
at least for testing and building tasks.

I will submit a PR if using gradle seems useful to slowly phase out ant?

I think it will make a few things easier and more standard/modern.

Or we can try to change the runner and then use the parallel ant task?

I don't have much time this month but should be able to help in February.

Graham


On Fri, 5 Jan 2018, 15:14 Philippe Mouawad, 
wrote:

> Spock tests added.
> Maybe we’ll need to optimize build a bit as it takes now nearly half an
> hour to build
>
> On Friday, January 5, 2018, Philippe Mouawad 
> wrote:
>
> > Hi,
> > See:
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=61966
> >
> > We need to add Spock tests
> >
> > Regards
> >
> > On Fri, Jan 5, 2018 at 12:33 AM, Philippe Mouawad <
> > philippe.moua...@gmail.com> wrote:
> >
> >> Hello,
> >> This is not currently configured on jenkins as a post-build task.
> >>
> >> As we run junit test using java task, the XML files required for the
> >> report are not generated.
> >> There is a task "complete-junit" that would generate results, but
> >> currently it runs tests without required configuration which leads to
> >> errors/ failures:
> >>
> >>- https://builds.apache.org/job/JMeter-trunk/6575/testReport/
> >>- https://builds.apache.org/job/JMeter-trunk/test_results_analyzer/
> >>
> >> If you'd like to contribute an enhancement to build, feel free to do so.
> >>
> >> Regards
> >>
> >> On Wed, Jan 3, 2018 at 2:55 PM, jmeter tea  wrote:
> >>
> >>> Hello,
> >>>
> >>> Test Results Analyzer in Jenkins isn't working for JMeter
> >>> https://builds.apache.org/job/JMeter-trunk/test_results_analyzer/
> >>>
> >>> It's working in other other projects as:
> >>> https://builds.apache.org/job/HBase-Flaky-Tests/test_results_analyzer/
> >>>
> >>> FYI
> >>>
> >>
> >>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
> >>
> >>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
> >
> >
>
> --
> Cordialement.
> Philippe Mouawad.
>

Re: Controversial topic: Remove internationalization

[Graham Russell]

I don't think translations should be removed. I think they add value to
those who do not have a good understanding of English. We don't have any
usage metrics so it's hard to tell how much they are used.

Regarding it being unprofessional, I agree, but I do not think it is an
issue, especially if English is now the default.

I guess that we don't have more contributions because of a lack of
awareness and perhaps a lack of desire from people who have the ability to
translate, because they can use the English.

We could try to make the community more aware that we need more
translations? Perhaps via Twitter or the users list etc. and see if this
helps. However we first need to make sure the translation guidance is
really simple and easy for people to follow.

Graham

On Fri, 5 Jan 2018 at 00:31 Philippe Mouawad 
wrote:

> Hello,
>
> Currently we provide ability to translate JMeter GUI in many languages.
> In our tests we only ensure French translations are available because we
> have french team members.
>
> For other languages, we are in best effort and most probably the UI looks
> non professional for many users as there will be a mix of english and non
> english labels.
>
> I am aware that it's a controversial topic and many people probably rely on
> translated GUI BUT:
>
>- I dislike the fact that GUI looks non professional
>- Why don't we have more translation contributions if they are used ?
>- It's a certain piece of work to maintain and create those translations
>
> So unless there is a magical way to fully translate all labels and maintain
> them efficiently, I am  in favor of:
>
>- Having english forced in setup instead of relying on default locale.
>It seems this happened accidentally in 3.3 and nobody complained about
> it.
>- In a second step, and unless there is a big move to help on
>translation, I propose to drop all languages, even french one as it's an
>additional work and we have other and a lot of things to do
>
>
> Thoughts :-) ?
> --
> Cordialement.
> Philippe Mouawad.
>

Re: Weird Test failure

[Graham Russell]

If someone implementing the unit tests (and Felix) made that mistake is
there a way for us to prevent users making the same mistake?

On Sat, 30 Dec 2017 at 23:39 Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 30. Dezember 2017 16:06:34 MEZ schrieb Philippe Mouawad <
> philippe.moua...@gmail.com>:
> >Hi,
> >Should be fixed, please review.
>
> Looks good.
>
> I constructed a simple jmx file to test timeShift and stumbled over the
> same formatting problems (using Y instead of y) - but good no other
> concurrency problem.
>
> Regards,
>  Felix
>
> >
> >Thanks
> >
> >On Sat, Dec 30, 2017 at 3:29 PM, Philippe Mouawad <
> >philippe.moua...@gmail.com> wrote:
> >
> >> It is an issue with formatter creation:
> >> - https://bz.apache.org/bugzilla/show_bug.cgi?id=61938
> >>
> >> Regards
> >>
> >> On Sat, Dec 30, 2017 at 3:17 PM, Philippe Mouawad <
> >> philippe.moua...@gmail.com> wrote:
> >>
> >>> Hi Felix,
> >>> You can see a new strange behaviour today with last test failure.
> >>> Regards
> >>>
> >>> On Fri, Dec 22, 2017 at 9:27 PM, Philippe Mouawad <
> >>> philippe.moua...@gmail.com> wrote:
> >>>
>  Hi Felix,
>  I have just commited
> >TestTimeShiftFunction#testPotentialBugWithComplexPeriod
>  to show you the problem I describe.
>  As you can see the jmeter tests are  now running fine just because
> >we
>  moved 1 day.
> 
>  Regards
> 
>  On Fri, Dec 22, 2017 at 9:52 AM, Felix Schumacher <
>  felix.schumac...@internetallee.de> wrote:
> 
> > Am 21.12.2017 um 22:02 schrieb Philippe Mouawad:
> >
> >> Hello,
> >> We have since few days a failure in this method which didn't
> >change
> >> neither
> >> in test function nor in the test:
> >>
> >> - TestTimeShiftFunction#testNowWithComplexPeriod
> >>
> >>
> >> It seems something strange happens with Duration#parse.
> >>
> >> - P10DT-1H-5M5S
> >>
> >> Reading :
> >>
> >> -
> >https://docs.oracle.com/javase/8/docs/api/java/time/Duration
> >> .html#parse
> >>
> >> I would expect this to means :
> >>
> >> - Plus 10 days, -1 hours, -5 minutes + 5s
> >>
> >> But it ends up becoming:
> >>
> >> - 860105 seconds
> >>
> > If I type "10*(24*60*60)-1*(60*60)-5*(60)+5" into bc it spits out
> > "860105" which seems to be the same result. So I guess java and
> >the
> > documentation is correct.
> >
> > What did you expect?
> >
> > Felix
> >
> >
> >
> >> Is this a Java bug , or something I am missing ?
> >>
> >> Thanks
> >>
> >
> >
> >
> 
> 
>  --
>  Cordialement.
>  Philippe Mouawad.
> 
> 
> 
> >>>
> >>>
> >>> --
> >>> Cordialement.
> >>> Philippe Mouawad.
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
> >>
> >>
> >>
>

Re: Menu item ordering

[Graham Russell]

I've submitted a PR (https://github.com/apache/jmeter/pull/360) for the
menu re-ordering.
Testing, critiques and any major disagreements with my proposed order very
much welcomed!

I've tried to keep it simple for the time being. We could add another item
to the annotation, e.g. groups, which could then define more than the
current (specifically ordered vs. the rest).

The search box might take me a while, my swing GUI skills are lacking, and
I might not get time before Christmas to work on it.

I'm starting to like the idea of grouping plugins in their own sub-menu as
this might make it more obvious for beginners and easier if you need a lot
of plugins, then again, a palette with up to 10-15 things "ought to be
enough for anybody".

Thanks

Graham


On 12 December 2017 at 16:58, Vincent HERILIER  wrote:
> Maybe could we propose different layouts (full flat (default ?), full
> grouped, plugin only... defined by a property) mixed with LRU proposition,
> Search box... accordingly to user preferences/habits/needs ?
>
>
>
> Le mar. 12 déc. 2017 à 16:40, Vincent HERILIER  a
> écrit :
>
>> In the PR, I proposed, I grouped JMeter native elements as example, but
>> the PR insured to let some elements at their initial place (JMEter ones
to
>> keep its current usability) and allow others to be grouped (3rd party
ones
>> if required and proposed by their related maintainers).
>> So it was just allowing the feature, it didn't ordered it.
>>
>> Maybe it could be no more compatible with some evolutions you planned and
>> that avoids it anyway.
>> Or we could try to make these approaches complementary too...
>>
>> Anyway, I stay really interested in JMeter usability improvement.
>>
>> Le mar. 12 déc. 2017 à 16:15, Graham Russell  a écrit
:
>>
>>> Ah, I didn't appreciate the use case you had.
>>>
>>> I still think the additional menu groupings would be detrimental to more
>>> common use cases.
>>>
>>> Perhaps we can keep plugin menus ordered separated from the native ones
>>> this might help slightly. I will make sure I test my changes with some
>>> plugins!
>>>
>>> I was thinking to keep a LRU list in the search box results which should
>>> speed things up for most use cases.
>>>
>>> Graham
>>>
>>>
>>> On 12 December 2017 at 14:15, Vincent HERILIER 
>>> wrote:
>>> > I clearly understand your points of view.
>>> >
>>> > But with plugins used in my case (and average 300 testers) which bring
>>> > average 40 config elements and 90 samplers, they are mixed (with
JMeter
>>> > native ones too) for complex and cross-protocol flows we would like to
>>> > simulate (average 15 protocols - new , redefined protocols or server
>>> side
>>> > part - for our needs coverage).
>>> >
>>> > Reconfiguring a palette does not really solve my issue because the
range
>>> of
>>> > required elements changes often or is wide each time.
>>> > Loading and using a search box often will not really a gain of time
too.
>>> >
>>> > That's why a protocol grouping is IMHO and in my specific use-case
more
>>> > accurate and quickly usable.
>>> > I hope beiing wrong and I'm waiting for a quicker menu navigation
>>> mechanism
>>> > even it is not a submenu one ;).
>>> >
>>> > Thanks for all the work you provide to improve JMeter.
>>> >
>>> > Vincent
>>> >
>>> > Le mar. 12 déc. 2017 à 14:29, Graham Russell  a
>>> écrit :
>>> >
>>> >> I agree with Phillipe that adding more menus, and therefore steps to
>>> >> get to items you need (key presses or mouse moves) and items to read
>>> >> is not an improvement.
>>> >>
>>> >> I like the idea of a configurable palette (with some sensible
>>> >> defaults), much easier for beginners.
>>> >>
>>> >> This still requires use of the mouse, so for more advanced users,
what
>>> >> do we think of introducing a "find/search"?
>>> >> Pressing ctrl+shift+a loads a pop-up search box, as you type it
>>> >> filters the list and you click/press enter on the one you want and
>>> >> it's added to the tree.
>>> >>
>>> >> On 12 December 2017 at 13:11, Philippe Mouawad
>>> >>  wrote:
>>> >> > Hello,
>>> >> > I am personally against an additi

Re: Menu item ordering

[Graham Russell]

Ah, I didn't appreciate the use case you had.

I still think the additional menu groupings would be detrimental to more
common use cases.

Perhaps we can keep plugin menus ordered separated from the native ones
this might help slightly. I will make sure I test my changes with some
plugins!

I was thinking to keep a LRU list in the search box results which should
speed things up for most use cases.

Graham


On 12 December 2017 at 14:15, Vincent HERILIER  wrote:
> I clearly understand your points of view.
>
> But with plugins used in my case (and average 300 testers) which bring
> average 40 config elements and 90 samplers, they are mixed (with JMeter
> native ones too) for complex and cross-protocol flows we would like to
> simulate (average 15 protocols - new , redefined protocols or server side
> part - for our needs coverage).
>
> Reconfiguring a palette does not really solve my issue because the range
of
> required elements changes often or is wide each time.
> Loading and using a search box often will not really a gain of time too.
>
> That's why a protocol grouping is IMHO and in my specific use-case more
> accurate and quickly usable.
> I hope beiing wrong and I'm waiting for a quicker menu navigation
mechanism
> even it is not a submenu one ;).
>
> Thanks for all the work you provide to improve JMeter.
>
> Vincent
>
> Le mar. 12 déc. 2017 à 14:29, Graham Russell  a écrit :
>
>> I agree with Phillipe that adding more menus, and therefore steps to
>> get to items you need (key presses or mouse moves) and items to read
>> is not an improvement.
>>
>> I like the idea of a configurable palette (with some sensible
>> defaults), much easier for beginners.
>>
>> This still requires use of the mouse, so for more advanced users, what
>> do we think of introducing a "find/search"?
>> Pressing ctrl+shift+a loads a pop-up search box, as you type it
>> filters the list and you click/press enter on the one you want and
>> it's added to the tree.
>>
>> On 12 December 2017 at 13:11, Philippe Mouawad
>>  wrote:
>> > Hello,
>> > I am personally against an additional level in the popup menu as it
would
>> > be a loss of time.
>> > If it's about reorganizing the menu order to put most popular ones on
>> top,
>> > why not.
>> >
>> > A configurable palette in the right or bottom left (now we  have
dropped
>> > workbench)  might be a better alternative. User could put here the
>> elements
>> > he uses the most.
>> >
>> > Regards
>> >
>> >
>> >
>> > On Tue, Dec 12, 2017 at 2:05 PM, Vincent HERILIER 
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> I already proposed a PR in that way (
>> >> https://github.com/apache/jmeter/pull/236) and I'm still interested in
>> >> having the capability to group some elements ,per protocol class for
>> >> example, to reduce the amount of different menus entries shown.
>> >>
>> >> Vincent
>> >>
>> >> Le mar. 12 déc. 2017 à 10:07, Antonio Gomes Rodrigues <
ra0...@gmail.com>
>> a
>> >> écrit :
>> >>
>> >> > Hi,
>> >> >
>> >> > About advanced mode, some code has been written and maybe we need to
>> >> remove
>> >> > it and discuss again and finish it.
>> >> >
>> >> > Yes, it's hockey.
>> >> >
>> >> >
>> >> > For the moment I have few free time but I probably write some blog
>> post
>> >> > (Apache provide blog) about some features.
>> >> >
>> >> > Thanks to the PR
>> >> >
>> >> > Antonio
>> >> >
>> >> >
>> >> > 2017-12-11 21:00 GMT+01:00 Graham Russell :
>> >> >
>> >> > > Ah ok, I noticed something about advanced mode and wondered what
it
>> >> > meant,
>> >> > > probably worth tidying up?
>> >> > >
>> >> > > I think those hotkeys should be more prominently documented, I
only
>> >> > > recently discovered them, or are there other shortcuts you were
>> >> referring
>> >> > > to?
>> >> > >
>> >> > > I will attempt a PR with a proof of concept in the coming week.
>> >> > >
>> >> > > Thanks
>> >> > >
>> >> > > Graham
>> >> > >
>> >> &g

Re: Menu item ordering

[Graham Russell]

I agree with Phillipe that adding more menus, and therefore steps to
get to items you need (key presses or mouse moves) and items to read
is not an improvement.

I like the idea of a configurable palette (with some sensible
defaults), much easier for beginners.

This still requires use of the mouse, so for more advanced users, what
do we think of introducing a "find/search"?
Pressing ctrl+shift+a loads a pop-up search box, as you type it
filters the list and you click/press enter on the one you want and
it's added to the tree.

On 12 December 2017 at 13:11, Philippe Mouawad
 wrote:
> Hello,
> I am personally against an additional level in the popup menu as it would
> be a loss of time.
> If it's about reorganizing the menu order to put most popular ones on top,
> why not.
>
> A configurable palette in the right or bottom left (now we  have dropped
> workbench)  might be a better alternative. User could put here the elements
> he uses the most.
>
> Regards
>
>
>
> On Tue, Dec 12, 2017 at 2:05 PM, Vincent HERILIER 
> wrote:
>
>> Hi,
>>
>> I already proposed a PR in that way (
>> https://github.com/apache/jmeter/pull/236) and I'm still interested in
>> having the capability to group some elements ,per protocol class for
>> example, to reduce the amount of different menus entries shown.
>>
>> Vincent
>>
>> Le mar. 12 déc. 2017 à 10:07, Antonio Gomes Rodrigues  a
>> écrit :
>>
>> > Hi,
>> >
>> > About advanced mode, some code has been written and maybe we need to
>> remove
>> > it and discuss again and finish it.
>> >
>> > Yes, it's hockey.
>> >
>> >
>> > For the moment I have few free time but I probably write some blog post
>> > (Apache provide blog) about some features.
>> >
>> > Thanks to the PR
>> >
>> > Antonio
>> >
>> >
>> > 2017-12-11 21:00 GMT+01:00 Graham Russell :
>> >
>> > > Ah ok, I noticed something about advanced mode and wondered what it
>> > meant,
>> > > probably worth tidying up?
>> > >
>> > > I think those hotkeys should be more prominently documented, I only
>> > > recently discovered them, or are there other shortcuts you were
>> referring
>> > > to?
>> > >
>> > > I will attempt a PR with a proof of concept in the coming week.
>> > >
>> > > Thanks
>> > >
>> > > Graham
>> > >
>> > > On Mon, 11 Dec 2017, 09:21 Antonio Gomes Rodrigues, 
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > Sometime ago we have discuss to have an advanced mode with all
>> options
>> > > and
>> > > > an basic mode with only the essentials. Unfortunately there was no
>> > > > consensus
>> > > >
>> > > > For the moment we have shortcuts
>> > > >
>> > > > +1 for your solution
>> > > >
>> > > > Antonio
>> > > >
>> > > >
>> > > > 2017-12-10 19:36 GMT+01:00 Graham Russell :
>> > > >
>> > > > > Hi all
>> > > > >
>> > > > > Currently the menus are ordered alphabetically, which is fine for
>> > > > > small menus, and better than not at all for the large ones,
>> however I
>> > > > > think we can do better.
>> > > > >
>> > > > > If the menu has more than 4-5 items in it I think we should split
>> it
>> > > > > up into chunks of 5-7 with the most popular (e.g. HTTP Request
>> > > > > Sampler) at the top. I hope this would ease a bit of RSI for users
>> > and
>> > > > > help improve the usability.
>> > > > >
>> > > > > Any thoughts?
>> > > > >
>> > > > > Having looked at the code it seems the menus are built by looking
>> at
>> > > > > the classes, does adding an annotation with "sort order" and maybe
>> > > > > "group" make sense or is there a better way to dictate the order of
>> > > > > items in the menus?
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > > > Graham
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Menu item ordering

[Graham Russell]

Ah ok, I noticed something about advanced mode and wondered what it meant,
probably worth tidying up?

I think those hotkeys should be more prominently documented, I only
recently discovered them, or are there other shortcuts you were referring
to?

I will attempt a PR with a proof of concept in the coming week.

Thanks

Graham

On Mon, 11 Dec 2017, 09:21 Antonio Gomes Rodrigues, 
wrote:

> Hi,
>
> Sometime ago we have discuss to have an advanced mode with all options and
> an basic mode with only the essentials. Unfortunately there was no
> consensus
>
> For the moment we have shortcuts
>
> +1 for your solution
>
> Antonio
>
>
> 2017-12-10 19:36 GMT+01:00 Graham Russell :
>
> > Hi all
> >
> > Currently the menus are ordered alphabetically, which is fine for
> > small menus, and better than not at all for the large ones, however I
> > think we can do better.
> >
> > If the menu has more than 4-5 items in it I think we should split it
> > up into chunks of 5-7 with the most popular (e.g. HTTP Request
> > Sampler) at the top. I hope this would ease a bit of RSI for users and
> > help improve the usability.
> >
> > Any thoughts?
> >
> > Having looked at the code it seems the menus are built by looking at
> > the classes, does adding an annotation with "sort order" and maybe
> > "group" make sense or is there a better way to dictate the order of
> > items in the menus?
> >
> > Thanks
> >
> > Graham
> >
>

Menu item ordering

[Graham Russell]

Hi all

Currently the menus are ordered alphabetically, which is fine for
small menus, and better than not at all for the large ones, however I
think we can do better.

If the menu has more than 4-5 items in it I think we should split it
up into chunks of 5-7 with the most popular (e.g. HTTP Request
Sampler) at the top. I hope this would ease a bit of RSI for users and
help improve the usability.

Any thoughts?

Having looked at the code it seems the menus are built by looking at
the classes, does adding an annotation with "sort order" and maybe
"group" make sense or is there a better way to dictate the order of
items in the menus?

Thanks

Graham

Re: ExternalSampleSorter#sortSamplesParallel

[Graham Russell]

I agree with Felix, however I cannot see where the code is being used.
If someone could explain where and how it's being used then I'm happy to
help test it, otherwise this is more code to delete.

On Tue, 28 Nov 2017 at 21:30 Philippe Mouawad 
wrote:

> Hi Graham,
> Resurecting this question from Felix as you're working on this.
>
> Regards
>
> On Wed, Dec 30, 2015 at 7:42 PM, Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
> > Hi all,
> >
> > in the sortSamplesParallel method two new jobs are created and put into
> > workQueue, but are only needed, when parallelize is true. In the
> > corresponding method sortFilesParallel the addition of the jobs to the
> > workQueue is done only when parallelize is true.
> >
> > I think it would be correct to change sortSamplesParallel to add the jobs
> > to the workQueue in parallel mode only.
> >
> > What do you think?
> >
> > Regards,
> >  Felix
> >
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

Re: Screenshot in doc

[Graham Russell]

I don't think it should stop a release, but if someone has the time to
re-take most (all) of them, then I think screenshots with the new default
LaF would be best.

P.S. please make sure pngquant or something like tinypng.com is used to
ensure the files are a small as possible - we wouldn't want our
documentation for a perf testing tool to be slower than it needs to be.

On Wed, 29 Nov 2017 at 16:12 Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 29. November 2017 15:26:49 MEZ schrieb Antonio Gomes Rodrigues <
> ra0...@gmail.com>:
> >Hi,
> >
> >I have a question about screenshots in documentation, which Look And
> >Feel
> >do we need to use?
>
> I think it is OK to have different look and feels. Currently we have
> different look and feels in the docs.
>
> Felix
>
> >
> >For the moment, we have the classical L&F, bit in this PR
> >https://github.com/apache/jmeter/pull/344/files#diff-1it's darcula
> >
> >Antonio
>

ExternalSampleSorter

[Graham Russell]

Hi all

Does anyone know if
org.apache.jmeter.report.processor.ExternalSampleSorter is used? I am
trying to unit test it (and think I may have found a small bug in
CsvSampleReader) but it doesn't look like ExternalSampleSorter is used
in our codebase, nor anyone else's (that Google can see).

Can we delete this or can someone enlighten me how and where it
is/might be used?

Thank you

Graham

Re: Remove comments about object ages in bin/jmeter

[Graham Russell]

+1 to remove the link (or replace with a modern alternative?)
+0 to remove the text

On Sun, 26 Nov 2017 at 21:35 Antonio Gomes Rodrigues 
wrote:

> Hi,
>
> In bin/jmeter we have
>
> #
> # Original page has disappeared, it is now only available at:
> #
>
> https://web.archive.org/web/20060614151434/http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606
> #
> # JMeter objects can generally be grouped into three life-length groups:
> #
> # - Per-sample objects (results, DOMs,...). An awful lot of those.
> #   Life length of milliseconds to a few seconds.
> #
> # - Per-run objects (threads, listener data structures,...). Not that many
> #   of those unless we use the table or tree listeners on heavy runs.
> #   Life length of minutes to several hours, from creation to start of next
> run.
> #
> # - Per-work-session objects (test plans, GUIs,...).
> #   Life length: for the life of the JVM.
>
> The link is very old 2003 and not updated to G1 GC
>
> Moreover I find that the information given is useless
>
> O propose to remove these lines
>
> Antonio
>

Re: ApacheJMeter_parent.pom test dependencies

[Graham Russell]

Yes, you might be right. It would make sense to add them to the test scope
if this doesn't break the maven release as they shouldn't be part of any
release.

On Sat, 25 Nov 2017 at 17:30 Philippe Mouawad 
wrote:

> Hello,
> I am wondering if we don't have an issue with our dependencies:
>
> Shouldn't those ones be in scope test:
> spock-core
> hamcrest-core
> hamcrest-date
> objenesis
> cglib-nodep
>
> --
> Regards.
> Philippe
>

Re: Static Analysis Issues

[Graham Russell]

I've raised https://issues.apache.org/jira/browse/INFRA-15530

I guess we can turn it off or tune the gate if we find it too noisy.

On 21 November 2017 at 21:48, Philippe Mouawad
 wrote:
> Hi Graham,
> My answers below.
> Regards
>
> On Sun, Nov 19, 2017 at 3:09 PM, Graham Russell  wrote:
>
>> It looks to me like the quality gate is already failing?
>> https://builds.apache.org/analysis/overview?id=org.apache.jmeter%3AJMeter
>>
>> How do we normally know if we are passing or failing, could it be made part
>> of the build?
>>
> We can tune quality gate:
>
>- https://docs.sonarqube.org/display/SONAR/Quality+Gates
>
>
>> How do we open a request to infra about notifications?
>>
>
> Open a JIRA request:
> See similar issue:
>
>- https://issues.apache.org/jira/browse/INFRA-15506
>
>
>> Thanks
>>
>> Graham
>>
>> On Sun, 19 Nov 2017, 11:11 Philippe Mouawad, 
>> wrote:
>>
>> > Hello,
>> > It should be possible by configuring Quality Gate to fail .
>> > Regarding notifications, I think we must open a request towards Infra
>> team.
>> >
>> > Regards
>> >
>> > On Sun, Nov 19, 2017 at 11:56 AM, Graham Russell 
>> > wrote:
>> >
>> > > All
>> > >
>> > > Do we get notifications of sonar issues? I've just noticed that 8
>> > > "bugs" were introduced yesterday:
>> > > https://builds.apache.org/analysis/component_issues?id=
>> > > org.apache.jmeter%3AJMeter#resolved=false|types=BUG
>> > >
>> > > Is it also possible to get it to check PRs as we do with codecov, is
>> > > this one for ifra?
>> > >
>> > > Thanks
>> > >
>> > > Graham
>> > >
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>> >
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Deprecated Classes

[Graham Russell]

I came across the following classes, in org.apache.log, which are
deprecated and the comment says will be removed in 3.3, but they still
seem to be here:
LogEvent
ContextMap
LogTarget
Logger
Priority

Was this an oversight or should these have been removed?

Thanks

Graham

Re: Static Analysis Issues

[Graham Russell]

It looks to me like the quality gate is already failing?
https://builds.apache.org/analysis/overview?id=org.apache.jmeter%3AJMeter

How do we normally know if we are passing or failing, could it be made part
of the build?

How do we open a request to infra about notifications?

Thanks

Graham

On Sun, 19 Nov 2017, 11:11 Philippe Mouawad, 
wrote:

> Hello,
> It should be possible by configuring Quality Gate to fail .
> Regarding notifications, I think we must open a request towards Infra team.
>
> Regards
>
> On Sun, Nov 19, 2017 at 11:56 AM, Graham Russell 
> wrote:
>
> > All
> >
> > Do we get notifications of sonar issues? I've just noticed that 8
> > "bugs" were introduced yesterday:
> > https://builds.apache.org/analysis/component_issues?id=
> > org.apache.jmeter%3AJMeter#resolved=false|types=BUG
> >
> > Is it also possible to get it to check PRs as we do with codecov, is
> > this one for ifra?
> >
> > Thanks
> >
> > Graham
> >
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

Re: Mocking Framework

[Graham Russell]

Hi all

I've resurrected the Spock branch (https://github.com/apache/jmeter/pull/332)
does anyone have any thoughts on this thread?
Does this need a vote, some more work or discussion?
Is there a test which I should try to re-write in Spock to make sure it can
do what we need?
Unfortunately a lot of the code hasn't been written with testability in
mind, so mocking etc. is difficult without refactoring.
I really think this will help improve unit test coverage in JMeter by
making it easier (and more fun) to test.

If you had some time please read http://spockframework.org/spock/docs/1.0/
alongside the tests I've created, it has more detail about Mock/Spy/Stubs
in Spock.

Thanks

Graham

On Sun, 22 Jan 2017 at 12:43 Graham Russell  wrote:
>
> I've added a few more tests which make more use of mocks and I've
refactored AbstractJDBCTestElement a little: https://github.com/ham1/jmeter
/commits/spock
>
> One of the nice things about testing with groovy is that you can test
protected and private methods/classes without having to use reflection or
change access.
>
> Does anyone have any questions/concerns/thoughts on the code so far with
Spock?
>
> What needs to be done next to agree (or not) the move to Spock?
>
> Many thanks
>
> Graham
>
> On Sat, 14 Jan 2017, 21:47 Graham Russell,  wrote:
>>
>> Felix/all
>>
>> 1. I've reverted the move - it was intended to make compilation simpler,
but it isn't required.
>>
>> 2. Thanks for the pointer - I've edited AllTests to find Spock
Specifications.
>>
>> 3. I've added a few more examples, I've used Mocks in a few places.
>>
>> The main tests of interest are in org.apache.jmeter.engine.util:
>> PackageTest has gone from 234 to 107 lines in PackageSpec by using
"where:"
>> and HTTPUtilsSpec is also much easier to read/edit/add to.
>>
>> I've edited the base JMeterTestCases to work when run from IntelliJ (and
created a similar base JMeterSpec).
>> I've also fixed tests which failed when adding the Spock library e.g.
eclipse.classpath and LICENSE file.
>>
>> Are there any tests for which you think mocking would be especially
useful and easy i.e. without having to refactor a lot of code?
>>
>> I'm not sure about my changes to build.xml, especially the compilation
of tests.
>> Please have a look at: https://github.com/ham1/jmeter/commits/spock
>> and let me know thoughts/feedback and what needs to be done next.
>>
>> If we do move to Spock I'd like to help increase the test coverage and
improve readability of the current tests.
>>
>> Thanks
>>
>>
>> Graham
>>
>> P.S. Sorry for the extra whitespace fixes/changes, it's just a habit - I
could remove it and squash commits if that would help reviewing?

Static Analysis Issues

[Graham Russell]

All

Do we get notifications of sonar issues? I've just noticed that 8
"bugs" were introduced yesterday:
https://builds.apache.org/analysis/component_issues?id=org.apache.jmeter%3AJMeter#resolved=false|types=BUG

Is it also possible to get it to check PRs as we do with codecov, is
this one for ifra?

Thanks

Graham

Re: XPath Extractor : Drop Tidy Option

[Graham Russell]

+0

I agree that CSS should be preferred for HTML and, in general, I'm in
favour of removing seldom used/broken bits of functionality which don't
warrant the cost of keeping them around, but I don't know enough about it
nor how often XPath is currently used by people to say +1 for this yet.

Maybe worth deprecating it and emailing the user mailing list to see the
reaction?

Graham

On 16 November 2017 at 19:20, Philippe Mouawad 
wrote:
> Hello,
> Tidy option AFAIK used to allow using XPath Extractor for HTML.
> I don't think it's needed anymore since we have CSS/JQuery extractor which
> is:
> - Up to date
> - Powerful
> - Performing much better than XPath
>
> I propose to drop tidy options from XPath.
> I even propose to think about dropping jtidy library which would mean :
>
>- Either Dropping AnchorModifier or finding a better alternative to
>jtidy to it if it's useful
>
> IMO, we should drop it, as it doesn't work  with Distributed testing as it
> requires keeping the previous SampleResult response Data to be able to
work
> which Stripping mode clears.
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Validate Functionality

[Graham Russell]

This is a very quick mock-up but hopefully this helps explain what I
am thinking:
https://www.fluidui.com/editor/live/preview/cF9YVTlxS0JUU3ZCbHdVTjl1WDQ0QlpUNzhVdXhyNm5UNA==

Click the person with a green tick icon at the top which will 'load' a
new (modified) view results tree, then you can edit the params and
rerun the thread group in the new window.

Let me know if it makes sense.

Thanks

Graham

On 14 November 2017 at 21:20, Philippe Mouawad
 wrote:
> Hello Graham,
> Your proposals are interesting but it maybe be useful to create some
> mock-up (modifiable/sharable) if possible.
>
> I think we could by the way enhance the Run experience in GUI, an idea:
>
>- Be able to have something like Eclipse "Run Configuration" to
>configure user defined properties without having to restart , see
>https://bz.apache.org/bugzilla/show_bug.cgi?id=61755
>
> Regards
>
>
> On Fri, Nov 10, 2017 at 11:34 PM, Graham Russell  wrote:
>
>> I will list the user steps to see if that is clearer:
>>
>> 1. User right clicks on thread group (or has one selected, or any
>> sub-part, and clicks "validate user" button)
>> 2. A new window appears containing a View Results Tree with the name
>> " - Validate User" and the user can watch the thread run -
>> this window also displays the properties such as # of threads, iterations,
>> pause enabled/disabled.
>> 3. As items are clicked in validate view results tree the corresponding
>> item in the main window is selected.
>>
>> This can be further refined but this should make the validate feature far
>> more intuitive, efficient and useful.
>>
>> A potentially simpler, but slightly less efficient UX, #2:Existing View
>> Results Tree is selected, or add to the Test Plan and then select.
>>
>> Does that make sense? If not I can do a mock-up.
>>
>> Thanks
>>
>> Graham
>>
>> On Fri, 10 Nov 2017 at 19:38 UBIK LOAD PACK Support <
>> supp...@ubikloadpack.com> wrote:
>>
>>> Hi Graham,
>>> My answers below.
>>> Regards
>>>
>>> On Fri, Nov 10, 2017 at 6:27 PM, Graham Russell 
>>> wrote:
>>>
>>> > I thought I'd start a new thread as not to derail the Workbench one.
>>> >
>>> > You understood correctly, the validate function was a much needed
>>> addition
>>> > to JMeter, it currently needs more importance in the UI. I think it
>>> could
>>> > be vastly improved with a button on the top row and by auto adding, and
>>> > switching to, the results tree view once pressed. Or perhaps use a
>>> > separate/temp tree view that's not attached to the test plan but lives
>>> in a
>>> > separate window?
>>> >
>>> Would it be possible to show some  mock-up ?
>>> I don't clearly see what you have in mind , but I am very curious to
>>> understand.
>>>
>>> >
>>> > Thoughts?
>>> >
>>>
>>> +1 once I see mockup :-) or a patch if it's faster for you.
>>>
>>>
>>> > Graham
>>> >
>>> > On Fri, 10 Nov 2017 at 16:39 UBIK LOAD PACK Support <
>>> > supp...@ubikloadpack.com> wrote:
>>> >
>>> > Hi Graham,
>>> > Thanks for your answers and feedback.
>>> >
>>> > My answers below.
>>> > Regards
>>> >
>>> > On Fri, Nov 10, 2017 at 5:26 PM, Graham Russell 
>>> wrote:
>>> >
>>> > > +1
>>> > >
>>> > > ...
>>> > > I think to improve the UX would be to enable running of individual
>>> thread
>>> > > groups, single threaded with a tree results view (that you don't have
>>> to
>>> > > manually add).
>>> > >
>>> >
>>> > Except for the manually added View Results Tree, the feature you're
>>> looking
>>> > for already exists:
>>> >
>>> > 1. Right click on Thread Group:
>>> > 1. Validate : Runs by default 1 thread (configurable), 1 iteration
>>> > (configurable), No pauses (configurable)
>>> > 2. Start No Pause
>>> > 3. Start
>>> >
>>> > Did I misunderstand ?
>>> >
>>> >
>>> > This would be far more intuitive and better align to a usual load test
>>> > > workflow but far more work and maybe something I should raise a
>>> bugzilla
>>> > > on?
>>> > >
>>> >
>>> > Yes , create the remaining part as per my previous comment.
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> Regards
>>> Ubik Load Pack <http://ubikloadpack.com> Team
>>> Follow us on Twitter <http://twitter.com/ubikloadpack>
>>>
>>>
>>> Cordialement
>>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
>>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>
> UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>
>
> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Re: Validate Functionality

[Graham Russell]

I will list the user steps to see if that is clearer:

1. User right clicks on thread group (or has one selected, or any sub-part,
and clicks "validate user" button)
2. A new window appears containing a View Results Tree with the name
" - Validate User" and the user can watch the thread run -
this window also displays the properties such as # of threads, iterations,
pause enabled/disabled.
3. As items are clicked in validate view results tree the corresponding
item in the main window is selected.

This can be further refined but this should make the validate feature far
more intuitive, efficient and useful.

A potentially simpler, but slightly less efficient UX, #2:Existing View
Results Tree is selected, or add to the Test Plan and then select.

Does that make sense? If not I can do a mock-up.

Thanks

Graham

On Fri, 10 Nov 2017 at 19:38 UBIK LOAD PACK Support <
supp...@ubikloadpack.com> wrote:

> Hi Graham,
> My answers below.
> Regards
>
> On Fri, Nov 10, 2017 at 6:27 PM, Graham Russell  wrote:
>
> > I thought I'd start a new thread as not to derail the Workbench one.
> >
> > You understood correctly, the validate function was a much needed
> addition
> > to JMeter, it currently needs more importance in the UI. I think it could
> > be vastly improved with a button on the top row and by auto adding, and
> > switching to, the results tree view once pressed. Or perhaps use a
> > separate/temp tree view that's not attached to the test plan but lives
> in a
> > separate window?
> >
> Would it be possible to show some  mock-up ?
> I don't clearly see what you have in mind , but I am very curious to
> understand.
>
> >
> > Thoughts?
> >
>
> +1 once I see mockup :-) or a patch if it's faster for you.
>
>
> > Graham
> >
> > On Fri, 10 Nov 2017 at 16:39 UBIK LOAD PACK Support <
> > supp...@ubikloadpack.com> wrote:
> >
> > Hi Graham,
> > Thanks for your answers and feedback.
> >
> > My answers below.
> > Regards
> >
> > On Fri, Nov 10, 2017 at 5:26 PM, Graham Russell 
> wrote:
> >
> > > +1
> > >
> > > ...
> > > I think to improve the UX would be to enable running of individual
> thread
> > > groups, single threaded with a tree results view (that you don't have
> to
> > > manually add).
> > >
> >
> > Except for the manually added View Results Tree, the feature you're
> looking
> > for already exists:
> >
> > 1. Right click on Thread Group:
> > 1. Validate : Runs by default 1 thread (configurable), 1 iteration
> > (configurable), No pauses (configurable)
> > 2. Start No Pause
> > 3. Start
> >
> > Did I misunderstand ?
> >
> >
> > This would be far more intuitive and better align to a usual load test
> > > workflow but far more work and maybe something I should raise a
> bugzilla
> > > on?
> > >
> >
> > Yes , create the remaining part as per my previous comment.
> >
>
>
>
> --
>
> Regards
> Ubik Load Pack <http://ubikloadpack.com> Team
> Follow us on Twitter <http://twitter.com/ubikloadpack>
>
>
> Cordialement
> L'équipe Ubik Load Pack <http://ubikloadpack.com>
> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>

Validate Functionality

[Graham Russell]

I thought I'd start a new thread as not to derail the Workbench one.

You understood correctly, the validate function was a much needed addition
to JMeter, it currently needs more importance in the UI. I think it could
be vastly improved with a button on the top row and by auto adding, and
switching to, the results tree view once pressed. Or perhaps use a
separate/temp tree view that's not attached to the test plan but lives in a
separate window?

Thoughts?

Graham

On Fri, 10 Nov 2017 at 16:39 UBIK LOAD PACK Support <
supp...@ubikloadpack.com> wrote:

Hi Graham,
Thanks for your answers and feedback.

My answers below.
Regards

On Fri, Nov 10, 2017 at 5:26 PM, Graham Russell  wrote:

> +1
>
> ...
> I think to improve the UX would be to enable running of individual thread
> groups, single threaded with a tree results view (that you don't have to
> manually add).
>

Except for the manually added View Results Tree, the feature you're looking
for already exists:

1. Right click on Thread Group:
1. Validate : Runs by default 1 thread (configurable), 1 iteration
(configurable), No pauses (configurable)
2. Start No Pause
3. Start

Did I misunderstand ?


This would be far more intuitive and better align to a usual load test
> workflow but far more work and maybe something I should raise a bugzilla
> on?
>

Yes , create the remaining part as per my previous comment.

Re: Workbench : Let's drop it ?

[Graham Russell]

+1

I think dropping it will simplify the code and the UX in the most efficient
way, especially as time is always short for contributors.

It seems generally confusing and not especially useful:
https://stackoverflow.com/questions/44746278/why-workbench-is-shown-as-default-in-jmeter
http://blog.sourcepole.ch/2011/01/04/the-jmeter-workbench-a-trapdoor-for-the-newbie/

>From the docs: "The WorkBench simply provides a place to temporarily store
test elements while not in use, for copy/paste purposes, or any other
purpose you desire."

This can be replicated (as Andrey said) in the test plan by a separate
tread group and just disabling or deleting it before running a test, this
is less likely to confuse and for people to lose work.

I think to improve the UX would be to enable running of individual thread
groups, single threaded with a tree results view (that you don't have to
manually add).
This would be far more intuitive and better align to a usual load test
workflow but far more work and maybe something I should raise a bugzilla on?

Thanks

Graham

On Fri, 10 Nov 2017 at 15:07 Philippe Mouawad 
wrote:

> If we look at consensus, we have:
>
>- 3 (+1) to remove it (Maxime, Antonio and me) with favor to move the
>elements inside Test plan as disabled (so backward compat). If we have
> a PR
>or patch that does that, I'll merge it after testing as much as
> possible.
>- 1 (-1) or (0) for sebb, do you agree sebb ? what would be your exact
>position ?
>
>
> @Felix, @Milamber, @Vladimir,@Graham, @Mikhail , any thoughts on this ?
>
>
>
> Thanks
>
> On Fri, Nov 10, 2017 at 4:01 PM, Andrey Pokhilko  wrote:
>
> > I don't see any point for Workbench to exist. Simply disabling elements
> > in-place makes them temporary stored anywhere in test plan.
> >
> > Do we have a decision to remote it or not? I don't want to spend
> > resources if we don't have consensus.
> >
> > Andrey Pokhilko
> >
> > 09.11.2017 13:41, sebb пишет:
> > > Why not consider how to make the Workbench more intuitive and useful?
> > >
> > > On 8 November 2017 at 16:47, Philippe Mouawad
> > >  wrote:
> > >> As you say, it’s oddity.
> > >> A tool should be intuitive, this part is not, we cannot always say,
> > rtfm.
> > >> You know that lot of people don’t read docs.
> > >>
> > >> Let’s try and see if it is that complex.
> > >>
> > >> We shouldn’t say , we cannot touch, JMeter is not legacy, so we touch
> ,
> > >> break then fix .
> > >>
> > >> Regards
> > >>
> > >> On Wednesday, November 8, 2017, sebb  wrote:
> > >>
> > >>> On 8 November 2017 at 16:18, Philippe Mouawad
> > >>> > wrote:
> >  Hello,
> >  I’d say Test Plan.
> >  I suggest testcompiler ignores them
> > >>> That would involve a lot of testing to ensure nothing broke.
> > >>>
> > >>> Are you sure it's worth it?
> > >>>
> > >>> There have been other instances where what seems to be a minor change
> > >>> turns out to be far more intrusive than first expected.
> > >>> Dropping Workbench seems like such a case to me; it's been part of
> > >>> JMeter for so long that there are bound to be lots of places that
> > >>> assume it is present.
> > >>>
> > >>> I agree that the Workbench is a bit of an oddity, but I think
> removing
> > >>> it is going to prove much more of a headache than improving the
> > >>> documentation to explain it better.
> > >>> And potentially find more uses for it.
> > >>>
> >  Regards
> > 
> >  On Wednesday, November 8, 2017, Artem Fedorov <
> > >>> artem.fedo...@blazemeter.com >
> >  wrote:
> > 
> > > Hello,
> > >
> > > If we dropped WorkBench, in which element we can add Non-Test
> > Elements
> > > (HTTP Mirror Server, HTTP(S) Test Script Recorder, Property
> Display)?
> > > Can we add these Non-Test Elements to Test Plan (root) or Test
> > Fragment?
> > >
> > > Thanks
> > >
> > >  > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > Без
> > > вирусов. www.avast.ru
> > >  > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >
> > > On Wed, Nov 8, 2017 at 4:41 PM, Philippe Mouawad <
> > > philippe.moua...@gmail.com  
> > >> wrote:
> > >> Great !
> > >>
> > >> On Wed, Nov 8, 2017 at 2:38 PM, Andrey Pokhilko  > >>> 
> > > > wrote:
> > >>> FYI BlazeMeter will attempt to implement this change and
> contribute
> > >>> it.
> > >>> Andrey Pokhilko
> > >>>
> > >>> 04.11.2017 17:06, Andrey Pokhilko пишет:
> >  I'll need to think about it.
> > 
> >  Andrey Pokhilko
> > 
> >  04.11.2017 17:01, Philippe Mouawad пишет:
> > > On Sat, Nov 4, 2017 at 2:52 PM, Andrey Pokhilko  > >>> 
> > > > wrote:
> > >> +1 from me, I think it is possible to automatically move
> > >>> elements
> > >> from
> 

Re: Workbench : Let's drop it ?

[Graham Russell]

I agree.

It's confusing/distracting for new users and I've never seen anyone use it
(on purpose).

It would be best if we had usage data but I'm sure there will be an
outpouring of complaints if this is a well used feature.

I'm always in favour of removing seldom used features/code it often helps
improve the quality of what remains and makes it easier for people to get
started.

Thanks

Graham


On Sat, 4 Nov 2017, 12:18 Maxime Chassagneux, 
wrote:

> Hi,
>
> I never use it, except for recording script, so +1 for me.
>
> Regards
>
> 2017-11-04 13:07 GMT+01:00 Philippe Mouawad :
>
> > Hello,
> > Workbench element is confusing for beginners who don't understand
> > clearly its use.
> >
> > Thinking more about it, I don't see today why we should still keep it.
> >
> > The only advantage of this element is Non Test Elements which would
> > be made available from Test Plan directly.
> > When running a test those element would not impact test plan.
> >
> > The only issue is backward compatibility, should we try to move elements
> in
> >
> > workbench under test plan or just mention a backward incompatibility.
> >
> > Users would manually move there elements to Test Plan.
> >
> > Regards
> >
>

Re: Drop HTMLAssertion

[Graham Russell]

+1

Sounds good to me too; I only really use the "Response Assertion".
I think it's a good thing to remove rarely used features to save
effort reading/testing/maintaining/fixing/supporting these.

Thanks

Graham

On 25 February 2017 at 22:17, Philippe Mouawad
 wrote:
> Hello,
> I propose to drop HTML Assertion element as it does not support HTML5 and
> it seems not possible to support it easily :
> - https://bz.apache.org/bugzilla/show_bug.cgi?id=60774
>
> Besides, I am not sure it is really a  useful element.
>
> Regards
> Philippe

Re: Zoom-In/Out

[Graham Russell]

Screen resolution is: 1366 x 768.
I'm not sure what my DPI is - the "User interface Scaling" is set to
Normal (other options are Auto and Double (Hi-DPI)) and font scaling
is set to 1.0.
Yes, using the Oracle JRE.

I've tried the crossplatform LaF and this behaves much better. I will
attached the screenshot to the bz.

Should the icons also scale?

On 25 February 2017 at 09:24, Felix Schumacher
 wrote:
>
>
> Am 24. Februar 2017 23:12:07 MEZ schrieb Graham Russell :
>>Felix, I'm using:
>>java version "1.8.0_121"
>>Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
>>Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>>
>>with Linux Mint 18
>>and the Cinnamon v3.0.7 desktop.
>
> What is the size of your screen and which DPI has your screen? I presume the 
> jre is the Oracle one.
>
> Can you try to use a bigger zoom factor for the feature?
>
>>
>>It's not an especially common set-up, so feel free to ignore it.
>>I just thought it worth noting that it doesn't behave the same, which
>>might
>>point to a deeper issue?
>
> I don't want to ignore it. My setup showed the same behavior, but before the 
> latest changes.
>
> And Philippe had problems with windows 10.
>
> Without knowing the root cause, I think we should disable that code by 
> default and enable only by use of an parameter flag.
>
> Regards,
>  Felix
>
>>
>>Thanks
>>
>>Graham
>>
>>On Sun, 12 Feb 2017 at 20:49 Felix Schumacher >internetallee.de> wrote:
>>
>>>
>>>
>>> Am 11. Februar 2017 22:49:56 MEZ schrieb Graham Russell
>>>> >:
>>> >I've also added a screenshot after zooming in (many times to make
>>the
>>> >changes obvious) on Linux mint.
>>> >It doesn't seem to work quite as well as the others.
>>>
>>> What version of java did you use? Which plaf and which desktop
>>environment?
>>>
>>> It seemed to work on Ubuntu with gnome and the current Oracle jdk.
>>>
>>> Regards,
>>>  Felix
>>>
>>> >
>>> >On 11 February 2017 at 21:44, Philippe Mouawad
>>> > wrote:
>>> >> Hi Felix,
>>> >> I've attached screenshot to bugzilla for Windows 7 Pro and MacOSX
>>> >> ElCapitan, they look rather ok.
>>> >>
>>> >> But meanwhile I tested on Windows 10 Surface pro and on this
>>device
>>> >the
>>> >> Left Tree sizing does not change, the font increase but text
>>overlaps
>>> >> between nodes.
>>> >>
>>> >> I don't understand why display is so different on Windows.
>>> >>
>>> >> Regards
>>> >>
>>> >>
>>> >>
>>> >> On Sat, Jan 28, 2017 at 4:37 PM, Philippe Mouawad <
>>> >> philippe.moua...@gmail.com> wrote:
>>> >>
>>> >>> Not very nice indeed.
>>> >>> What scale did you use ?
>>> >>>
>>> >>> I'll attach screenshots for windows to show difference.
>>> >>>
>>> >>> Regards
>>> >>>
>>> >>>
>>> >>> On Saturday, January 28, 2017, Felix Schumacher
>>>> >>> internetallee.de> wrote:
>>> >>>
>>> >>>> Am 28.01.2017 um 16:29 schrieb Felix Schumacher:
>>> >>>>
>>> >>>>> Am 28.01.2017 um 15:53 schrieb Philippe Mouawad:
>>> >>>>>
>>> >>>>>> Hi Felix,
>>> >>>>>> Could you show some screenshots ? On which OS did you test and
>>> >what LAF
>>> >>>>>> did
>>> >>>>>> you use ?
>>> >>>>>>
>>> >>>>> I tried in on ubuntu 16.04 with the metal theme (default). I
>>have
>>> >>>>> attached a screenshot. Let's hope, that it doesn't get
>>stripped.
>>> >>>>>
>>> >>>> Got stripped, so I attached the screenshot to bug 59995.
>>> >>>>
>>> >>>> Felix
>>> >>>>
>>> >>>>
>>> >>>>> I used it on a Windows 8 where JMeter fonts were really too
>>tiny
>>> >and it
>>> >>>>>> improved usability for me.
>>> >>>>>> I also tested it on Mac OSX , it's not as good as real HiDPI
>>but
>>> >at
>>> >>>>>> least
>>> >>>>>> it look a bit better.
>>> >>>>>>
>>> >>>>> Have you tried with a JSyntaxArea?
>>> >>>>>
>>> >>>>> Regards,
>>> >>>>>  Felix
>>> >>>>>
>>> >>>>>> Ok for the mouse wheel.
>>> >>>>>>
>>> >>>>>> On Sat, Jan 28, 2017 at 3:35 PM, Felix Schumacher <
>>> >>>>>> felix.schumac...@internetallee.de> wrote:
>>> >>>>>>
>>> >>>>>> Hi all,
>>> >>>>>>>
>>> >>>>>>> I tried the new zoom functionality and it looks a bit flaky
>>to
>>> >me. It
>>> >>>>>>> doesn't change all font sizes and seems to work especially
>>> >"good" on
>>> >>>>>>> labels
>>> >>>>>>> and key-combo hints in the menu.
>>> >>>>>>>
>>> >>>>>>> I am not sure, how useful this feature is in the current
>>state.
>>> >>>>>>>
>>> >>>>>>> On the other hand, if we include the feature, I think it
>>would
>>> >be nice
>>> >>>>>>> to
>>> >>>>>>> register a mousewheel listener and linking ctrl+mousewheel
>>> >up/down to
>>> >>>>>>> zoom-in/-out.
>>> >>>>>>>
>>> >>>>>>> Regards,
>>> >>>>>>>
>>> >>>>>>>   Felix
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>> --
>>> >>> Cordialement.
>>> >>> Philippe Mouawad.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> Cordialement.
>>> >> Philippe Mouawad.
>>>

NPE during GUI launch on latest trunk

[Graham Russell]

Hi all

I just tried to run `ant run_gui` on the latest (github) trunk but
this results in an NPE - specifically when trying to create the
JMeterTreeModel.

Any ideas?

Thanks

Graham

The JMeter log is:

2017-02-25 13:26:50,223 INFO o.a.j.u.JMeterUtils: Setting Locale to en_GB
2017-02-25 13:26:50,246 INFO o.a.j.JMeter: Loading user properties
from: /home/coding/jmeter/bin/user.properties
2017-02-25 13:26:50,247 INFO o.a.j.JMeter: Loading system properties
from: /home/coding/jmeter/bin/system.properties
2017-02-25 13:26:50,317 INFO o.a.j.JMeter: Copyright (c) 1998-2017 The
Apache Software Foundation
2017-02-25 13:26:50,318 INFO o.a.j.JMeter: Version 3.2-SNAPSHOT.20170225
2017-02-25 13:26:50,318 INFO o.a.j.JMeter: java.version=1.8.0_121
2017-02-25 13:26:50,318 INFO o.a.j.JMeter: java.vm.name=Java
HotSpot(TM) 64-Bit Server VM
2017-02-25 13:26:50,318 INFO o.a.j.JMeter: os.name=Linux
2017-02-25 13:26:50,318 INFO o.a.j.JMeter: os.arch=amd64
2017-02-25 13:26:50,318 INFO o.a.j.JMeter: os.version=4.4.0-59-generic
2017-02-25 13:26:50,318 INFO o.a.j.JMeter: file.encoding=UTF-8
2017-02-25 13:26:50,318 INFO o.a.j.JMeter: Max memory =1342177280
2017-02-25 13:26:50,318 INFO o.a.j.JMeter: Available Processors =4
2017-02-25 13:26:50,323 INFO o.a.j.JMeter: Default Locale=English
(United Kingdom)
2017-02-25 13:26:50,323 INFO o.a.j.JMeter: JMeter  Locale=English
(United Kingdom)
2017-02-25 13:26:50,323 INFO o.a.j.JMeter: JMeterHome=/home/coding/jmeter
2017-02-25 13:26:50,323 INFO o.a.j.JMeter: user.dir  =/home/coding/jmeter
2017-02-25 13:26:50,323 INFO o.a.j.JMeter: PWD   =/home/coding/jmeter
2017-02-25 13:26:50,324 INFO o.a.j.JMeter: IP: 127.0.1.1 Name:
EliteBook FullName: EliteBook
2017-02-25 13:26:50,607 INFO o.a.j.g.a.LookAndFeelCommand: Using look
and feel: com.sun.java.swing.plaf.gtk.GTKLookAndFeel [GTK+, System]
2017-02-25 13:26:50,805 INFO o.a.j.JMeter: Loaded icon properties from
org/apache/jmeter/images/icon.properties
2017-02-25 13:26:50,842 ERROR o.a.j.JMeter: An error occurred:
java.lang.NullPointerException: null
at org.apache.jmeter.gui.NamePanel.getName(NamePanel.java:75)
~[ApacheJMeter_core.jar:3.2-SNAPSHOT.20170225]
at com.sun.java.swing.plaf.gtk.GTKStyle.getInsets(GTKStyle.java:316)
~[?:1.8.0_121]
at 
javax.swing.plaf.synth.SynthStyle.installDefaults(SynthStyle.java:913)
~[?:1.8.0_121]
at 
javax.swing.plaf.synth.SynthLookAndFeel.updateStyle(SynthLookAndFeel.java:265)
~[?:1.8.0_121]
at 
javax.swing.plaf.synth.SynthPanelUI.updateStyle(SynthPanelUI.java:117)
~[?:1.8.0_121]
at 
javax.swing.plaf.synth.SynthPanelUI.installDefaults(SynthPanelUI.java:100)
~[?:1.8.0_121]
at javax.swing.plaf.basic.BasicPanelUI.installUI(BasicPanelUI.java:56)
~[?:1.8.0_121]
at javax.swing.plaf.synth.SynthPanelUI.installUI(SynthPanelUI.java:62)
~[?:1.8.0_121]
at javax.swing.JComponent.setUI(JComponent.java:666) ~[?:1.8.0_121]
at javax.swing.JPanel.setUI(JPanel.java:153) ~[?:1.8.0_121]
at javax.swing.JPanel.updateUI(JPanel.java:126) ~[?:1.8.0_121]
at javax.swing.JPanel.(JPanel.java:86) ~[?:1.8.0_121]
at javax.swing.JPanel.(JPanel.java:109) ~[?:1.8.0_121]
at javax.swing.JPanel.(JPanel.java:117) ~[?:1.8.0_121]
at org.apache.jmeter.gui.NamePanel.(NamePanel.java:44)
~[ApacheJMeter_core.jar:3.2-SNAPSHOT.20170225]
at 
org.apache.jmeter.gui.AbstractJMeterGuiComponent.(AbstractJMeterGuiComponent.java:78)
~[ApacheJMeter_core.jar:3.2-SNAPSHOT.20170225]
at org.apache.jmeter.control.gui.TestPlanGui.(TestPlanGui.java:68)
~[ApacheJMeter_core.jar:3.2-SNAPSHOT.20170225]
at 
org.apache.jmeter.gui.tree.JMeterTreeModel.(JMeterTreeModel.java:49)
~[ApacheJMeter_core.jar:3.2-SNAPSHOT.20170225]
at org.apache.jmeter.JMeter.startGui(JMeter.java:366)
~[ApacheJMeter_core.jar:3.2-SNAPSHOT.20170225]
at org.apache.jmeter.JMeter.start(JMeter.java:519)
[ApacheJMeter_core.jar:3.2-SNAPSHOT.20170225]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:1.8.0_121]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:1.8.0_121]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_121]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_121]
at org.apache.jmeter.NewDriver.main(NewDriver.java:256)
[ApacheJMeter.jar:3.2-SNAPSHOT.20170225]

Re: Zoom-In/Out

[Graham Russell]

Felix, I'm using:
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

with Linux Mint 18
and the Cinnamon v3.0.7 desktop.

It's not an especially common set-up, so feel free to ignore it.
I just thought it worth noting that it doesn't behave the same, which might
point to a deeper issue?

Thanks

Graham

On Sun, 12 Feb 2017 at 20:49 Felix Schumacher  wrote:

>
>
> Am 11. Februar 2017 22:49:56 MEZ schrieb Graham Russell  >:
> >I've also added a screenshot after zooming in (many times to make the
> >changes obvious) on Linux mint.
> >It doesn't seem to work quite as well as the others.
>
> What version of java did you use? Which plaf and which desktop environment?
>
> It seemed to work on Ubuntu with gnome and the current Oracle jdk.
>
> Regards,
>  Felix
>
> >
> >On 11 February 2017 at 21:44, Philippe Mouawad
> > wrote:
> >> Hi Felix,
> >> I've attached screenshot to bugzilla for Windows 7 Pro and MacOSX
> >> ElCapitan, they look rather ok.
> >>
> >> But meanwhile I tested on Windows 10 Surface pro and on this device
> >the
> >> Left Tree sizing does not change, the font increase but text overlaps
> >> between nodes.
> >>
> >> I don't understand why display is so different on Windows.
> >>
> >> Regards
> >>
> >>
> >>
> >> On Sat, Jan 28, 2017 at 4:37 PM, Philippe Mouawad <
> >> philippe.moua...@gmail.com> wrote:
> >>
> >>> Not very nice indeed.
> >>> What scale did you use ?
> >>>
> >>> I'll attach screenshots for windows to show difference.
> >>>
> >>> Regards
> >>>
> >>>
> >>> On Saturday, January 28, 2017, Felix Schumacher  >>> internetallee.de> wrote:
> >>>
> >>>> Am 28.01.2017 um 16:29 schrieb Felix Schumacher:
> >>>>
> >>>>> Am 28.01.2017 um 15:53 schrieb Philippe Mouawad:
> >>>>>
> >>>>>> Hi Felix,
> >>>>>> Could you show some screenshots ? On which OS did you test and
> >what LAF
> >>>>>> did
> >>>>>> you use ?
> >>>>>>
> >>>>> I tried in on ubuntu 16.04 with the metal theme (default). I have
> >>>>> attached a screenshot. Let's hope, that it doesn't get stripped.
> >>>>>
> >>>> Got stripped, so I attached the screenshot to bug 59995.
> >>>>
> >>>> Felix
> >>>>
> >>>>
> >>>>> I used it on a Windows 8 where JMeter fonts were really too tiny
> >and it
> >>>>>> improved usability for me.
> >>>>>> I also tested it on Mac OSX , it's not as good as real HiDPI but
> >at
> >>>>>> least
> >>>>>> it look a bit better.
> >>>>>>
> >>>>> Have you tried with a JSyntaxArea?
> >>>>>
> >>>>> Regards,
> >>>>>  Felix
> >>>>>
> >>>>>> Ok for the mouse wheel.
> >>>>>>
> >>>>>> On Sat, Jan 28, 2017 at 3:35 PM, Felix Schumacher <
> >>>>>> felix.schumac...@internetallee.de> wrote:
> >>>>>>
> >>>>>> Hi all,
> >>>>>>>
> >>>>>>> I tried the new zoom functionality and it looks a bit flaky to
> >me. It
> >>>>>>> doesn't change all font sizes and seems to work especially
> >"good" on
> >>>>>>> labels
> >>>>>>> and key-combo hints in the menu.
> >>>>>>>
> >>>>>>> I am not sure, how useful this feature is in the current state.
> >>>>>>>
> >>>>>>> On the other hand, if we include the feature, I think it would
> >be nice
> >>>>>>> to
> >>>>>>> register a mousewheel listener and linking ctrl+mousewheel
> >up/down to
> >>>>>>> zoom-in/-out.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>>   Felix
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>> --
> >>> Cordialement.
> >>> Philippe Mouawad.
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
>

Re: Proposition for contribution

[Graham Russell]

As Philippe said I've started a test for the JDBCSampler and
AbstractJDBCTestElement using Spock:
https://github.com/ham1/jmeter/blob/spock/test/src/org/apache/jmeter/protocol/jdbc/sampler/JDBCSamplerSpec.groovy
but until we decide which Mocking/testing framework to use it would be
great to get some test coverage on the current trunk.

Thanks

Graham

On 16 February 2017 at 14:46, Philippe Mouawad
 wrote:
> Great !
> I think you can go ahead
> There was a discussion about a mocking framework to use.
> Graham started something around spock,
> Felix proposed jmockit, I don't know if he started something.
> And I mentioned mockito2 but without producing anything ;)
>
> But maybe your work does not need a mocking framework.
>
> Regards
>
> On Thursday, February 16, 2017, Woonsan Ko  > wrote:
>
>> Hi folks,
>>
>> Is there anyone working in unit tests for JDBC protocol?
>> If not, I'd like to take a look into it next week.
>>
>> Cheers,
>>
>> Woonsan
>>
>>
>> On Fri, Jan 6, 2017 at 2:35 PM, Philippe Mouawad
>>  wrote:
>> > Hello,
>> > Thanks for your proposal.
>> > Yes it is still up to date.
>> >
>> > You can have a look at our Sonar report to know what needs testing:
>> >
>> >- https://builds.apache.org/analysis/
>> >
>> > Our priorities regarding tests:
>> >
>> >- JDBC protocol (more the NON Gui classes)
>> >- HTTP (more non gui classes)
>> >- org.apache.jmeter.assertions:
>> >   - .HTMLAssertion
>> >   - JSR223Assertion
>> >- org.apache.jmeter.core.report
>> >- org.apache.jmeter.visualizers.backend.graphite
>> >- core/org/apache/jmeter/control
>> >
>> > Note coverage is not only related to JUnit tests but also to tests builds
>> > with JMX plans and ran with Jacoco agent.
>> >
>> > Regards
>> >
>> >
>> >
>> > On Fri, Jan 6, 2017 at 5:32 PM, Sébastien Col 
>> > wrote:
>> >
>> >> Hi,
>> >> I would like to contribute to the project and I thought I could start
>> >> working on the task #41118bb8 related to test suite enhancement and
>> >> migration to JUnit 4.
>> >> I found it from the helpwanted.apache.org site.
>> >> Is it still up-to-date?
>> >> Regards,
>> >> Sebastien
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: INFRA-13535

[Graham Russell]

Great, thanks for getting that sorted.

How do we see the sonar reports? A quick google and wiki search didn't help.

Thanks

Graham

On 18 February 2017 at 09:51, Philippe Mouawad
 wrote:
> New version has been setup.
> False positive on streams have disappeared but it seems analysis has deepen
> and new errors were found.
>
>
>
> On Friday, February 17, 2017, Philippe Mouawad 
> wrote:
>
>> Hello
>> I have created a request to upgrade SONARJAVA as we get false positive on
>> Streams.
>>
>> Regards
>> Philippe
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Code Style Guidelines

[Graham Russell]

On 11 February 2017 at 23:14, Philippe Mouawad
 wrote:
> On Sat, Feb 11, 2017 at 11:27 PM, Graham Russell  wrote:
>
>> Hi all
>>
>> Do we have any (written) guidance on code style?
>>
>> I know we have checkstyle, but this has very few rules.
>>
>> The reason for asking is that I think having a consistent style is very
>> important for readability (which helps writing new feature or fixing
>> existing code etc.).
>>
>> The main things I think contribute to this are (and which are fairly easy
>> to detect/fix):
>> * (soft) line lengths (80, 100?)
>> * spacing between elements on a line e.g. if (..., while (...,
>> methodCall(arg1, arg2), "con" + "cat"
>>
> If this is related to String concat, we should only do that in places where
> performance is not a critical point as IMU StringBuilder concat is still
> better than '+'

This was mainly about white space. However, I believe StringBuilder is
only better (performance) than "+" when inside a loop, elsewhere you
should use "+" for readability:
http://stackoverflow.com/questions/1532461/stringbuilder-vs-string-concatenation-in-tostring-in-java

>
>> * import order, spacing and not using .*
>> * line length of methods (soft limit of 50?)
>> * line length of classes (soft limit of 500?)
>>
>
> I am ok with these proposals and providing a checkstyle and Eclipse
> formatter might be very useful.
> But if possible, I'd prefer that we do not modify too much code only for
> code style as it might make it difficult to look into particular
> regressions.
> So maybe do that on new code or when changing a file for something else..

Yes, I agree that this should only be on new code or 'while you are in
the area' i.e. the boy scout rule (leave the code better than you
found it).

I use IntelliJ - I will export my current JMeter code formatting rules
and also try to create one for Eclipse which broadly aligns.

If we put these into checkstyle would this fail the build, or can they
just be warnings?

I've created a wiki page to capture the key points:
https://wiki.apache.org/jmeter/CodeStyleGuidelines

>
>>
>> From Phillippe's Java 8 email:
>>
> * Use of Optional
>>
>
> From the document, I understand Optional has a memory/performance impact so
> we need to take this into account where we decide to apply it.
> But I'm ok with it.

Certainly, this is important with performance critical parts of the code.

>
>
>> * Default/static methods on Interfaces
>>
> +1
>
>> * Lambas where possible (max ~5 lines?)
>>
> +1 provided reduced code is more readable than existing one. If it's
> reduced but we have to scratch our head to understand it I'm not sure it's
> a gain :-)

Absolutely, this is all to do with readability, if it doesn't fit in
~5 lines then it should probably be moved to a method and named
appropriately.

>
> Regarding Streams, we need to be sure of performance impact. And It appears
> Sonar has some issues analyzing such code

Yes I noticed that too, is this due to the version of Sonar we are
using or to unidentified/unfixed bugs?

>
>
>> I have found this: https://wiki.apache.org/jmeter/JMeterEclipse
>> which suggests some formatting e.g. 80 char line length and new line before
>> opening brace but most of the code doesn't conform to that - it was also
>> updated 8 years ago.
>>
>> Any other ideas/thoughts?
>>
>> Thanks
>>
>> Graham
>
> --
> Cordialement.
> Philippe Mouawad.

Code Style Guidelines

[Graham Russell]

Hi all

Do we have any (written) guidance on code style?

I know we have checkstyle, but this has very few rules.

The reason for asking is that I think having a consistent style is very
important for readability (which helps writing new feature or fixing
existing code etc.).

The main things I think contribute to this are (and which are fairly easy
to detect/fix):
* (soft) line lengths (80, 100?)
* spacing between elements on a line e.g. if (..., while (...,
methodCall(arg1, arg2), "con" + "cat"
* import order, spacing and not using .*
* line length of methods (soft limit of 50?)
* line length of classes (soft limit of 500?)

>From Phillippe's Java 8 email:
* Use of Optional
* Default/static methods on Interfaces
* Lambas where possible (max ~5 lines?)

I have found this: https://wiki.apache.org/jmeter/JMeterEclipse
which suggests some formatting e.g. 80 char line length and new line before
opening brace but most of the code doesn't conform to that - it was also
updated 8 years ago.

Any other ideas/thoughts?

Thanks

Graham

Re: Zoom-In/Out

[Graham Russell]

I've also added a screenshot after zooming in (many times to make the
changes obvious) on Linux mint.
It doesn't seem to work quite as well as the others.

On 11 February 2017 at 21:44, Philippe Mouawad
 wrote:
> Hi Felix,
> I've attached screenshot to bugzilla for Windows 7 Pro and MacOSX
> ElCapitan, they look rather ok.
>
> But meanwhile I tested on Windows 10 Surface pro and on this device the
> Left Tree sizing does not change, the font increase but text overlaps
> between nodes.
>
> I don't understand why display is so different on Windows.
>
> Regards
>
>
>
> On Sat, Jan 28, 2017 at 4:37 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
>> Not very nice indeed.
>> What scale did you use ?
>>
>> I'll attach screenshots for windows to show difference.
>>
>> Regards
>>
>>
>> On Saturday, January 28, 2017, Felix Schumacher > internetallee.de> wrote:
>>
>>> Am 28.01.2017 um 16:29 schrieb Felix Schumacher:
>>>
 Am 28.01.2017 um 15:53 schrieb Philippe Mouawad:

> Hi Felix,
> Could you show some screenshots ? On which OS did you test and what LAF
> did
> you use ?
>
 I tried in on ubuntu 16.04 with the metal theme (default). I have
 attached a screenshot. Let's hope, that it doesn't get stripped.

>>> Got stripped, so I attached the screenshot to bug 59995.
>>>
>>> Felix
>>>
>>>
 I used it on a Windows 8 where JMeter fonts were really too tiny and it
> improved usability for me.
> I also tested it on Mac OSX , it's not as good as real HiDPI but at
> least
> it look a bit better.
>
 Have you tried with a JSyntaxArea?

 Regards,
  Felix

> Ok for the mouse wheel.
>
> On Sat, Jan 28, 2017 at 3:35 PM, Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
> Hi all,
>>
>> I tried the new zoom functionality and it looks a bit flaky to me. It
>> doesn't change all font sizes and seems to work especially "good" on
>> labels
>> and key-combo hints in the menu.
>>
>> I am not sure, how useful this feature is in the current state.
>>
>> On the other hand, if we include the feature, I think it would be nice
>> to
>> register a mousewheel listener and linking ctrl+mousewheel up/down to
>> zoom-in/-out.
>>
>> Regards,
>>
>>   Felix
>>
>>
>>
>

>>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Wiki Contributors Group

[Graham Russell]

Thank you.

On 11 February 2017 at 21:36, sebb  wrote:
> Should be OK now
>
> On 11 February 2017 at 20:15, Graham Russell  wrote:
>> Sorry, I still don't seem to be able to edit the wiki.
>> Have I missed a big edit button somewhere or was I added to the wrong group?
>> It says on the front page I need to be part of:
>> https://wiki.apache.org/jmeter/ContributorsGroup
>>
>> Thanks
>>
>> Graham
>>
>> On 11 February 2017 at 20:11, Graham Russell  wrote:
>>> Thank you.
>>>
>>> On 11 February 2017 at 20:09, Antonio Gomes Rodrigues  
>>> wrote:
>>>> Hi,
>>>>
>>>> Done
>>>>
>>>> Antonio
>>>>
>>>> 2017-02-11 20:59 GMT+01:00 Graham Russell :
>>>>
>>>>> Hi
>>>>>
>>>>> Could someone please add me (username: ham1) to the Contributors Group
>>>>> in the wiki? I'd initially like to remove some dead links from the
>>>>> home page.
>>>>>
>>>>> Many thanks
>>>>>
>>>>> Graham
>>>>>

Re: JAVA 8 interesting

[Graham Russell]

Philippe

Good find - thanks for sharing.

I think some of those topics might be worth further discussion
regarding how/if we use them in the future.

* Optional: I like the idea of using Optional for return types (where
null is/could be returned) - however it might not be worth the
change/effort?
  * As a quick example: JMeterUtils.loadProperties could return
Optional (and even log if not found) which would clean up
calling code. Perhaps the getPropertiesAsX methods in TestElement
could also return Optional.

* Default methods on Interfaces: I've been looking at this for the
TestElement Interface
https://github.com/ham1/jmeter/commits/default-methods-TE-interface
I don't know if this is better or worse than the current code - maybe
the interface is a bit too big already (but then again so is the
AbstractClass).

* Parallel streams: should be used with caution, they can be slower
due to the overhead of the parallelism

* These also might be interesting to watch/read:
https://www.youtube.com/watch?v=NcetKbGayZY
https://blog.jetbrains.com/idea/2016/07/java-8-top-tips/
https://blog.jetbrains.com/upsource/2016/08/03/what-to-look-for-in-java-8-code/

I was also about to send an email asking about code style - I will
also mention these there.

Thanks again for the link.

Graham

On 11 February 2017 at 13:25, Philippe Mouawad
 wrote:
> http://fr.slideshare.net/scolebourne/java-se-8-best-practices-53975908

Re: Wiki Contributors Group

[Graham Russell]

Sorry, I still don't seem to be able to edit the wiki.
Have I missed a big edit button somewhere or was I added to the wrong group?
It says on the front page I need to be part of:
https://wiki.apache.org/jmeter/ContributorsGroup

Thanks

Graham

On 11 February 2017 at 20:11, Graham Russell  wrote:
> Thank you.
>
> On 11 February 2017 at 20:09, Antonio Gomes Rodrigues  
> wrote:
>> Hi,
>>
>> Done
>>
>> Antonio
>>
>> 2017-02-11 20:59 GMT+01:00 Graham Russell :
>>
>>> Hi
>>>
>>> Could someone please add me (username: ham1) to the Contributors Group
>>> in the wiki? I'd initially like to remove some dead links from the
>>> home page.
>>>
>>> Many thanks
>>>
>>> Graham
>>>

Re: Wiki Contributors Group

[Graham Russell]

Thank you.

On 11 February 2017 at 20:09, Antonio Gomes Rodrigues  wrote:
> Hi,
>
> Done
>
> Antonio
>
> 2017-02-11 20:59 GMT+01:00 Graham Russell :
>
>> Hi
>>
>> Could someone please add me (username: ham1) to the Contributors Group
>> in the wiki? I'd initially like to remove some dead links from the
>> home page.
>>
>> Many thanks
>>
>> Graham
>>

Wiki Contributors Group

[Graham Russell]

Hi

Could someone please add me (username: ham1) to the Contributors Group
in the wiki? I'd initially like to remove some dead links from the
home page.

Many thanks

Graham

Re: Test Failures on latest trunk

[Graham Russell]

Doh! Yes that worked. Thanks.

However, I now see this message "XML document structures must start
and end within the same entity."
which looks like it's from an accidentally(?) committed println in
TestXPathExtractor (line 305).

Thanks

On 11 February 2017 at 17:00, Felix Schumacher
 wrote:
>
>
> Am 11. Februar 2017 17:59:03 MEZ schrieb Graham Russell :
>>Hi all
>>
>>When I run ant test I see ~50 test failures, all with a similar
>>message:
>>[java] 51) testArguments(org.apache.jmeter.testelement.PackageTest)
>> [java] java.lang.NoSuchFieldError: log
>
> ant clean ?
>
> Felix
>
>>
>>I've tried download_jars as well but this didn't seem to fix the
>>issues.
>>I've also tried: "ant -Djava.awt.headless=true
>>-Drmi_force_localhost=true -Dskip.bug52310=true -Dskip.test_https=true
>>test" but get the same issues.
>>
>>I am running on Linux with Java version "1.8.0_121" and both ant
>>v1.9.6 and v1.10.1.
>>
>>Is there something I've missed when running tests?
>>
>>Thanks



-- 
Graham

Test Failures on latest trunk

[Graham Russell]

Hi all

When I run ant test I see ~50 test failures, all with a similar message:
 [java] 51) testArguments(org.apache.jmeter.testelement.PackageTest)
 [java] java.lang.NoSuchFieldError: log

I've tried download_jars as well but this didn't seem to fix the issues.
I've also tried: "ant -Djava.awt.headless=true
-Drmi_force_localhost=true -Dskip.bug52310=true -Dskip.test_https=true
test" but get the same issues.

I am running on Linux with Java version "1.8.0_121" and both ant
v1.9.6 and v1.10.1.

Is there something I've missed when running tests?

Thanks

-- 
Graham

Re: svn commit: r1780852 - in /jmeter/trunk: src/protocol/http/org/apache/jmeter/protocol/http/control/DNSCacheManager.java test/src/org/apache/jmeter/protocol/http/control/TestDNSCacheManager.java

[Graham Russell]

The same failure is happening on Travis as well:
https://travis-ci.org/apache/jmeter/jobs/198595940

Graham
Graham


On 5 February 2017 at 16:40, Milamber  wrote:
>
>
> On 29/01/2017 20:35, pmoua...@apache.org wrote:
>>
>> Modified:
>> jmeter/trunk/test/src/org/apache/jmeter/protocol/http/control/TestDNSCacheManager.java
>>
>> URL:http://svn.apache.org/viewvc/jmeter/trunk/test/src/org/apache/jmeter/protocol/http/control/TestDNSCacheManager.java?rev=1780852&r1=1780851&r2=1780852&view=diff
>>
>> ==
>> ---
>> jmeter/trunk/test/src/org/apache/jmeter/protocol/http/control/TestDNSCacheManager.java
>> (original)
>> +++
>> jmeter/trunk/test/src/org/apache/jmeter/protocol/http/control/TestDNSCacheManager.java
>> Sun Jan 29 20:35:59 2017
>> @@ -20,18 +20,92 @@ package org.apache.jmeter.protocol.http.
>> import static org.junit.Assert.fail;
>>   []
>> -
>> +
>> +@Test
>> +public void testResolveExistingHostWithSystemDefaultDnsServer()
>> throws UnknownHostException {
>> +DNSCacheManager original = new DNSCacheManager();
>> +original.setCustomResolver(false);
>> +try {
>> +InetAddress[] result = original.resolve("www.example.org");
>> +Assert.assertNotNull(result);
>> +Assert.assertNull(original.resolver);
>> +// IPv4 and IPv6
>> +Assert.assertTrue(result.length == 2);
>
>
> When I execute test ant task, I have this error below.
> When I resolve the www.example.org, I've found only IPv4 address (my network
> is only on ipv4).
>
> Have you the same error (on ipv4 installation)?
>
>
>
>  [java] There was 1 failure:
>  [java] 1)
> testResolveExistingHostWithSystemDefaultDnsServer(org.apache.jmeter.protocol.http.control.TestDNSCacheManager)
>  [java] java.lang.AssertionError
>  [java] at org.junit.Assert.fail(Assert.java:86)
>  [java] at org.junit.Assert.assertTrue(Assert.java:41)
>  [java] at org.junit.Assert.assertTrue(Assert.java:52)
>  [java] at
> org.apache.jmeter.protocol.http.control.TestDNSCacheManager.testResolveExistingHostWithSystemDefaultDnsServer(TestDNSCacheManager.java:154)
>  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>  [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  [java] at java.lang.reflect.Method.invoke(Method.java:498)
>  [java] at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  [java] at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  [java] at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  [java] at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  [java] at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>  [java] at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>  [java] at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>  [java] at
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>  [java] at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>  [java] at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>  [java] at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>  [java] at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>  [java] at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>  [java] at org.junit.runners.Suite.runChild(Suite.java:128)
>  [java] at org.junit.runners.Suite.runChild(Suite.java:27)
>  [java] at
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>  [java] at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>  [java] at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>  [java] at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>  [java] at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>  [java] at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>  [java] at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>  [java] at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
>  [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:222)
>  [java]
>  [java] FAILURES!!!
>  [java] Tests run: 2700,  Failures: 1
>  [java]
>
>
>
>
>> +} catch (UnknownHostException e) {
>> +Assert.fail("Should not have failed");
>> +}
>> +}
>> +
>> +@Test
>> +public void testResolveNonExistingHostWit

Re: Participate to Google Summer of Code

[Graham Russell]

I think it's a good idea - especially h/2 support.

My only suggestion beyond those would be: Study and improve the UX -
especially for novice users/basic actions.

Thanks

Graham
Graham


On 3 February 2017 at 19:56, Philippe Mouawad
 wrote:
> Hello,
> What do you think of submitting a project to GsC where topic would be
> around :
> - Http/2 support on Apache JMeter and complete httpclient with required
> protocol parts (ALPN)
> - Introducing async IO
> - Working on Threading model ?
>
> Other ideas ?
> Regards
> Philippe
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Mocking Framework

[Graham Russell]

Felix/all

1. I've reverted the move - it was intended to make compilation simpler,
but it isn't required.

2. Thanks for the pointer - I've edited AllTests to find Spock
Specifications.

3. I've added a few more examples, I've used Mocks in a few places.

The main tests of interest are in org.apache.jmeter.engine.util:
PackageTest has gone from 234 to 107 lines in PackageSpec by using "where:"
and HTTPUtilsSpec is also much easier to read/edit/add to.

I've edited the base JMeterTestCases to work when run from IntelliJ (and
created a similar base JMeterSpec).
I've also fixed tests which failed when adding the Spock library e.g.
eclipse.classpath and LICENSE file.

Are there any tests for which you think mocking would be especially useful
and easy i.e. without having to refactor a lot of code?

I'm not sure about my changes to build.xml, especially the compilation of
tests.
Please have a look at: https://github.com/ham1/jmeter/commits/spock
and let me know thoughts/feedback and what needs to be done next.

If we do move to Spock I'd like to help increase the test coverage and
improve readability of the current tests.

Thanks

Graham

P.S. Sorry for the extra whitespace fixes/changes, it's just a habit - I
could remove it and squash commits if that would help reviewing?

On 12 January 2017 at 20:11, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:
> Am 12.01.2017 um 19:47 schrieb Graham Russell:
>>
>> Hi all
>>
>> I've created a branch on github where I've started using Spock -
>> https://github.com/ham1/jmeter/tree/spock - I can create a PR if that's
>> more useful.
>
> For now that is fine.
>
> Why did you move the test src from test/src to test/src/java? Is it needed
> by spock?
>
>>
>> Test compilation works with ant and I can run tests run via my IDE
>> (IntelliJ), however, I haven't yet been able to figure out how to run
>> these
>> as part of `ant test`.
>
> ant test looks for classes, that can be assigned to TestCase or have junit
> annotations. Do spock classes come with those?
>
>>
>> Does someone, with more experience of ant, have some time to look at the
>> code and help get it fully working?
>>
>> I've created two tests, one which replicates an existing test and one for
>> a
>> new class.
>>
>> I really like Spock's given/when/then test structure and built-in
>> Mock/Spy/Stubs.
>> It is also possible to mock static Java methods with Spock and PowerMock
>> (see: https://dzone.com/articles/mocking-static-methods-groovy).
>
> I think it would be nice to have a few more cases, where we can see
mocking
> and such and the nice tabular data parameters for tests.
>
> Thanks for your contribution so far.
>  Felix
>
>
>>
>> Thanks
>>
>> Graham
>>
>> On 19 December 2016 at 11:47, Felix Schumacher <
>> felix.schumac...@internetallee.de> wrote:
>>>
>>> Am 18.12.2016 um 15:46 schrieb Graham Russell:
>>>>
>>>> Felix
>>>>
>>>> I really like using spock.
>>>>
>>>> I'm not sure how to get it working with ant, but I'm sure it's doable.
I
>>>> should have some time in the new year to try adding some spock tests if
>>>> that's useful?
>>>
>>> That would be great.
>>>
>>>> Please see:
>>>> https://mechanitis.blogspot.com/2013/12/spock-data-driven-testing.html
>>
>> and
>>>>
>>>> the two other posts in that series (not my blog) for some of the
reasons
>>
>> I
>>>>
>>>> like it.
>>>
>>>
>>> Will have a look, thanks.
>>>
>>>   Felix
>>>
>>>> Thanks
>>>>
>>>> Graham
>>>>
>>>> On Sun, 18 Dec 2016, 20:30 Felix Schumacher, <
>>>> felix.schumac...@internetallee.de> wrote:
>>>>
>>>>> Am Dienstag, den 13.12.2016, 22:36 +0100 schrieb Philippe Mouawad:
>>>>>>
>>>>>> On Sunday, December 11, 2016, Felix Schumacher <
>>>>>> felix.schumac...@internetallee.de> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Philippe has brought up the potential usage of a mocking framework
>>>>>>> in
>>>>>>> another thread. That is something I too would like to see used in
>>>>>>> our
>>>>>>> tests. He has linked mockito 2 as a candidate. I think a strong
>>>

Re: Mocking Framework

[Graham Russell]

Hi all

I've created a branch on github where I've started using Spock -
https://github.com/ham1/jmeter/tree/spock - I can create a PR if that's
more useful.

Test compilation works with ant and I can run tests run via my IDE
(IntelliJ), however, I haven't yet been able to figure out how to run these
as part of `ant test`.

Does someone, with more experience of ant, have some time to look at the
code and help get it fully working?

I've created two tests, one which replicates an existing test and one for a
new class.

I really like Spock's given/when/then test structure and built-in
Mock/Spy/Stubs.
It is also possible to mock static Java methods with Spock and PowerMock
(see: https://dzone.com/articles/mocking-static-methods-groovy).

Thanks

Graham

On 19 December 2016 at 11:47, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:
> Am 18.12.2016 um 15:46 schrieb Graham Russell:
>>
>> Felix
>>
>> I really like using spock.
>>
>> I'm not sure how to get it working with ant, but I'm sure it's doable. I
>> should have some time in the new year to try adding some spock tests if
>> that's useful?
>
> That would be great.
>
>>
>> Please see:
>> https://mechanitis.blogspot.com/2013/12/spock-data-driven-testing.html
and
>> the two other posts in that series (not my blog) for some of the reasons
I
>> like it.
>
>
> Will have a look, thanks.
>
>  Felix
>
>>
>> Thanks
>>
>> Graham
>>
>> On Sun, 18 Dec 2016, 20:30 Felix Schumacher, <
>> felix.schumac...@internetallee.de> wrote:
>>
>>> Am Dienstag, den 13.12.2016, 22:36 +0100 schrieb Philippe Mouawad:
>>>>
>>>> On Sunday, December 11, 2016, Felix Schumacher <
>>>> felix.schumac...@internetallee.de> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Philippe has brought up the potential usage of a mocking framework
>>>>> in
>>>>> another thread. That is something I too would like to see used in
>>>>> our
>>>>> tests. He has linked mockito 2 as a candidate. I think a strong
>>>>> contender
>>>>> would be jmockit (http://jmockit.org/) or (additionally) something
>>>>> like
>>>>> spock (http://spockframework.org/).
>>>>>
>>>>> What do you think?
>>>>
>>>> I have a little experience with mockito2, not with other, so it's
>>>> hard to
>>>> answer.
>>>> Some elements that might be useful:
>>>>
>>>> - https://www.openhub.net/p/spock
>>>> - https://www.openhub.net/p/jmockit
>>>> - https://www.openhub.net/p/mockito
>>>>
>>>>
>>>> Maybe we should take a place where we want to introduce it and make
>>>> an
>>>> example with the 2 or 3 implementations to give us some ideas
>>>
>>> Now that builds.apache.org/analysis includes jmeter stats, we can see,
>>> that jdbc needs a few more tests :) So I think it would be a good idea
>>> to test mockito and jmockit on some jdbc test elements.
>>>
>>> I haven't used spock before, so I don't really know, what we would have
>>> to do in order to use it.
>>>
>>> I will open a bug enhancement to add a mocking framework. We could add
>>> patches there, or add PR to it.
>>>
>>> Regards,
>>>   Felix
>>>>
>>>>
>>>>
>>>>> Felix
>>>>>
>>>>>
>

Re: Mocking Framework

[Graham Russell]

Felix

I really like using spock.

I'm not sure how to get it working with ant, but I'm sure it's doable. I
should have some time in the new year to try adding some spock tests if
that's useful?

Please see:
https://mechanitis.blogspot.com/2013/12/spock-data-driven-testing.html and
the two other posts in that series (not my blog) for some of the reasons I
like it.

Thanks

Graham

On Sun, 18 Dec 2016, 20:30 Felix Schumacher, <
felix.schumac...@internetallee.de> wrote:

> Am Dienstag, den 13.12.2016, 22:36 +0100 schrieb Philippe Mouawad:
> > On Sunday, December 11, 2016, Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> >
> > >
> > > Hi all,
> > >
> > > Philippe has brought up the potential usage of a mocking framework
> > > in
> > > another thread. That is something I too would like to see used in
> > > our
> > > tests. He has linked mockito 2 as a candidate. I think a strong
> > > contender
> > > would be jmockit (http://jmockit.org/) or (additionally) something
> > > like
> > > spock (http://spockframework.org/).
> > >
> > > What do you think?
> > I have a little experience with mockito2, not with other, so it's
> > hard to
> > answer.
> > Some elements that might be useful:
> >
> >- https://www.openhub.net/p/spock
> >- https://www.openhub.net/p/jmockit
> >- https://www.openhub.net/p/mockito
> >
> >
> > Maybe we should take a place where we want to introduce it and make
> > an
> > example with the 2 or 3 implementations to give us some ideas
>
> Now that builds.apache.org/analysis includes jmeter stats, we can see,
> that jdbc needs a few more tests :) So I think it would be a good idea
> to test mockito and jmockit on some jdbc test elements.
>
> I haven't used spock before, so I don't really know, what we would have
> to do in order to use it.
>
> I will open a bug enhancement to add a mocking framework. We could add
> patches there, or add PR to it.
>
> Regards,
>  Felix
> >
> >
> >
> > >
> > > Felix
> > >
> > >
>

Re: [GitHub] jmeter pull request: Removing unnecessary (un)boxing

[Graham Russell]

Hi Sebb

Thanks for having a look through the PR. I appreciate all the work you
do with JMeter!

I do not fully understand your argument. Do you have an example of
issues to help me understand where explicit (un)boxing would help
prevent a problem?

My main reason for the PR was to reduce the amount of code to improve
readability. In my opinion most explicit (un)boxing is just noise -
happy to be persuaded otherwise.

For example:
What potential problems does the booleanValue() here avoid? I
understand the need for the null check as you are right auto unboxing
could hide a NPE.

if (success != null) {
if (success.booleanValue()) { ...

vs.:

if (success != null) {
if (success) { ...

If the reasoning was to make it even more obvious that it was an
object and needed the null check, then, just as one example, this
hasn't worked in the HtmlTemplateExporter class, the method
EmptyGraphChecker.checkResult has
supportsControllerDiscrimination.booleanValue() but no null check even
though the method which created it could return null.

As another example, in a method which returns a long, I do not
understand why the .longValue() is helpful, e.g.:

public long getTimestamp() {
return getData(long.class, CSVSaveService.TIME_STAMP).longValue();
}

Or why:
Double.valueOf(((double) data.longValue() * 100 / errorCount))

is preferred over:

((double) data * 100 / errorCount)

I acknowledge you need to be mindful of NPE and auto (un)boxing in
loops etc. 
(http://brian.pontarelli.com/2004/07/15/jdk-5-auto-boxing-best-practices/)
but I currently do not see how being explicit about (ub)boxing helps?

I would very much appreciate any time you (or anyone else on the list)
could spare to improve my understanding of this issue, via email or
perhaps comment in github on specific changes and I would be happy to
update the PR.

Many thanks

Graham

On Mon, 15 Feb 2016 at 09:32 sebb  wrote:
>
> -1
>
> Auto boxing is generally a bad idea as it can hide poor design (wrong
> choice of long/Long).
>
> It can also hide wrong choice of method (Long.parseLong/Long.decode)
>
> Implicit unboxing can hide potential NPE.
>
> About the only place where autoboxing is useful is in String.format,
> but that should not be used as an excuse to allow it elsewhere.
>

Re: JPopupMenu Behaviours

[Graham Russell]

Hi again

I've uploaded my current work in progress to
https://issues.apache.org/bugzilla/show_bug.cgi?id=54784
The enter key now adds items to the JM Tree however there is a strange bug
whereby sometimes the popup menu doesn't disappear after adding items using
the enter key - the bug isn't there when using the mouse to click the menu
item - I've only tested it on Linux.

Is anyone able to take a look?

Thanks

Graham

Graham

On 19 October 2014 00:12, Graham Russell  wrote:

> Hi all
>
> I've been looking at the below bug about adding test elements using the
> keyboard:  https://issues.apache.org/bugzilla/show_bug.cgi?id=54784
>
> I've managed to get the popup menu to appear in the expected location when
> shift + F10 (or the context menu key) is pressed (in
> JMeterTreeListener.java) but I am struggling to understand where the
> behaviour of clicking on one of the buttons is defined i.e. adding an item
> to the tree,  such that I can ensure the InputMap for the popup menu is
> defined in such a way that the enter key behaves like a left mouse click.
>
> Grateful for any assistance.
>
> Thanks
>
> Graham
>

JPopupMenu Behaviours

[Graham Russell]

Hi all

I've been looking at the below bug about adding test elements using the
keyboard:  https://issues.apache.org/bugzilla/show_bug.cgi?id=54784

I've managed to get the popup menu to appear in the expected location when
shift + F10 (or the context menu key) is pressed (in
JMeterTreeListener.java) but I am struggling to understand where the
behaviour of clicking on one of the buttons is defined i.e. adding an item
to the tree,  such that I can ensure the InputMap for the popup menu is
defined in such a way that the enter key behaves like a left mouse click.

Grateful for any assistance.

Thanks

Graham

IDEs and Java Formatting

[Graham Russell]

Hi all

I've recently started to look at/contribute to the JMeter code and I've
noticed that there are quite a few formatting inconstancies, which I find
quite distracting (especially those relating to indentation) when trying to
efficiently read and understand code.

I use Eclipse as my Java IDE. Does any one else?
If a sizeable number do I'd like to propose that we use a consistent
formatter, I personally like the Google eclipse Java code formatter
(however I'd change the indentation from 2 to 4 spaces).

https://code.google.com/p/google-styleguide/source/browse/trunk/eclipse-java-google-style.xml

The eclipse formatter can also be run stand-alone by anyone who don't use
it as their IDE:
http://www.peterfriese.de/formatting-your-code-using-the-eclipse-code-formatter/

https://wiki.apache.org/jmeter/JMeterEclipse seems to be quite old/limited
and a manual process. Is there a reason for not checking in
default/bare-bones eclipse project/.settings files/folders to make it even
easier for people to checkout and get things working (building but also
formatting) in eclipse?

What do people think?

Regards


Graham