Re: Report : Drop Response Time Per Sample Graph

[sebb]

On 15 April 2016 at 22:45, Philippe Mouawad  wrote:
> Hello,
> I propose to drop Response Time Per Sample Graph for the following reasons:
>
>- It duplicates (in a visual manner) what already exists in the
>"Statistics" table but in a less readable way
>- Currently it does not take into account the filter on transactions
>defined with "jmeter.reportgenerator.exporter.html.series_filter"
>- As a consequence, it suffers from an existing bug:
>   - https://bz.apache.org/bugzilla/show_bug.cgi?id=58953
>- The Bar graphs are not very usable, you have to select each percentile
>to be able to read the values
>- I'm afraid it will be more difficult to drop it once it is out for
>backward compatibility
>
> As a summary, I think it is useless.
>
> If Ok, I propose to drop it before release of 3.0, I am ready to commit it.

If it has yet to be released, then feel free to drop it.

>
> Regards
> Philippe

Report : Drop Response Time Per Sample Graph

[Philippe Mouawad]

Hello,
I propose to drop Response Time Per Sample Graph for the following reasons:

   - It duplicates (in a visual manner) what already exists in the
   "Statistics" table but in a less readable way
   - Currently it does not take into account the filter on transactions
   defined with "jmeter.reportgenerator.exporter.html.series_filter"
   - As a consequence, it suffers from an existing bug:
  - https://bz.apache.org/bugzilla/show_bug.cgi?id=58953
   - The Bar graphs are not very usable, you have to select each percentile
   to be able to read the values
   - I'm afraid it will be more difficult to drop it once it is out for
   backward compatibility

As a summary, I think it is useless.

If Ok, I propose to drop it before release of 3.0, I am ready to commit it.


Regards
Philippe

[GitHub] jmeter pull request: Bug 59281 testTimeDurationGUI

[ra0077]

Github user ra0077 commented on the pull request:

https://github.com/apache/jmeter/pull/182#issuecomment-210493454
  
Hi Philippe,

I have ask to a UX Expert about this part (no time to audit all JMeter GUI)
I should have an answer next week

Antonio


---
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.
---

Early Access builds of JDK 9 b113 & JDK 9 with Project Jigsaw b113 (#4848) are available on java.net

[Rory O'Donnell]

Hi Philippe,

Early Access b113  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.


Early Access b113  (#4664) for JDK 9 with 
Project Jigsaw is available on java.net.


 * The important change in this build is that root modules when
   compiling code in the unnamed module, or when running and the main
   class is loaded from the class path, do not include the EE modules.
   More on this in JEP 261.
 * The other change in this build is that the -Xpatch option is now
   aligned with what we have documented in JEP 261, support for the old
   form has been removed.

We are very interested in hearing your experiences in testing any Early 
Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered 
showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me or 
via the mailing lists [1], [2].


Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland

Re: Bug 58679 : blocker for next release

[Milamber]

On 15/04/2016 10:17, Felix Schumacher wrote:


Am 15. April 2016 09:22:57 MESZ, schrieb Milamber :

Revert done.

Thanks.

We have to find a way to generate valid xml in 3.1, though.


Probably, the changes 58679 need more works to save in a valid xml the 
param fields of HTTP requests (inside a CDATA block if special chars are 
found?)





Felix

On 14/04/2016 22:44, Philippe Mouawad wrote:

Hello,

I created a test case not related to JMeter and submitted:

- https://github.com/x-stream/xstream/issues/51

Jörg from XStream already answered:
https://github.com/x-stream/xstream/issues/51#issuecomment-210155359



--

well, your source code already contains invalid UTF-8 characters

(assuming

your Java files are UTF-8 encoded). This means that already the

compiler

produces garbage when creating the class file.

However, not every character is valid in XML (and it depends on the

XML

version). Some parsers do not care (like Xpp3), some do (all StAX)

drivers.

See valid characters in XML spec 1.0
 and XML spec

1.1

, and

XStream's FAQ

.



--

So I think we should for now revert then see what we do with this in

the

future.


Regards
Philippe

On Thu, Apr 14, 2016 at 9:30 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:


HI Milamber,
How was this plan created ?

For me it's not a blocker as the XML is wrong. But if we end up

thinking

it is a blocker, then let's revert the code and wait for 3.1 to

"fix" this

although I don't see how it can be.
Regards

On Thu, Apr 14, 2016 at 9:10 PM, Milamber 

wrote:

Hello,

Please see the Bug 58679, I've found a regression with the changes

from

xstream/xpp librairies.

Error : missing class
com.thoughtworks.xstream.converters.ConversionException: :

ParseError at

[row,col]:
etc.

If I revert the associated commits, my simple script works.

Milamber

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




--
Cordialement.
Philippe Mouawad.

Re: Bug 58679 : blocker for next release

[Felix Schumacher]

Am 15. April 2016 09:22:57 MESZ, schrieb Milamber :
>
>Revert done.

Thanks.

We have to find a way to generate valid xml in 3.1, though. 

Felix
>
>On 14/04/2016 22:44, Philippe Mouawad wrote:
>> Hello,
>>
>> I created a test case not related to JMeter and submitted:
>>
>> - https://github.com/x-stream/xstream/issues/51
>>
>> Jörg from XStream already answered:
>> https://github.com/x-stream/xstream/issues/51#issuecomment-210155359
>>
>>
>--
>>
>> well, your source code already contains invalid UTF-8 characters
>(assuming
>> your Java files are UTF-8 encoded). This means that already the
>compiler
>> produces garbage when creating the class file.
>>
>> However, not every character is valid in XML (and it depends on the
>XML
>> version). Some parsers do not care (like Xpp3), some do (all StAX)
>drivers.
>> See valid characters in XML spec 1.0
>>  and XML spec
>1.1
>> , and
>XStream's FAQ
>> .
>>
>>
>--
>>
>> So I think we should for now revert then see what we do with this in
>the
>> future.
>>
>>
>> Regards
>> Philippe
>>
>> On Thu, Apr 14, 2016 at 9:30 PM, Philippe Mouawad <
>> philippe.moua...@gmail.com> wrote:
>>
>>> HI Milamber,
>>> How was this plan created ?
>>>
>>> For me it's not a blocker as the XML is wrong. But if we end up
>thinking
>>> it is a blocker, then let's revert the code and wait for 3.1 to
>"fix" this
>>> although I don't see how it can be.
>>> Regards
>>>
>>> On Thu, Apr 14, 2016 at 9:10 PM, Milamber 
>wrote:
>>>
 Hello,

 Please see the Bug 58679, I've found a regression with the changes
>from
 xstream/xpp librairies.

 Error : missing class
 com.thoughtworks.xstream.converters.ConversionException: :
>ParseError at
 [row,col]:
 etc.

 If I revert the associated commits, my simple script works.

 Milamber

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



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

Re: Bug 58679 : blocker for next release

[Philippe Mouawad]

Thanks a lot Milamber for your tests and findings.

On Friday, April 15, 2016, Milamber  wrote:

>
> Revert done.
>
> On 14/04/2016 22:44, Philippe Mouawad wrote:
>
>> Hello,
>>
>> I created a test case not related to JMeter and submitted:
>>
>> - https://github.com/x-stream/xstream/issues/51
>>
>> Jörg from XStream already answered:
>> https://github.com/x-stream/xstream/issues/51#issuecomment-210155359
>>
>>
>> --
>>
>> well, your source code already contains invalid UTF-8 characters (assuming
>> your Java files are UTF-8 encoded). This means that already the compiler
>> produces garbage when creating the class file.
>>
>> However, not every character is valid in XML (and it depends on the XML
>> version). Some parsers do not care (like Xpp3), some do (all StAX)
>> drivers.
>> See valid characters in XML spec 1.0
>>  and XML spec 1.1
>> , and XStream's
>> FAQ
>> .
>>
>>
>> --
>>
>> So I think we should for now revert then see what we do with this in the
>> future.
>>
>>
>> Regards
>> Philippe
>>
>> On Thu, Apr 14, 2016 at 9:30 PM, Philippe Mouawad <
>> philippe.moua...@gmail.com> wrote:
>>
>> HI Milamber,
>>> How was this plan created ?
>>>
>>> For me it's not a blocker as the XML is wrong. But if we end up thinking
>>> it is a blocker, then let's revert the code and wait for 3.1 to "fix"
>>> this
>>> although I don't see how it can be.
>>> Regards
>>>
>>> On Thu, Apr 14, 2016 at 9:10 PM, Milamber  wrote:
>>>
>>> Hello,

 Please see the Bug 58679, I've found a regression with the changes from
 xstream/xpp librairies.

 Error : missing class
 com.thoughtworks.xstream.converters.ConversionException: : ParseError at
 [row,col]:
 etc.

 If I revert the associated commits, my simple script works.

 Milamber

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




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

-- 
Cordialement.
Philippe Mouawad.

Re: Bug 58679 : blocker for next release

[Milamber]

Revert done.

On 14/04/2016 22:44, Philippe Mouawad wrote:

Hello,

I created a test case not related to JMeter and submitted:

- https://github.com/x-stream/xstream/issues/51

Jörg from XStream already answered:
https://github.com/x-stream/xstream/issues/51#issuecomment-210155359

--

well, your source code already contains invalid UTF-8 characters (assuming
your Java files are UTF-8 encoded). This means that already the compiler
produces garbage when creating the class file.

However, not every character is valid in XML (and it depends on the XML
version). Some parsers do not care (like Xpp3), some do (all StAX) drivers.
See valid characters in XML spec 1.0
 and XML spec 1.1
, and XStream's FAQ
.

--

So I think we should for now revert then see what we do with this in the
future.


Regards
Philippe

On Thu, Apr 14, 2016 at 9:30 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:


HI Milamber,
How was this plan created ?

For me it's not a blocker as the XML is wrong. But if we end up thinking
it is a blocker, then let's revert the code and wait for 3.1 to "fix" this
although I don't see how it can be.
Regards

On Thu, Apr 14, 2016 at 9:10 PM, Milamber  wrote:


Hello,

Please see the Bug 58679, I've found a regression with the changes from
xstream/xpp librairies.

Error : missing class
com.thoughtworks.xstream.converters.ConversionException: : ParseError at
[row,col]:
etc.

If I revert the associated commits, my simple script works.

Milamber

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





--
Cordialement.
Philippe Mouawad.

[GitHub] jmeter pull request: Revert Bugzilla 58679

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---