Re: Management of Redirect and rfc7231

2016-03-18 Thread Philippe Mouawad 
Ok sebb, but what about the target rfc we want to support ?
Thanks

On Thu, Mar 17, 2016 at 9:54 PM, sebb  wrote:

> Ideally JMeter should delegate the redirect decision to the HTTP library.
>
> However this may not be possible for all libraries.
>
> On 17 March 2016 at 20:46, Philippe Mouawad 
> wrote:
> > +1 for this change
> >
> > @all thoughts ?
> >
> > On Thu, Mar 17, 2016 at 4:15 PM, UBIK LOAD PACK Support <
> > supp...@ubikloadpack.com> wrote:
> >
> >> Hello Team,
> >> Is JMeter 3.0 supposed to support :
> >>
> >>- https://tools.ietf.org/html/rfc7231
> >>
> >>
> >> 1/ If so there may be an issue in support of Redirect:
> >>
> >>- https://tools.ietf.org/html/rfc7231#section-6.4
> >>
> >>
> >> Currently only Head is considered as Safe:
> >>
> >>-
> >>
> https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java#L1504
> >>
> >>
> >> But as per https://tools.ietf.org/html/rfc7231#section-4.2.1:
> >>
> >> GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.
> >>
> >>
> >> So if JMeter is supposed to respect rfc7231, this should be fixed.
> >>
> >> 2/ Besides, as per https://tools.ietf.org/html/rfc7231#section-6.4.7,
> 307
> >> redirect code does not allow to change the initial method , so 307
> redirect
> >> code should be managed differently
> >>
> >>
> >> We can create a PR to fix this.
> >>
> >> Thanks
> >>
> >> Regards
> >> UbikLoadPack Support Team
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

Re: svn commit: r1735407 - in /jmeter/trunk: build.properties build.xml eclipse.classpath lib/ lib/aareadme.txt res/maven/ApacheJMeter_parent.pom xdocs/changes.xml

2016-03-18 Thread sebb 
This is a new 3rd party jar.
The license needs to be checked for compatibility and if OK must be
documented in LICENSE - and stored locally if it is not AL 2.0


On 17 March 2016 at 12:14,   wrote:
> Author: pmouawad
> Date: Thu Mar 17 12:14:44 2016
> New Revision: 1735407
>
> URL: http://svn.apache.org/viewvc?rev=1735407=rev
> Log:
> Bug 59187 - JSON Post Processor : java.lang.NoClassDefFoundError: 
> net/minidev/asm/FieldFilter at 
> net.minidev.json.reader.JsonWriter.(JsonWriter.java:157) (affects nightly 
> build before 3.0 release)
> Bugzilla Id: 59187
>
> Modified:
> jmeter/trunk/build.properties
> jmeter/trunk/build.xml
> jmeter/trunk/eclipse.classpath
> jmeter/trunk/lib/   (props changed)
> jmeter/trunk/lib/aareadme.txt
> jmeter/trunk/res/maven/ApacheJMeter_parent.pom
> jmeter/trunk/xdocs/changes.xml
>
> Modified: jmeter/trunk/build.properties
> URL: 
> http://svn.apache.org/viewvc/jmeter/trunk/build.properties?rev=1735407=1735406=1735407=diff
> ==
> --- jmeter/trunk/build.properties (original)
> +++ jmeter/trunk/build.properties Thu Mar 17 12:14:44 2016
> @@ -42,11 +42,21 @@
>
>  maven2.repo = https://repo1.maven.org/maven2
>
> +accessors-smart.version = 1.1
> +accessors-smart.jar = accessors-smart-${accessors-smart.version}.jar
> +accessors-smart.loc = 
> ${maven2.repo}/net/minidev/accessors-smart/${accessors-smart.version}
> +accessors-smart.md5 = b75cda0d7dadff9e6c20f4e7f3c3bc82
> +
>  apache-bsf.version  = 2.4.0
>  apache-bsf.jar  = bsf-${apache-bsf.version}.jar
>  apache-bsf.loc  = ${maven2.repo}/bsf/bsf/${apache-bsf.version}
>  apache-bsf.md5  = 16e82d858c648962fb5c959f21959039
>
> +asm.version = 5.1
> +asm.jar = asm-${asm.version}.jar
> +asm.loc = ${maven2.repo}/org/ow2/asm/asm/${asm.version}
> +asm.md5 = 3770466405f163d6616b65c32e16a3cd
> +
>  avalon-framework.version= 4.1.4
>  avalon-framework.jar= 
> avalon-framework-${avalon-framework.version}.jar
>  avalon-framework.loc= 
> ${maven2.repo}/avalon-framework/avalon-framework/${avalon-framework.version}
>
> Modified: jmeter/trunk/build.xml
> URL: 
> http://svn.apache.org/viewvc/jmeter/trunk/build.xml?rev=1735407=1735406=1735407=diff
> ==
> --- jmeter/trunk/build.xml (original)
> +++ jmeter/trunk/build.xml Thu Mar 17 12:14:44 2016
> @@ -360,7 +360,9 @@
>
>
>
> +   
>  
> +
>  
>  
>  
> @@ -432,7 +434,9 @@
>
>
>  
> +   
>  
> +
>  
>  
>  
> @@ -2848,7 +2852,9 @@ run JMeter unless all the JMeter jars ar
>  conditional execution (it would be a lot easier if antcall supported 
> if/unless).
>  -->
>  
> -
> +
> +   
> +
>  
>  
>  
>
> Modified: jmeter/trunk/eclipse.classpath
> URL: 
> http://svn.apache.org/viewvc/jmeter/trunk/eclipse.classpath?rev=1735407=1735406=1735407=diff
> ==
> --- jmeter/trunk/eclipse.classpath (original)
> +++ jmeter/trunk/eclipse.classpath Thu Mar 17 12:14:44 2016
> @@ -43,6 +43,8 @@
>  path="src/protocol/native"/>
>  path="src/protocol/tcp"/>
> 
> +
> +
> 
> 
> 
>
> Propchange: jmeter/trunk/lib/
> --
> --- svn:ignore (original)
> +++ svn:ignore Thu Mar 17 12:14:44 2016
> @@ -1,5 +1,7 @@
>  ext
>  src
> +accessors-smart-1.1.jar
> +asm-5.1.jar
>  avalon-framework-4.1.4.jar
>  bsf-2.4.0.jar
>  bsh-2.0b5.jar
>
> Modified: jmeter/trunk/lib/aareadme.txt
> URL: 
> http://svn.apache.org/viewvc/jmeter/trunk/lib/aareadme.txt?rev=1735407=1735406=1735407=diff
> ==
> --- jmeter/trunk/lib/aareadme.txt (original)
> +++ jmeter/trunk/lib/aareadme.txt Thu Mar 17 12:14:44 2016
> @@ -13,6 +13,14 @@ Which jars are used by which modules?
>  
>  [not exhaustive]
>
> +asm-5.1 (org.ow2.asm)
> +--
> +- JSON Path extractor
> +
> +accessors-smart-1.1 (net.minidev)
> +--
> +- JSON Path extractor
> +
>  avalon-framework-4.1.4 (org.apache.avalon.framework)
>  --
>  - LogKit (LoggingManager)
> @@ -144,7 +152,7 @@ https://github.com/jayway/JsonPath
>  - JSON Path Extractor
>  - JSON Path Renderer
>
> -json-smart-2.2.1
> +json-smart-2.2.1 (net.minidev)
>  
>  https://github.com/netplex/json-smart-v2
>  - JSON Path Extractor
>
> Modified: jmeter/trunk/res/maven/ApacheJMeter_parent.pom
> URL: 
>

Re: Remaining Work before Release of 3.0

2016-03-18 Thread sebb 
On 17 March 2016 at 16:59, Philippe Mouawad  wrote:
> Hi sebb,
> I have fixed 1/4 issues reported in 59173 and think other "issues" should
> be mentioned in changes and not fixed as I think some cannot be without
> important work without real ROI.

? cannot parse.

> Regarding 58832, it's a minor issue without effect as report works and
> displays fine under ff, chrome, safari and IE and generation works fine on
> windows, linux and macosx.
> So unless you have an issue with it that you clearly find as blocker I
> don't think it should delay release.

I've already renamed the files and marked the bug fixed.

> Can you answer my question on output report in the bugzilla your reopened ?
> so that I can proceed withfix ?

What question?

> Finally regarding the order of columns in the Save configuration, you
> commited something but issue is not in changes nor resolved, what's the
> status on it ?

Waiting for review to see if the order is sensible or not.
We don't want to change it unnecessarily later.

Also note that various new jars need to be mentioned in LICENSE.
This assumes that their licenses are compatible; I've not seen any
analysis of them.

> Thanks
>
> On Wednesday, March 16, 2016, sebb  wrote:
>
>> There are some regressions/new bugs:
>>
>> Bug 59173
>>
>> Bug 58832
>>
>>
>>
>> On 16 March 2016 at 19:16, Philippe Mouawad > > wrote:
>> > Hi sebb,
>> > With the last commits and comments on the issues you mentioned,
>> > can we consider that remaining work is the following:
>> > - sort the columns of saved columns per english translation : you seem to
>> > be handling it
>> > - for the output of reports, check that if -o is not used the default
>> > target folder is not overwritten if not empty. I propose to delay other
>> > propositions to next 3.1 and wait for user feedback. I can take it unless
>> > sebb you want to
>> > - fix the NTLM auth issue with https: Felix can you confirm you will be
>> > able to fix it in a not too big delay ?
>> > - screenshots for all modified elements, volunteers ?
>> > - new and noteworthy section, I can start it
>> >
>> >
>> > We're now 1 year since we released 2.13, I think users are waiting this
>> 3.0
>> > .
>> >
>> > I am as a user
>> >
>> >
>> > Thanks
>> > On Tuesday, March 15, 2016, Philippe Mouawad > >
>> > wrote:
>> >
>> >>
>> >>
>> >> On Tue, Mar 15, 2016 at 9:45 PM, Felix Schumacher <
>> >> felix.schumac...@internetallee.de 
>> >> > ');>>
>> >> wrote:
>> >>
>> >>>
>> >>>
>> >>> Am 14. März 2016 21:58:50 MEZ, schrieb Philippe Mouawad <
>> >>> philippe.moua...@gmail.com 
>> >>> > ');>>:
>> >>> >On Monday, March 14, 2016, Felix Schumacher <
>> >>> >felix.schumac...@internetallee.de 
>> >>> > ');>>
>> >>> wrote:
>> >>> >
>> >>> >> Am 14.03.2016 um 21:34 schrieb Philippe Mouawad:
>> >>> >>
>> >>> >>> Hello,
>> >>> >>> All remaining issues before 3.0 are now fixed.
>> >>> >>>
>> >>> >> https://issues.apache.org/jira/browse/HTTPCLIENT-1712
>> >>> >> means that we can't do kerberos with https. Is this a big problem?
>> >>> >
>> >>> >
>> >>> >are we able to workaround in jmeter the issue ?
>> >>> >If not it would mean we have to wait for a 4.5.3
>> >>> >
>> >>> >It does not seem critical for me but I don't know
>> >>>
>> >>> We could work around it. We would have to subclass two classes.
>> >>> SPnegoScheme and its factory.
>> >>>
>> >> Let's do that Felix if you think we need to fix it before 3.0.
>> >>
>> >>>
>> >>> The problem is fixed in httpclients trunk, but I don't know when a next
>> >>> release is planned.
>> >>>
>> >>
>> >> 4.5.2 was just released, I doubt a new one will be released for such a
>> bug
>> >>
>> >>
>> >>>
>> >>> Felix
>> >>>
>> >>> >
>> >>> >>
>> >>> >> Felix
>> >>> >>
>> >>> >>>
>> >>> >>> Except for the documentation screenshots everything is ready for a
>> >>> >>> release.
>> >>> >>>
>> >>> >>> When do we launch the release of 3.0 ?
>> >>> >>>
>> >>> >>> Regards
>> >>> >>> Philippe
>> >>> >>>
>> >>> >>>
>> >>> >>> On Fri, Mar 11, 2016 at 8:20 AM, Milamber > 
>> >>> ');>>
>> >>> >wrote:
>> >>> >>>
>> >>> >>>
>> >>>  On 08/03/2016 23:02, Philippe Mouawad wrote:
>> >>> 
>> >>>  @Milamber, do you intend to take into account before 3.0 release
>> >>> >the
>> >>> > notes
>> >>> > from Benoit Wiart:
>> >>> > -https://bz.apache.org/bugzilla/show_bug.cgi?id=58426
>> >>> >
>> >>> > Not before the 3.0.
>> >>> 
>> >>> 
>> >>>  If not, I suggest we close this one and open a new one to complete
>> >>> >HiDPI
>>

[GitHub] jmeter pull request: Force JSONPATH to always return list of Objec...

2016-03-18 Thread pmouawad 
Github user pmouawad commented on the pull request:

https://github.com/apache/jmeter/pull/168#issuecomment-197558458
  
Hello Maxime,
Could you provide a simple test plan showing the bug you faced ?
Thank you


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

Re: IllegalAccessError when running ant run_gui

2016-03-18 Thread Philippe Mouawad 
I found the problem.
run_gui uses a classpath which is wrong, since the classpath is build by
NewDriver
I will create a bug to trace the change

On Thu, Mar 17, 2016 at 8:44 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> I also get this one before If my plan contains a CookieManager:
> 2016/03/17 20:42:20 ERROR - jmeter.protocol.http.control.CookieManager:
> Unable to load or invoke class:
> org.apache.jmeter.protocol.http.control.HC4CookieHandler
> org.apache.jorphan.util.JMeterException: java.lang.ClassNotFoundException:
> org.apache.jmeter.protocol.http.control.HC4CookieHandler
> at org.apache.jorphan.reflect.ClassTools.construct(ClassTools.java:92)
> at
> org.apache.jmeter.protocol.http.control.CookieManager.testStarted(CookieManager.java:417)
> at
> org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart(StandardJMeterEngine.java:203)
> at
> org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:324)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.jmeter.protocol.http.control.HC4CookieHandler
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:191)
> at org.apache.jorphan.reflect.ClassTools.construct(ClassTools.java:86)
> ... 4 more
>
> On Thu, Mar 17, 2016 at 7:07 PM, Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>> Hi all,
>>
>> currently I get
>>
>> 2016/03/17 19:04:07 ERROR - jmeter.threads.JMeterThread: Test failed!
>> java.lang.IllegalAccessError: tried to access class
>> org.apache.http.impl.conn.HttpConnPool from class
>> org.apache.http.impl.conn.JMeterPoolingClientConnectionManager
>> at
>> org.apache.http.impl.conn.JMeterPoolingClientConnectionManager.(JMeterPoolingClientConnectionManager.java:111)
>> at
>> org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager.(MeasuringConnectionManager.java:59)
>> at
>> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.setupClient(HTTPHC4Impl.java:724)
>> at
>> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:274)
>> at
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
>> at
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1143)
>> at
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1132)
>> at
>> org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:465)
>> at
>> org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:410)
>> at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:241)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> when I run a simple http sampler when jmeter was started with "ant
>> run_gui". If I start it with bin/jmeter it works without a problem.
>>
>> The problem is probably that HttpConnPool and
>> JMeterPoolingClientConnectionManager are in different classloaders in the
>> first case, but I don't know, why that would be.
>>
>> Any thoughts?
>>  Felix
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

buildbot success in on jmeter-trunk

2016-03-18 Thread buildbot 
The Buildbot has detected a restored build on builder jmeter-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/jmeter-trunk/builds/855

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: hemera_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-jmeter-commit' 
triggered this build
Build Source Stamp: [branch jmeter/trunk] 1735576
Blamelist: fschumacher

Build succeeded!

Sincerely,
 -The Buildbot

Re: svn commit: r1735407 - in /jmeter/trunk: build.properties build.xml eclipse.classpath lib/ lib/aareadme.txt res/maven/ApacheJMeter_parent.pom xdocs/changes.xml

2016-03-18 Thread Philippe Mouawad 
Done

On Thu, Mar 17, 2016 at 4:56 PM, sebb  wrote:

> This is a new 3rd party jar.
> The license needs to be checked for compatibility and if OK must be
> documented in LICENSE - and stored locally if it is not AL 2.0
>
>
> On 17 March 2016 at 12:14,   wrote:
> > Author: pmouawad
> > Date: Thu Mar 17 12:14:44 2016
> > New Revision: 1735407
> >
> > URL: http://svn.apache.org/viewvc?rev=1735407=rev
> > Log:
> > Bug 59187 - JSON Post Processor : java.lang.NoClassDefFoundError:
> net/minidev/asm/FieldFilter at
> net.minidev.json.reader.JsonWriter.(JsonWriter.java:157) (affects nightly
> build before 3.0 release)
> > Bugzilla Id: 59187
> >
> > Modified:
> > jmeter/trunk/build.properties
> > jmeter/trunk/build.xml
> > jmeter/trunk/eclipse.classpath
> > jmeter/trunk/lib/   (props changed)
> > jmeter/trunk/lib/aareadme.txt
> > jmeter/trunk/res/maven/ApacheJMeter_parent.pom
> > jmeter/trunk/xdocs/changes.xml
> >
> > Modified: jmeter/trunk/build.properties
> > URL:
> http://svn.apache.org/viewvc/jmeter/trunk/build.properties?rev=1735407=1735406=1735407=diff
> >
> ==
> > --- jmeter/trunk/build.properties (original)
> > +++ jmeter/trunk/build.properties Thu Mar 17 12:14:44 2016
> > @@ -42,11 +42,21 @@
> >
> >  maven2.repo = https://repo1.maven.org/maven2
> >
> > +accessors-smart.version = 1.1
> > +accessors-smart.jar =
> accessors-smart-${accessors-smart.version}.jar
> > +accessors-smart.loc =
> ${maven2.repo}/net/minidev/accessors-smart/${accessors-smart.version}
> > +accessors-smart.md5 = b75cda0d7dadff9e6c20f4e7f3c3bc82
> > +
> >  apache-bsf.version  = 2.4.0
> >  apache-bsf.jar  = bsf-${apache-bsf.version}.jar
> >  apache-bsf.loc  =
> ${maven2.repo}/bsf/bsf/${apache-bsf.version}
> >  apache-bsf.md5  = 16e82d858c648962fb5c959f21959039
> >
> > +asm.version = 5.1
> > +asm.jar = asm-${asm.version}.jar
> > +asm.loc =
> ${maven2.repo}/org/ow2/asm/asm/${asm.version}
> > +asm.md5 = 3770466405f163d6616b65c32e16a3cd
> > +
> >  avalon-framework.version= 4.1.4
> >  avalon-framework.jar=
> avalon-framework-${avalon-framework.version}.jar
> >  avalon-framework.loc=
> ${maven2.repo}/avalon-framework/avalon-framework/${avalon-framework.version}
> >
> > Modified: jmeter/trunk/build.xml
> > URL:
> http://svn.apache.org/viewvc/jmeter/trunk/build.xml?rev=1735407=1735406=1735407=diff
> >
> ==
> > --- jmeter/trunk/build.xml (original)
> > +++ jmeter/trunk/build.xml Thu Mar 17 12:14:44 2016
> > @@ -360,7 +360,9 @@
> >
> >
> >
> > +   
> >  
> > +
> >  
> >  
> >  
> > @@ -432,7 +434,9 @@
> >
> >
> >  
> > +   
> >  
> > +
> >  
> >  
> >  
> > @@ -2848,7 +2852,9 @@ run JMeter unless all the JMeter jars ar
> >  conditional execution (it would be a lot easier if antcall
> supported if/unless).
> >  -->
> >  
> > -
> > +
> > +   
> > +
> >  
> >  
> >  
> >
> > Modified: jmeter/trunk/eclipse.classpath
> > URL:
> http://svn.apache.org/viewvc/jmeter/trunk/eclipse.classpath?rev=1735407=1735406=1735407=diff
> >
> ==
> > --- jmeter/trunk/eclipse.classpath (original)
> > +++ jmeter/trunk/eclipse.classpath Thu Mar 17 12:14:44 2016
> > @@ -43,6 +43,8 @@
> >  path="src/protocol/native"/>
> >  path="src/protocol/tcp"/>
> > 
> > +
> > +
> >  path="lib/avalon-framework-4.1.4.jar"/>
> > 
> > 
> >
> > Propchange: jmeter/trunk/lib/
> >
> --
> > --- svn:ignore (original)
> > +++ svn:ignore Thu Mar 17 12:14:44 2016
> > @@ -1,5 +1,7 @@
> >  ext
> >  src
> > +accessors-smart-1.1.jar
> > +asm-5.1.jar
> >  avalon-framework-4.1.4.jar
> >  bsf-2.4.0.jar
> >  bsh-2.0b5.jar
> >
> > Modified: jmeter/trunk/lib/aareadme.txt
> > URL:
> http://svn.apache.org/viewvc/jmeter/trunk/lib/aareadme.txt?rev=1735407=1735406=1735407=diff
> >
> ==
> > --- jmeter/trunk/lib/aareadme.txt (original)
> > +++ jmeter/trunk/lib/aareadme.txt Thu Mar 17 12:14:44 2016
> > @@ -13,6 +13,14 @@ Which jars are used by which modules?
> >  
> >  [not exhaustive]
> >
> > +asm-5.1 (org.ow2.asm)
> > +--
> > +- JSON Path extractor
> > +
> > +accessors-smart-1.1 (net.minidev)
> > +--
> > +- JSON Path extractor
> > +
> >  avalon-framework-4.1.4 (org.apache.avalon.framework)
> >  --
> >  - LogKit

buildbot success in on jmeter-trunk

2016-03-18 Thread buildbot 
The Buildbot has detected a restored build on builder jmeter-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/jmeter-trunk/builds/843

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: hemera_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-jmeter-commit' 
triggered this build
Build Source Stamp: [branch jmeter/trunk] 1735541
Blamelist: pmouawad

Build succeeded!

Sincerely,
 -The Buildbot

Re: Remaining Work before Release of 3.0

2016-03-18 Thread sebb 
There are some regressions/new bugs:

Bug 59173

Bug 58832



On 16 March 2016 at 19:16, Philippe Mouawad  wrote:
> Hi sebb,
> With the last commits and comments on the issues you mentioned,
> can we consider that remaining work is the following:
> - sort the columns of saved columns per english translation : you seem to
> be handling it
> - for the output of reports, check that if -o is not used the default
> target folder is not overwritten if not empty. I propose to delay other
> propositions to next 3.1 and wait for user feedback. I can take it unless
> sebb you want to
> - fix the NTLM auth issue with https: Felix can you confirm you will be
> able to fix it in a not too big delay ?
> - screenshots for all modified elements, volunteers ?
> - new and noteworthy section, I can start it
>
>
> We're now 1 year since we released 2.13, I think users are waiting this 3.0
> .
>
> I am as a user
>
>
> Thanks
> On Tuesday, March 15, 2016, Philippe Mouawad 
> wrote:
>
>>
>>
>> On Tue, Mar 15, 2016 at 9:45 PM, Felix Schumacher <
>> felix.schumac...@internetallee.de
>> >
>> wrote:
>>
>>>
>>>
>>> Am 14. März 2016 21:58:50 MEZ, schrieb Philippe Mouawad <
>>> philippe.moua...@gmail.com
>>> >:
>>> >On Monday, March 14, 2016, Felix Schumacher <
>>> >felix.schumac...@internetallee.de
>>> >
>>> wrote:
>>> >
>>> >> Am 14.03.2016 um 21:34 schrieb Philippe Mouawad:
>>> >>
>>> >>> Hello,
>>> >>> All remaining issues before 3.0 are now fixed.
>>> >>>
>>> >> https://issues.apache.org/jira/browse/HTTPCLIENT-1712
>>> >> means that we can't do kerberos with https. Is this a big problem?
>>> >
>>> >
>>> >are we able to workaround in jmeter the issue ?
>>> >If not it would mean we have to wait for a 4.5.3
>>> >
>>> >It does not seem critical for me but I don't know
>>>
>>> We could work around it. We would have to subclass two classes.
>>> SPnegoScheme and its factory.
>>>
>> Let's do that Felix if you think we need to fix it before 3.0.
>>
>>>
>>> The problem is fixed in httpclients trunk, but I don't know when a next
>>> release is planned.
>>>
>>
>> 4.5.2 was just released, I doubt a new one will be released for such a bug
>>
>>
>>>
>>> Felix
>>>
>>> >
>>> >>
>>> >> Felix
>>> >>
>>> >>>
>>> >>> Except for the documentation screenshots everything is ready for a
>>> >>> release.
>>> >>>
>>> >>> When do we launch the release of 3.0 ?
>>> >>>
>>> >>> Regards
>>> >>> Philippe
>>> >>>
>>> >>>
>>> >>> On Fri, Mar 11, 2016 at 8:20 AM, Milamber >> >
>>> >wrote:
>>> >>>
>>> >>>
>>>  On 08/03/2016 23:02, Philippe Mouawad wrote:
>>> 
>>>  @Milamber, do you intend to take into account before 3.0 release
>>> >the
>>> > notes
>>> > from Benoit Wiart:
>>> > -https://bz.apache.org/bugzilla/show_bug.cgi?id=58426
>>> >
>>> > Not before the 3.0.
>>> 
>>> 
>>>  If not, I suggest we close this one and open a new one to complete
>>> >HiDPI
>>> > support in 3.1
>>> >
>>> > That seems a good idea.
>>> 
>>> 
>>>  Milamber
>>> 
>>> 
>>> >>>
>>> >>>
>>> >>
>>>
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.

[GitHub] jmeter pull request: java constants naming

2016-03-18 Thread benbenw 
GitHub user benbenw opened a pull request:

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

java constants naming



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

$ git pull https://github.com/benbenw/jmeter javanaming

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

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


commit 2c291a3547387a43ecaed2aa926fef045d6f263d
Author: benoit 
Date:   2016-03-18T16:37:13Z

java constants naming




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

Re: [GitHub] jmeter pull request: java constants naming

2016-03-18 Thread Philippe Mouawad 
Hello,
Frankly I don't understand this discussion:

   - LOG (Upper Case) for static is the usual policy that is applied by all
   of us since few time
   - The guy named it LOGGER, what's the problem except that it does not
   suit a particular taste ? :
  - It is in UPPERCASE
  - It is meaningful
  - and if we don't like it, why just not merge it and rename the
  variable ?


Finally, the guy here ( Benoit W.) contributed around 100 patches on this
version ! (many very precious),
do you think this kind of big discussion for a Variable naming without a
THANK YOU ! and a HELLO ! is a good way to encourage other contributors ?

I don't think so, and  I disagree with such behaviour !



Regards
Philippe


On Fri, Mar 18, 2016 at 7:06 PM, sebb  wrote:

> On 18 March 2016 at 17:55, Vladimir Sitnikov
>  wrote:
> >>Why change log to LOGGER?
> >>It would make more sense to change it to LOG
> >
> > Frankly speaking, I think lowercase log is just perfect.
> > What is the purpose of making LOG shout at you?
> >
> > Isn't log.info(...) self-descriptive enough?
>
> Good point.
> [But if it is to be changed, it should be just upcased.]
>
> On reflection I agree with you that it makes sense to leave "log" as
> lower-case.
>
> For the other constants, using the conventional upper-case is generally
> helpful.
>
> > Vladimir
>



-- 
Cordialement.
Philippe Mouawad.

[GitHub] jmeter pull request: Force JSONPATH to always return list of Objec...

2016-03-18 Thread pmouawad 
Github user pmouawad commented on the pull request:

https://github.com/apache/jmeter/pull/168#issuecomment-197859425
  
Fixed with commit


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

[GitHub] jmeter pull request: deprecate some methods in JMeterUtils

2016-03-18 Thread pmouawad 
Github user pmouawad commented on the pull request:

https://github.com/apache/jmeter/pull/148#issuecomment-198560249
  
pong

Thanks


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

[GitHub] jmeter pull request: deprecate some methods in JMeterUtils

2016-03-18 Thread asfgit 
Github user asfgit closed the pull request at:

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


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

Re: New fields/changed defaults cause earlier test plans to be marked as changed (bug 59173)

2016-03-18 Thread sebb 
On 18 March 2016 at 22:10, Philippe Mouawad  wrote:
> On Fri, Mar 18, 2016 at 11:02 PM, sebb  wrote:
>
>> On 18 March 2016 at 21:46, Philippe Mouawad 
>> wrote:
>> > Hello,
>> >
>> > Sebb opened a bug 59173 reporting a problem of "spurious" save message
>> when
>> > 4 elements are selected.
>> >
>> >
>> > I fixed 1/4 of these.
>> > The problem is that fixing the 3/4 other "issues" is if not impossible
>> not
>> > simple at all:
>> >
>> > 1/ Access Log Sampler:
>> >
>> > AFAIU (but I may not understand well) , nothing seems to be available
>> > for this case when using
>> > BeanInfo
>>
>> True, but it could be added fairly easily.
>>
> Great news. So can you add it or explain it to me ?

Looking at it now.

>>
>> >
>> > 2/ JMS Publisher:
>> >
>> > There was a mistake made in previous release (my fault) when adding 2
>> > properties.
>> >
>> > Fixing the bug makes code ugly. I personally prefer the spurious
>> > message vs the ugly code.
>>
>> Yes, but you are a developer who understands why this message occurs.
>>
>> I am too, but I still find it very disconcerting when I'm told my test
>> plan has been changed without having done anything.
>>
>>
> I tried to find a clean fix, I didn't.

What fix did you find?

>
>> >
>> >
>> > 3/ Backend Listener :
>> > - A new parameter was added , AFAIK (but I may be wrong) we have
>> > nothing currently to handle this case. But it does not hurt me, as
>> > JMeter 3.0 adds a new parameter, the test plan really changed.
>>
>> But this is precisely the issue.
>> The test plan from 2.13 behaves exactly the same in 3.0 (if not,
>> there's another bug).
>> The new parameter defaults to false, so if it is missing the test
>> behaves as before.
>>
>> > - This informs indirectly the user of this new property.
>>
>> But the new property does not change the test unless it is changed
>> from the default, so it's really not helpful.
>>
>> Imagine if your favourite word processor behaved like this.
>>
>> You write a document and save it.
>> Later on you open it in a new version of the program; you don't make
>> any changes.
>> Yet when you close the document the word processor asks you to save it.
>> That would be very disconcerting.
>> You would wonder if you had changed anything by mistake.
>>
>
> It's true.
> But we can add it as a known issue and fix it in next release.

No, we cannot.

>>
>> >
>> > For 1/ and 3/, maybe we can implement it in a future release but I
>> > don't think it should be blocker for the 3.0 release.
>>
>> We have either got to do it now or not at all.
>> Otherwise we have the same issue for plans created in 3.0.
>>
>
> No as we would have fixed it in 3.1.

Not possible.

If we don't fix 3.0, then it will save the extra properties.

If we do fix 3.1 so its test plans agree with 2.13, then its test
plans won't agree with 3.0.

In other words:

We start with TP2.13 != TP3.0

If we make TP3.1 == TP2.13 that implies TP3.1 != TP3.0.

The problem has to be fixed now, or not at all for these particular
test element properties.

Going forward, we need to make sure that we don't cause the problem
again for other test elements.

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

[GitHub] jmeter pull request: Force JSONPATH to always return list of Objec...

2016-03-18 Thread max3163 
GitHub user max3163 opened a pull request:

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

Force JSONPATH to always return list of Object

When the JSONPATH expression retrieve only one value, an exeption was 
thrown ( Unable to cast String type to List type by example)
Add the Option.ALWAYS_RETURN_LIST force JSONPATH to always return a list.
To avoid problem of cast, the list type is set to Object.

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

$ git pull https://github.com/max3163/jmeter trunk

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

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


commit b7f85917865a5c0ee19cd8dee69e5f08c041b622
Author: max 
Date:   2016-03-16T21:10:14Z

Force JSONPATH to always return list of Object




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

buildbot success in on jmeter-trunk

2016-03-18 Thread buildbot 
The Buildbot has detected a restored build on builder jmeter-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/jmeter-trunk/builds/834

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: hemera_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-jmeter-commit' 
triggered this build
Build Source Stamp: [branch jmeter/trunk] 1735409
Blamelist: pmouawad

Build succeeded!

Sincerely,
 -The Buildbot

IllegalAccessError when running ant run_gui

2016-03-18 Thread Felix Schumacher 

Hi all,

currently I get

2016/03/17 19:04:07 ERROR - jmeter.threads.JMeterThread: Test failed! 
java.lang.IllegalAccessError: tried to access class 
org.apache.http.impl.conn.HttpConnPool from class 
org.apache.http.impl.conn.JMeterPoolingClientConnectionManager
at 
org.apache.http.impl.conn.JMeterPoolingClientConnectionManager.(JMeterPoolingClientConnectionManager.java:111)
at 
org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager.(MeasuringConnectionManager.java:59)
at 
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.setupClient(HTTPHC4Impl.java:724)
at 
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:274)
at 
org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at 
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1143)
at 
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1132)
at 
org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:465)
at 
org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:410)

at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:241)
at java.lang.Thread.run(Thread.java:745)

when I run a simple http sampler when jmeter was started with "ant 
run_gui". If I start it with bin/jmeter it works without a problem.


The problem is probably that HttpConnPool and 
JMeterPoolingClientConnectionManager are in different classloaders in 
the first case, but I don't know, why that would be.


Any thoughts?
 Felix

Re: New fields/changed defaults cause earlier test plans to be marked as changed (bug 59173)

2016-03-18 Thread sebb 
On 18 March 2016 at 21:46, Philippe Mouawad  wrote:
> Hello,
>
> Sebb opened a bug 59173 reporting a problem of "spurious" save message when
> 4 elements are selected.
>
>
> I fixed 1/4 of these.
> The problem is that fixing the 3/4 other "issues" is if not impossible not
> simple at all:
>
> 1/ Access Log Sampler:
>
> AFAIU (but I may not understand well) , nothing seems to be available
> for this case when using
> BeanInfo

True, but it could be added fairly easily.

>
> 2/ JMS Publisher:
>
> There was a mistake made in previous release (my fault) when adding 2
> properties.
>
> Fixing the bug makes code ugly. I personally prefer the spurious
> message vs the ugly code.

Yes, but you are a developer who understands why this message occurs.

I am too, but I still find it very disconcerting when I'm told my test
plan has been changed without having done anything.

>
>
> 3/ Backend Listener :
> - A new parameter was added , AFAIK (but I may be wrong) we have
> nothing currently to handle this case. But it does not hurt me, as
> JMeter 3.0 adds a new parameter, the test plan really changed.

But this is precisely the issue.
The test plan from 2.13 behaves exactly the same in 3.0 (if not,
there's another bug).
The new parameter defaults to false, so if it is missing the test
behaves as before.

> - This informs indirectly the user of this new property.

But the new property does not change the test unless it is changed
from the default, so it's really not helpful.

Imagine if your favourite word processor behaved like this.

You write a document and save it.
Later on you open it in a new version of the program; you don't make
any changes.
Yet when you close the document the word processor asks you to save it.
That would be very disconcerting.
You would wonder if you had changed anything by mistake.

>
> For 1/ and 3/, maybe we can implement it in a future release but I
> don't think it should be blocker for the 3.0 release.

We have either got to do it now or not at all.
Otherwise we have the same issue for plans created in 3.0.

>
> Regards
> Philippe

Re: New fields/changed defaults cause earlier test plans to be marked as changed (bug 59173)

2016-03-18 Thread Philippe Mouawad 
On Fri, Mar 18, 2016 at 11:02 PM, sebb  wrote:

> On 18 March 2016 at 21:46, Philippe Mouawad 
> wrote:
> > Hello,
> >
> > Sebb opened a bug 59173 reporting a problem of "spurious" save message
> when
> > 4 elements are selected.
> >
> >
> > I fixed 1/4 of these.
> > The problem is that fixing the 3/4 other "issues" is if not impossible
> not
> > simple at all:
> >
> > 1/ Access Log Sampler:
> >
> > AFAIU (but I may not understand well) , nothing seems to be available
> > for this case when using
> > BeanInfo
>
> True, but it could be added fairly easily.
>
Great news. So can you add it or explain it to me ?

>
> >
> > 2/ JMS Publisher:
> >
> > There was a mistake made in previous release (my fault) when adding 2
> > properties.
> >
> > Fixing the bug makes code ugly. I personally prefer the spurious
> > message vs the ugly code.
>
> Yes, but you are a developer who understands why this message occurs.
>
> I am too, but I still find it very disconcerting when I'm told my test
> plan has been changed without having done anything.
>
>
I tried to find a clean fix, I didn't.


> >
> >
> > 3/ Backend Listener :
> > - A new parameter was added , AFAIK (but I may be wrong) we have
> > nothing currently to handle this case. But it does not hurt me, as
> > JMeter 3.0 adds a new parameter, the test plan really changed.
>
> But this is precisely the issue.
> The test plan from 2.13 behaves exactly the same in 3.0 (if not,
> there's another bug).
> The new parameter defaults to false, so if it is missing the test
> behaves as before.
>
> > - This informs indirectly the user of this new property.
>
> But the new property does not change the test unless it is changed
> from the default, so it's really not helpful.
>
> Imagine if your favourite word processor behaved like this.
>
> You write a document and save it.
> Later on you open it in a new version of the program; you don't make
> any changes.
> Yet when you close the document the word processor asks you to save it.
> That would be very disconcerting.
> You would wonder if you had changed anything by mistake.
>

It's true.
But we can add it as a known issue and fix it in next release.

>
> >
> > For 1/ and 3/, maybe we can implement it in a future release but I
> > don't think it should be blocker for the 3.0 release.
>
> We have either got to do it now or not at all.
> Otherwise we have the same issue for plans created in 3.0.
>

No as we would have fixed it in 3.1.

>
> >
> > Regards
> > Philippe
>



-- 
Cordialement.
Philippe Mouawad.