RE: Some JMeter (technical) concerns

[Emilian Bold]

>> The whole communication between JMeter client and servers should be
>> rewritten using more modern protocols.
>>
> For this, I think the most important thing to pay attention to is the
> usability and efficiency. Distributed execution of sophisticated test plans
> is a 10x Advantage of JMeter; to my knowledge, this is the only tool that
> can do it. So it'd be wise capitalise on that by making sure anyone else who
> comes into this area has a tall order to be anything other than an also-ran.


I didn't study this enough but in what way would a more sophisticated test plan 
impact the distributed execution? Normally, the test shouldn't even know it's 
running differently.

Anyhow, like I've mentioned my no.1 problem with RMI is that it needs open 
ports on both sides. There's also no security basically.

And finally, the connection is brittle.

A protocol that would have a single open port on the remote machine, use an 
encrypted channel and have some queuing to handle temporary connection errors 
would be peachy.

--emi

Re: Integrating Darcula LAF as JMeter main LAF

[Emilian Bold]

Yes, sadly the project is not in Maven Central, which is annoying. I use Maven 
for YaMeter and the Darcula JAR needs special treatment since it's local...

--emi

> Original Message 
>Subject: Integrating Darcula LAF as JMeter main LAF
>Local Time: October 30, 2017 8:28 PM
>UTC Time: October 30, 2017 6:28 PM
>From: philippe.moua...@gmail.com
>To: dev@jmeter.apache.org <dev@jmeter.apache.org>
>
>Hello,
> Following Emilian Bold suggestion about Darcula LAF, I've had a look at it.
> Integration seems easy.
>
> But I see 2 minor to major problems:
> - Library does not seem to have a versioning system: 
> - https://github.com/bulenkov/Darcula/issues/40
> - There is no maven artifact :
> - https://github.com/bulenkov/Darcula/issues/7
> - There seems to be an issue with Java9, but I think this one is not a
> problem
>
> But I'll move towards integration by for now managing a download as we do
> for Checkstyle.
> The JAR is available at:
> - https://github.com/bulenkov/Darcula/raw/master/build/darcula.jar
>
> My main concern is that it's not versioned clearly but I think we can work
> with commits ids:
> - 
>https://github.com/bulenkov/Darcula/blob/e208efb96f70e4be9dc362fbb46f6e181ef501dd/build/darcula.jar
>
>
> If I am wrong, please correct me here.
> Thanks
>
>Cordialement.
> Philippe Mouawad.
>

Re: Some JMeter (technical) concerns

[Emilian Bold]

Answers bellow:

>1.1 Metrics
>>I believe it is possible to add usage metrics to JMeter while respecting
>> the ASF policy on privacy, etc.
>>It's also unclear to me how download stats are not shared by the Apache
>> mirrors (any ASF document explaining this policy?).
>>
>I agree with this.
> I have asked Apache infra if we are able to get some metrics but it seems
> it's not the case.
> I am also very unhappy with this and have to default to:
> - stackoverflow questions
> - downloads of plugins
> - user mails


Can I start a discussion with ASF legal@, infra@ and the rest about how an 
Apache project could get some metrics or add "telemetry".


>>2. Speed of development
[...]
> But another thing, did you have a look at the frequency at which user
> upgrade ?

Where would I see such info?


> I still see a lot of people using version that are 5 year old, so if we
> released more often, would user upgrade their versions ?

They would, if JMeter would tell them about this and provide a simple one-click 
way to auto-update (think how Google Chrome autoupdates, etc).

>>Are any companies putting resources into JMeter? I see a lot of companies
>> / startups trying to make money off JMeter but how many are contributing
>> back?
>>
>Not enough involvement in Core IMO:
> - My company Ubik-Ingenierie contributes in 2 ways: 
> - Patches, bug fixes
> - Bigger features like JMeter Web Report , JSON Plugin
> - Sponsoring partly my time for working on project


> I wonder for example why HTTP2 was not donated immediately to Core.

Because it's better for them to control the plugin.

>>BTW, one reason I decided to do YaMeter.com instead of trying to push into
>> JMeter proper is the approval speed. Getting a patch in seems to take a lot
>> of effort and I can only imagine how long it would have take to try
>> something as large as what I did with YaMeter.
>>
>I think we have made improvements in that field, have a look at PR and
> Patches taken into account, look at thanks section of every released.
> I don't think we are slow to take into account PR provided they are
> complete. We give feedback in max 1 days AFAIK. For bugs it is even less.
> I don't know statistics of other projects , but from my experience we are
> good here.

I guess the speed matters less if it's a one-off bugfix that you want to 
upstream.

In my case, I had the time to contribute and felt it would have taken me 
forever to wait for each fix. Due to bad luck, this also happened near a JMeter 
release which implied a code freeze of sorts...

> Regarding YaMeter, I thing we would have integrated it very quickly. I
> wrote to you about it.

I have to prepare multiple patches from YaMeter. The code is also using some 
NetBeans Platform frameworks so I would have to un-tangle those and use simpler 
things if I have to port it to JMeter as a plugin or something.

> Regarding Undo, I was commited after the release, but as you know it is
> still not satisfying .

Yes, but not because of my patch which fixed quite a few things.

>>3. UI

> JMeter UI is clearly a bad publicity for the core. I am always disappointed
> to read tweet about JMeter looking very 90, being ugly ...
>
> The IDE is powerful but the Swing look is not great and some LAF are even
> more awful , for example the Windows one are very ugly on some OSes.

I believe YaMeter looks great and it's just a LnF (Darcula from IntelliJ).

How about we add that to JMeter?

>>3.1 Swing
>>If Swing remains the future of JMeter, I suggest looking into a better
>> framework like Apache NetBeans Platform which provides a lot of useful
>> things for desktop Java apps.
>>Generally speaking, it would be good to split the UI from the "core" so we
>> have some path where we evolve to some other UI.
>>
>If we had time , I would go for a full rewriting either in WEB or Using
> Java FX, why not netbeans but I am not an expert of it. I am also very
> impressed by IntelliJ look while it is in Swing AFAIK

IntelliJ also has the IntelliJ Platform, just like Apache NetBeans Platform. 
Both are Apache 2.0.


>>3.2 Web based
>>Alternatively, a web-based interface could be made for JMeter. Any
>> interest in this?
>>
>Yes , but always the same problem , no time


This might be an interesting exercise.

What sub-set of JMeter could we provide in the 1st release of a web UI? Just 
some HTTP request and a visualization would be a great start for users (this is 
where some metrics would help to see what users use most).


>>4. Plugin Manager
>>It seems unacceptable to me that JMeter does not have a Plugin Manager and
>> a plugin portal with some lower-usage plugins (eg. mongodb).
>>It's acceptable for other plugins to exist elsewhere, but those should be
>> just another "PPA" (see Ubuntu PPA) or another "plugin repository" URL to
>> register.
>>
>
>I absolutely agree. When Andrei started his work on Plugin Manager, I wrote
> that this feature should have been in JMeter core.

How about JMeter provides a Plugin Manager out of 

Some JMeter (technical) concerns

[Emilian Bold]

Hello,

I've been following JMeter for a while now, even did a separate project based 
on JMeter (YaMeter.com ) so I figured I should mention some (technical) 
concerns of mine about JMeter.

I thought about sending multiple emails, each about a single aspect, but I will 
just list everything here and people are invited to only answer the subset they 
care about.

1. Userbase

It seems to me there are no clear metrics about the JMeter userbase. We have no 
phone-home, no plugin portal, no download statistics(!?) so we can only use 
indirect means of estimating the userbase: stackoverflow questions and such.

This seems a very poor state of affairs. Resources are scarce: how do you know 
what to focus on if you have very little insight into who your users are, what 
are they doing and where are they struggling?

1.1 Metrics

I believe it is possible to add usage metrics to JMeter while respecting the 
ASF policy on privacy, etc.

It's also unclear to me how download stats are not shared by the Apache mirrors 
(any ASF document explaining this policy?).

2. Speed of development

Compared to some of the plugins, JMeter seems to move very slowly. This might 
create the impression of stability but I believe it's just a sign of being 
resource constrained.

Are any companies putting resources into JMeter? I see a lot of companies / 
startups trying to make money off JMeter but how many are contributing back?

BTW, one reason I decided to do YaMeter.com instead of trying to push into 
JMeter proper is the approval speed. Getting a patch in seems to take a lot of 
effort and I can only imagine how long it would have take to try something as 
large as what I did with YaMeter.

3. UI

The JMeter UI needs some improving. The problem is not that it uses Java / 
Swing because even Swing can be made to look good but we need people to look 
into this. Is it "good enough" for people being forced to use JMeter in a 
corporate setting? Would an user pick it just based on the UI?

3.1 Swing

If Swing remains the future of JMeter, I suggest looking into a better 
framework like Apache NetBeans Platform which provides a lot of useful things 
for desktop Java apps.

Generally speaking, it would be good to split the UI from the "core" so we have 
some path where we evolve to some other UI.

3.2 Web based

Alternatively, a web-based interface could be made for JMeter. Any interest in 
this?

Just like companies use local GitLab installations, I am certain a lot of 
companies would install a local Apache JMeter Web Portal where all the load 
testing would be centralised.

4. Plugin Manager

It seems unacceptable to me that JMeter does not have a Plugin Manager and a 
plugin portal with some lower-usage plugins (eg. mongodb).

It's acceptable for other plugins to exist elsewhere, but those should be just 
another "PPA" (see Ubuntu PPA) or another "plugin repository" URL to register.

5. Out of the box experience

The way I see it, Apache JMeter is not just a "platform" with some core files 
and external plugins but something usable out of the box.

So, except niche situations, users should be catered by the default JMeter 
install.

5.1 HTTP2

A major problem being the lack of an official HTTP2 plugin, which people have 
to take from elsewhere. Blazemeter is probably quite happy with their 
implementation being used since it funnels people into their services.

6. Project based

I find the whole configuration .properties file a very poor solution to the 
notion of a "project". If a JMX needs a .properties change, then those two 
belong together.

JMeter should have the notion of a 'project' and maybe even be capable of 
having two projects open at once. And executing two unrelated tests at once. 
(Same for servers perhaps?)

6.1 Too many .properties

I also believe JMeter tries to be too configurable sometimes with flags for 
everything.

7. Module system

JMeter is using a lot of reflection to reinvent its own quirky module system 
(which provides the way the plugins work).

This needs some standardization work.

The NetBeans Platform, for example, comes with its own module system that also 
supports OSGI bundles (another module system). Then, there's the JVM service 
locator (for services) and the Java 9 modules.

8. Remote is using old technologies

RMI is a killer in modern setups. It needs open ports on both the slave and 
master for communication which only makes sense within the same intranet and 
it's a pain to configure when using Cloud resources.

The whole communication between JMeter client and servers should be rewritten 
using more modern protocols.

9. Cloud aware

The notion that the user tries to configure N servers then gives JMeter a list 
of IPs for remote load testing seems... primitive. This is something I've been 
trying to solve with YaMeter.com

10. Packaging

JMeter should be everywhere. Official Docker files, AMI images, etc.

11. Pipeline aware / agents

JMeter should think more about making it easy to 

Re: SampleSender modes

[Emilian Bold]

These "modes" are actually "services". When you configure the mode in
some .properties file you basically pick which service gets used.

We should not have a SampleSenderFactory that does an `if` on modes,
we should have a more generic mechanism where any such sample sender
implementation might exist.

When looking at things like this, I don't see how a mode existing or
not bothers anybody. Why shouldn't I be able to use a RAMdisk and use
the 'DiskStore' "mode"? Did you know Google Cloud has instances with
hundreds of GB of RAM? Rather cheap too if you only needs if a few
hours!

> Any issue in network or injector will loose results.

Any reason JMeter server has to be so brittle?

Instead of dropping modes, I'd say we focus on doing a sample sender
infrastructure where bi-directional connections aren't mandatory (drop
Java RMI) and allow some network hiccups (have some buffered message
queues or something).

My 2c.


--emi


On Mon, Oct 23, 2017 at 9:19 PM, Philippe Mouawad
 wrote:
> Hi,
> Any feedback on this ?
>
> Regards
>
> On Thu, Oct 12, 2017 at 4:35 PM, Philippe Mouawad <
> p.moua...@ubik-ingenierie.com> wrote:
>
>> Hello,
>> We have currently 10 modes and I believe at least 3 of them are useless:
>>
>> - DiskStore : Probably overwhelms disks / IO and the fact that results are
>> sent at end will probably induce an important network traffic and time to
>> get the results. Any issue in network or injector will loose results.
>> - StrippedDiskStore : The fact that results are sent at end will probably
>> induce an important network traffic and time to get the results. Any issue
>> in network or injector will loose results.
>> - Hold : holds results in memory which makes it useless IMO
>>
>> I propose to drop them.
>> If anybody uses them, let him speak now or remain silent until the end of
>> times :-)
>>
>>
>> Regards
>> Philippe
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>
> UBIK LOAD PACK Web Site 
>
> UBIK LOAD PACK on TWITTER 

Re: http2 support

[Emilian Bold]

See this reply 
https://lists.apache.org/thread.html/a08c9c77b9cce401043bc58cef303ed7501705e48243e17ec1a7f145@%3Clegal-discuss.apache.org%3E
confirming we are OK including the code:

> > Now, this is precisely my plan. So -- it's perfectly fine to handle
> > things this way:
> >
> > 1. Import 3rd party source code without a formal IP clearance and just
> > reference the existing license info in the NOTICE file
> > 2. Distribute the 3rd party source code with formal Apache releases
> > and build binary plugin JARs ourselves.
> > 3. Try to submit our fixes upstream. Perhaps highlight our changes to
> > the 3rd party source code in the NOTICE file
>
> NOTICE is for legally-required attributions. But it's ok to include comments 
> about what you changed. From the alv2.0: "You may add Your own attribution 
> notices within Derivative Works that You distribute, alongside or as an 
> addendum to the NOTICE text from the Work, provided that such additional 
> attribution notices cannot be construed as modifying the License."
>
> 4. You didn't explicitly mention it, but do not change the headers in the 
> source.
>
> I'd say this is a good plan.

So now it's just a matter of deciding if we include the plugins or
not, but Apache 2.0 code should not be a problem as per the answer
above. No IP clearance required, just a NOTICE update like we do for
any new library.


--emi


On Tue, Oct 3, 2017 at 11:07 PM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Hello,
> Also one note on HTTP2. I didn't find any possibility to record http2 which
> IMO is a mandatory feature.
>
> Oleg from HC project had pointed to a class that would have allowed this.
> But on Jetty I don't see a way to do that.
>
>
> Regards
>
> On Tue, Oct 3, 2017 at 9:37 PM, Emilian Bold <emilian.b...@gmail.com> wrote:
>
>> >
>> > I have already asked Andrei wether he would be ready to contribute it, at
>> > that time he was not.
>> > But maybe we can ask again.
>>
>>
>> I will be asking again.
>>
>> >
>> > > 1. https://lists.apache.org/thread.html/8db4686f7a2d98da66d57e7533eee1
>> > > 3f81d7ecf19afa293a7c26e99f@%3Clegal-discuss.apache.org%3E
>> > >
>> > I see the thread is big now :-)
>> > So I wasn't wrong thinking it was not that easy
>>
>>
>> As with anything Apache there are many opinions. I have yet to get a clear
>> answer backed by some documentation. I think we will be fine using them.
>>
>>
>> > Yes. But maybe on this topic, Emilian is doing something :-)
>>
>> Google Cloud next. Hopefully by November.
>>
>>
>>
>>
>> --emi
>>
>> On Tue, Oct 3, 2017 at 10:33 PM, Philippe Mouawad <
>> philippe.moua...@gmail.com> wrote:
>>
>> > On Tue, Oct 3, 2017 at 1:09 PM, Emilian Bold <emilian.b...@gmail.com>
>> > wrote:
>> >
>> > > I've asked legal-discuss@ [1] and will post back here with what I
>> find.
>> > >
>> > > In the mean time I also believe it might not be out of the question for
>> > CA
>> > > Technologies to donate the code to the ASF.
>> >
>> > It would be the best option.
>> >
>> >
>> > > I know some of the folks there
>> > > are on the mailing list, perhaps we'll get some replies regarding this
>> > > possibility.
>> > >
>> >
>> > I hope so.
>> >
>> > >
>> > > 1. https://lists.apache.org/thread.html/8db4686f7a2d98da66d57e7533eee1
>> > > 3f81d7ecf19afa293a7c26e99f@%3Clegal-discuss.apache.org%3E
>> > >
>> >
>> > I see the thread is big now :-)
>> > So I wasn't wrong thinking it was not that easy
>> >
>> > >
>> > > --emi
>> > >
>> > > On Tue, Oct 3, 2017 at 1:59 PM, Philippe Mouawad <
>> > > philippe.moua...@gmail.com
>> > > > wrote:
>> > >
>> > > > On Tue, Oct 3, 2017 at 12:55 PM, Emilian Bold <
>> emilian.b...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > > Correct me if I am wrong, if we plan to include the code of one
>> of
>> > > > those
>> > > > > plugins, I don't see how we could without it being donated.
>> > > > >
>> > > > > Just like any dependency. I don't believe it's a rule that
>> > dependencies
>> > > > > have to be binary JARs. A "work" being "included" could mean source
>

Re: http2 support

[Emilian Bold]

>
> I have already asked Andrei wether he would be ready to contribute it, at
> that time he was not.
> But maybe we can ask again.


I will be asking again.

>
> > 1. https://lists.apache.org/thread.html/8db4686f7a2d98da66d57e7533eee1
> > 3f81d7ecf19afa293a7c26e99f@%3Clegal-discuss.apache.org%3E
> >
> I see the thread is big now :-)
> So I wasn't wrong thinking it was not that easy


As with anything Apache there are many opinions. I have yet to get a clear
answer backed by some documentation. I think we will be fine using them.


> Yes. But maybe on this topic, Emilian is doing something :-)

Google Cloud next. Hopefully by November.




--emi

On Tue, Oct 3, 2017 at 10:33 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> On Tue, Oct 3, 2017 at 1:09 PM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
> > I've asked legal-discuss@ [1] and will post back here with what I find.
> >
> > In the mean time I also believe it might not be out of the question for
> CA
> > Technologies to donate the code to the ASF.
>
> It would be the best option.
>
>
> > I know some of the folks there
> > are on the mailing list, perhaps we'll get some replies regarding this
> > possibility.
> >
>
> I hope so.
>
> >
> > 1. https://lists.apache.org/thread.html/8db4686f7a2d98da66d57e7533eee1
> > 3f81d7ecf19afa293a7c26e99f@%3Clegal-discuss.apache.org%3E
> >
>
> I see the thread is big now :-)
> So I wasn't wrong thinking it was not that easy
>
> >
> > --emi
> >
> > On Tue, Oct 3, 2017 at 1:59 PM, Philippe Mouawad <
> > philippe.moua...@gmail.com
> > > wrote:
> >
> > > On Tue, Oct 3, 2017 at 12:55 PM, Emilian Bold <emilian.b...@gmail.com>
> > > wrote:
> > >
> > > > > Correct me if I am wrong, if we plan to include the code of one of
> > > those
> > > > plugins, I don't see how we could without it being donated.
> > > >
> > > > Just like any dependency. I don't believe it's a rule that
> dependencies
> > > > have to be binary JARs. A "work" being "included" could mean source
> > code,
> > > > not just compiled JAR.
> > > >
> > >
> > > As I am not sure I'll let legal answer
> > >
> > > >
> > > > > If we are only including the binaries, then I don't see any benefit
> > > from
> > > > it, as it is already a plugin.
> > > >
> > > > Having something included in JMeter proper would at least guarantee
> > some
> > > > stability and security wrt the code
> > >
> > >
> > > Absolutely
> > >
> > > > .
> > > >
> > > > A 3rd party plugin has no such guarantees. I personally don't like
> > > hunting
> > > > down plugins for my tools especially when it's not something niche.
> > > >
> > >
> > > Absolutely
> > >
> > > >
> > > > I don't believe JMeter should encourage users to always use plugins;
> is
> > > > JMeter something usable out of the box or just a platform?
> > > >
> > >
> > > OOTB usable for me
> > >
> > > >
> > > > I would gladly drop JDBC/MongoDB/JMS to have everything HTTP-related
> > > > included.
> > > >
> > >
> > > MongoDB is a good candidate.
> > > I think JMS and JDBC are far from being a niche based on questions on
> SO
> > > for example.
> > >
> > > >
> > > > --emi
> > > >
> > > > On Tue, Oct 3, 2017 at 1:41 PM, sebb <seb...@gmail.com> wrote:
> > > >
> > > > > If the code is available as a plugin then I don't see the need to
> > > > > include it in JMeter itself.
> > > > > It can be listed on a plugins page on the Wiki.
> > > > >
> > > > > Remember that code that is added to the JMeter code base adds to
> the
> > > > > ongoing maintenance cost.
> > > > > This reduces the time that can be spent on the rest of the JMeter
> > code.
> > > > >
> > > > > On 3 October 2017 at 11:27, Philippe Mouawad
> > > > > <p.moua...@ubik-ingenierie.com> wrote:
> > > > > > Hi Emilian,
> > > > > > Correct me if I am wrong, if we plan to include the code of one
> of
> > > > those
> > > > > > plugins, I don't see how we could without it being donated.
&g

Re: http2 support

[Emilian Bold]

I've asked legal-discuss@ [1] and will post back here with what I find.

In the mean time I also believe it might not be out of the question for CA
Technologies to donate the code to the ASF. I know some of the folks there
are on the mailing list, perhaps we'll get some replies regarding this
possibility.

1. https://lists.apache.org/thread.html/8db4686f7a2d98da66d57e7533eee1
3f81d7ecf19afa293a7c26e99f@%3Clegal-discuss.apache.org%3E

--emi

On Tue, Oct 3, 2017 at 1:59 PM, Philippe Mouawad <philippe.moua...@gmail.com
> wrote:

> On Tue, Oct 3, 2017 at 12:55 PM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
> > > Correct me if I am wrong, if we plan to include the code of one of
> those
> > plugins, I don't see how we could without it being donated.
> >
> > Just like any dependency. I don't believe it's a rule that dependencies
> > have to be binary JARs. A "work" being "included" could mean source code,
> > not just compiled JAR.
> >
>
> As I am not sure I'll let legal answer
>
> >
> > > If we are only including the binaries, then I don't see any benefit
> from
> > it, as it is already a plugin.
> >
> > Having something included in JMeter proper would at least guarantee some
> > stability and security wrt the code
>
>
> Absolutely
>
> > .
> >
> > A 3rd party plugin has no such guarantees. I personally don't like
> hunting
> > down plugins for my tools especially when it's not something niche.
> >
>
> Absolutely
>
> >
> > I don't believe JMeter should encourage users to always use plugins; is
> > JMeter something usable out of the box or just a platform?
> >
>
> OOTB usable for me
>
> >
> > I would gladly drop JDBC/MongoDB/JMS to have everything HTTP-related
> > included.
> >
>
> MongoDB is a good candidate.
> I think JMS and JDBC are far from being a niche based on questions on SO
> for example.
>
> >
> > --emi
> >
> > On Tue, Oct 3, 2017 at 1:41 PM, sebb <seb...@gmail.com> wrote:
> >
> > > If the code is available as a plugin then I don't see the need to
> > > include it in JMeter itself.
> > > It can be listed on a plugins page on the Wiki.
> > >
> > > Remember that code that is added to the JMeter code base adds to the
> > > ongoing maintenance cost.
> > > This reduces the time that can be spent on the rest of the JMeter code.
> > >
> > > On 3 October 2017 at 11:27, Philippe Mouawad
> > > <p.moua...@ubik-ingenierie.com> wrote:
> > > > Hi Emilian,
> > > > Correct me if I am wrong, if we plan to include the code of one of
> > those
> > > > plugins, I don't see how we could without it being donated.
> > > > I am not even sure that this project would be willing to donate it.
> > > >
> > > > If we are only including the binaries, then I don't see any benefit
> > from
> > > > it, as it is already a plugin.
> > > >
> > > > Maybe before going further, we should review the code to see if it is
> > > worth
> > > > the discussion.
> > > >
> > > > Then we can ask Legal team, or feel free to ask.
> > > >
> > > > Regards
> > > >
> > > > On Tue, Oct 3, 2017 at 12:22 PM, Emilian Bold <
> emilian.b...@gmail.com>
> > > > wrote:
> > > >
> > > >> IP clearance applies to donated code which will have an ASF license
> > > header.
> > > >>
> > > >> For dependencies and included works this might help:
> > > >> https://www.apache.org/legal/resolved.html#category-a
> > > >>
> > > >> FOR THE PURPOSES OF BEING INCLUDED IN AN APACHE PRODUCT, WHICH
> > LICENSES
> > > >>> ARE CONSIDERED TO BE SIMILAR IN TERMS TO THE APACHE LICENSE 2.0?
> > > >>> Works under the following licenses may be included within Apache
> > > products:
> > > >>>
> > > >>
> > > >>
> > > >> Apache License 2.0
> > > >>
> > > >>
> > > >> Please ask Apache legal because I don't believe there are any
> > > restrictions.
> > > >>
> > > >>
> > > >>
> > > >> --emi
> > > >>
> > > >> On Tue, Oct 3, 2017 at 12:49 PM, UBIK LOAD PACK Support <
> > > >> supp...@ubikloadpack.com> wrote:
> > > >>
> > > >>> Hello,
> > > >>> 

Re: http2 support

[Emilian Bold]

> Correct me if I am wrong, if we plan to include the code of one of those
plugins, I don't see how we could without it being donated.

Just like any dependency. I don't believe it's a rule that dependencies
have to be binary JARs. A "work" being "included" could mean source code,
not just compiled JAR.

> If we are only including the binaries, then I don't see any benefit from
it, as it is already a plugin.

Having something included in JMeter proper would at least guarantee some
stability and security wrt the code.

A 3rd party plugin has no such guarantees. I personally don't like hunting
down plugins for my tools especially when it's not something niche.

I don't believe JMeter should encourage users to always use plugins; is
JMeter something usable out of the box or just a platform?

I would gladly drop JDBC/MongoDB/JMS to have everything HTTP-related
included.

--emi

On Tue, Oct 3, 2017 at 1:41 PM, sebb <seb...@gmail.com> wrote:

> If the code is available as a plugin then I don't see the need to
> include it in JMeter itself.
> It can be listed on a plugins page on the Wiki.
>
> Remember that code that is added to the JMeter code base adds to the
> ongoing maintenance cost.
> This reduces the time that can be spent on the rest of the JMeter code.
>
> On 3 October 2017 at 11:27, Philippe Mouawad
> <p.moua...@ubik-ingenierie.com> wrote:
> > Hi Emilian,
> > Correct me if I am wrong, if we plan to include the code of one of those
> > plugins, I don't see how we could without it being donated.
> > I am not even sure that this project would be willing to donate it.
> >
> > If we are only including the binaries, then I don't see any benefit from
> > it, as it is already a plugin.
> >
> > Maybe before going further, we should review the code to see if it is
> worth
> > the discussion.
> >
> > Then we can ask Legal team, or feel free to ask.
> >
> > Regards
> >
> > On Tue, Oct 3, 2017 at 12:22 PM, Emilian Bold <emilian.b...@gmail.com>
> > wrote:
> >
> >> IP clearance applies to donated code which will have an ASF license
> header.
> >>
> >> For dependencies and included works this might help:
> >> https://www.apache.org/legal/resolved.html#category-a
> >>
> >> FOR THE PURPOSES OF BEING INCLUDED IN AN APACHE PRODUCT, WHICH LICENSES
> >>> ARE CONSIDERED TO BE SIMILAR IN TERMS TO THE APACHE LICENSE 2.0?
> >>> Works under the following licenses may be included within Apache
> products:
> >>>
> >>
> >>
> >> Apache License 2.0
> >>
> >>
> >> Please ask Apache legal because I don't believe there are any
> restrictions.
> >>
> >>
> >>
> >> --emi
> >>
> >> On Tue, Oct 3, 2017 at 12:49 PM, UBIK LOAD PACK Support <
> >> supp...@ubikloadpack.com> wrote:
> >>
> >>> Hello,
> >>> See:
> >>>
> >>> - https://incubator.apache.org/guides/ip_clearance.html
> >>>
> >>> Regards
> >>>
> >>> On Tuesday, October 3, 2017, Antonio Gomes Rodrigues <ra0...@gmail.com
> >
> >>> wrote:
> >>>
> >>> > Hi,
> >>> >
> >>> > I'm also curious about why we could not integrate apache licensed
> code.
> >>> I
> >>> > was thinking we can fork a plugin and integrate it in JMeter.
> >>> >
> >>> > Anybody have an idea?
> >>> >
> >>> > Antonio
> >>> >
> >>> > 2017-10-02 21:25 GMT+02:00 Philippe Mouawad <
> philippe.moua...@gmail.com
> >>> > <javascript:;>>:
> >>> >
> >>> > > On Mon, Oct 2, 2017 at 9:21 PM, Emilian Bold <
> emilian.b...@gmail.com
> >>> > <javascript:;>>
> >>>
> >>> > > wrote:
> >>> > >
> >>> > > > > AFAIK, unless the project donates their code to JMeter, we
> cannot
> >>> > take
> >>> > > it
> >>> > > > as it would be a license infringement at minimum.
> >>> > > >
> >>> > > > It's open source under the Apache 2.0 license. The license itself
> >>> > allows
> >>> > > > you to bundle it with JMeter proper. Of course, it won't be
> owned by
> >>> > the
> >>> > > > ASF but you can have it as a dependency.
> >>> > > >
> &g

Re: http2 support

[Emilian Bold]

IP clearance applies to donated code which will have an ASF license header.

For dependencies and included works this might help:
https://www.apache.org/legal/resolved.html#category-a

FOR THE PURPOSES OF BEING INCLUDED IN AN APACHE PRODUCT, WHICH LICENSES ARE
> CONSIDERED TO BE SIMILAR IN TERMS TO THE APACHE LICENSE 2.0?
> Works under the following licenses may be included within Apache products:
>


Apache License 2.0


Please ask Apache legal because I don't believe there are any restrictions.



--emi

On Tue, Oct 3, 2017 at 12:49 PM, UBIK LOAD PACK Support <
supp...@ubikloadpack.com> wrote:

> Hello,
> See:
>
> - https://incubator.apache.org/guides/ip_clearance.html
>
> Regards
>
> On Tuesday, October 3, 2017, Antonio Gomes Rodrigues <ra0...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I'm also curious about why we could not integrate apache licensed code. I
> > was thinking we can fork a plugin and integrate it in JMeter.
> >
> > Anybody have an idea?
> >
> > Antonio
> >
> > 2017-10-02 21:25 GMT+02:00 Philippe Mouawad <philippe.moua...@gmail.com
> > <javascript:;>>:
> >
> > > On Mon, Oct 2, 2017 at 9:21 PM, Emilian Bold <emilian.b...@gmail.com
> > <javascript:;>>
> > > wrote:
> > >
> > > > > AFAIK, unless the project donates their code to JMeter, we cannot
> > take
> > > it
> > > > as it would be a license infringement at minimum.
> > > >
> > > > It's open source under the Apache 2.0 license. The license itself
> > allows
> > > > you to bundle it with JMeter proper. Of course, it won't be owned by
> > the
> > > > ASF but you can have it as a dependency.
> > > >
> > > > You could also "fork" it (or "vendor" it) if you want to add some
> > > patches.
> > > >
> > >
> > > AFAIK, we need for this the owner to make a donation as piece of code
> is
> > > important.
> > > There is IP clearance process at Apache for that. I doubt that we can
> > take
> > > it as is or fork it, but I'm not an expert in those matters.
> > > Maybe Andrei can tell us more.
> > >
> > >
> > >
> > > > Have there been any talks with CA Technologies / Blazemeter to
> perhaps
> > > > donate the plugin to the ASF?
> > > >
> > > > > Would you like to work on its implementation ?
> > > >
> > > > Why would I do that when you have this plugin available under a
> > > compatible
> > > > license as well as this other one
> > > > https://github.com/syucream/jmeter-http2-plugin under Apache 2.0
> based
> > > on
> > > > netty?
> > > >
> > > I tested this one, it does not work very well.
> > > Looks more like a POC than a stable implementation.
> > >
> > >
> > >
> > > >
> > > >
> > > > --emi
> > > >
> > > > On Mon, Oct 2, 2017 at 10:11 PM, Philippe Mouawad <
> > > > philippe.moua...@gmail.com <javascript:;>> wrote:
> > > >
> > > > > Hi Emilian,
> > > > > AFAIK, unless the project donates their code to JMeter, we cannot
> > take
> > > it
> > > > > as it would be a license infringement at minimum.
> > > > >
> > > > > Regarding HTTP2 there are many options AFAIK:
> > > > >
> > > > >- Jetty
> > > > >- Netty
> > > > >- HC5
> > > > >
> > > > > Would you like to work on its implementation ?
> > > > >
> > > > >
> > > > > Regards
> > > > >
> > > > > On Mon, Oct 2, 2017 at 8:54 PM, Emilian Bold <
> emilian.b...@gmail.com
> > <javascript:;>>
> > > > > wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I see we have a HTTP2 plugin
> > > > > > https://github.com/Blazemeter/jmeter-bzm-plugins based on the
> > Jetty
> > > > > HTTP2
> > > > > > support and under an Apache 2.0 license.
> > > > > >
> > > > > > Is there any reason JMeter could not bless this implementation
> and
> > > > bundle
> > > > > > it?
> > > > > >
> > > > > > --emi
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cordialement.
> > > > > Philippe Mouawad.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cordialement.
> > > Philippe Mouawad.
> > >
> >
>
>
> --
>
> 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>
>

Re: http2 support

[Emilian Bold]

> AFAIK, unless the project donates their code to JMeter, we cannot take it
as it would be a license infringement at minimum.

It's open source under the Apache 2.0 license. The license itself allows
you to bundle it with JMeter proper. Of course, it won't be owned by the
ASF but you can have it as a dependency.

You could also "fork" it (or "vendor" it) if you want to add some patches.

Have there been any talks with CA Technologies / Blazemeter to perhaps
donate the plugin to the ASF?

> Would you like to work on its implementation ?

Why would I do that when you have this plugin available under a compatible
license as well as this other one
https://github.com/syucream/jmeter-http2-plugin under Apache 2.0 based on
netty?



--emi

On Mon, Oct 2, 2017 at 10:11 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hi Emilian,
> AFAIK, unless the project donates their code to JMeter, we cannot take it
> as it would be a license infringement at minimum.
>
> Regarding HTTP2 there are many options AFAIK:
>
>- Jetty
>- Netty
>- HC5
>
> Would you like to work on its implementation ?
>
>
> Regards
>
> On Mon, Oct 2, 2017 at 8:54 PM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
> > Hello,
> >
> > I see we have a HTTP2 plugin
> > https://github.com/Blazemeter/jmeter-bzm-plugins based on the Jetty
> HTTP2
> > support and under an Apache 2.0 license.
> >
> > Is there any reason JMeter could not bless this implementation and bundle
> > it?
> >
> > --emi
> >
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

http2 support

[Emilian Bold]

Hello,

I see we have a HTTP2 plugin
https://github.com/Blazemeter/jmeter-bzm-plugins based on the Jetty HTTP2
support and under an Apache 2.0 license.

Is there any reason JMeter could not bless this implementation and bundle
it?

--emi

Re: JMeter - Common JMS/RabbitMQ component

[emilian . bold]

It should be possible to either develop such a component in-house or to hire 
somebody to develop the component for you.

--emi 

> On 27 Sep 2017, at 20:13, hiren.pa...@intellectdesign.com wrote:
> 
> Hi, This option is evaluated. Thanks for sharing.
> 
> However, it doesn't help, bcos if we have 10 test cases for example, we 
> will still need 10 * 2 components (JMS + RabbitMQ) configured and 
> maintained. And we are expecting hundreds!
> 
> What is desired is single component where we specify:
> - Broker = JMS / RabbitMQ
> - Connection Factory = JMS one or RMQ one
> - Queue configuration = JMS one of RMQ one
> 
> And with all above as JMeter variables, we could very well just have one 
> single component configured to switch between ActiveMQ and RabbitMQ as and 
> when required.
> 
> Too wishful? :-)
> 
> Regards,
> Hiren
> 
> 
> 
> 
> 
> From:   Antonio Gomes Rodrigues <ra0...@gmail.com>
> To: JMeter Users List <u...@jmeter.apache.org>
> Cc: "JMeter Dev@" <dev@jmeter.apache.org>
> Date:   27-09-2017 10:30 PM
> Subject:Re: JMeter - Common JMS/RabbitMQ component
> 
> 
> 
> Try with a variable pass to JMeter and use a IF to choose the right 
> sampler
> 
> Le 27 sept. 2017 18:40, <hiren.pa...@intellectdesign.com> a écrit :
> 
>> Yes, using the same RabbitMQ plugin you mentioned.
>> 
>> Was hoping for some component already out there supporting both
>> protocol's.
>> 
>> Nevertheless, if there is a need to create new plugin, where should I 
> look
>> for relevant guide?
>> 
>> Thanks,
>> Hiren
>> 
>> 
>> 
>> 
>> 
>> From:   Emilian Bold <emilian.b...@gmail.com>
>> To: JMeter Users List <u...@jmeter.apache.org>
>> Cc: "JMeter Dev@" <dev@jmeter.apache.org>
>> Date:   27-09-2017 09:57 PM
>> Subject:Re: JMeter - Common JMS/RabbitMQ component
>> 
>> 
>> 
>> I imagine that for AMQP you use a 3rd party plugin like
>> https://github.com/
>> jlavallee/JMeter-Rabbit-AMQP ?
>> 
>> I guess it might be possible to create a custom plugin to bridge towards
>> those two underlying.
>> 
>> 
>> --emi
>> 
>> On Wed, Sep 27, 2017 at 7:00 PM, <hiren.pa...@intellectdesign.com> 
> wrote:
>> 
>>> Hi,
>>> 
>>> As part of our Integration Test Automation process, we have been
>> actively
>>> using Apache JMeter tool.
>>> 
>>> Some part of test automation needs Asynchronous Message
>>> Publisher/Subscriber. We have both ActiveMQ (JMS) and RabbitMQ brokers
>> to
>>> be supported in integration tests.
>>> 
>>> What we see is JMeter:
>>> 
>>>   - uses *JMS *Point-to-Point/ Publisher/ Subscriber for *ActiveMQ *
>>>   communication.
>>>   - and needs *AMQP *Publisher/ Consumer for *RabbitMQ* 
> communication.
>>> 
>>> 
>>> This works well in isolation. However, problem is when we want to 
> switch
>>> between RabbitMQ and ActiveMQ broker, depending on what environment we
>> are
>>> testing with (e.g. Dev, Test, QA etc).
>>> 
>>> Problem is we have to maintain completely two different Test Suite:
>>> 
>>>   - one with AMQP components (for RabbitMQ)
>>>   - another one with JMS components (for ActiveMQ)
>>> 
>>> 
>>> *Is there a way in JMeter *by which we use some common
>> publisher/consumer
>>> that can support both RabbitMQ and ActiveMQ, without us having to
>> maintain
>>> two different Test Suite? So that we can anytime switch between the
>> brokers.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Thanks,
>>> Hiren
>>> 
>>> 
>>> 
>>> 
>>> 
>>> *-- This e-Mail may contain proprietary 
> and
>>> confidential information and is sent for the intended recipient(s) 
> only.
>> If
>>> by an addressing or transmission error this mail has been misdirected 
> to
>>> you, you are requested to delete this mail immediately. You are also
>> hereby
>>> notified that any use, any form of reproduction, dissemination, 
> copying,
>>> disclosure, modification, distribution and/or publication of this 
> e-mail
>>> message, contents or its attachment other than by its intended
>> recipient/s
>>> is strictly prohibited. Visit us at http://www.intellectdesign.com
>>> <http://www.intellectdesign.com> --*
>> 
>> 
> 

Re: JMeter - Common JMS/RabbitMQ component

[Emilian Bold]

I imagine that for AMQP you use a 3rd party plugin like https://github.com/
jlavallee/JMeter-Rabbit-AMQP ?

I guess it might be possible to create a custom plugin to bridge towards
those two underlying.


--emi

On Wed, Sep 27, 2017 at 7:00 PM,  wrote:

> Hi,
>
> As part of our Integration Test Automation process, we have been actively
> using Apache JMeter tool.
>
> Some part of test automation needs Asynchronous Message
> Publisher/Subscriber. We have both ActiveMQ (JMS) and RabbitMQ brokers to
> be supported in integration tests.
>
> What we see is JMeter:
>
>- uses *JMS *Point-to-Point/ Publisher/ Subscriber for *ActiveMQ *
>communication.
>- and needs *AMQP *Publisher/ Consumer for *RabbitMQ* communication.
>
>
> This works well in isolation. However, problem is when we want to switch
> between RabbitMQ and ActiveMQ broker, depending on what environment we are
> testing with (e.g. Dev, Test, QA etc).
>
> Problem is we have to maintain completely two different Test Suite:
>
>- one with AMQP components (for RabbitMQ)
>- another one with JMS components (for ActiveMQ)
>
>
> *Is there a way in JMeter *by which we use some common publisher/consumer
> that can support both RabbitMQ and ActiveMQ, without us having to maintain
> two different Test Suite? So that we can anytime switch between the brokers.
>
>
>
>
>
> Thanks,
> Hiren
>
>
>
>
>
> *-- This e-Mail may contain proprietary and
> confidential information and is sent for the intended recipient(s) only. If
> by an addressing or transmission error this mail has been misdirected to
> you, you are requested to delete this mail immediately. You are also hereby
> notified that any use, any form of reproduction, dissemination, copying,
> disclosure, modification, distribution and/or publication of this e-mail
> message, contents or its attachment other than by its intended recipient/s
> is strictly prohibited. Visit us at http://www.intellectdesign.com
>  --*

Re: Bug 60966 - getClass().getResource() does not work as a File if the classpath contains spaces

[Emilian Bold]

Looks to me like this bug should be closed already. The test has been
fixed since April
https://github.com/apache/jmeter/commit/bdd6b7034f5d3e15e62064d324872bc746684ac8#diff-7cae783ef064e0d9b1bf09d5924ed877

--emi


On Mon, Sep 25, 2017 at 6:59 AM, Tharindu Dananjaya
 wrote:
> Hello,
> In here as the description when class path contains
> spaces.getClass().getResource() doesn't work.it contains only in
> ApdexPerTransactionTest.java.
> it is a class that contain test cases.when i checked this with spaces,
> testing failed
> when i searched for ApdexPerTransaction it shows as a hashmap.so where
> should i check for get more idea.If someone has explanation of this bug
> please help me.

Re: JMeter Bug ID 61262

[Emilian Bold]

Felix mentioned the documentation is probably wrong. So, by looking at
the behavior / code what should the documentation say?

--emi


On Sun, Sep 24, 2017 at 8:48 AM, Harsha Gayan  wrote:
> when read data from csv file, if loop count value is set to 1, all data in
> the csv file need to be read for 1 iteration. but, it returns only 1 line
> of the csv file when it set as 1. if it is set as 2, csv file need to be
> used for 2 times as mention in documentation. can some one help me with the
> issue.
> thank you
>
> On Sun, Sep 24, 2017 at 9:10 AM, Harsha Gayan 
> wrote:
>
>> When testing data from csv file in CSV Data Set Config, Number of
>> Threads(Users) in the Thread Group need to be set as number of data
>> sets(rows) in the csv file. so, the user need to be know the number of data
>> sets in the csv file before testing it. can someone tell me is that a issue
>> or some kind of miss understand. i attached some screen shots regarding the
>> issue
>>
>> On Thu, Aug 3, 2017 at 12:13 AM, Felix Schumacher > internetallee.de> wrote:
>>
>>> Am 01.08.2017 um 19:03 schrieb Harsha Gayan:
>>>
 When testing data from csv file in CSV Data Set Config, Number of
 Threads(Users) in the Thread Group need to be set as number of data
 sets(rows) in the csv file. so, the user need to be know the number of
 data
 sets in the csv file before testing it. can someone tell me is that a
 issue
 or some kind of miss understand.

>>> The number of threads and the number of rows in a csv file don't have to
>>> be the same and in most cases (at least the ones I use) are not the same.
>>>
>>> CSV Data Set Config has a few options, that control its behaviour. Look
>>> at "Recycle on EOF?" and "Sharing mode".
>>>
>>> EOF stands for End Of File. If you check the option "Recycle on EOF?" the
>>> file will be read from start, if the end was reached.
>>> Sharing mode will control, whether each thread has its own pointer into
>>> the file, or all/some threads share a pointer into the file.
>>>
>>> Felix
>>>
>>>
>>>
 On Thu, Jul 20, 2017 at 1:13 PM, Harsha Gayan 
 wrote:

 Hello, i'm working with the JMeter issue ID 55840. i haven't clean idea
> about what XPathExtractor.java class does. so can someone help me to
> clear about that
>
> On Tue, Jul 18, 2017 at 12:18 PM, Harsha Gayan 
> wrote:
>
> Hello, i;m working with the JMeter Bug ID 61262. so, i read the those
>> kind of data (city and appid) from csv file and i test that using
>> weather
>> API site. so i tested but it didn't show me any kind of error. so can
>> someone describe what exactly the bug in there. thank you
>>
>>
>
>>>
>>

Re: YaMeter - Yet Another Load Testing Tool with more Cloud

[Emilian Bold]

I've published the binaries on http://yameter.com/

--emi


On Fri, Sep 15, 2017 at 2:09 AM, Emilian Bold <emilian.b...@gmail.com> wrote:
>> For "marketing" purpose, I would select more recent graphs for demos :)
>
> Maybe there is some nice "demo" JMeter project that showcases these
> cool new things?
>
>>> modular architecture,
>> +1 provided it's backward compatible
>
> In some regards it might be backwards compatible, but generally
> speaking some things must be deprecated in order to architect better
> (the global configuration files / singletons come to mind).
>
>>Note I tend to prefer completing each piece of work than starting lots of
> ideas at the same time. But that's only me :)
>
> The Plugin Portal works, I just need to integrate a few plugins for
> testing and see if they hook up properly.
>
> I could also use the Plugin Portal to deliver less important plugins
> like MongoDB...
>
>> I'll be happy to help on PR at jmeter github
>
> Not everything can be done incrementally in a PR.
>
> But there's plenty of other incremental changes that I need into
> JMeter that would also help the project itself (like Maven, etc).
>
> I'll start preparing more patches next month, this month I want to
> release YaMeter builds.
>
>> Anyway, thanks for all your innovations ! That's pretty refreshing
>
> This is not a proof of concept, it's all functioning stuff. Some more
> error recovery and detection might be needed but I'd say it's
> basically usable.
>
> --emi
>
>
> On Fri, Sep 15, 2017 at 1:06 AM, Philippe Mouawad
> <philippe.moua...@gmail.com> wrote:
>> On Wednesday, September 13, 2017, Emilian Bold <emilian.b...@gmail.com>
>> wrote:
>>
>>> >- I suppose you're embedding a JMeter right ?
>>>
>>> Yes, of course. Which was not easy because JMeter really expects to be
>>> running with full control of the VM.
>>>
>>> >   - why use this old "graph results" and not more modern elements or the
>>> >   web report ?
>>>
>>> No particular reason, I just picked something from the Add | Listener
>>> popup menu.
>>
>> For "marketing" purpose, I would select more recent graphs for demos :)
>> We must show people JMeter has evolved :)
>>
>>>
>>> >   - Any reason to limiting it to AWS ? why not use jcloud to make it more
>>> >   cloud agnostic ?
>>>
>>> To me AWS is the big one. I didn't want to use jCloud because I didn't
>>> want to have to think about how jCloud might map their concepts on top
>>> of the AWS concepts and debug jCloud instead of just debugging AWS's
>>> own SDK. In time it might make sense to code against a single API.
>>
>>
>> Is it that complex to start immediately with jcloud ?
>> I found their API pretty easy to map , at least for ypur requirement.
>>
>>>
>>> >   - You plan to share it on github ?
>>>
>>> In time, yes. Right now this is also a poll for load testing users' needs.
>>
>> okay
>>
>>>
>>> Besides the cloud integration, there are some other aspects the might
>>> be interesting for JMeter to pursue: multi-document,
>>
>> +0
>>
>>>
>>> modular
>>> architecture,
>>
>>
>> +1 provided it's backward compatible
>>
>>>  out-of-the-box plugin portal.
>>>
>>
>>>
>> +1000
>> I'll be happy to help on PR at jmeter github
>>
>> Note I tend to prefer completing each piece of work than starting lots of
>> ideas at the same time. But that's only me :)
>>
>>
>> Anyway, thanks for all your innovations ! That's pretty refreshing
>>
>> --emi
>>>
>>>
>>> On Tue, Sep 12, 2017 at 11:07 PM, Philippe Mouawad
>>> <philippe.moua...@gmail.com <javascript:;>> wrote:
>>> > Hello Emilian,
>>> > Very Interesting and nice for a prototype, few notes/questions:
>>> >
>>> >- I suppose you're embedding a JMeter right ?
>>> >- why use this old "graph results" and not more modern elements or the
>>> >web report ?
>>> >- Any reason to limiting it to AWS ? why not use jcloud to make it
>>> more
>>> >cloud agnostic ?
>>> >- You plan to share it on github ?
>>> >
>>> > Thanks for sharing
>>> >
>>> > Regards
>>> >
>>> > On Tue, Sep 12, 2017 at 10:02 AM, Emilian Bold <emilian.b...@gmail.com
>>> <javascript:;>>
>>> > wrote:
>>> >
>>> >> Here's a video with a working prototype of my Amazon EC2 integration for
>>> >> remote tests: https://vimeo.com/233443690
>>> >>
>>> >> --emi
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Cordialement.
>>> > Philippe Mouawad.
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.

Re: Remove "or later" words into "Requires Java 8 or later"

[Emilian Bold]

I believe "or later" is implied. So if it does not work with Java 9 it
should be said so expressly.

--emi


On Fri, Sep 22, 2017 at 9:59 PM, Philippe Mouawad
 wrote:
> yes, good catch
>
> On Friday, September 22, 2017, Milamber  wrote:
>
>> Hello,
>>
>> I thinks we need to remove the "or later" words from these pages because
>> JMeter (out of the box) won't start with Java 9
>>
>> Note: of course you can start JMeter 3.3 with Java 9 with some tweaks to
>> disable the check of Java version from launch scripts.
>>
>> Are you ok for I updated these pages?
>>
>> http://jmeter.apache.org/download_jmeter.cgi
>> https://www.apache.org/dist/jmeter/
>>
>> Milamber
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: YaMeter - Yet Another Load Testing Tool with more Cloud

[Emilian Bold]

> For "marketing" purpose, I would select more recent graphs for demos :)

Maybe there is some nice "demo" JMeter project that showcases these
cool new things?

>> modular architecture,
> +1 provided it's backward compatible

In some regards it might be backwards compatible, but generally
speaking some things must be deprecated in order to architect better
(the global configuration files / singletons come to mind).

>Note I tend to prefer completing each piece of work than starting lots of
ideas at the same time. But that's only me :)

The Plugin Portal works, I just need to integrate a few plugins for
testing and see if they hook up properly.

I could also use the Plugin Portal to deliver less important plugins
like MongoDB...

> I'll be happy to help on PR at jmeter github

Not everything can be done incrementally in a PR.

But there's plenty of other incremental changes that I need into
JMeter that would also help the project itself (like Maven, etc).

I'll start preparing more patches next month, this month I want to
release YaMeter builds.

> Anyway, thanks for all your innovations ! That's pretty refreshing

This is not a proof of concept, it's all functioning stuff. Some more
error recovery and detection might be needed but I'd say it's
basically usable.

--emi


On Fri, Sep 15, 2017 at 1:06 AM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> On Wednesday, September 13, 2017, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>> >- I suppose you're embedding a JMeter right ?
>>
>> Yes, of course. Which was not easy because JMeter really expects to be
>> running with full control of the VM.
>>
>> >   - why use this old "graph results" and not more modern elements or the
>> >   web report ?
>>
>> No particular reason, I just picked something from the Add | Listener
>> popup menu.
>
> For "marketing" purpose, I would select more recent graphs for demos :)
> We must show people JMeter has evolved :)
>
>>
>> >   - Any reason to limiting it to AWS ? why not use jcloud to make it more
>> >   cloud agnostic ?
>>
>> To me AWS is the big one. I didn't want to use jCloud because I didn't
>> want to have to think about how jCloud might map their concepts on top
>> of the AWS concepts and debug jCloud instead of just debugging AWS's
>> own SDK. In time it might make sense to code against a single API.
>
>
> Is it that complex to start immediately with jcloud ?
> I found their API pretty easy to map , at least for ypur requirement.
>
>>
>> >   - You plan to share it on github ?
>>
>> In time, yes. Right now this is also a poll for load testing users' needs.
>
> okay
>
>>
>> Besides the cloud integration, there are some other aspects the might
>> be interesting for JMeter to pursue: multi-document,
>
> +0
>
>>
>> modular
>> architecture,
>
>
> +1 provided it's backward compatible
>
>>  out-of-the-box plugin portal.
>>
>
>>
> +1000
> I'll be happy to help on PR at jmeter github
>
> Note I tend to prefer completing each piece of work than starting lots of
> ideas at the same time. But that's only me :)
>
>
> Anyway, thanks for all your innovations ! That's pretty refreshing
>
> --emi
>>
>>
>> On Tue, Sep 12, 2017 at 11:07 PM, Philippe Mouawad
>> <philippe.moua...@gmail.com <javascript:;>> wrote:
>> > Hello Emilian,
>> > Very Interesting and nice for a prototype, few notes/questions:
>> >
>> >- I suppose you're embedding a JMeter right ?
>> >- why use this old "graph results" and not more modern elements or the
>> >web report ?
>> >- Any reason to limiting it to AWS ? why not use jcloud to make it
>> more
>> >cloud agnostic ?
>> >- You plan to share it on github ?
>> >
>> > Thanks for sharing
>> >
>> > Regards
>> >
>> > On Tue, Sep 12, 2017 at 10:02 AM, Emilian Bold <emilian.b...@gmail.com
>> <javascript:;>>
>> > wrote:
>> >
>> >> Here's a video with a working prototype of my Amazon EC2 integration for
>> >> remote tests: https://vimeo.com/233443690
>> >>
>> >> --emi
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: YaMeter - Yet Another Load Testing Tool with more Cloud

[Emilian Bold]

> What do you mean by multi-document?

Having multiple test plans open at the same time, being able to edit /
run them independently.

--emi


On Wed, Sep 13, 2017 at 10:44 AM, Antonio Gomes Rodrigues
<ra0...@gmail.com> wrote:
> 2017-09-13 7:48 GMT+02:00 Emilian Bold <emilian.b...@gmail.com>:
>
>> >- I suppose you're embedding a JMeter right ?
>>
>> Yes, of course. Which was not easy because JMeter really expects to be
>> running with full control of the VM.
>>
>> >   - why use this old "graph results" and not more modern elements or the
>> >   web report ?
>>
>> No particular reason, I just picked something from the Add | Listener
>> popup menu.
>>
>> >   - Any reason to limiting it to AWS ? why not use jcloud to make it more
>> >   cloud agnostic ?
>>
>> To me AWS is the big one. I didn't want to use jCloud because I didn't
>> want to have to think about how jCloud might map their concepts on top
>> of the AWS concepts and debug jCloud instead of just debugging AWS's
>> own SDK. In time it might make sense to code against a single API.
>>
>> >   - You plan to share it on github ?
>>
>> In time, yes. Right now this is also a poll for load testing users' needs.
>>
>
> Great :-)
>
>
>>
>> Besides the cloud integration, there are some other aspects the might
>> be interesting for JMeter to pursue: multi-document,
>
> What do you mean by multi-document?
>
>
>> modular
>> architecture,
>
>
>
>> out-of-the-box plugin portal.
>>
> It will be great too
>
>
>>
>> --emi
>>
>>
>> On Tue, Sep 12, 2017 at 11:07 PM, Philippe Mouawad
>> <philippe.moua...@gmail.com> wrote:
>> > Hello Emilian,
>> > Very Interesting and nice for a prototype, few notes/questions:
>> >
>> >- I suppose you're embedding a JMeter right ?
>> >- why use this old "graph results" and not more modern elements or the
>> >web report ?
>> >- Any reason to limiting it to AWS ? why not use jcloud to make it
>> more
>> >cloud agnostic ?
>> >- You plan to share it on github ?
>> >
>> > Thanks for sharing
>> >
>> > Regards
>> >
>> > On Tue, Sep 12, 2017 at 10:02 AM, Emilian Bold <emilian.b...@gmail.com>
>> > wrote:
>> >
>> >> Here's a video with a working prototype of my Amazon EC2 integration for
>> >> remote tests: https://vimeo.com/233443690
>> >>
>> >> --emi
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>

Re: YaMeter - Yet Another Load Testing Tool with more Cloud

[Emilian Bold]

>- I suppose you're embedding a JMeter right ?

Yes, of course. Which was not easy because JMeter really expects to be
running with full control of the VM.

>   - why use this old "graph results" and not more modern elements or the
>   web report ?

No particular reason, I just picked something from the Add | Listener
popup menu.

>   - Any reason to limiting it to AWS ? why not use jcloud to make it more
>   cloud agnostic ?

To me AWS is the big one. I didn't want to use jCloud because I didn't
want to have to think about how jCloud might map their concepts on top
of the AWS concepts and debug jCloud instead of just debugging AWS's
own SDK. In time it might make sense to code against a single API.

>   - You plan to share it on github ?

In time, yes. Right now this is also a poll for load testing users' needs.

Besides the cloud integration, there are some other aspects the might
be interesting for JMeter to pursue: multi-document, modular
architecture, out-of-the-box plugin portal.

--emi


On Tue, Sep 12, 2017 at 11:07 PM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Hello Emilian,
> Very Interesting and nice for a prototype, few notes/questions:
>
>- I suppose you're embedding a JMeter right ?
>- why use this old "graph results" and not more modern elements or the
>web report ?
>- Any reason to limiting it to AWS ? why not use jcloud to make it more
>cloud agnostic ?
>- You plan to share it on github ?
>
> Thanks for sharing
>
> Regards
>
> On Tue, Sep 12, 2017 at 10:02 AM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>> Here's a video with a working prototype of my Amazon EC2 integration for
>> remote tests: https://vimeo.com/233443690
>>
>> --emi
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

YaMeter - Yet Another Load Testing Tool with more Cloud

[Emilian Bold]

Here's a video with a working prototype of my Amazon EC2 integration for
remote tests: https://vimeo.com/233443690

--emi

Re: [GitHub] jmeter issue #306: Fix to BUG_60156

[Emilian Bold]

Looks much better now.

--emi

Pe 8 sept. 2017, la 12:04, UBIK LOAD PACK Support <supp...@ubikloadpack.com> a 
scris:

> Hello Emilian,
> There was indeed one last issue in TCPClientImpl with backward
> compatibility, we pushed a commit
> It should be ok now, but please review (
> https://github.com/apache/jmeter/pull/306/files):
> 
>   - If AbstractTCPClient implement the old method they will work
>   - If AbstractTCPClient implement the new  method, they will of course
>   work
>   - If 3rd party code calls the old method, they should also work
> 
> 
> Regards
> 
> @ubikloadpack Team
>> On Fri, Sep 8, 2017 at 6:31 AM, Emilian Bold <emilian.b...@gmail.com> wrote:
>> 
>> It is backwards compatible as an SPI, meaning that 3rd party
>> implementations that use AbstractTCPClient will still work if they
>> implement only the old method.
>> 
>> But it is not backwards compatible as an API because 3rd party code that
>> calls the old method will now receive nulls for those existing
>> implementations.
>> 
>> So the question is if this is supposed to be an API or it's just an SPI.
>> 
>> --emi
>> 
>> On Fri, Sep 8, 2017 at 12:03 AM, Philippe Mouawad <
>> philippe.moua...@gmail.com> wrote:
>> 
>>> Hi Emilian
>>> AFAIU, it is backward compatible no ?
>>> 
>>> in AbstractTCPClient.java
>>> <https://github.com/apache/jmeter/pull/306/files#diff-37500f
>>> a9c4a5285efe7b85e9bcd62614>,
>>> the new method calls the old one.
>>> 
>>> Only the subclasses has been modified to implement the new one.
>>> 
>>> Thanks for reviewing
>>> 
>>> On Thu, Sep 7, 2017 at 10:58 PM, Emilian Bold <emilian.b...@gmail.com>
>>> wrote:
>>> 
>>>> I don't know the codebase but why bother marking the old method as
>>>> @Deprecated if you are not making the change backwards compatible?
>>>> 
>>>> I see 'return null' in two existing methods while previously those
>>> methods
>>>> returned something.
>>>> 
>>>> A proper pattern would have been to call read(is, null) or read(is, new
>>>> DummySampleResult()).
>>>> 
>>>> 
>>>> --emi
>>>> 
>>>>> On Thu, Sep 7, 2017 at 11:25 PM, pmouawad <g...@git.apache.org> wrote:
>>>>> 
>>>>> Github user pmouawad commented on the issue:
>>>>> 
>>>>>https://github.com/apache/jmeter/pull/306
>>>>> 
>>>>>Hello
>>>>>Unless there is a NO GO , I'll commit this tomorrow.
>>>>> 
>>>>>Thanks
>>>>> 
>>>>> 
>>>>> ---
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Cordialement.
>>> Philippe Mouawad.
>>> 
>> 

Re: [GitHub] jmeter issue #306: Fix to BUG_60156

[Emilian Bold]

It is backwards compatible as an SPI, meaning that 3rd party
implementations that use AbstractTCPClient will still work if they
implement only the old method.

But it is not backwards compatible as an API because 3rd party code that
calls the old method will now receive nulls for those existing
implementations.

So the question is if this is supposed to be an API or it's just an SPI.

--emi

On Fri, Sep 8, 2017 at 12:03 AM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hi Emilian
> AFAIU, it is backward compatible no ?
>
> in AbstractTCPClient.java
> <https://github.com/apache/jmeter/pull/306/files#diff-37500f
> a9c4a5285efe7b85e9bcd62614>,
> the new method calls the old one.
>
> Only the subclasses has been modified to implement the new one.
>
> Thanks for reviewing
>
> On Thu, Sep 7, 2017 at 10:58 PM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
> > I don't know the codebase but why bother marking the old method as
> > @Deprecated if you are not making the change backwards compatible?
> >
> > I see 'return null' in two existing methods while previously those
> methods
> > returned something.
> >
> > A proper pattern would have been to call read(is, null) or read(is, new
> > DummySampleResult()).
> >
> >
> > --emi
> >
> > On Thu, Sep 7, 2017 at 11:25 PM, pmouawad <g...@git.apache.org> wrote:
> >
> > > Github user pmouawad commented on the issue:
> > >
> > > https://github.com/apache/jmeter/pull/306
> > >
> > > Hello
> > > Unless there is a NO GO , I'll commit this tomorrow.
> > >
> > > Thanks
> > >
> > >
> > > ---
> > >
> >
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

Re: [GitHub] jmeter issue #306: Fix to BUG_60156

[Emilian Bold]

I don't know the codebase but why bother marking the old method as
@Deprecated if you are not making the change backwards compatible?

I see 'return null' in two existing methods while previously those methods
returned something.

A proper pattern would have been to call read(is, null) or read(is, new
DummySampleResult()).


--emi

On Thu, Sep 7, 2017 at 11:25 PM, pmouawad  wrote:

> Github user pmouawad commented on the issue:
>
> https://github.com/apache/jmeter/pull/306
>
> Hello
> Unless there is a NO GO , I'll commit this tomorrow.
>
> Thanks
>
>
> ---
>

Re: [apache/jmeter] Mavenization (#299)

[Emilian Bold]

I removed my repository from GitHub and it left the PR in an odd state.

I will re-do the PR from another repository after the 3.3 release.


--emi

On Sun, Sep 3, 2017 at 6:30 PM, Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:

> Hi Emilian,
> Is there a reason for closing this PR ?
>
> We are interested to merge it, but just waiting for 3.3 release.
>
> Thanks
> Regards
>
> On Sat, Sep 2, 2017 at 1:05 PM, Emilian Bold <notificati...@github.com>
> wrote:
>
>> Closed #299 <https://github.com/apache/jmeter/pull/299>.
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/apache/jmeter/pull/299#event-1232304962>, or mute
>> the thread
>> <https://github.com/notifications/unsubscribe-auth/AC-4q38QbEfeZimbvuYpHnHNcCXeSkr5ks5seTaIgaJpZM4OZa2O>
>> .
>>
>
>
>
> --
> Cordialement.
> Philippe
>

Re: Is there a high level explanation of the JMeter remote execute architecture?

[Emilian Bold]

> Yes, but the main issue is not serialization from client to server on test 
> start, but the reverse side

Still, why is the MainFrame added to the test tree? All I could think
of is you need the TestStateListener which the MainFrame implements.

Do you need any Swing components on the slave side?

> But I think there should be better protocols than RMI now

Ideally something that needs a single standard port open (443 / HTTPS)
on the slave.

What kind of effort would such a migration imply?

--emi


On Wed, Aug 30, 2017 at 11:51 AM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Hi Emilian,
> My answers inline.
>
> Regards
>
> On Wednesday, August 30, 2017, Emilian Bold <emilian.b...@gmail.com> wrote:
>
>> Hello,
>>
>> I am looking at two aspects in the JMeter codebase: RMI and serialization.
>>
>> I don't believe I've ran into a document explaining the architecture
>> here, only documents explaining how to configure JMeter as an user.
>>
>> So, about RMI, the way I see it you have two "channels":
>>
>> * a control channel where the master starts/stops/provisions the slaves and
>> * a results channel where result data is streamed back (which is also
>> the most bandwidth intensive)
>
>
> Correct understanding
>
>>
>> Is this correct? What other communications happen between the master and
>> slave?
>
>
> None I think about
>
>>
>> Regarding serialization: why is so much serialized?
>>
>> I saw this line in RemoteStart
>>
>> > testTree.add(testTree.getArray()[0], gui.getMainFrame());
>>
>> and it makes no sense to me to serialize the main frame itself. Maybe
>> this is just done because MainFrame implements TestStateListener so
>> you actually just want to provide a TestStateListener?
>
>
> Yes, but the main issue is not serialization from client to server on test
> start, but the reverse side
>
>>
>> I understand why you would send the model but why the whole GUI?
>
>
> Historical
>
>>
>> I feel there is some historic and architectural info I am missing
>> here. Where is the API boundary between the GUI, the model and the
>> engine?
>
>
> Should be created.
> But I think there should be better protocols than RMI now
>
>>
>> --emi
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Is there a high level explanation of the JMeter remote execute architecture?

[Emilian Bold]

Hello,

I am looking at two aspects in the JMeter codebase: RMI and serialization.

I don't believe I've ran into a document explaining the architecture
here, only documents explaining how to configure JMeter as an user.

So, about RMI, the way I see it you have two "channels":

* a control channel where the master starts/stops/provisions the slaves and
* a results channel where result data is streamed back (which is also
the most bandwidth intensive)

Is this correct? What other communications happen between the master and slave?

Regarding serialization: why is so much serialized?

I saw this line in RemoteStart

> testTree.add(testTree.getArray()[0], gui.getMainFrame());

and it makes no sense to me to serialize the main frame itself. Maybe
this is just done because MainFrame implements TestStateListener so
you actually just want to provide a TestStateListener?

I understand why you would send the model but why the whole GUI?

I feel there is some historic and architectural info I am missing
here. Where is the API boundary between the GUI, the model and the
engine?

--emi

Re: [JMETER iISSUE #53277]

[Emilian Bold]

I believe it would be better if you would explain instead what are you
trying to accomplish.

Why did you pick #53277 and how do you plan on approaching it?

--emi


On Thu, Jul 27, 2017 at 11:41 AM, Mareena Fernando
<mareena@gmail.com> wrote:
> Hello Emilian,
>
> Could you explain more about logger [1] . It's not much clear what you have
> said in the previous mail.]
>
> Thank you.
>
> On Tue, Jul 25, 2017 at 11:06 AM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>> By logging I meant use the logger [1] to save potential situations
>> where different items that are actually equal are replaced. How you
>> detect such a situation would be interesting to figure out.
>>
>> 1. https://docs.oracle.com/javase/7/docs/api/java/util/
>> logging/Logger.html#info(java.lang.String)
>>
>> PS: Don't start new email threads to continue a discussion. If you
>> reply to the last email in the previous thread they will all stay
>> grouped. I see you have 3 threads started for #53277.
>>
>> --emi
>>
>>
>> On Mon, Jul 24, 2017 at 9:27 PM, Mareena Fernando <mareena@gmail.com>
>> wrote:
>> > Hello Emilian,
>> >
>> > As you told me to logging to detect the situation, I try to do it. There
>> > was no separate option as 'Login'. So but I did was, I just entered the
>> > 'name' and the 'value' and then clicked the 'add' button. And again I
>> added
>> > the same name and same value, But there was no replacement. Is this the
>> > thing what you meant by logging?
>> >
>> > Thank you.
>>

Better JMeter remote testing on Amazon EC2

[Emilian Bold]

Hello,

JMeter remote testing is interesting but seems to require a lot of
manual fiddling to deploy to Amazon EC2.

I wonder if users would be interested in some simpler interface for
Amazon EC2 where you just give your credentials, the test you want to
run, the EC2 regions / machine type and it automatically starts and
runs everything behind the scenes?

--emi

Re: [JMETER iISSUE #53277]

[Emilian Bold]

By logging I meant use the logger [1] to save potential situations
where different items that are actually equal are replaced. How you
detect such a situation would be interesting to figure out.

1. 
https://docs.oracle.com/javase/7/docs/api/java/util/logging/Logger.html#info(java.lang.String)

PS: Don't start new email threads to continue a discussion. If you
reply to the last email in the previous thread they will all stay
grouped. I see you have 3 threads started for #53277.

--emi


On Mon, Jul 24, 2017 at 9:27 PM, Mareena Fernando  wrote:
> Hello Emilian,
>
> As you told me to logging to detect the situation, I try to do it. There
> was no separate option as 'Login'. So but I did was, I just entered the
> 'name' and the 'value' and then clicked the 'add' button. And again I added
> the same name and same value, But there was no replacement. Is this the
> thing what you meant by logging?
>
> Thank you.

Re: Opportunities for cohesion improvement and refatoring.

[Emilian Bold]

You might as well create a GitHub pull request for each of these so
it's more simple to see how the code would look like with your
suggestion.

Although, personally, I wouldn't refactor just for synthetic reasons.

--emi


On Sun, Jul 23, 2017 at 5:50 PM, João Paulo Lemes Machado
 wrote:
> Hello everyone.
>
> My name is João Paulo, I am a graduate student the Federal University of
> Uberlandia, Brazil.
>
> I was analyzing the modularization of some classes of JMeter, and  I
> identified some opportunities for cohesion improvement in the following
> classes:
>
> SampleSaveConfiguration
> JMeterUtils
> SampleResult
>
>
> Could you please take a look and tell me if it's viable?
>
> Maybe some of these classes could benefit from some kind of refactoring
> that we can discuss.
>
> I created the following issues for each class:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61309
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61308
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61306

JMeter GUI Undo/Redo

[Emilian Bold]

Hello,

See my undo/redo commits
https://github.com/emilianbold/jmeter/commits/emilianbold-undoredo

The 1st commit [1] fixes #57039 -- it was a matter of sharing internal
data and then editing that in the UI.

The other commit [2] rewrites part of UndoHistory using the standard
javax.swing.undo classes and also introduces the concept of an 'undo
transaction'.

This is needed to group multiple changes like the node changes after
"Search for a node by name".

The are probably many other places that need some
beginUndoTransaction/endUndoTransaction pairs, I've only added a few.

Also, we probably need a way to temporarily disable UndoHistory, for
example during loading. I haven't tested this, so please confirm if
loading large files has a big impact with undo enabled.

Some low hanging fruit exists for compound edits where we could
merge/swallow edits.

1. 
https://github.com/emilianbold/jmeter/commit/ea9859995d1fb53905b720bc57a1ddf283b29ce8
2. 
https://github.com/emilianbold/jmeter/commit/401221e9f6e480e43fcf51ee99458a0d7fdd661d

--emi

Re: Replacing ClassFinder with ServiceLoader

[Emilian Bold]

BTW: here is an example code with ServiceLoader in the JMeter codebase
https://github.com/emilianbold/jmeter/commit/4bc26448e8c301b2af11f6629da93081abcb9935

What I'm trying is separate the hard dependency on NewDriver which
lives in the separate launcher JAR.

I'm introducing for that two new services (well, singletons,
actually): Places and ClassPath.

They are registered in META-INF/services.

And the launcher has the implementations of these services which
provide a bridge towards NewDriver.


--emi


On Thu, Jul 20, 2017 at 10:45 PM, Emilian Bold <emilian.b...@gmail.com> wrote:
>>  - Another critical part is to make it as easy as today to register a
>>   plugin which is IMO one of the major reasons for JMeter success.
>
> Do you mean easy to register a plugin in the UI or easy to develop a plugin?
>
>>   - The backward compatibility with 3rd party plugins is a critical part.
>>   IMO, no change should be made before validating new proposal will work with
>>   most popular existing 3rd plugins.
>
> I can imagine a scenario where old plugin JARs are inspected with the
> current ClassFinder while for everything else we use ServiceLoader.
>
> The idea being that the old style is deprecated and will be removed in
> time. But we shouldn't use ClassFinder at all in JMeter internal code.
>
>> Can you clarify:
>> => "The only downside is we have to think about older external JARs that
>> expect the current behaviour. We could use some flag (in MANIFEST perhaps?)
>> to differentiate between them."
>
> It would help to know if a plugin uses the ServiceLoader or not. One
> trivial check would be to verify for the presence of
> META-INF/services/. Another would be to invent a manifest flag,
> perhaps "X-JMeter-API-level: 4" in the MANIFEST.MF
>
> Markings in the GUI and showing warnings about plugins that don't keep
> up with API changes would also be a good way to encourage them being
> up to update.
>
>> => "many calls of ClassFinder do some filtering, excluding some
>> implementations. This would be simple by just not registering those
>> implementations as a service."
>
> ClassFinder calls usually include the "String notContains" filter.
> Which is an odd way because callers shouldn't care what they get
> except in very specific situations. If a "service" is registered
> globally it will be there.
>
> I assume filtering happens because you need some implementations
> (like, a GUI Command) but there's no way to differentiate right now if
> that implementation is for global public consumption or not. Is should
> be generally up to the implementation class to declare itself a
> service and not for the calling class to filter (because then, every
> new subclass needs a decision about being filtered or not).
>
> Also note that the Lookup API handles this global / labeled separation
> with "named" lookups inside META-INF/namedservices/ [1]. This would
> allow one to write
> Lookups.forPath("GUI/Main/Menu").lookupAll(Command.class) and
> Lookups.forPath("GUI/Report/Menu").lookupAll(Command.class) and get
> the commands instances separately. But this is an advanced situation
> -- seems to me JMeter never uses the filtered classes in some other
> case, so it's just a way of 'hiding' them.
>
> 1. 
> http://bits.netbeans.org/8.0/javadoc/org-openide-util-lookup/org/openide/util/lookup/Lookups.html#forPath(java.lang.String)
>
> --emi
>
>
> On Thu, Jul 20, 2017 at 10:20 PM, Philippe Mouawad
> <philippe.moua...@gmail.com> wrote:
>> Hello Emilian,
>> Thanks for your analysis , and new ideas !
>>
>> Can you clarify:
>> => "The only downside is we have to think about older external JARs that
>> expect the current behaviour. We could use some flag (in MANIFEST perhaps?)
>> to differentiate between them."
>>
>> => "many calls of ClassFinder do some filtering, excluding some
>> implementations. This would be simple by just not registering those
>> implementations as a service."
>>
>> My 2 cents with current (partial ?) understanding of your proposal:
>>
>>- The backward compatibility with 3rd party plugins is a critical part.
>>IMO, no change should be made before validating new proposal will work 
>> with
>>most popular existing 3rd plugins.
>>- Another critical part is to make it as easy as today to register a
>>plugin which is IMO one of the major reasons for JMeter success.
>>
>>
>> Thanks
>>
>>
>> On Wed, Jul 19, 2017 at 2:16 AM, Emilian Bold <emilian.b...@gmail.com>
>> wrote:
>>
>>> H

Re: MongoDB driver

[Emilian Bold]

I would vote to remove it entirely then from the codebase. A 3rd party
plugin could be created if people need it.

Do you want me to submit a patch?

--emi


On Thu, Jul 20, 2017 at 10:15 PM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Hello,
> The decision to deprecate was motivated by many reasons:
>
>- Very low feedback both on SO, bugzilla and user mailing list
>- No mention at all from MongoDB which seems to have its own tool
>- The effort to upgrade (lot of deprecations) + the fact that an async
>driver was released and that might be a better choice
>- The fact that we need to make choices based on priorities :-) JDBC
>sampler addresses many DB, MongoDB addresses 1 Product. I think it was a
>mistake to add it (my mistake :-) )
>
> Regards
>
> On Wed, Jul 19, 2017 at 6:19 PM, John Schulz <john_sch...@aol.com> wrote:
>
>> When the decision was made to deprecate no one was volunteering to update
>> it. If we have volunteers then the volunteer(s) can update the driver.
>> Mongo becomes undeprecated.
>>
>> Sent from my iPhone
>>
>> > On Jul 19, 2017, at 10:02 AM, Antonio Gomes Rodrigues <ra0...@gmail.com>
>> wrote:
>> >
>> > Issues, question in stackoverflow...
>> >
>> > 2017-07-19 16:00 GMT+02:00 Emilian Bold <emilian.b...@gmail.com>:
>> >
>> >> Out of curiosity, how do you measure usage? Based on issues opened?
>> >>
>> >> --emi
>> >>
>> >>
>> >> On Wed, Jul 19, 2017 at 3:19 PM, Antonio Gomes Rodrigues
>> >> <ra0...@gmail.com> wrote:
>> >>> Hi,
>> >>>
>> >>> If I remember it's because we have few time to update it and because
>> it's
>> >>> not very used
>> >>>
>> >>> Antonio
>> >>>
>> >>> 2017-07-19 14:15 GMT+02:00 Emilian Bold <emilian.b...@gmail.com>:
>> >>>
>> >>>> I don't know why the MongoDB protocol got deprecated, but the next
>> >>>> step would be removal of the classes not updating libraries.
>> >>>>
>> >>>> --emi
>> >>>>
>> >>>>
>> >>>> On Wed, Jul 19, 2017 at 12:55 PM, Maxime Chassagneux
>> >>>> <mchassagn...@apache.org> wrote:
>> >>>>> Hi,
>> >>>>>
>> >>>>> The JMeter bundle still include a mongoDB java driver ( version
>> >> 2.11.3 )
>> >>>>> which is really old and doesn't work with all authentication
>> >>>>>
>> >>>>> By example :
>> >>>>>
>> >>>>> javax.script.ScriptException: java.lang.IllegalArgumentException:
>> >>>>> Unsupported authMechanism: SCRAM-SHA-1
>> >>>>>
>> >>>>>
>> >>>>> As mongoDB is deprecated in JMeter, my question is : Should we keep
>> >> this
>> >>>>> librairie or update it to the lastest version ?
>> >>>>>
>> >>>>> Thanks for ur feedback.
>> >>>>
>> >>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Replacing ClassFinder with ServiceLoader

[Emilian Bold]

>  - Another critical part is to make it as easy as today to register a
>   plugin which is IMO one of the major reasons for JMeter success.

Do you mean easy to register a plugin in the UI or easy to develop a plugin?

>   - The backward compatibility with 3rd party plugins is a critical part.
>   IMO, no change should be made before validating new proposal will work with
>   most popular existing 3rd plugins.

I can imagine a scenario where old plugin JARs are inspected with the
current ClassFinder while for everything else we use ServiceLoader.

The idea being that the old style is deprecated and will be removed in
time. But we shouldn't use ClassFinder at all in JMeter internal code.

> Can you clarify:
> => "The only downside is we have to think about older external JARs that
> expect the current behaviour. We could use some flag (in MANIFEST perhaps?)
> to differentiate between them."

It would help to know if a plugin uses the ServiceLoader or not. One
trivial check would be to verify for the presence of
META-INF/services/. Another would be to invent a manifest flag,
perhaps "X-JMeter-API-level: 4" in the MANIFEST.MF

Markings in the GUI and showing warnings about plugins that don't keep
up with API changes would also be a good way to encourage them being
up to update.

> => "many calls of ClassFinder do some filtering, excluding some
> implementations. This would be simple by just not registering those
> implementations as a service."

ClassFinder calls usually include the "String notContains" filter.
Which is an odd way because callers shouldn't care what they get
except in very specific situations. If a "service" is registered
globally it will be there.

I assume filtering happens because you need some implementations
(like, a GUI Command) but there's no way to differentiate right now if
that implementation is for global public consumption or not. Is should
be generally up to the implementation class to declare itself a
service and not for the calling class to filter (because then, every
new subclass needs a decision about being filtered or not).

Also note that the Lookup API handles this global / labeled separation
with "named" lookups inside META-INF/namedservices/ [1]. This would
allow one to write
Lookups.forPath("GUI/Main/Menu").lookupAll(Command.class) and
Lookups.forPath("GUI/Report/Menu").lookupAll(Command.class) and get
the commands instances separately. But this is an advanced situation
-- seems to me JMeter never uses the filtered classes in some other
case, so it's just a way of 'hiding' them.

1. 
http://bits.netbeans.org/8.0/javadoc/org-openide-util-lookup/org/openide/util/lookup/Lookups.html#forPath(java.lang.String)

--emi


On Thu, Jul 20, 2017 at 10:20 PM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Hello Emilian,
> Thanks for your analysis , and new ideas !
>
> Can you clarify:
> => "The only downside is we have to think about older external JARs that
> expect the current behaviour. We could use some flag (in MANIFEST perhaps?)
> to differentiate between them."
>
> => "many calls of ClassFinder do some filtering, excluding some
> implementations. This would be simple by just not registering those
> implementations as a service."
>
> My 2 cents with current (partial ?) understanding of your proposal:
>
>- The backward compatibility with 3rd party plugins is a critical part.
>IMO, no change should be made before validating new proposal will work with
>most popular existing 3rd plugins.
>- Another critical part is to make it as easy as today to register a
>plugin which is IMO one of the major reasons for JMeter success.
>
>
> Thanks
>
>
> On Wed, Jul 19, 2017 at 2:16 AM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>> Hello,
>>
>> I noticed ClassFinder while tweaking ActionRouter and I believe it should
>> be replace with a proper service declaration and loading.
>>
>> I'm a fan of the Lookup API (see [1] [2]) which is a small standalone JAR
>> used a lot in NetBeans.
>>
>> The standard ServiceLoader [3] would also be a better replacement.
>>
>> Some remarks:
>>
>> * ClassFinder is almost always called with JMeterUtils.getSearchPaths().
>> This must be expected to be the class path actually.
>> * many calls of ClassFinder do some filtering, excluding some
>> implementations. This would be simple by just not registering those
>> implementations as a service.
>>
>> With the ServiceLoader, ActionRouter would load commands with something
>> like:
>>
>> > ServiceLoader commands = ServiceLoader.load(Command.class);
>>
>> An each command will have to be registered in MET

JMeter priorities [WAS: Re: JMeter project analytics]

[Emilian Bold]

> http2 support

I believe somebody already is working on this and we are waiting for
HttpComponents HttpClient 5.

> - fix on undo/redo . With your experience of Netbeans , would you have an 
> idea for that missing and always requested feature

Undo/redo is a lot about the underlying data model too, not just the
UI. If state propagates in unknown ways undo/redo becomes tricky.

> - fix caching of resources in already cached resources

What is this about?

--emi


On Thu, Jul 20, 2017 at 8:53 AM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Hello Emilian,
> In the past it was possible through Apache to know number of downloads.
> With mirrors it appears we lost this precious (IMO) info.
>
> What you propose is a good idea but there are many issues:
> - privacy if we use something like GA
> - all users behind enterprise proxies or with a bad network
> - plus amount of work
>
> For now we use:
> - number of issues reported
> - questions on SO and mailing lists
>
> IMO, we should concentrate our efforts on:
> - http2 support
> - fix on undo/redo . With your experience of Netbeans , would you have an
> idea for that missing and always requested feature
> - fix caching of resources in already cached resources
>
> Thanks for your recent works !
> Regards
>
> On Thursday, July 20, 2017, Emilian Bold <emilian.b...@gmail.com> wrote:
>
>> Hello,
>>
>> I was wondering about how many users / downloads does JMeter have and
>> I couldn't find such information except indirectly via the usage
>> statistics from http://www.jmeter-plugins.org/stats/
>>
>> Just yesterday we were discussing about MongoDB support which is
>> deprecated since it's not used very much but usage is measured
>> indirectly from support questions.
>>
>> Are there any other sources of such info?
>>
>> I believe it would be healthy for JMeter to actively measure such
>> usage info in order to better decide the future.
>>
>> A while back NetBeans measured anonymously various metrics in order to
>> prioritise work. Information such as this
>> http://statistics.netbeans.org/analytics/graph/projecttypes.jsp and
>> this http://statistics.netbeans.org/analytics/graph/databaseservers.jsp
>> and this http://statistics.netbeans.org/analytics/graph/technologies.jsp
>> help determine which plugin deserves extra attention and which is
>> heading towards deprecation.
>>
>> So, we should think about how we could implement something like this
>> while respecting the Apache rules surrounding user data.
>>
>> --emi
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: JMeter project analytics

[Emilian Bold]

I wouldn't discard this because it needs work. There must be some way
to get some data and still preserve privacy (see Apple's Differential
Privacy and Google's RAPPOR[1] paper).

1. 
http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42852.pdf

--emi


On Thu, Jul 20, 2017 at 8:53 AM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Hello Emilian,
> In the past it was possible through Apache to know number of downloads.
> With mirrors it appears we lost this precious (IMO) info.
>
> What you propose is a good idea but there are many issues:
> - privacy if we use something like GA
> - all users behind enterprise proxies or with a bad network
> - plus amount of work
>
> For now we use:
> - number of issues reported
> - questions on SO and mailing lists
>
> IMO, we should concentrate our efforts on:
> - http2 support
> - fix on undo/redo . With your experience of Netbeans , would you have an
> idea for that missing and always requested feature
> - fix caching of resources in already cached resources
>
> Thanks for your recent works !
> Regards
>
> On Thursday, July 20, 2017, Emilian Bold <emilian.b...@gmail.com> wrote:
>
>> Hello,
>>
>> I was wondering about how many users / downloads does JMeter have and
>> I couldn't find such information except indirectly via the usage
>> statistics from http://www.jmeter-plugins.org/stats/
>>
>> Just yesterday we were discussing about MongoDB support which is
>> deprecated since it's not used very much but usage is measured
>> indirectly from support questions.
>>
>> Are there any other sources of such info?
>>
>> I believe it would be healthy for JMeter to actively measure such
>> usage info in order to better decide the future.
>>
>> A while back NetBeans measured anonymously various metrics in order to
>> prioritise work. Information such as this
>> http://statistics.netbeans.org/analytics/graph/projecttypes.jsp and
>> this http://statistics.netbeans.org/analytics/graph/databaseservers.jsp
>> and this http://statistics.netbeans.org/analytics/graph/technologies.jsp
>> help determine which plugin deserves extra attention and which is
>> heading towards deprecation.
>>
>> So, we should think about how we could implement something like this
>> while respecting the Apache rules surrounding user data.
>>
>> --emi
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

JMeter project analytics

[Emilian Bold]

Hello,

I was wondering about how many users / downloads does JMeter have and
I couldn't find such information except indirectly via the usage
statistics from http://www.jmeter-plugins.org/stats/

Just yesterday we were discussing about MongoDB support which is
deprecated since it's not used very much but usage is measured
indirectly from support questions.

Are there any other sources of such info?

I believe it would be healthy for JMeter to actively measure such
usage info in order to better decide the future.

A while back NetBeans measured anonymously various metrics in order to
prioritise work. Information such as this
http://statistics.netbeans.org/analytics/graph/projecttypes.jsp and
this http://statistics.netbeans.org/analytics/graph/databaseservers.jsp
and this http://statistics.netbeans.org/analytics/graph/technologies.jsp
help determine which plugin deserves extra attention and which is
heading towards deprecation.

So, we should think about how we could implement something like this
while respecting the Apache rules surrounding user data.

--emi

Re: MongoDB driver

[Emilian Bold]

Out of curiosity, how do you measure usage? Based on issues opened?

--emi


On Wed, Jul 19, 2017 at 3:19 PM, Antonio Gomes Rodrigues
<ra0...@gmail.com> wrote:
> Hi,
>
> If I remember it's because we have few time to update it and because it's
> not very used
>
> Antonio
>
> 2017-07-19 14:15 GMT+02:00 Emilian Bold <emilian.b...@gmail.com>:
>
>> I don't know why the MongoDB protocol got deprecated, but the next
>> step would be removal of the classes not updating libraries.
>>
>> --emi
>>
>>
>> On Wed, Jul 19, 2017 at 12:55 PM, Maxime Chassagneux
>> <mchassagn...@apache.org> wrote:
>> > Hi,
>> >
>> > The JMeter bundle still include a mongoDB java driver ( version 2.11.3 )
>> > which is really old and doesn't work with all authentication
>> >
>> > By example :
>> >
>> > javax.script.ScriptException: java.lang.IllegalArgumentException:
>> > Unsupported authMechanism: SCRAM-SHA-1
>> >
>> >
>> > As mongoDB is deprecated in JMeter, my question is : Should we keep this
>> > librairie or update it to the lastest version ?
>> >
>> > Thanks for ur feedback.
>>

Re: MongoDB driver

[Emilian Bold]

I don't know why the MongoDB protocol got deprecated, but the next
step would be removal of the classes not updating libraries.

--emi


On Wed, Jul 19, 2017 at 12:55 PM, Maxime Chassagneux
 wrote:
> Hi,
>
> The JMeter bundle still include a mongoDB java driver ( version 2.11.3 )
> which is really old and doesn't work with all authentication
>
> By example :
>
> javax.script.ScriptException: java.lang.IllegalArgumentException:
> Unsupported authMechanism: SCRAM-SHA-1
>
>
> As mongoDB is deprecated in JMeter, my question is : Should we keep this
> librairie or update it to the lastest version ?
>
> Thanks for ur feedback.

Replacing ClassFinder with ServiceLoader

[Emilian Bold]

Hello,

I noticed ClassFinder while tweaking ActionRouter and I believe it should
be replace with a proper service declaration and loading.

I'm a fan of the Lookup API (see [1] [2]) which is a small standalone JAR
used a lot in NetBeans.

The standard ServiceLoader [3] would also be a better replacement.

Some remarks:

* ClassFinder is almost always called with JMeterUtils.getSearchPaths().
This must be expected to be the class path actually.
* many calls of ClassFinder do some filtering, excluding some
implementations. This would be simple by just not registering those
implementations as a service.

With the ServiceLoader, ActionRouter would load commands with something
like:

> ServiceLoader commands = ServiceLoader.load(Command.class);

An each command will have to be registered in META-INF/services (for Java
8) or in the module declaration (for Java 9).

In NetBeans we have an annotation @ServiceProvider [4] which is simpler and
behind the scenes the build system generates at build time the
META-INF/services registration file.

Note that service registration and loading would work the same for 3rd
party JARs.

The only downside is we have to think about older external JARs that expect
the current behaviour. We could use some flag (in MANIFEST perhaps?) to
differentiate between them.

1.
http://bits.netbeans.org/8.0/javadoc/org-openide-util-lookup/org/openide/util/Lookup.html
2.
http://bits.netbeans.org/8.0/javadoc/org-openide-util-lookup/org/openide/util/lookup/doc-files/lookup-api.html
3. http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html
4.
http://bits.netbeans.org/8.0/javadoc/org-openide-util-lookup/org/openide/util/lookup/ServiceProvider.html

--emi

Re: JMeter Bug ID 61262

[Emilian Bold]

You could start by submitting a test case on the issue tracker.

The bug seems to be in __StringFromFile but perhaps it's just a matter
of the documentation being unclear?

--emi


On Tue, Jul 18, 2017 at 9:48 AM, Harsha Gayan  wrote:
> Hello, i;m working with the JMeter Bug ID 61262. so, i read the those kind
> of data (city and appid) from csv file and i test that using weather API
> site. so i tested but it didn't show me any kind of error. so can someone
> describe what exactly the bug in there. thank you

Re: [JMETER ISSUE #53277]

[Emilian Bold]

Like I've said in the 1st email:

> The problems doesn't seem to be with HashTree per-se but with the bad 
> architecture of the calling code which adds "equal" elements.

Maybe some logging would help to detect these situations (when a new
'add' replaces an element).

--emi


On Sun, Jul 16, 2017 at 5:10 PM, Mareena Fernando <mareena@gmail.com> wrote:
> Hello Emilian,
>
> I'm still studying the code "HashTree.java" which has a problem. So could
> you please give some instruction to do that?
>
> Thank you.
>
> On Sun, Jul 16, 2017 at 7:29 PM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>> There's no inconvenience. The underlying cause had a wide range of
>> possibilities: the IDE, compiler version, project configuration, etc.
>> and I was trying to figure it out.
>>
>> Still curious how you are approaching #53277 for a fix.
>>
>> --emi
>>
>>
>> On Sun, Jul 16, 2017 at 4:49 PM, Mareena Fernando <mareena@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > Yes, I successfully built JMeter project before. But when I compiled only
>> > the HashTree class inside the relevant sub module it displayed  those
>> > compiled errors. Now I realized It can't be compiled that way. So Thank
>> you
>> > very much for your concern and sorry for the inconvenience.
>> >
>> > Thank you.
>> >
>> > On Sun, Jul 16, 2017 at 6:31 PM, Emilian Bold <emilian.b...@gmail.com>
>> > wrote:
>> >
>> >> 1. What are you trying to accomplish with regard to #53277?
>> >>
>> >> > I compiled it inside that sub module.
>> >>
>> >> How?
>> >>
>> >> > Yet it didn't work.
>> >>
>> >> Does compiling JMeter generally work? Have you compiled JMeter before?
>> >> Do previous versions compile?
>> >>
>> >>
>> >> --emi
>> >>
>> >>
>> >> On Sun, Jul 16, 2017 at 3:58 PM, Mareena Fernando <
>> mareena@gmail.com>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > I compiled it inside that sub module. Yet it didn't work.
>> >> >
>> >> > On Sat, Jul 15, 2017 at 9:10 AM, Emilian Bold <emilian.b...@gmail.com
>> >
>> >> > wrote:
>> >> >
>> >> >> How exactly are you compiling? HashTree is part of src/jorphan and
>> you
>> >> >> should compile that submodule.
>> >> >>
>> >> >> It's also unclear to me how are you trying to fix #53277. The
>> problems
>> >> >> doesn't seem to be with HashTree per-se but with the bad architecture
>> >> >> of the calling code which adds "equal" elements.
>> >> >>
>> >> >> --emi
>> >> >>
>> >> >>
>> >> >> On Fri, Jul 14, 2017 at 11:20 PM, Mareena Fernando
>> >> >> <mareena@gmail.com> wrote:
>> >> >> > Hello,
>> >> >> >
>> >> >> > The issue description mentioned that issue is in "HashTree class".
>> >> When I
>> >> >> > compile that class (HashTree.java) I got compile time errors as
>> >> >> following,
>> >> >> >
>> >> >> > HashTree.java:975:error: cannot find symbol
>> >> >> > public void traverse {
>> >> >> >
>> >> >> >symbol: class HashTreeTraverser
>> >> >> >location: class HashTree
>> >> >> > HashTree.java:1019: error : cannot find symbol
>> >> >> > private static class TreeSearcher implements
>> >> HashTreeTraverser {
>> >> >> >
>> >> >> >symbol: class HashTreeTraverser
>> >> >> >location: class HashTree
>> >> >> >
>> >> >> >  HashTree.java: 1034: error: method does not override or implement
>> >> from a
>> >> >> > supertype
>> >> >> >  @Override
>> >> >>
>> >>
>>

Re: Checking values of properties more thoroughly

[Emilian Bold]

> The getPropDefault looks for values inside text files and tries to find one 
> matching the name of the first argument. If it can't find one, it gives back 
> the default value (which is the second argument).

The text file is an implementation detail. The API getPropDefault
should allow me to think the value is validated already.

>> RemoteJMeterEngineImpl.startServer(JMeterUtils.getPropDefault("server_port", 
>> 0));
> Than this is more an argument against this specific usage of getPropDefault, 
> isn't it?

Well, yes, it is rare to have non-constants.

> Where would you register/configure the validators?

Via annotations would be the most simple. Some service registration
would work too.

> What happens with third party modules, that would want to be checked, too?

Third party modules that define their own properties should do their
own validation. If they just use official JMeter properties, they
should expect the getPropDefault API call to return valid values.

> How would you integrate these annotations into our codebase?

I think the most "basic" way would be with code generation. Use the
annotations but then generate code with an annotation processor. The
generated code would be used to validate the properties file at
startup.


--emi


On Sun, Jul 16, 2017 at 5:10 PM, Felix Schumacher
 wrote:
> Am 16.07.2017 um 15:59 schrieb Vladimir Sitnikov:
>>
>> Emilian>The reason being that I expect getPropDefault to already return a
>> valid value or *my* default which I also know it's valid.
>>
>> +1
>>
>>
>> Emilian>A solution would be to validate the whole configuration file at
>> start up.
>>
>> There always might be "runtime validations", so we can't rely on "validate
>> everything at startup time".
>>
>> JMeter has lots of features and lots of options. Should it warn user if
>> some unused feature is misconfigured?
>>
>> Alternative (additional) option is to define properties via  some
>> class-interface like entities.
>> That is tie validator to the property, and not to the call site.
>
> Something like find all classes with interface PropertyValidatorInitializer
> (or something like that) and run them on startup. These classes could
> register (in a central registry) validators for property names.
>
> Than getPropDefault (or other getProp-variants) could ask the central
> registry to validate the values and even give specific error messages on
> failure.
>
>>
>> Note: "string -> whatever" conversion might need to use original string
>> value in order to make error message clear.
>>
>> Do you think error messages should be localizable?
>
> Might be nice, so I think it would definitely be a plus.
>>
>> Do you think error messages should refer to the relevant documentation
>> sections and/or provide corrective actions?
>
> Would be nice, too.
>
> Felix
>
>>
>> PS. Here's a relevant quote:
>> https://twitter.com/mezzoblue/status/878336246996647938
>>
>> Vladimir
>>
>

Re: [JMETER ISSUE #53277]

[Emilian Bold]

There's no inconvenience. The underlying cause had a wide range of
possibilities: the IDE, compiler version, project configuration, etc.
and I was trying to figure it out.

Still curious how you are approaching #53277 for a fix.

--emi


On Sun, Jul 16, 2017 at 4:49 PM, Mareena Fernando <mareena@gmail.com> wrote:
> Hi,
>
> Yes, I successfully built JMeter project before. But when I compiled only
> the HashTree class inside the relevant sub module it displayed  those
> compiled errors. Now I realized It can't be compiled that way. So Thank you
> very much for your concern and sorry for the inconvenience.
>
> Thank you.
>
> On Sun, Jul 16, 2017 at 6:31 PM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>> 1. What are you trying to accomplish with regard to #53277?
>>
>> > I compiled it inside that sub module.
>>
>> How?
>>
>> > Yet it didn't work.
>>
>> Does compiling JMeter generally work? Have you compiled JMeter before?
>> Do previous versions compile?
>>
>>
>> --emi
>>
>>
>> On Sun, Jul 16, 2017 at 3:58 PM, Mareena Fernando <mareena....@gmail.com>
>> wrote:
>> > Hello,
>> >
>> > I compiled it inside that sub module. Yet it didn't work.
>> >
>> > On Sat, Jul 15, 2017 at 9:10 AM, Emilian Bold <emilian.b...@gmail.com>
>> > wrote:
>> >
>> >> How exactly are you compiling? HashTree is part of src/jorphan and you
>> >> should compile that submodule.
>> >>
>> >> It's also unclear to me how are you trying to fix #53277. The problems
>> >> doesn't seem to be with HashTree per-se but with the bad architecture
>> >> of the calling code which adds "equal" elements.
>> >>
>> >> --emi
>> >>
>> >>
>> >> On Fri, Jul 14, 2017 at 11:20 PM, Mareena Fernando
>> >> <mareena@gmail.com> wrote:
>> >> > Hello,
>> >> >
>> >> > The issue description mentioned that issue is in "HashTree class".
>> When I
>> >> > compile that class (HashTree.java) I got compile time errors as
>> >> following,
>> >> >
>> >> > HashTree.java:975:error: cannot find symbol
>> >> > public void traverse {
>> >> >
>> >> >symbol: class HashTreeTraverser
>> >> >location: class HashTree
>> >> > HashTree.java:1019: error : cannot find symbol
>> >> > private static class TreeSearcher implements
>> HashTreeTraverser {
>> >> >
>> >> >symbol: class HashTreeTraverser
>> >> >location: class HashTree
>> >> >
>> >> >  HashTree.java: 1034: error: method does not override or implement
>> from a
>> >> > supertype
>> >> >  @Override
>> >>
>>

Re: Checking values of properties more thoroughly

[Emilian Bold]

I don't know the codebase well, but I wouldn't add a validator to
getPropDefault.

The reason being that I expect getPropDefault to already return a
valid value or *my* default which I also know it's valid.

So, validation should happen at a layer bellow getPropDefault.

Also, having the validator in there is not very good if you don't have
a constant. For example, I see in JMeter the call:

> RemoteJMeterEngineImpl.startServer(JMeterUtils.getPropDefault("server_port", 
> 0));

If you have the same key accessed multiple times with getPropDefault
they each would have to register a potentially different validator.

A solution would be to validate the whole configuration file at start up.

In order to have the validators you could use an annotation processor
to gather some validation annotations from the codebase. Eg.

@PositiveOrZero
private static int TIMEOUT =
JMeterUtils.getPropDefault("some.timeout", 5 * 1000);

Where @ PositiveOrZero is something I took from BeanValidation but we
don't have to use that (
http://beanvalidation.org/latest-draft/spec/#builtinconstraints-positiveorzero
).


--emi


On Sun, Jul 16, 2017 at 4:13 PM, Felix Schumacher
 wrote:
> While looking for easy enhancements and bugs I stumbled upon:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=56862
>
> I have to admit, that the error messages for wrong values are not always
> that helpful. Especially, when those values are used very late.
>
> To help things, we could either add a validate function (lambda?) to the
> JMeterUtils#getPropDefault family of functions, or surround those calls by a
> validator.
>
> I was thinking of something like
>
>  private static int TIMEOUT = JMeterUtils.getPropDefault("some.timeout", 5 *
> 1000, i -> i >= 0);
>
>  private static int TIMEOUT = JMeterUtils.getPropDefault("some.timeout", 5 *
> 1000, Validator::notNegative);
>
> or
>
>  private static int TIMEOUT =
> Validator.notNegative(JMeterUtils.getPropDefault("some.timeout", 5 * 1000),
> "some.timeout must not be negative");
>
> At the moment I prefer the first variants.
>
> What do you think?
>
> Felix
>

Re: [JMETER ISSUE #53277]

[Emilian Bold]

1. What are you trying to accomplish with regard to #53277?

> I compiled it inside that sub module.

How?

> Yet it didn't work.

Does compiling JMeter generally work? Have you compiled JMeter before?
Do previous versions compile?


--emi


On Sun, Jul 16, 2017 at 3:58 PM, Mareena Fernando <mareena@gmail.com> wrote:
> Hello,
>
> I compiled it inside that sub module. Yet it didn't work.
>
> On Sat, Jul 15, 2017 at 9:10 AM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>> How exactly are you compiling? HashTree is part of src/jorphan and you
>> should compile that submodule.
>>
>> It's also unclear to me how are you trying to fix #53277. The problems
>> doesn't seem to be with HashTree per-se but with the bad architecture
>> of the calling code which adds "equal" elements.
>>
>> --emi
>>
>>
>> On Fri, Jul 14, 2017 at 11:20 PM, Mareena Fernando
>> <mareena@gmail.com> wrote:
>> > Hello,
>> >
>> > The issue description mentioned that issue is in "HashTree class". When I
>> > compile that class (HashTree.java) I got compile time errors as
>> following,
>> >
>> > HashTree.java:975:error: cannot find symbol
>> > public void traverse {
>> >
>> >symbol: class HashTreeTraverser
>> >location: class HashTree
>> > HashTree.java:1019: error : cannot find symbol
>> > private static class TreeSearcher implements HashTreeTraverser {
>> >
>> >symbol: class HashTreeTraverser
>> >location: class HashTree
>> >
>> >  HashTree.java: 1034: error: method does not override or implement from a
>> > supertype
>> >  @Override
>>

Re: [JMETER ISSUE #53277]

[Emilian Bold]

How exactly are you compiling? HashTree is part of src/jorphan and you
should compile that submodule.

It's also unclear to me how are you trying to fix #53277. The problems
doesn't seem to be with HashTree per-se but with the bad architecture
of the calling code which adds "equal" elements.

--emi


On Fri, Jul 14, 2017 at 11:20 PM, Mareena Fernando
 wrote:
> Hello,
>
> The issue description mentioned that issue is in "HashTree class". When I
> compile that class (HashTree.java) I got compile time errors as following,
>
> HashTree.java:975:error: cannot find symbol
> public void traverse {
>
>symbol: class HashTreeTraverser
>location: class HashTree
> HashTree.java:1019: error : cannot find symbol
> private static class TreeSearcher implements HashTreeTraverser {
>
>symbol: class HashTreeTraverser
>location: class HashTree
>
>  HashTree.java: 1034: error: method does not override or implement from a
> supertype
>  @Override

Re: [JMETER ISSUE #61078]

[Emilian Bold]

The way I'm reading #61078, TestStatCalculatorPercentile.java is a new
test added as an attachment to that issue.

--emi


On Fri, Jul 14, 2017 at 11:09 PM, Lakshika Damithri Deshapriya
 wrote:
> Hello,
> I tried to work with this issue. As mentioned in the issue description the
> bug is in the "TestStatCalculatorPercentile.java" class. But when I
> searched that class in the source code there was no class by that name, but
> there were a class called "StatCalculator.java" which appeared as the
> corresponding class to the issue. I need to know that whether that class
> ("StatCalculator.java") is the correct class which includes the error.
> Regards!

Re: Mavenization [WAS: Re: JMeter project structure and IDEs support]

[Emilian Bold]

Q6: Could we get rid of the protocol/ folder?

I'm trying to avoid some copy-paste with the protocol sub-modules.
This happens because relative paths (to, say, the NOTICE file) will be
different from the relative paths of components and core/.

One approach would be to add another parent pom just for the protocol/
modules. This parent pom would still inherit from the main parent pom.
A minor downside is that this would change the parent pom that was
used so far in the basic Maven poms from res/maven/.

Another approach would be to just move all protocol modules at the
same level as all the others. (Either move the folders are they are:
ftp, http or move and rename them to protocol-ftp, protocol-http).

I think getting rid of the protocol/ folder and using protocol-ftp/,
protocol-http, etc. (or ftp/, http/) would be cleaner, but I probably
don't know all the benefits and history of the current layout.

--emi


On Wed, Jul 12, 2017 at 12:30 AM, Emilian Bold <emilian.b...@gmail.com> wrote:
> Q5: Why are org/apache/jmeter/images/{toolbar, tree}/icons-custom
> folders part of src? I don't see them being used and
> org/apache/jmeter/images/toolbar/icons-custom/** is expressly excluded
> from ApacheJMeter_core.jar. (But oddly,
> org/apache/jmeter/images/tree/icons-custom is *not*).
>
> I suggest to move them from src/ into res/icons or something.
>
> --emi
>
>
> On Tue, Jul 11, 2017 at 11:44 PM, Philippe Mouawad
> <philippe.moua...@gmail.com> wrote:
>> Yes
>>
>> On Mon, Jul 10, 2017 at 11:53 PM, Emilian Bold <emilian.b...@gmail.com>
>> wrote:
>>
>>> Q4: Why do ApacheJMeter_core.jar and ApacheJMeter.jar both contain
>>> ShutdownClient.class? I'm assuming it should only live in the lancher,
>>> ie. ApacheJMeter.jar?
>>>
>>> --emi
>>>
>>>
>>> On Sun, Jul 9, 2017 at 7:43 PM, Emilian Bold <emilian.b...@gmail.com>
>>> wrote:
>>> > Q3: Source split up.
>>> >
>>> > I see build.xml does some .class filtering when creating the JARs.
>>> >
>>> > For example:
>>> >
>>> > * the JMeter launch jar (ApacheJMeter.jar) is made from
>>> > src/core/**/NewDriver*, src/core/**/DynamicClassLoader*,
>>> > src/core/**/ShutdownClient.*
>>> >
>>> > I suggest we split up the launcher to a separate src/launcher folder
>>> > which would hold these classes.
>>> >
>>> > * the BeanShell Client (bshclient.jar) is made from
>>> > src/core/**/BeanShellClient*.java
>>> >
>>> > This should also be a separate src/bshclient folder.
>>> >
>>> > * like I mentioned in the other thread, the junit/test.jar sample is
>>> > redundant and we should create no such Maven artifacts anymore. I
>>> > suggest to go even further and remove the ant task too and the related
>>> > stub test classes from the src/junit/test and src/junit/woolfel
>>> > folders.
>>> >
>>> > PS: I'm publishing commits on
>>> > https://github.com/emilianbold/jmeter/commits/emilianbold-mavenization
>>> > So far only the resources rename is there, next will come the pom.xml
>>> > files.
>>> >
>>> > Note how build.xml already treats the resources differently and
>>> > switching to the Maven layout is rather harmless:
>>> > https://github.com/emilianbold/jmeter/commit/
>>> a194bbd8458116ea229692b6d3c461ca0f07c8e9
>>> >
>>> > I assume the same will be when I move the sources too.
>>> >
>>> > --emi
>>> >
>>> >
>>> > On Sat, Jul 8, 2017 at 12:22 PM, Emilian Bold <emilian.b...@gmail.com>
>>> wrote:
>>> >> Could we use this opportunity to remove the junit/test.jar sample,
>>> >> related Maven pom.xml, ant task and perhaps the src/junit/test and
>>> >> src/junit/woolfel folders entirely?
>>> >>
>>> >> --emi
>>> >>
>>> >>
>>> >> On Sat, Jul 8, 2017 at 11:36 AM, Philippe Mouawad
>>> >> <philippe.moua...@gmail.com> wrote:
>>> >>> Hello Emilian,
>>> >>> I agree with you
>>> >>>
>>> >>> Regards
>>> >>>
>>> >>> On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold <emilian.b...@gmail.com>
>>> >>> wrote:
>>> >>>
>>> >>>> Q2: ApacheJMeter_junit-test seems redundant to me. It only contains
>>> >>>> the src/junit/test and src/juni

Re: Mavenization [WAS: Re: JMeter project structure and IDEs support]

[Emilian Bold]

Q5: Why are org/apache/jmeter/images/{toolbar, tree}/icons-custom
folders part of src? I don't see them being used and
org/apache/jmeter/images/toolbar/icons-custom/** is expressly excluded
from ApacheJMeter_core.jar. (But oddly,
org/apache/jmeter/images/tree/icons-custom is *not*).

I suggest to move them from src/ into res/icons or something.

--emi


On Tue, Jul 11, 2017 at 11:44 PM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Yes
>
> On Mon, Jul 10, 2017 at 11:53 PM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>> Q4: Why do ApacheJMeter_core.jar and ApacheJMeter.jar both contain
>> ShutdownClient.class? I'm assuming it should only live in the lancher,
>> ie. ApacheJMeter.jar?
>>
>> --emi
>>
>>
>> On Sun, Jul 9, 2017 at 7:43 PM, Emilian Bold <emilian.b...@gmail.com>
>> wrote:
>> > Q3: Source split up.
>> >
>> > I see build.xml does some .class filtering when creating the JARs.
>> >
>> > For example:
>> >
>> > * the JMeter launch jar (ApacheJMeter.jar) is made from
>> > src/core/**/NewDriver*, src/core/**/DynamicClassLoader*,
>> > src/core/**/ShutdownClient.*
>> >
>> > I suggest we split up the launcher to a separate src/launcher folder
>> > which would hold these classes.
>> >
>> > * the BeanShell Client (bshclient.jar) is made from
>> > src/core/**/BeanShellClient*.java
>> >
>> > This should also be a separate src/bshclient folder.
>> >
>> > * like I mentioned in the other thread, the junit/test.jar sample is
>> > redundant and we should create no such Maven artifacts anymore. I
>> > suggest to go even further and remove the ant task too and the related
>> > stub test classes from the src/junit/test and src/junit/woolfel
>> > folders.
>> >
>> > PS: I'm publishing commits on
>> > https://github.com/emilianbold/jmeter/commits/emilianbold-mavenization
>> > So far only the resources rename is there, next will come the pom.xml
>> > files.
>> >
>> > Note how build.xml already treats the resources differently and
>> > switching to the Maven layout is rather harmless:
>> > https://github.com/emilianbold/jmeter/commit/
>> a194bbd8458116ea229692b6d3c461ca0f07c8e9
>> >
>> > I assume the same will be when I move the sources too.
>> >
>> > --emi
>> >
>> >
>> > On Sat, Jul 8, 2017 at 12:22 PM, Emilian Bold <emilian.b...@gmail.com>
>> wrote:
>> >> Could we use this opportunity to remove the junit/test.jar sample,
>> >> related Maven pom.xml, ant task and perhaps the src/junit/test and
>> >> src/junit/woolfel folders entirely?
>> >>
>> >> --emi
>> >>
>> >>
>> >> On Sat, Jul 8, 2017 at 11:36 AM, Philippe Mouawad
>> >> <philippe.moua...@gmail.com> wrote:
>> >>> Hello Emilian,
>> >>> I agree with you
>> >>>
>> >>> Regards
>> >>>
>> >>> On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold <emilian.b...@gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Q2: ApacheJMeter_junit-test seems redundant to me. It only contains
>> >>>> the src/junit/test and src/junit/woolfel sample test cases which are
>> >>>> basically a small JUnit tutorial. They make sense to have on the
>> >>>> website but why have them as public Maven artifacts?
>> >>>>
>> >>>> --emi
>> >>>>
>> >>>>
>> >>>> On Sat, Jul 8, 2017 at 10:07 AM, Philippe Mouawad
>> >>>> <philippe.moua...@gmail.com> wrote:
>> >>>> > On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <
>> emilian.b...@gmail.com>
>> >>>> wrote:
>> >>>> >
>> >>>> >> Q1: Maven artifact and group IDs?
>> >>>> >>
>> >>>> >> Currently I see in res/maven some basic Maven poms for central
>> >>>> >> deployment. These use the org.apache.jmeter groupId and
>> >>>> >> ApacheJMeter_parent, ApacheJMeter_http, ApacheJMeter_core artifact
>> Ids
>> >>>> >>
>> >>>> >> The groupId org.apache.jmeter is fine to me but the artifactID
>> look odd.
>> >>>> >>
>> >>>> >> Instead of ApacheJMeter_core I would just use 'core',
>> >>>> >&g

Re: Mavenization [WAS: Re: JMeter project structure and IDEs support]

[Emilian Bold]

Q4: Why do ApacheJMeter_core.jar and ApacheJMeter.jar both contain
ShutdownClient.class? I'm assuming it should only live in the lancher,
ie. ApacheJMeter.jar?

--emi


On Sun, Jul 9, 2017 at 7:43 PM, Emilian Bold <emilian.b...@gmail.com> wrote:
> Q3: Source split up.
>
> I see build.xml does some .class filtering when creating the JARs.
>
> For example:
>
> * the JMeter launch jar (ApacheJMeter.jar) is made from
> src/core/**/NewDriver*, src/core/**/DynamicClassLoader*,
> src/core/**/ShutdownClient.*
>
> I suggest we split up the launcher to a separate src/launcher folder
> which would hold these classes.
>
> * the BeanShell Client (bshclient.jar) is made from
> src/core/**/BeanShellClient*.java
>
> This should also be a separate src/bshclient folder.
>
> * like I mentioned in the other thread, the junit/test.jar sample is
> redundant and we should create no such Maven artifacts anymore. I
> suggest to go even further and remove the ant task too and the related
> stub test classes from the src/junit/test and src/junit/woolfel
> folders.
>
> PS: I'm publishing commits on
> https://github.com/emilianbold/jmeter/commits/emilianbold-mavenization
> So far only the resources rename is there, next will come the pom.xml
> files.
>
> Note how build.xml already treats the resources differently and
> switching to the Maven layout is rather harmless:
> https://github.com/emilianbold/jmeter/commit/a194bbd8458116ea229692b6d3c461ca0f07c8e9
>
> I assume the same will be when I move the sources too.
>
> --emi
>
>
> On Sat, Jul 8, 2017 at 12:22 PM, Emilian Bold <emilian.b...@gmail.com> wrote:
>> Could we use this opportunity to remove the junit/test.jar sample,
>> related Maven pom.xml, ant task and perhaps the src/junit/test and
>> src/junit/woolfel folders entirely?
>>
>> --emi
>>
>>
>> On Sat, Jul 8, 2017 at 11:36 AM, Philippe Mouawad
>> <philippe.moua...@gmail.com> wrote:
>>> Hello Emilian,
>>> I agree with you
>>>
>>> Regards
>>>
>>> On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold <emilian.b...@gmail.com>
>>> wrote:
>>>
>>>> Q2: ApacheJMeter_junit-test seems redundant to me. It only contains
>>>> the src/junit/test and src/junit/woolfel sample test cases which are
>>>> basically a small JUnit tutorial. They make sense to have on the
>>>> website but why have them as public Maven artifacts?
>>>>
>>>> --emi
>>>>
>>>>
>>>> On Sat, Jul 8, 2017 at 10:07 AM, Philippe Mouawad
>>>> <philippe.moua...@gmail.com> wrote:
>>>> > On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <emilian.b...@gmail.com>
>>>> wrote:
>>>> >
>>>> >> Q1: Maven artifact and group IDs?
>>>> >>
>>>> >> Currently I see in res/maven some basic Maven poms for central
>>>> >> deployment. These use the org.apache.jmeter groupId and
>>>> >> ApacheJMeter_parent, ApacheJMeter_http, ApacheJMeter_core artifact Ids
>>>> >>
>>>> >> The groupId org.apache.jmeter is fine to me but the artifactID look odd.
>>>> >>
>>>> >> Instead of ApacheJMeter_core I would just use 'core',
>>>> >> ApacheJMeter_http would become protocol-http, etc.
>>>> >>
>>>> >> Still, since these artifactIDs are already public I assume we have to
>>>> >> continue using them, no?
>>>> >>
>>>> >
>>>> > Yes please.
>>>> >
>>>> >>
>>>> >>
>>>> >> --emi
>>>> >>
>>>> >>
>>>> >> On Sat, Jul 8, 2017 at 9:21 AM, Vladimir Sitnikov
>>>> >> <sitnikov.vladi...@gmail.com> wrote:
>>>> >> > Philippe>The decision for no maven in project was due to the fact that
>>>> >> > nobody had
>>>> >> > time to work on it and as project has a lot of other work needed, we
>>>> >> wanted
>>>> >> > to put efforts in other fields.
>>>> >> >
>>>> >> > Oh, really?
>>>> >> > What about moving files around in order to better follow "default
>>>> maven
>>>> >> > convention"?
>>>> >> >
>>>> >> > Philippe>also project may be hard to mavenize knowing all the
>>>> >> customization
>>>> >> > need

Mavenization [WAS: Re: JMeter project structure and IDEs support]

[Emilian Bold]

Q3: Source split up.

I see build.xml does some .class filtering when creating the JARs.

For example:

* the JMeter launch jar (ApacheJMeter.jar) is made from
src/core/**/NewDriver*, src/core/**/DynamicClassLoader*,
src/core/**/ShutdownClient.*

I suggest we split up the launcher to a separate src/launcher folder
which would hold these classes.

* the BeanShell Client (bshclient.jar) is made from
src/core/**/BeanShellClient*.java

This should also be a separate src/bshclient folder.

* like I mentioned in the other thread, the junit/test.jar sample is
redundant and we should create no such Maven artifacts anymore. I
suggest to go even further and remove the ant task too and the related
stub test classes from the src/junit/test and src/junit/woolfel
folders.

PS: I'm publishing commits on
https://github.com/emilianbold/jmeter/commits/emilianbold-mavenization
So far only the resources rename is there, next will come the pom.xml
files.

Note how build.xml already treats the resources differently and
switching to the Maven layout is rather harmless:
https://github.com/emilianbold/jmeter/commit/a194bbd8458116ea229692b6d3c461ca0f07c8e9

I assume the same will be when I move the sources too.

--emi


On Sat, Jul 8, 2017 at 12:22 PM, Emilian Bold <emilian.b...@gmail.com> wrote:
> Could we use this opportunity to remove the junit/test.jar sample,
> related Maven pom.xml, ant task and perhaps the src/junit/test and
> src/junit/woolfel folders entirely?
>
> --emi
>
>
> On Sat, Jul 8, 2017 at 11:36 AM, Philippe Mouawad
> <philippe.moua...@gmail.com> wrote:
>> Hello Emilian,
>> I agree with you
>>
>> Regards
>>
>> On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold <emilian.b...@gmail.com>
>> wrote:
>>
>>> Q2: ApacheJMeter_junit-test seems redundant to me. It only contains
>>> the src/junit/test and src/junit/woolfel sample test cases which are
>>> basically a small JUnit tutorial. They make sense to have on the
>>> website but why have them as public Maven artifacts?
>>>
>>> --emi
>>>
>>>
>>> On Sat, Jul 8, 2017 at 10:07 AM, Philippe Mouawad
>>> <philippe.moua...@gmail.com> wrote:
>>> > On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <emilian.b...@gmail.com>
>>> wrote:
>>> >
>>> >> Q1: Maven artifact and group IDs?
>>> >>
>>> >> Currently I see in res/maven some basic Maven poms for central
>>> >> deployment. These use the org.apache.jmeter groupId and
>>> >> ApacheJMeter_parent, ApacheJMeter_http, ApacheJMeter_core artifact Ids
>>> >>
>>> >> The groupId org.apache.jmeter is fine to me but the artifactID look odd.
>>> >>
>>> >> Instead of ApacheJMeter_core I would just use 'core',
>>> >> ApacheJMeter_http would become protocol-http, etc.
>>> >>
>>> >> Still, since these artifactIDs are already public I assume we have to
>>> >> continue using them, no?
>>> >>
>>> >
>>> > Yes please.
>>> >
>>> >>
>>> >>
>>> >> --emi
>>> >>
>>> >>
>>> >> On Sat, Jul 8, 2017 at 9:21 AM, Vladimir Sitnikov
>>> >> <sitnikov.vladi...@gmail.com> wrote:
>>> >> > Philippe>The decision for no maven in project was due to the fact that
>>> >> > nobody had
>>> >> > time to work on it and as project has a lot of other work needed, we
>>> >> wanted
>>> >> > to put efforts in other fields.
>>> >> >
>>> >> > Oh, really?
>>> >> > What about moving files around in order to better follow "default
>>> maven
>>> >> > convention"?
>>> >> >
>>> >> > Philippe>also project may be hard to mavenize knowing all the
>>> >> customization
>>> >> > needed.
>>> >> >
>>> >> > I do get that, and I am fine with the challenge provided one day that
>>> >> would
>>> >> > become the master build script for the project.
>>> >> >
>>> >> >
>>> >> > I thought sebb was against Maven as:
>>> >> > 1) it is slower to build. That is true, Maven has non-zero per-module
>>> >> > overhead.
>>> >> > 2) "it adds no value". Well, I would argue that having Maven-first
>>> makes
>>> >> > JMeter presence in Maven Central much more solid, and it greatly
&g

Re: JMeter project structure and IDEs support

[Emilian Bold]

Could we use this opportunity to remove the junit/test.jar sample,
related Maven pom.xml, ant task and perhaps the src/junit/test and
src/junit/woolfel folders entirely?

--emi


On Sat, Jul 8, 2017 at 11:36 AM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Hello Emilian,
> I agree with you
>
> Regards
>
> On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>> Q2: ApacheJMeter_junit-test seems redundant to me. It only contains
>> the src/junit/test and src/junit/woolfel sample test cases which are
>> basically a small JUnit tutorial. They make sense to have on the
>> website but why have them as public Maven artifacts?
>>
>> --emi
>>
>>
>> On Sat, Jul 8, 2017 at 10:07 AM, Philippe Mouawad
>> <philippe.moua...@gmail.com> wrote:
>> > On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <emilian.b...@gmail.com>
>> wrote:
>> >
>> >> Q1: Maven artifact and group IDs?
>> >>
>> >> Currently I see in res/maven some basic Maven poms for central
>> >> deployment. These use the org.apache.jmeter groupId and
>> >> ApacheJMeter_parent, ApacheJMeter_http, ApacheJMeter_core artifact Ids
>> >>
>> >> The groupId org.apache.jmeter is fine to me but the artifactID look odd.
>> >>
>> >> Instead of ApacheJMeter_core I would just use 'core',
>> >> ApacheJMeter_http would become protocol-http, etc.
>> >>
>> >> Still, since these artifactIDs are already public I assume we have to
>> >> continue using them, no?
>> >>
>> >
>> > Yes please.
>> >
>> >>
>> >>
>> >> --emi
>> >>
>> >>
>> >> On Sat, Jul 8, 2017 at 9:21 AM, Vladimir Sitnikov
>> >> <sitnikov.vladi...@gmail.com> wrote:
>> >> > Philippe>The decision for no maven in project was due to the fact that
>> >> > nobody had
>> >> > time to work on it and as project has a lot of other work needed, we
>> >> wanted
>> >> > to put efforts in other fields.
>> >> >
>> >> > Oh, really?
>> >> > What about moving files around in order to better follow "default
>> maven
>> >> > convention"?
>> >> >
>> >> > Philippe>also project may be hard to mavenize knowing all the
>> >> customization
>> >> > needed.
>> >> >
>> >> > I do get that, and I am fine with the challenge provided one day that
>> >> would
>> >> > become the master build script for the project.
>> >> >
>> >> >
>> >> > I thought sebb was against Maven as:
>> >> > 1) it is slower to build. That is true, Maven has non-zero per-module
>> >> > overhead.
>> >> > 2) "it adds no value". Well, I would argue that having Maven-first
>> makes
>> >> > JMeter presence in Maven Central much more solid, and it greatly
>> >> simplifies
>> >> > use of JMeter as a dependency.
>> >> > 3) "it makes builds more complicated"
>> >> >
>> >> > I know file rearrangements will hurt "svn blame" kind of scenarios a
>> bit,
>> >> > however default layout conventions do help IDEs to work with the
>> project.
>> >> >
>> >> > PS. Currently Gradle is the thing, and it is more flexible when it
>> comes
>> >> to
>> >> > multi-module configurations. It is has faster build times (it might be
>> >> even
>> >> > faster than current Ant builds), so I guess we might want to try
>> Gradle
>> >> if
>> >> > the build speed is an issue.
>> >> >
>> >> > PPS. I've did mavenization / code relayout for pgjdbc, and I do
>> release
>> >> > pgjdbc, so it (me speaking of mavenization) is not something
>> theoretical.
>> >> >
>> >> > PPPS. I've not used Gradle extensively. So, even if I would try adding
>> >> > Gradle build scripts, I would like someone to check those for the
>> sanity.
>> >> >
>> >> > Vladimir
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: JMeter project structure and IDEs support

[Emilian Bold]

Q1: Maven artifact and group IDs?

Currently I see in res/maven some basic Maven poms for central
deployment. These use the org.apache.jmeter groupId and
ApacheJMeter_parent, ApacheJMeter_http, ApacheJMeter_core artifact Ids

The groupId org.apache.jmeter is fine to me but the artifactID look odd.

Instead of ApacheJMeter_core I would just use 'core',
ApacheJMeter_http would become protocol-http, etc.

Still, since these artifactIDs are already public I assume we have to
continue using them, no?


--emi


On Sat, Jul 8, 2017 at 9:21 AM, Vladimir Sitnikov
 wrote:
> Philippe>The decision for no maven in project was due to the fact that
> nobody had
> time to work on it and as project has a lot of other work needed, we wanted
> to put efforts in other fields.
>
> Oh, really?
> What about moving files around in order to better follow "default maven
> convention"?
>
> Philippe>also project may be hard to mavenize knowing all the customization
> needed.
>
> I do get that, and I am fine with the challenge provided one day that would
> become the master build script for the project.
>
>
> I thought sebb was against Maven as:
> 1) it is slower to build. That is true, Maven has non-zero per-module
> overhead.
> 2) "it adds no value". Well, I would argue that having Maven-first makes
> JMeter presence in Maven Central much more solid, and it greatly simplifies
> use of JMeter as a dependency.
> 3) "it makes builds more complicated"
>
> I know file rearrangements will hurt "svn blame" kind of scenarios a bit,
> however default layout conventions do help IDEs to work with the project.
>
> PS. Currently Gradle is the thing, and it is more flexible when it comes to
> multi-module configurations. It is has faster build times (it might be even
> faster than current Ant builds), so I guess we might want to try Gradle if
> the build speed is an issue.
>
> PPS. I've did mavenization / code relayout for pgjdbc, and I do release
> pgjdbc, so it (me speaking of mavenization) is not something theoretical.
>
> PPPS. I've not used Gradle extensively. So, even if I would try adding
> Gradle build scripts, I would like someone to check those for the sanity.
>
> Vladimir

Re: JMeter project structure and IDEs support

[Emilian Bold]

What customization is needed?

As of now I'm able to build JMeter (components, core, functions,
jorphan, protocol/*) and with a little tweak run it as-is from
NetBeans.

One separate aspect is that I see the canonical source is under
Subversion. So even if I make a Git patch (or pull request), all the
renames will probably have to be re-done in Subversion? I'm not sure
how Subversion handles patches that rename files.

--emi


On Sat, Jul 8, 2017 at 9:03 AM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> Hello,
> The decision for no maven in project was due to the fact that nobody had
> time to work on it and as project has a lot of other work needed, we wanted
> to put efforts in other fields.
> also project may be hard to mavenize knowing all the customization needed.
>
> But if there is a volunteer , let's move forward.
> If it ends up too hard, then an intermediate step would be to at least
> provide source and javadocs artifacts which are currently missing.
>
>
> Regards
>
> On Friday, July 7, 2017, Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
> wrote:
>
>> As far as I can remember, the current agreement with "mavenization" is:
>> 1) JMeter is ok with having some pom.xml files in the repository if they
>> would help to load the project with IDE
>> 2) ant must stay the master build system
>>
>> #2 implies that:
>> implication 1) dependencies are to be managed by ant build.xml
>> implication 2) if a new dependency added, then build.xml must be updated
>> first (to reflect the change), then pom.xml might be required (if anyone
>> uses pom.xml)
>>
>> Frankly speaking, I would love to switch to Maven (I can do mavenization),
>> however I think it is just "not wanted" by the project.
>>
>> Vladimir
>>
>> пт, 7 июл. 2017 г. в 23:34, Antonio Gomes Rodrigues <ra0...@gmail.com
>> <javascript:;>>:
>>
>> > Great
>> >
>> > Antonio
>> >
>> > 2017-07-07 15:29 GMT+02:00 Emilian Bold <emilian.b...@gmail.com
>> <javascript:;>>:
>> >
>> > > OK, I'll Mavenize the project and keep you posted.
>> > >
>> > > --emi
>> > >
>> > >
>> > > On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
>> > > <ra0...@gmail.com <javascript:;>> wrote:
>> > > > Hi,
>> > > >
>> > > > Using Maven have been considered, unfortunately we don't have enough
>> > time
>> > > > to work on it
>> > > > Feel free to do it
>> > > >
>> > > > Antonio
>> > > >
>> > > > 2017-07-07 12:34 GMT+02:00 Emilian Bold <e...@apache.org
>> <javascript:;>>:
>> > > >
>> > > >> Hello,
>> > > >>
>> > > >> I see that officially only Eclipse is a supported IDE
>> > > >> http://jmeter.apache.org/building.html
>> > > >>
>> > > >> I would like to add at least Apache NetBeans support too.
>> > > >>
>> > > >> I'm able to run the project, but I'm creating a single JAR for all
>> the
>> > > >> src/ submodules instead a multiple JARs.
>> > > >>
>> > > >> It might be a silly question, but have you considered using Maven or
>> > > >> Gradle or some other build system that would be sub-project aware?
>> > > >>
>> > > >> This would more easily allow the project to be loaded from multiple
>> > > IDEs.
>> > > >>
>> > > >> It would also allow a segmentation of dependency JARs per submodule.
>> > > >>
>> > > >> If dev@ is not the proper place for this I can resend the email to
>> > > >> some other mailing list.
>> > > >>
>> > > >> --emi
>> > > >>
>> > >
>> >
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: JMeter project structure and IDEs support

[Emilian Bold]

OK, I'll Mavenize the project and keep you posted.

--emi


On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
<ra0...@gmail.com> wrote:
> Hi,
>
> Using Maven have been considered, unfortunately we don't have enough time
> to work on it
> Feel free to do it
>
> Antonio
>
> 2017-07-07 12:34 GMT+02:00 Emilian Bold <e...@apache.org>:
>
>> Hello,
>>
>> I see that officially only Eclipse is a supported IDE
>> http://jmeter.apache.org/building.html
>>
>> I would like to add at least Apache NetBeans support too.
>>
>> I'm able to run the project, but I'm creating a single JAR for all the
>> src/ submodules instead a multiple JARs.
>>
>> It might be a silly question, but have you considered using Maven or
>> Gradle or some other build system that would be sub-project aware?
>>
>> This would more easily allow the project to be loaded from multiple IDEs.
>>
>> It would also allow a segmentation of dependency JARs per submodule.
>>
>> If dev@ is not the proper place for this I can resend the email to
>> some other mailing list.
>>
>> --emi
>>

JMeter project structure and IDEs support

[Emilian Bold]

Hello,

I see that officially only Eclipse is a supported IDE
http://jmeter.apache.org/building.html

I would like to add at least Apache NetBeans support too.

I'm able to run the project, but I'm creating a single JAR for all the
src/ submodules instead a multiple JARs.

It might be a silly question, but have you considered using Maven or
Gradle or some other build system that would be sub-project aware?

This would more easily allow the project to be loaded from multiple IDEs.

It would also allow a segmentation of dependency JARs per submodule.

If dev@ is not the proper place for this I can resend the email to
some other mailing list.

--emi

Re: Deprecate / drop Graph listener

[Emilian Bold]

Why would the listener guarantee an OOME?

If you are leaking listeners did you look into WeakListeners? 
http://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/WeakListeners.html

--emi

Pe 2 iun. 2017, la 01:07, Andrey Pokhilko  a scris:

> +1
> 
> Andrey Pokhilko
> 
>> On 02.06.2017 01:01, Philippe Mouawad wrote:
>> Hello,
>> What do you think of dropping this old listener which generates a now very
>> old looking graph and which leads to OOM when user runs JMeter in gui mode ?
>> 
>> With 3.2, we found a solution for some listeners in Gui mode but I think we
>> should bury  this one.
>> See this conversation with newbie :
>> - https://twitter.com/fnicollet/status/869689600758996992
>> 
>> 
>> 
>> Regards
>> Philippe
>> 
>> 
> 

Re: Issue with Search replace functionality in jmeter

[Emilian Bold]

That's odd, replacing "abc" with "abcd" seems like a common use case. So, it's 
a bug in replaceAllWithRegex, no?

--emi

Pe 29 apr. 2017, la 12:40, Felix Schumacher  
a scris:

>> Am 28.04.2017 um 08:25 schrieb mitsm:
>> Hello,
>> 
>> I was trying to do search and replace in jmeter (3.2 r1790748) for a change
>> in URL for my application. I did as shown in the snaps below but found that
>> the search replace was stuck and did not responded even after about 30 mins.
>> 
>> I did a bit of digging using jvisual vm and found that the method
>> "org.apache.jorphan.util.JOrphanUtils.replaceAllWithRegex()" had the highest
>> self time and it kept increasing with time (obviously!).
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Seems to be a bug. Can i please get some suggestions?
> I just filed a bug https://bz.apache.org/bugzilla/show_bug.cgi?id=61054
> 
> The problem is, that you are replacing a string with a string, that includes 
> the search. That leads to an endless loop in JOrphanUtils#replaceAllWithRegex.
> 
> A simple testcase would be to add a ThreadGroup containing a HTTP Sampler 
> with a Parameter having a key "name" and a value "abc".
> 
> Now, if one does a find replace with "abc" as the search and "abcabc" as the 
> replacement, "replace all" will never come to a halt :(
> 
> Regards,
> Felix
> 
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://www.jmeter-archive.org/Issue-with-Search-replace-functionality-in-jmeter-tp5725533.html
>> Sent from the JMeter - Dev mailing list archive at Nabble.com.
> 
> 

Re: Issue with Search replace functionality in jmeter

[Emilian Bold]

A reproducible test would be nice.


--emi

On Fri, Apr 28, 2017 at 9:25 AM, mitsm  wrote:

> Hello,
>
> I was trying to do search and replace in jmeter (3.2 r1790748) for a change
> in URL for my application. I did as shown in the snaps below but found that
> the search replace was stuck and did not responded even after about 30
> mins.
>
> I did a bit of digging using jvisual vm and found that the method
> "org.apache.jorphan.util.JOrphanUtils.replaceAllWithRegex()" had the
> highest
> self time and it kept increasing with time (obviously!).
>
>  Search_Replace_Snap.png>
>
>  Search_Replace_snap_2.png>
>
>  >
>
> Seems to be a bug. Can i please get some suggestions?
>
>
>
> --
> View this message in context: http://www.jmeter-archive.org/
> Issue-with-Search-replace-functionality-in-jmeter-tp5725533.html
> Sent from the JMeter - Dev mailing list archive at Nabble.com.
>

Re: [GitHub] jmeter pull request #293: Prevent use of the same array in CollectionPropert...

[Emilian Bold]

I'm also on the mailing list if somebody has anything to remark about
this patch.

--emi


On Wed, Apr 26, 2017 at 6:04 PM, emilianbold <g...@git.apache.org> wrote:
> GitHub user emilianbold opened a pull request:
>
> https://github.com/apache/jmeter/pull/293
>
> Prevent use of the same array in CollectionProperty (close #58743)
>
> CollectionProperty constructor receives an empty ObjectTableModel.objects
> collection but normalizeList will return it as-is instead of creating a
> new empty collection.
>
> The two classes share the same array but add different kind of classes.
>
> NOTE: Basically the bug is in AbstractProperty.normalizeList because it 
> should never reuse the same instance. I've done the patch as you see it 
> because it has the lowest impact and does not change the normalizeList API 
> (perhaps reusing is expected in some cases?)
>
> Let me know if I should redo the patch by just changing normalizeList!
>
> Constructor stacktrace:
> at 
> org.apache.jmeter.testelement.property.CollectionProperty.(CollectionProperty.java:40)
> at 
> org.apache.jmeter.testelement.property.AbstractProperty.makeProperty(AbstractProperty.java:395)
> at 
> org.apache.jmeter.testelement.property.AbstractProperty.createProperty(AbstractProperty.java:368)
> at 
> org.apache.jmeter.testbeans.gui.TestBeanGUI.setPropertyInElement(TestBeanGUI.java:277)
> at 
> org.apache.jmeter.testbeans.gui.TestBeanGUI.modifyTestElement(TestBeanGUI.java:266)
> at 
> org.apache.jmeter.gui.tree.JMeterTreeModel.addComponent(JMeterTreeModel.java:148)
> at org.apache.jmeter.gui.action.AddToTree.doAction(AddToTree.java:70)
> at 
> org.apache.jmeter.gui.action.ActionRouter.performAction(ActionRouter.java:74)
> at 
> org.apache.jmeter.gui.action.ActionRouter.lambda$actionPerformed$28(ActionRouter.java:59)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>
>
> You can merge this pull request into a Git repository by running:
>
> $ git pull https://github.com/emilianbold/jmeter trunk
>
> Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/jmeter/pull/293.patch
>
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
>
> This closes #293
>
> 
> commit 2b829035f144c49e565d99ed0ca8f83ba6f85cf4
> Author: Emilian Bold <e...@apache.org>
> Date:   2017-04-26T14:57:58Z
>
> Prevent use of the same array in CollectionProperty (close #58743)
>
> CollectionProperty constructor receives an empty ObjectTableModel.objects
> collection but normalizeList will return it as-is instead of creating a
> new empty collection.
>
> The two classes share the same array but add different kind of classes.
>
> 
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---