[GitHub] jmeter pull request #330: Remove Workbench

[artem-fedorov]

GitHub user artem-fedorov opened a pull request:

https://github.com/apache/jmeter/pull/330

Remove Workbench

https://bz.apache.org/bugzilla/show_bug.cgi?id=61591

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/artem-fedorov/jmeter drop-workbench

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jmeter/pull/330.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 #330


commit a44559f3d132130a3c75bcad51ee6d5f83c8cf94
Author: Artem Fedorov 
Date:   2017-11-15T07:19:14Z

drop workbench




---

Re: Validate Functionality

[Graham Russell]

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

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

Let me know if it makes sense.

Thanks

Graham

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

[GitHub] jmeter pull request #329: Expansion of "Add expand/collapse all menu in rend...

[ham1]

GitHub user ham1 opened a pull request:

https://github.com/apache/jmeter/pull/329

Expansion of "Add expand/collapse all menu in render XML view" (PR #294)

## Description

Update and expansion to PR #294. I hope @max3163 doesn't mind. It improves 
upon the UX of the original (good) idea by having the right click also select 
the node, rather than right click bring up the menu but not changing the 
selected node which felt counter intuitive.

## Motivation and Context

Makes exploring the XML results far easier, especially for large documents.

## How Has This Been Tested?

Manually downloading a few different xml docs and right clicking, expanding 
and collapsing in various places.

## Screenshots (if appropriate):
Right clicking on the element, selects it and brings up the menu:
![Right-click on 
element](https://user-images.githubusercontent.com/3393038/32809390-93ddce74-c98e-11e7-98a0-ba6db1814109.png)
Expands all:
![Expand 
All](https://user-images.githubusercontent.com/3393038/32809399-99c05500-c98e-11e7-83e9-a334aedd692b.png)

## Types of changes
- New feature (non-breaking change which adds functionality)

## Checklist:
- [x] My code follows the [code style][style-guide] of this project.
- [x] I have updated the documentation accordingly.

[style-guide]: https://wiki.apache.org/jmeter/CodeStyleGuidelines



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ham1/jmeter pr_294

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jmeter/pull/329.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 #329


commit f3819f9e94e6e9890f0483f645f214137867e547
Author: Graham Russell 
Date:   2017-11-14T22:29:38Z

formatting

commit afb038ae7341f6448c1573c073d5f140371c1e82
Author: Graham Russell 
Date:   2017-11-14T22:31:10Z

Right click XML view will select node and show menu for collapse/expand.

commit 094716219c6a22bebf16048946b291d9dbab467e
Author: Graham Russell 
Date:   2017-11-14T23:03:55Z

Updated docs




---

Re: Validate Functionality

[Philippe Mouawad]

Hello Graham,
Your proposals are interesting but it maybe be useful to create some
mock-up (modifiable/sharable) if possible.

I think we could by the way enhance the Run experience in GUI, an idea:

   - Be able to have something like Eclipse "Run Configuration" to
   configure user defined properties without having to restart , see
   https://bz.apache.org/bugzilla/show_bug.cgi?id=61755

Regards


On Fri, Nov 10, 2017 at 11:34 PM, Graham Russell  wrote:

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


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site 

UBIK LOAD PACK on TWITTER 

[GitHub] jmeter pull request #320: HTTPClient 4.5. migration to last APIs / Bugzilla ...

[ham1]

Github user ham1 commented on a diff in the pull request:

https://github.com/apache/jmeter/pull/320#discussion_r150891448
  
--- Diff: 
src/protocol/http/org/apache/jmeter/protocol/http/api/auth/DigestParameters.java
 ---
@@ -0,0 +1,98 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ * 
+ */
+
+package org.apache.jmeter.protocol.http.api.auth;
+
+/**
+ * Allows digest customization
+ * @since 4.0
+ */
+public class DigestParameters {
+public static final String VARIABLE_NAME = "__jmeter_DP__";
+private String qop;
+private String nonce;
+private String charset;
+private String algorithm;
+private String opaque;
+/**
+ * 
--- End diff --

I think this class would be better without any of the JavaDoc comments, 
they do not add anything because the class is so simple there's nothing which 
needs commenting.


---

[GitHub] jmeter pull request #320: HTTPClient 4.5. migration to last APIs / Bugzilla ...

[ham1]

Github user ham1 commented on a diff in the pull request:

https://github.com/apache/jmeter/pull/320#discussion_r150905177
  
--- Diff: 
src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java ---
@@ -215,22 +269,128 @@ public long getKeepAliveDuration(HttpResponse 
response, HttpContext context) {
 
 };
 
-/**
- * Special interceptor made to keep metrics when connection is 
released for some method like HEAD
- * Otherwise calling directly ((HttpConnection) 
localContext.getAttribute(HttpCoreContext.HTTP_CONNECTION)).getMetrics();
- * would throw org.apache.http.impl.conn.ConnectionShutdownException
- * See https://bz.apache.org/jira/browse/HTTPCLIENT-1081;>HTTPCLIENT-1081
- */
-private static final HttpResponseInterceptor METRICS_SAVER = 
(HttpResponse response, HttpContext context) -> {
-HttpConnectionMetrics metrics = ((HttpConnection) 
context.getAttribute(HttpCoreContext.HTTP_CONNECTION)).getMetrics();
-context.setAttribute(CONTEXT_METRICS, metrics);
-};
-private static final HttpRequestInterceptor METRICS_RESETTER = 
(HttpRequest request, HttpContext context) -> {
-HttpConnectionMetrics metrics = ((HttpConnection) 
context.getAttribute(HttpCoreContext.HTTP_CONNECTION)).getMetrics();
-metrics.reset();
+private static final String DIGEST_PARAMETERS = 
DigestParameters.VARIABLE_NAME;
+
+
+private static final HttpRequestInterceptor 
PREEMPTIVE_AUTH_INTERCEPTOR = new HttpRequestInterceptor() {
--- End diff --

This is almost 100 lines and with lots of nesting becomes very hard to read 
and review, could it be split into smaller methods?


---

[GitHub] jmeter pull request #320: HTTPClient 4.5. migration to last APIs / Bugzilla ...

[ham1]

Github user ham1 commented on a diff in the pull request:

https://github.com/apache/jmeter/pull/320#discussion_r150895140
  
--- Diff: 
src/protocol/http/org/apache/jmeter/protocol/http/control/DynamicKerberosSchemeFactory.java
 ---
@@ -0,0 +1,47 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ */
+
+package org.apache.jmeter.protocol.http.control;
+
+import org.apache.http.auth.AuthScheme;
+import org.apache.http.impl.auth.KerberosScheme;
+import org.apache.http.impl.auth.KerberosSchemeFactory;
+import org.apache.http.protocol.HttpContext;
+
+/**
+ * Extends {@link KerberosSchemeFactory} to provide ability to customize 
stripPort
+ * setting in {@link KerberosScheme} based on {@link HttpContext}
+ */
+public class DynamicKerberosSchemeFactory extends KerberosSchemeFactory {
+static final String CONTEXT_ATTRIBUTE_STRIP_PORT = "__jmeter.K_SP__";
+
+/**
+ * @since 4.0
+ */
+public DynamicKerberosSchemeFactory(final boolean stripPort, final 
boolean useCanonicalHostname) {
+super(stripPort, useCanonicalHostname);
+}
+
+@Override
+public AuthScheme create(final HttpContext context) {
+Boolean localStripPort = (Boolean) 
context.getAttribute(CONTEXT_ATTRIBUTE_STRIP_PORT);
+return new KerberosScheme(localStripPort != null ? 
--- End diff --

might be better as a variable rather than a multi-line ternary operator as 
a parameter?
e.g.
```java
Boolean stripPort = localStripPort != null ? localStripPort : isStripPort();
return new KerberosScheme(stripPort, isUseCanonicalHostname());
```


---

[GitHub] jmeter pull request #320: HTTPClient 4.5. migration to last APIs / Bugzilla ...

[ham1]

Github user ham1 commented on a diff in the pull request:

https://github.com/apache/jmeter/pull/320#discussion_r150891784
  
--- Diff: 
src/protocol/http/org/apache/jmeter/protocol/http/control/AuthManager.java ---
@@ -97,10 +94,33 @@
 private static final boolean DEFAULT_CLEAR_VALUE = false;
 
 /** Decides whether port should be omitted from SPN for kerberos 
spnego authentication */
-private static final boolean STRIP_PORT = 
JMeterUtils.getPropDefault("kerberos.spnego.strip_port", true);
+public static final boolean STRIP_PORT = 
JMeterUtils.getPropDefault("kerberos.spnego.strip_port", true);
+
+/** Decides whether port should be omitted from SPN for kerberos 
spnego authentication */
+public static final boolean USE_CANONICAL_HOST_NAME = 
JMeterUtils.getPropDefault("kerberos.spnego.use_canonical_host_name", true);
 
 public enum Mechanism {
-BASIC_DIGEST, KERBEROS
+/**
+ * @deprecated (use {@link Mechanism#BASIC})
+ */
+@Deprecated 
+BASIC_DIGEST,
+/**
+ * Basic Auth
+ */
+BASIC, 
+/**
+ * Digest Auth
+ */
+DIGEST, 
+/**
+ * Kerberos Auth
+ */
+KERBEROS
+}
+
+public static void main(String[] args) {
+System.out.println(Mechanism.values());
--- End diff --

Should this be here?


---

[GitHub] jmeter issue #325: 61544 - Added read, browse and clear as communication sty...

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/325
  
Hello @bennyvw ,
Thanks for updating PR.
It seems the changes have introduced an issue in JMS_TESTS.jmx which is 
located in source files on github/svn (only, not in binary) in bin/testfiles:
https://github.com/apache/jmeter/blob/trunk/bin/testfiles/JMS_TESTS.jmx

To debug the issue, put activemq-all.jar in lib folder and run the test.

Thanks


---

[GitHub] jmeter issue #328: Improve wording and formatting of jmeter.properties

[codecov-io]

Github user codecov-io commented on the issue:

https://github.com/apache/jmeter/pull/328
  
# [Codecov](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=h1) 
Report
> Merging 
[#328](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=desc) into 
[trunk](https://codecov.io/gh/apache/jmeter/commit/358acbba80f7acc27d720b673d5537a10c658aa0?src=pr=desc)
 will **increase** coverage by `<.01%`.
> The diff coverage is `n/a`.

[![Impacted file tree 
graph](https://codecov.io/gh/apache/jmeter/pull/328/graphs/tree.svg?token=6Q7CI1wFSh=pr=650=150)](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=tree)

```diff
@@ Coverage Diff  @@
##  trunk #328  +/-   ##

+ Coverage 57.83%   57.83%   +<.01% 
+ Complexity 9937 9936   -1 

  Files  1141 1141  
  Lines 7321773217  
  Branches   7305 7305  

+ Hits  4234642347   +1 
+ Misses2840528403   -2 
- Partials   2466 2467   +1
```


| [Impacted 
Files](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=tree) | Coverage 
Δ | Complexity Δ | |
|---|---|---|---|
| 
[...s/org/apache/jmeter/timers/PoissonRandomTimer.java](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=tree#diff-c3JjL2NvbXBvbmVudHMvb3JnL2FwYWNoZS9qbWV0ZXIvdGltZXJzL1BvaXNzb25SYW5kb21UaW1lci5qYXZh)
 | `72.97% <0%> (-5.41%)` | `9% <0%> (-1%)` | |
| 
[...c/core/org/apache/jmeter/reporters/Summariser.java](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvcmVwb3J0ZXJzL1N1bW1hcmlzZXIuamF2YQ==)
 | `85.38% <0%> (-0.77%)` | `18% <0%> (-1%)` | |
| 
[...mpler/hc/JMeterPoolingClientConnectionManager.java](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=tree#diff-c3JjL3Byb3RvY29sL2h0dHAvb3JnL2FwYWNoZS9qbWV0ZXIvcHJvdG9jb2wvaHR0cC9zYW1wbGVyL2hjL0pNZXRlclBvb2xpbmdDbGllbnRDb25uZWN0aW9uTWFuYWdlci5qYXZh)
 | `30.95% <0%> (+3.17%)` | `11% <0%> (+1%)` | :arrow_up: |

--

[Continue to review full report at 
Codecov](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=continue).
> **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute  (impact)`, `ø = not affected`, `? = missing 
data`
> Powered by 
[Codecov](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=footer). Last 
update 
[358acbb...e26dc29](https://codecov.io/gh/apache/jmeter/pull/328?src=pr=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).



---

Re: Workbench : Let's drop it ?

[Artem Fedorov]

I attached patch in this bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=61591


On Sun, Nov 12, 2017 at 4:05 PM, Ralf Roeber  wrote:

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

[GitHub] jmeter issue #325: 61544 - Added read, browse and clear as communication sty...

[bennyvw]

Github user bennyvw commented on the issue:

https://github.com/apache/jmeter/pull/325
  
Processed your remarks, @pmouawad. Could you please review it again? And 
you might give us some hint why tests are failing in Travis CI. It complains 
about JMS_TESTS.JMX, but I did not find that file..


---