Re: [VOTE] Release JMeter 5.4 RC2

2020-11-30 Thread Woonsan Ko 
+1 (non-binding with my supports and thanks)

Woonsan

On Sun, Nov 29, 2020 at 11:55 AM Milamber  wrote:
>
> Hello,
>
> The second release candidate for JMeter 5.4 (079404a06a) has been
> prepared, and your votes are solicited.
>
> This release brings some new features and improvements, and also fixes bugs.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> Feedback is very welcome within the next 72 hours.
>
> You can read the New and Noteworthy section with some screenshots to
> illustrate improvements and full list of changes at:
> https://apache.github.io/jmeter-site-preview/site/changes.html
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8+
>
> Download - Archives/hashes/sigs:
> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4-rc2
> (dist revision 44732)
>
> RAT report:
> https://apache.github.io/jmeter-site-preview/rat/
>
> SHA512 hashes of archives for this vote: see footnote [1]
>
> Site preview is here:
> https://apache.github.io/jmeter-site-preview/site/
>
> JavaDoc API preview is here:
> https://apache.github.io/jmeter-site-preview/site/api/
>
> Maven staging repository is accessible here:
> https://repository.apache.org/content/repositories/orgapachejmeter-1068/org/apache/jmeter/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.4-rc2
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSign".
>
> JMeter 5.4 requires Java 8 or later to run.
>
> The artifacts were built with
>Java(TM) SE Runtime Environment Oracle Corporation (build 1.8.0_221-b11)
>Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> 25.221-b11, mixed mode)
>
> Some known issues and incompatible changes are listed on changes page.
> https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
>
>
> All feedback and vote are welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0  OK, but
> [  ] -1  I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> The PMC members please indicate the mention "(binding)" with your vote.
>
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
> ===
> [1] SHA512 hashes of archives for this vote:
>
> 47e4d6fe4ba327685636a0dd170a1732cf9010873a245c7e77dea42f579ebc8aabbab956f5087a9a16333b7ef964caaa3a187fead4825168decdfd4d1d2ae85a
> *apache-jmeter-5.4.tgz
> f2a1b98fb79224a97d8038660c97e390b798e0ba57b698bea8ae44f4061b86f7841ecb4165fc657684e89c9a0f8ec984d8a40a32a2f079a56953ce522ad9067a
> *apache-jmeter-5.4.zip
> c4f93e603c2aabdef0f26646bbcecda9d95988412ec3725c69eb3d409ddfa8686cca0b0a10f4a341ddc2632e0bc0c594bdd3279b32734a1b949bc24898b7a165
> *apache-jmeter-5.4_src.tgz
> c1ed92b63b9076bc802731b4ab5c82d76e16d74a04e40031f5fa6d828320f92374732210eddfc1fe8a1b14ad01893fa75855c4871949fee1781e3a350225b66f
> *apache-jmeter-5.4_src.zip
>

Re: GraphQL sampler?

2020-09-26 Thread Woonsan Ko 
Hello,

I've submitted a PR: https://github.com/apache/jmeter/pull/627
Please take a look.

Thanks in advance,

Woonsan

On Sun, Sep 20, 2020 at 5:14 PM Woonsan Ko  wrote:
>
> On Fri, Sep 18, 2020 at 4:02 PM Philippe Mouawad
>  wrote:
> >
> > On Fri, Sep 18, 2020 at 4:39 PM Woonsan Ko  wrote:
> >
> > > Hello Philippe,
> > >
> > > On Fri, Sep 18, 2020 at 7:20 AM Philippe Mouawad
> > >  wrote:
> > > >
> > > > Hello Woonsan,
> > > >
> > > > Thanks for your proposal and ideas.
> > >
> > > Great, thanks! :-)
> > >
> > > > Would you be ready to contribute to this ?
> > >
> > > Yes, I would.
> > >
> > > > What new dependencies will it bring on the project ?
> > >
> > > At this moment, I can just imagine that we could add one extending the
> > > HTTP Request Sampler, probably only with a different UI - preset to
> > > POST with the 2 textarea fields for the body json data, while leaving
> > > the stored data structure as-is.
> > > So, I guess we may use the existing library, json-smart, without
> > > introducing any new dependency.
> > >
> > json-smart does not seem to be maintained , so if you have a better one, go
> > for it.
>
> Thanks for the suggestion!
> I think we might want to use gson because it's simple enough for our
> use cases - just serialization and deserialization to/from string.
>
> Build fails when I just added
> 'implementation("com.google.code.gson:gson")' in
> src/protocol/build.gradle.kts and 'gson.version=2.8.6' in
> gradle.properties.
> Could someone give me a hint?
>
> Thanks in advance,
>
> Woonsan
>
> >
> > >
> > > Please share your insights otherwise.
> >
> >
> > > Cheers,
> > >
> > > Woonsan
> > >
> > > >
> > > >
> > > > Regards
> > > >
> > > > On Fri, Sep 18, 2020 at 1:15 PM Woonsan Ko  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I have used HTTP Request sampler for GraphQL testing with setting
> > > > > request body with escaped json strings like this:
> > > > >
> > > > > {"operationName":null,"variables":{},"query":"{\n fineSomethings(text:
> > > > > \"\", offset: 0, limit: 200) {\n offset\n limit\n count\n total\n
> > > > > items {\n ... }\n }\n }\n }\n}\n"}
> > > > >
> > > > > It is a bit harder to read and update than some graphql tools such as
> > > > > graphql playground [1] which escapes graphql and variable json to an
> > > > > escaped body under the hood.
> > > > > So, I think it would be nice if we have a GraphQL Sampler with a
> > > > > similar UI - separate graphql query or mutation input and variables
> > > > > (json) input.
> > > > > How does it sound?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Woonsan
> > > > >
> > > > > [1] https://github.com/graphql/graphql-playground
> > > > >
> > > >
> > > >
> > > > --
> > > > Cordialement.
> > > > Philippe Mouawad.
> > >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.

Re: GraphQL sampler?

2020-09-20 Thread Woonsan Ko 
On Fri, Sep 18, 2020 at 4:02 PM Philippe Mouawad
 wrote:
>
> On Fri, Sep 18, 2020 at 4:39 PM Woonsan Ko  wrote:
>
> > Hello Philippe,
> >
> > On Fri, Sep 18, 2020 at 7:20 AM Philippe Mouawad
> >  wrote:
> > >
> > > Hello Woonsan,
> > >
> > > Thanks for your proposal and ideas.
> >
> > Great, thanks! :-)
> >
> > > Would you be ready to contribute to this ?
> >
> > Yes, I would.
> >
> > > What new dependencies will it bring on the project ?
> >
> > At this moment, I can just imagine that we could add one extending the
> > HTTP Request Sampler, probably only with a different UI - preset to
> > POST with the 2 textarea fields for the body json data, while leaving
> > the stored data structure as-is.
> > So, I guess we may use the existing library, json-smart, without
> > introducing any new dependency.
> >
> json-smart does not seem to be maintained , so if you have a better one, go
> for it.

Thanks for the suggestion!
I think we might want to use gson because it's simple enough for our
use cases - just serialization and deserialization to/from string.

Build fails when I just added
'implementation("com.google.code.gson:gson")' in
src/protocol/build.gradle.kts and 'gson.version=2.8.6' in
gradle.properties.
Could someone give me a hint?

Thanks in advance,

Woonsan

>
> >
> > Please share your insights otherwise.
>
>
> > Cheers,
> >
> > Woonsan
> >
> > >
> > >
> > > Regards
> > >
> > > On Fri, Sep 18, 2020 at 1:15 PM Woonsan Ko  wrote:
> > >
> > > > Hi,
> > > >
> > > > I have used HTTP Request sampler for GraphQL testing with setting
> > > > request body with escaped json strings like this:
> > > >
> > > > {"operationName":null,"variables":{},"query":"{\n fineSomethings(text:
> > > > \"\", offset: 0, limit: 200) {\n offset\n limit\n count\n total\n
> > > > items {\n ... }\n }\n }\n }\n}\n"}
> > > >
> > > > It is a bit harder to read and update than some graphql tools such as
> > > > graphql playground [1] which escapes graphql and variable json to an
> > > > escaped body under the hood.
> > > > So, I think it would be nice if we have a GraphQL Sampler with a
> > > > similar UI - separate graphql query or mutation input and variables
> > > > (json) input.
> > > > How does it sound?
> > > >
> > > > Regards,
> > > >
> > > > Woonsan
> > > >
> > > > [1] https://github.com/graphql/graphql-playground
> > > >
> > >
> > >
> > > --
> > > Cordialement.
> > > Philippe Mouawad.
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.

GraphQL sampler?

2020-09-18 Thread Woonsan Ko 
Hi,

I have used HTTP Request sampler for GraphQL testing with setting
request body with escaped json strings like this:

{"operationName":null,"variables":{},"query":"{\n fineSomethings(text:
\"\", offset: 0, limit: 200) {\n offset\n limit\n count\n total\n
items {\n ... }\n }\n }\n }\n}\n"}

It is a bit harder to read and update than some graphql tools such as
graphql playground [1] which escapes graphql and variable json to an
escaped body under the hood.
So, I think it would be nice if we have a GraphQL Sampler with a
similar UI - separate graphql query or mutation input and variables
(json) input.
How does it sound?

Regards,

Woonsan

[1] https://github.com/graphql/graphql-playground

Re: Migrating build system to Gradle

2019-02-25 Thread Woonsan Ko 
On Mon, Feb 25, 2019 at 6:21 AM Vladimir Sitnikov
 wrote:
>
> sebb> Is is absolutely necessary to move the files around?
>
> 1) What's wrong with moving files?
>
> 2) What's your suggestion?
> How are you going to co-locate runtime and test classes yet use
> current core/org/apache/jmeter folder structure?
> Where test classes for "core" module should be located?
> Where test classes for "protocol/http" should be located?
>
> sebb>They are starting samples for the Eclipse .classpath and .project files.
>
> I don't use Eclipse, and I don't really want to spend time there.
> Gradle should make Eclipse integration automatic (or something like
> that), so eclipse.classpath, eclipse.project and eclipse.md should be
> just removed.

I haven't tested it with your work, but in general, yes, the Gradle
plugin for Eclipse imports it and generates all the necessary files
automatically.
That's what I experienced like mentioned in [1]:

"File -> Import... -> Gradle / Existing Gradle Project Import the
FreeMarker project directory. Everything can remain at its default.
Now Eclipse will automatically build the project in the backround.
There shouldn't be any errors."

So, we're able to remove .classpath, .project, ..., in v3 branch.

Regards,

Woonsan

[1] https://github.com/apache/freemarker/tree/3

>
> Vladimir

Re: Migrating build system to Gradle

2019-02-23 Thread Woonsan Ko 
On Sat, Feb 23, 2019 at 12:05 PM Woonsan Ko  wrote:
>
> On Sat, Feb 23, 2019 at 11:49 AM Philippe Mouawad
>  wrote:
> >
> > On Sat, Feb 23, 2019 at 5:24 PM Graham Russell  wrote:
> >
> > > Sebb:
> > > I will try again on a new VM and write them up, perhaps on Monday.
> > >
> > > I doubt it would have done it automatically, but it probably would
> > > have been quicker to solve.
> > > i.e. add: compile 'org.openjfx:javafx-controls:11' to dependencies and
> > > Gradle + IDE automatically then work.
> > > Rather than: finding the required jar, copying it to the lib folder
> > > and manually adding it to the IntelliJ project.
> > >
> > > Philippe:
> > > I do not think it would be able to handle the dependency management
> > > without also doing the compilation (but I could be wrong).
> > > For Darcula, there are options https://stackoverflow.com/a/34327202 or
> > >
> > > https://stackoverflow.com/questions/17123606/how-to-download-external-files-in-gradle
> > >
> > > However, the more we dig the more we might have to change the status
> > > quo, it seems the git discussion is similar, i.e. now that we might
> > > want to use a different tool we should probably use it in the way it
> > > was intended to solve our problems rather than simply use the same
> > > ways of working.
> > >
> > I agree, did I meant something else for you (in which answer ?) ?
> > It is just that Darcula is just not available in Maven Central.
> > I just wanted to highlight this specificity to have it mind when migrating.
>
> Should be possible with a either flatDir (after download) or custom
> repository setting:
> - https://docs.gradle.org/current/userguide/repository_types.html

And, after searching on the internet, I found two approaches to
download files in Groovy DSL: (a) use Ant! [1] ;-), (b) another AL'ed
download helper module [2].

BTW, also take a look at FreeMarker v3 (not released yet, still in
dev) branch's README about IDE setup instructions (probably many
already knew, but might be useful...):
- https://github.com/apache/freemarker/tree/3#ide-setup
(FreeMarker has a very complex setup in its Ant build in v2 the
official one, including JavaCC, separate unit tests with different
incompatible JVM or dependencies, ...), but FM3 has migrated from Ant
to Gradle, which works fine even if we are not done yet regarding
Apache Release artifacts generations.)

Regards,

Woonsan

[1] 
https://stackoverflow.com/questions/23023069/gradle-download-and-unzip-file-from-url/34327202
[2] https://github.com/michel-kraemer/gradle-download-task

>
> Woonsan
>
> >
> >
> > Thus, unfortunately, making these even more difficult than just the
> > > initial technical challenge, but, in my mind they will be well worth
> > > it in the long term.
> > >
> > Agreed
> >
> > >
> > >
> > > Graham
> > >
> > > On Sat, 23 Feb 2019 at 14:59, Philippe Mouawad
> > >  wrote:
> > > >
> > > > Thanks Graham for those very interesting insights.
> > > >
> > > > Is gradle able within its dependency management to handle case where
> > > > dependency is not a Maven nor Ivy one ?
> > > >
> > > >-
> > > >
> > > https://docs.gradle.org/current/userguide/introduction_dependency_management.html
> > > >
> > > > I guess it would be possible to do it with custom coding (download
> > > artifact
> > > > and put it in local maven repository, but if it's built-in it would be
> > > > better.
> > > >
> > > > We have Darcula which is in this case.
> > > >
> > > > Regarding your proposal, do you think it would be feasible as a first
> > > step
> > > > to delegate dependencies management to Gradle ?
> > > > I think it would possibly improve already developer experience.
> > > >
> > > > Thanks
> > > >
> > > >
> > > > On Sat, Feb 23, 2019 at 11:50 AM Graham Russell 
> > > wrote:
> > > >
> > > > > +1 to move to Gradle.
> > > > >
> > > > > I think the biggest benefit of moving to Gradle is that it will lead 
> > > > > to
> > > > > more contributions.
> > > > >
> > > > > People will no longer have to fight to get the code to import into an
> > > IDE
> > > > > (i.e. IntelliJ), compile and successfully run tests.
> > > > > I've just got a new lap

Re: Migrating build system to Gradle

2019-02-23 Thread Woonsan Ko 
On Sat, Feb 23, 2019 at 11:49 AM Philippe Mouawad
 wrote:
>
> On Sat, Feb 23, 2019 at 5:24 PM Graham Russell  wrote:
>
> > Sebb:
> > I will try again on a new VM and write them up, perhaps on Monday.
> >
> > I doubt it would have done it automatically, but it probably would
> > have been quicker to solve.
> > i.e. add: compile 'org.openjfx:javafx-controls:11' to dependencies and
> > Gradle + IDE automatically then work.
> > Rather than: finding the required jar, copying it to the lib folder
> > and manually adding it to the IntelliJ project.
> >
> > Philippe:
> > I do not think it would be able to handle the dependency management
> > without also doing the compilation (but I could be wrong).
> > For Darcula, there are options https://stackoverflow.com/a/34327202 or
> >
> > https://stackoverflow.com/questions/17123606/how-to-download-external-files-in-gradle
> >
> > However, the more we dig the more we might have to change the status
> > quo, it seems the git discussion is similar, i.e. now that we might
> > want to use a different tool we should probably use it in the way it
> > was intended to solve our problems rather than simply use the same
> > ways of working.
> >
> I agree, did I meant something else for you (in which answer ?) ?
> It is just that Darcula is just not available in Maven Central.
> I just wanted to highlight this specificity to have it mind when migrating.

Should be possible with a either flatDir (after download) or custom
repository setting:
- https://docs.gradle.org/current/userguide/repository_types.html

Woonsan

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

Re: Release a 3.2

2017-03-25 Thread Woonsan Ko 
On Fri, Mar 24, 2017 at 10:39 AM, Woonsan Ko <woon...@apache.org> wrote:
> On Mon, Mar 20, 2017 at 7:05 PM, sebb <seb...@gmail.com> wrote:
>> On 20 March 2017 at 22:57, Philippe Mouawad <philippe.moua...@gmail.com> 
>> wrote:
>>> On Monday, March 20, 2017, sebb <seb...@gmail.com> wrote:
>>>
>>>> I know I keep going on about this, but the logging documentation still
>>>> needs some work.
>>>>
>>>> The logging level names have changed.
>>>> Users need to be told what the mapping is from old name to new name.
>>>>
>>>> cf comments on r1786590
>>>
>>> Work has been done since that time.
>>> Please point to missing information.
>>
>> Where are the logging levels documented?
>> I had a quick look and could not find them.
I've submitted a PR: https://github.com/apache/jmeter/pull/286
Please take a look.

Regards,

Woonsan

>
> Sorry for late response. I'll try to submit a pull request to clarify
> the changes of the available log levels before Monday.
>
> Regards,
>
> Woosnan
>
>>
>>>
>>>>
>>>>
>>>> On 20 March 2017 at 22:26, Antonio Gomes Rodrigues <ra0...@gmail.com
>>>> <javascript:;>> wrote:
>>>> > +1
>>>> >
>>>> > Antonio
>>>> >
>>>> > 2017-03-20 21:49 GMT+01:00 Philippe Mouawad <philippe.moua...@gmail.com
>>>> <javascript:;>>:
>>>> >
>>>> >> Hello,
>>>> >> AFAIU, there are no more pending points for a release.
>>>> >>
>>>> >> Am I wrong ?
>>>> >> If not, could be start a release ?
>>>> >> Thanks
>>>> >> Regards
>>>> >>
>>>> >>
>>>> >> On Thu, Mar 16, 2017 at 11:43 PM, Antonio Gomes Rodrigues <
>>>> >> ra0...@gmail.com <javascript:;>>
>>>> >> wrote:
>>>> >>
>>>> >> > Hi,
>>>> >> >
>>>> >> > I have updated jmeter_accesslog_sampler_step_by_step document like I
>>>> >> have
>>>> >> > said previously
>>>> >> >
>>>> >> > Antonio
>>>> >> >
>>>> >> > 2017-03-16 14:25 GMT+01:00 Andrey Pokhilko <a...@ya.ru <javascript:;>
>>>> >:
>>>> >> >
>>>> >> > > We have fixed them and released plugin updates. For the record, it
>>>> >> were:
>>>> >> > >
>>>> >> > >   * OAuth Sampler broken - we decided to deprecate it
>>>> >> > >   * JMX Check tool were failing on call to removed
>>>> >> > > "org.apache.jmeter.save.SaveService.loadTree( InputStream
>>>> >> > > inputStream)", we've released update with other method used
>>>> >> > >   * Synthesis report were failing on call to modified
>>>> >> > > "org.apache.jmeter.save.CSVSaveService#saveCSVStats(
>>>> >> > java.util.List,
>>>> >> > > java.io.FileWriter, java.lang.String[])", we've released update
>>>> >> that
>>>> >> > > uses different method
>>>> >> > >   * BlazeMeter Debugger plugin fails due to changes to LoggerPanel
>>>> and
>>>> >> > > several other changes around logging, we have no good solution
>>>> for
>>>> >> > > now, that will work on both JMeter 3.1 and 3.2. We need more
>>>> time
>>>> >> to
>>>> >> > > work on it and we don't consider it as release blocker.
>>>> >> > >
>>>> >> > > Andrey Pokhilko
>>>> >> > >
>>>> >> > > On 16.03.2017 16:03, Philippe Mouawad wrote:
>>>> >> > > > What are the other "number of issues " ?
>>>> >> > > > Thanks
>>>> >> > > >
>>>> >> > > > On Thu, Mar 16, 2017 at 2:02 PM, Andrey Pokhilko <a...@ya.ru
>>>> <javascript:;>> wrote:
>>>> >> > > >
>>>> >> > > >> Hi,
>>>> >> > > >>
>>>> >> > > >> Yes, it's that message. The bugzilla is here:
>>

Re: svn commit: r1784829 - in /jmeter/trunk: extras/remote.bsh xdocs/usermanual/best-practices.xml

2017-02-28 Thread Woonsan Ko 
On Tue, Feb 28, 2017 at 6:16 PM, sebb  wrote:
> On 28 February 2017 at 22:39,   wrote:
>> Author: pmouawad
>> Date: Tue Feb 28 22:39:25 2017
>> New Revision: 1784829
>>
>> URL: http://svn.apache.org/viewvc?rev=1784829=rev
>> Log:
>> Remove log_level occurences
>>
>> Modified:
>> jmeter/trunk/extras/remote.bsh
>> jmeter/trunk/xdocs/usermanual/best-practices.xml
>>
>> Modified: jmeter/trunk/extras/remote.bsh
>> URL: 
>> http://svn.apache.org/viewvc/jmeter/trunk/extras/remote.bsh?rev=1784829=1784828=1784829=diff
>> ==
>> --- jmeter/trunk/extras/remote.bsh (original)
>> +++ jmeter/trunk/extras/remote.bsh Tue Feb 28 22:39:25 2017
>> @@ -34,9 +34,6 @@ print(args);
>>  printsysprop("user.home");
>>  printsysprop("user.dir");
>>
>> -printprop("log_level.jmeter");
>> -printprop("log_level.jorphan");
>> -
>>  // loglevel("DEBUG","jmeter");
>
> This should be a clue that there's a loglevel function somewhere.
> It needs to be found and updated to use the new style of logging.

The new way to set log level for a category or for root is here:
- 
https://github.com/apache/jmeter/blob/trunk/src/core/org/apache/jmeter/JMeter.java#L830-L852

Regards,

Woonsan

>
> And the printprop calls should ideally be replaced with something that
> displays the logging level.
>
>>
>>  for(i=0;i<10;i++){
>>
>> Modified: jmeter/trunk/xdocs/usermanual/best-practices.xml
>> URL: 
>> http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/best-practices.xml?rev=1784829=1784828=1784829=diff
>> ==
>> --- jmeter/trunk/xdocs/usermanual/best-practices.xml (original)
>> +++ jmeter/trunk/xdocs/usermanual/best-practices.xml Tue Feb 28 22:39:25 2017
>> @@ -214,8 +214,6 @@ BeanShell 2.0b5 - by Pat Niemeyer (pat@p
>>  bsh % remote.bsh starting
>>  user.home = C:\Documents and Settings\User
>>  user.dir = D:\eclipseworkspaces\main\JMeter_trunk\bin
>> -log_level.jmeter = INFO
>> -log_level.jorphan = INFO
>>  Setting property 'EXAMPLE' to '0'.
>>  Setting property 'EXAMPLE' to '1'.
>>  Setting property 'EXAMPLE' to '2'.
>>
>>

Re: Proposition for contribution

2017-02-16 Thread Woonsan Ko 
Hi folks,

Is there anyone working in unit tests for JDBC protocol?
If not, I'd like to take a look into it next week.

Cheers,

Woonsan


On Fri, Jan 6, 2017 at 2:35 PM, Philippe Mouawad
 wrote:
> Hello,
> Thanks for your proposal.
> Yes it is still up to date.
>
> You can have a look at our Sonar report to know what needs testing:
>
>- https://builds.apache.org/analysis/
>
> Our priorities regarding tests:
>
>- JDBC protocol (more the NON Gui classes)
>- HTTP (more non gui classes)
>- org.apache.jmeter.assertions:
>   - .HTMLAssertion
>   - JSR223Assertion
>- org.apache.jmeter.core.report
>- org.apache.jmeter.visualizers.backend.graphite
>- core/org/apache/jmeter/control
>
> Note coverage is not only related to JUnit tests but also to tests builds
> with JMX plans and ran with Jacoco agent.
>
> Regards
>
>
>
> On Fri, Jan 6, 2017 at 5:32 PM, Sébastien Col 
> wrote:
>
>> Hi,
>> I would like to contribute to the project and I thought I could start
>> working on the task #41118bb8 related to test suite enhancement and
>> migration to JUnit 4.
>> I found it from the helpwanted.apache.org site.
>> Is it still up-to-date?
>> Regards,
>> Sebastien
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback orCommons-Logging

2017-02-12 Thread Woonsan Ko 
Great initiative, indeed! And, it was great, pleasant and also
learning experiences for myself as a fan of the project!
Thanks a lot again for your collaborations for new comers and the community!

Cheers,

Woonsan


On Sat, Feb 11, 2017 at 10:32 AM,  <forag...@gmail.com> wrote:
> +1!
>
> As a downstream consumer of jmeter maven packages, this is absolutely great!
>
> RaGe
>
> From: Andrey Pokhilko
> Sent: Saturday, February 11, 2017 6:58 AM
> To: dev@jmeter.apache.org
> Subject: Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback 
> orCommons-Logging
>
> Great initiative! Good to hear that project is migrating towards modern
> libraries.
>
> Andrey Pokhilko
>
> On 11.02.2017 11:38, Philippe Mouawad wrote:
>> Hello,
>> I'm happy to announce that thanks to the huge work of Woonsan Ko, we've now
>> completed the migration to SLF4J/LOG4J2.
>>
>> Big thanks to Woonsan ! for the quality of his work and the amount of
>> involvement on this.
>>
>> Regards
>> Philippe
>>
>> On Wed, Dec 30, 2015 at 4:35 PM, Philippe Mouawad <
>> philippe.moua...@gmail.com> wrote:
>>
>>> Hello,
>>> I will start work on this, I propose to go for SLF4J + Log4j2 as default
>>> binding.
>>>
>>> Slf4j is already in JMeter and log4j2 is Apache project and the most
>>> efficient one currently.
>>>
>>> Unless I get a NOGO within the 24 hours,  I will start coding it.
>>> Regards
>>> Philippe
>>>
>>> On Wed, Oct 21, 2015 at 8:52 AM, Milamber <milam...@apache.org> wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm agree with you. I thinks we must have a more modern vision for the
>>>> code to attract more developers.
>>>> If the change from LogKit to Log4j2 is transparent then we must do the
>>>> change.
>>>>
>>>> I don't known if a technical vote is required, if yes, my vote will be +1.
>>>>
>>>> Milamber
>>>>
>>>>
>>>> On 18/10/2015 18:45, Antonio Gomes Rodrigues wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> My 2 cents,
>>>>>
>>>>> Each time I talk to a JMeter user which have read the source code I have
>>>>> this answer : "The code is old ..."
>>>>>
>>>>> And I think to keep old framework like LogKit in JMeter doesn't help to
>>>>> attract new committers.
>>>>>
>>>>> Maybe LogKit make the job but it don't help the project
>>>>>
>>>>> Regards,
>>>>> Antonio
>>>>>
>>>>>
>>>>> 2015-10-17 22:36 GMT+02:00 sebb <seb...@gmail.com>:
>>>>>
>>>>> On 17 October 2015 at 17:41, Philippe Mouawad
>>>>>> <philippe.moua...@gmail.com> wrote:
>>>>>>
>>>>>>> On Sat, Oct 17, 2015 at 5:44 PM, sebb <seb...@gmail.com> wrote:
>>>>>>>
>>>>>>> On 17 October 2015 at 15:06, Philippe Mouawad
>>>>>>>> <philippe.moua...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>> LogKit is in the Attic for a while now.
>>>>>>>>>
>>>>>>>>> AFAIK, we upgrade JDK version of JMeter based on EOL of Java
>>>>>>> version, why
>>>>>>> would strategy be different for dead libraries ?
>>>>>>>
>>>>>> Attic is not the same as Dead.
>>>>>>
>>>>>> What about dropping it in favor of a more up to date Logging library:
>>>>>>>>> - Apache Log4J2 which has great performances now
>>>>>>>>> - SLF4+LogBack which is also nice
>>>>>>>>> - Commons-logging
>>>>>>>>>
>>>>>>>>> I see many benefits:
>>>>>>>>> - Drop an outdated library (I think it's never a good thing to rely
>>>>>>>>> on
>>>>>>>>> unmaintained libraries, it can be a security issue, it can make
>>>>>>>>>
>>>>>>>> newbies
>>>>>>> think that JMeter is not maintained nor up to date)
>>>>>>>> Newer is not necessarily better.
>>>>>>>>
>>>>>>>> In this case, newer is better,  lot of technical r

Re: Want to help with migrating from Apache LogKit to SLF4J

2017-01-15 Thread Woonsan Ko 
On Mon, Jan 9, 2017 at 1:29 PM, Woonsan Ko <woon...@apache.org> wrote:
> On Fri, Jan 6, 2017 at 3:23 PM, Philippe Mouawad
> <philippe.moua...@gmail.com> wrote:
>> On Wednesday, January 4, 2017, sebb <seb...@gmail.com> wrote:
>>
>>> On 3 January 2017 at 20:59, Woonsan Ko <woon...@apache.org <javascript:;>>
>>> wrote:
>>> > On Tue, Jan 3, 2017 at 2:32 PM, Felix Schumacher
>>> > <felix.schumac...@internetallee.de <javascript:;>> wrote:
>>> >> Am 02.01.2017 um 21:31 schrieb Philippe Mouawad:
>>> >>>
>>> >>> On Monday, January 2, 2017, Woonsan Ko <woon...@apache.org
>>> <javascript:;>> wrote:
>>> >>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> I'd like to help with migrating from Apache LogKit to SLF4J [1], and
>>> >>>> so I've been reading the current logging implementation with logkit,
>>> >>>> avalon-framework and excalibur-logger.
>>> >>>
>>> >>> Thanks for your proposal
>>> >>
>>> >> +1
>>> >>>
>>> >>>
>>> >>>>  From my understanding, maybe we can take the following approach:
>>> >>>> - Since SLF4J API doesn't provide a logging implementation or binding
>>> >>>> by itself, we need to choose one at least such as log4j2 [2] or
>>> >>>> logback. [3] IMHO, log4j2 binding provided by Apache Logging services
>>> >>>> project could be a good default binding option.
>>> >>>
>>> >>>
>>> >>> +1
>>> >>
>>> >> Well, I would start with what we have, which is a working binding for
>>> SLF4J.
>>> >
>>> > It seems more important to migrate each logger usages to use slf4j
>>> > logger in each class than replacing logging framework in the first
>>> > step. So, we can keep the current logkit binding in the first step.
>>> > That prioritization makes sense to me.
>>> >
>>> >>>
>>> >>>
>>> >>>> - By the default binding such as log4j2, I mean JMeter should be
>>> >>>> bundled with log4j2 library and its binding library as well as a
>>> >>>> default configuration file (e.g, log4j2.xml), by default. It seems
>>> >>>> neater to separate the logging configuration file from
>>> >>>> jmeter.properties with simply following its default auto-resolving
>>> >>>> conventions such as log4j2.xml [4] or logback.xml [5] to me.
>>> >>>
>>> >>> +1
>>> >>
>>> >> I am +-0 to any decision right now.
>>> >
>>> > This can be revisited with separate ticket after the first step done.
>>> >
>>> >>>
>>> >>>
>>> >>>> - It seems like each Logger instance is created as a static member by
>>> >>>> `LoggingManager.getLoggerForXXX()' method(s). I suppose all of those
>>> >>>> should be replaced by simply using slf4j logger factory as done in
>>> >>>> AbstractSampleConsumer.java.
>>> >>>
>>> >>> Yes
>>> >>>
>>> >>>> - It might be even better if each logging line is more optimized by
>>> >>>> taking advantage of slf4j logging methods (e.g, message format
>>> >>>> arguments and throwable argument).
>>> >>>
>>> >>> Yes
>>> >>
>>> >> Plus, if we use formatted messages with arguments, the need for if
>>> >> (log-is-enabled) statements might be gone for simple cases.
>>> >
>>> > Yes.
>>> >
>>> >>
>>> >>>
>>> >>>> - After all migrated, the old logkit and some other related unused
>>> >>>> libraries should be gone.
>>> >>>
>>> >>>
>>> >>> A possible option to avoid breaking too many existing third party
>>> plugins
>>> >>> would be to embed in source code current logkit logger factory and
>>> logger
>>> >>> so that it delegates to slf4j.
>>> >>> We would drop avalon, logkit and  excalibur jars.
>>> >
>>> > Good point. This can be revisited in the later step.
>>> >
>>> >&

Re: Want to help with migrating from Apache LogKit to SLF4J

2017-01-09 Thread Woonsan Ko 
On Fri, Jan 6, 2017 at 3:23 PM, Philippe Mouawad
<philippe.moua...@gmail.com> wrote:
> On Wednesday, January 4, 2017, sebb <seb...@gmail.com> wrote:
>
>> On 3 January 2017 at 20:59, Woonsan Ko <woon...@apache.org <javascript:;>>
>> wrote:
>> > On Tue, Jan 3, 2017 at 2:32 PM, Felix Schumacher
>> > <felix.schumac...@internetallee.de <javascript:;>> wrote:
>> >> Am 02.01.2017 um 21:31 schrieb Philippe Mouawad:
>> >>>
>> >>> On Monday, January 2, 2017, Woonsan Ko <woon...@apache.org
>> <javascript:;>> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> I'd like to help with migrating from Apache LogKit to SLF4J [1], and
>> >>>> so I've been reading the current logging implementation with logkit,
>> >>>> avalon-framework and excalibur-logger.
>> >>>
>> >>> Thanks for your proposal
>> >>
>> >> +1
>> >>>
>> >>>
>> >>>>  From my understanding, maybe we can take the following approach:
>> >>>> - Since SLF4J API doesn't provide a logging implementation or binding
>> >>>> by itself, we need to choose one at least such as log4j2 [2] or
>> >>>> logback. [3] IMHO, log4j2 binding provided by Apache Logging services
>> >>>> project could be a good default binding option.
>> >>>
>> >>>
>> >>> +1
>> >>
>> >> Well, I would start with what we have, which is a working binding for
>> SLF4J.
>> >
>> > It seems more important to migrate each logger usages to use slf4j
>> > logger in each class than replacing logging framework in the first
>> > step. So, we can keep the current logkit binding in the first step.
>> > That prioritization makes sense to me.
>> >
>> >>>
>> >>>
>> >>>> - By the default binding such as log4j2, I mean JMeter should be
>> >>>> bundled with log4j2 library and its binding library as well as a
>> >>>> default configuration file (e.g, log4j2.xml), by default. It seems
>> >>>> neater to separate the logging configuration file from
>> >>>> jmeter.properties with simply following its default auto-resolving
>> >>>> conventions such as log4j2.xml [4] or logback.xml [5] to me.
>> >>>
>> >>> +1
>> >>
>> >> I am +-0 to any decision right now.
>> >
>> > This can be revisited with separate ticket after the first step done.
>> >
>> >>>
>> >>>
>> >>>> - It seems like each Logger instance is created as a static member by
>> >>>> `LoggingManager.getLoggerForXXX()' method(s). I suppose all of those
>> >>>> should be replaced by simply using slf4j logger factory as done in
>> >>>> AbstractSampleConsumer.java.
>> >>>
>> >>> Yes
>> >>>
>> >>>> - It might be even better if each logging line is more optimized by
>> >>>> taking advantage of slf4j logging methods (e.g, message format
>> >>>> arguments and throwable argument).
>> >>>
>> >>> Yes
>> >>
>> >> Plus, if we use formatted messages with arguments, the need for if
>> >> (log-is-enabled) statements might be gone for simple cases.
>> >
>> > Yes.
>> >
>> >>
>> >>>
>> >>>> - After all migrated, the old logkit and some other related unused
>> >>>> libraries should be gone.
>> >>>
>> >>>
>> >>> A possible option to avoid breaking too many existing third party
>> plugins
>> >>> would be to embed in source code current logkit logger factory and
>> logger
>> >>> so that it delegates to slf4j.
>> >>> We would drop avalon, logkit and  excalibur jars.
>> >
>> > Good point. This can be revisited in the later step.
>> >
>> >>>
>> >>>
>> >>>
>> >>>> Am I in the right track? Any advice or thoughts?
>> >>>
>> >>>
>> >>> please wait for other team members to answer before starting code.
>> >>> Give a week .
>> >>
>> >> I would start slowly and contribute drop by drop first, to see if you
>> are
>> >> going in

Want to help with migrating from Apache LogKit to SLF4J

2017-01-02 Thread Woonsan Ko 
Hi,

I'd like to help with migrating from Apache LogKit to SLF4J [1], and
so I've been reading the current logging implementation with logkit,
avalon-framework and excalibur-logger.

>From my understanding, maybe we can take the following approach:
- Since SLF4J API doesn't provide a logging implementation or binding
by itself, we need to choose one at least such as log4j2 [2] or
logback. [3] IMHO, log4j2 binding provided by Apache Logging services
project could be a good default binding option.
- By the default binding such as log4j2, I mean JMeter should be
bundled with log4j2 library and its binding library as well as a
default configuration file (e.g, log4j2.xml), by default. It seems
neater to separate the logging configuration file from
jmeter.properties with simply following its default auto-resolving
conventions such as log4j2.xml [4] or logback.xml [5] to me.
- It seems like each Logger instance is created as a static member by
`LoggingManager.getLoggerForXXX()' method(s). I suppose all of those
should be replaced by simply using slf4j logger factory as done in
AbstractSampleConsumer.java.
- It might be even better if each logging line is more optimized by
taking advantage of slf4j logging methods (e.g, message format
arguments and throwable argument).
- After all migrated, the old logkit and some other related unused
libraries should be gone.

Am I in the right track? Any advice or thoughts?

Kind regards,

Woonsan

[1] 
https://helpwanted.apache.org/task.html?ad91cbf270c711a1c6aa0e67180309d282c81e02
[2] https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html
[3] http://www.slf4j.org/manual.html
[4] 
https://logging.apache.org/log4j/2.x/manual/configuration.html#Automatic_Configuration
[5] http://logback.qos.ch/manual/configuration.html#auto_configuration