[GitHub] jmeter issue #223: Bug59945_DefaultGroovyEngineToJSR223ElementsV2
Github user milamberspace commented on the issue: https://github.com/apache/jmeter/pull/223 The manual must be updated too for indicate this new behavior (if no language, then groovy script) --- 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 #223: Bug59945_DefaultGroovyEngineToJSR223ElementsV2
Github user milamberspace commented on a diff in the pull request:
https://github.com/apache/jmeter/pull/223#discussion_r73644512
--- Diff: src/core/org/apache/jmeter/util/JSR223TestElement.java ---
@@ -86,11 +88,16 @@ public JSR223TestElement() {
}
protected ScriptEngine getScriptEngine() throws ScriptException {
-final String lang = getScriptLanguage();
+String lang = getScriptLanguage();
+
+if (lang.isEmpty()) {
+lang = defaultScriptLanguage;
+log.warn("Script language has not been chosen on the UI, the
script will be interpreted as a groovy script");
+}
ScriptEngine scriptEngine = getInstance().getEngineByName(lang);
if (scriptEngine == null) {
--- End diff --
The scriptEngine will be never null if groovy become the default language.
This (if and exception below) must be changes.
Perhaps put here the test (if lang is undefine then log warn "interpret as
groovy script")
---
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 issue #222: fixed garbled label in report dashboard
Github user scyiwei commented on the issue: https://github.com/apache/jmeter/pull/222 I will close this one, 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 #222: fixed garbled label in report dashboard
Github user scyiwei closed the pull request at: https://github.com/apache/jmeter/pull/222 --- 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 #223: Bug59945_DefaultGroovyEngineToJSR223ElementsV2
Github user vlsi commented on a diff in the pull request: https://github.com/apache/jmeter/pull/223#discussion_r73605191 --- Diff: src/core/org/apache/jmeter/util/ScriptingTestElement.java --- @@ -36,6 +36,8 @@ private String script = ""; // script (if file not provided) protected String scriptLanguage = ""; // BSF/JSR223 language to use + +protected String defaultScriptLanguage = "groovy"; // if no language is chosen in GUI --- End diff -- Should this be `final static`? --- 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: Default engine script language to JSR223 elements
Hi, My proposition of pacth PR : https://github.com/apache/jmeter/pull/223 commited Bugzilla : https://bz.apache.org/bugzilla/show_bug.cgi?id=59945 Antonio 2016-08-04 18:34 GMT+02:00 Antonio Gomes Rodrigues : > Great idea > > I will try to implement it asap and make a PR > > Antonio > > 2016-08-04 12:02 GMT+02:00 Milamber : > >> >> Why not. >> If the script language has not chosen on the UI, add a INFO (or WARN) >> message into the log to inform that the script will be interpreted as a >> groovy script >> >> >> On 03/08/2016 18:15, Antonio Gomes Rodrigues wrote: >> >>> Hi all, >>> >>> I have a proposition about default engine script language to JSR223 >>> elements (sampler, timer...) >>> >>> For the moment when we had a JSR223 elements, there is no default engine >>> script language >>> >>> And if we forgot to add it we have this error message "2016/08/03 >>> 17:46:43 >>> ERROR - jmeter.protocol.java.sampler.JSR223Sampler: Problem in JSR223 >>> script Echantillon JSR223, message:javax.script.ScriptException: Cannot >>> find engine named: '', ensure you set language field in JSR223 Test >>> Element:Echantillon JSR223" >>> >>> My proposal is to put Groovy as default engine script language to avoid >>> users to check the logs to understand the mistake they have made >>> >>> Do you think it's a great idea? >>> >>> Antonio >>> >>> >> >
[GitHub] jmeter issue #223: Bug59945_DefaultGroovyEngineToJSR223ElementsV2
Github user vlsi commented on the issue: https://github.com/apache/jmeter/pull/223 Do you think a test should be added to cover the change? An entry in changes.xml is missing as well. --- 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 #223: Bug59945_DefaultGroovyEngineToJSR223ElementsV2
Github user vlsi commented on a diff in the pull request:
https://github.com/apache/jmeter/pull/223#discussion_r73605217
--- Diff: src/core/org/apache/jmeter/util/JSR223TestElement.java ---
@@ -86,11 +88,16 @@ public JSR223TestElement() {
}
protected ScriptEngine getScriptEngine() throws ScriptException {
-final String lang = getScriptLanguage();
+String lang = getScriptLanguage();
+
+if (lang.isEmpty()) {
+lang = defaultScriptLanguage;
+log.warn("Script language has not been chosen on the UI, the
script will be interpreted as a groovy script");
--- End diff --
Do you really intend to warn on each and every sampler execution?
This looks awfully broken.
---
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 #223: Bug59945_DefaultGroovyEngineToJSR223ElementsV2
GitHub user ra0077 opened a pull request: https://github.com/apache/jmeter/pull/223 Bug59945_DefaultGroovyEngineToJSR223ElementsV2 Hi, If the script language has not been chosen on the GUI, I propose to add a WARN message into the log to inform that the script will be interpreted as a groovy script It's avoid message like "ERROR - jmeter.protocol.java.sampler.JSR223Sampler: Problem in JSR223 script Echantillon JSR223, message:javax.script.ScriptException: Cannot find engine named: '', ensure you set language field in JSR223 Test Element:Echantillon JSR223" and allow to execute the script Antonio You can merge this pull request into a Git repository by running: $ git pull https://github.com/ra0077/jmeter Bug59945_DefaultGroovyEngineToJSR223Elements Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jmeter/pull/223.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 #223 commit 8fe20ff7e9cb864b118ec650a854873de19abbac Author: ra0077 Date: 2016-08-04T21:12:59Z Bug59945_DefaultGroovyEngineToJSR223ElementsV2 Hi, If the script language has not been chosen on the GUI, I propose to add a WARN message into the log to inform that the script will be interpreted as a groovy script It's avoid message like "ERROR - jmeter.protocol.java.sampler.JSR223Sampler: Problem in JSR223 script Echantillon JSR223, message:javax.script.ScriptException: Cannot find engine named: '', ensure you set language field in JSR223 Test Element:Echantillon JSR223" and allow to execute the script 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. ---
Re: JMeter : Migrate to Java8
> > > Java 7 is EOL since April 2015 ( > > http://www.oracle.com/technetwork/java/eol-135779.html) > Oracle jdk 7 is eol. There is still openjdk. I don't think that has > reached eol yet. > EOL means "no more public updates, including security ones". Is there a vast number of users who absolutely cannot install Java 8? Do they know their Java 7 installations might have critical security issues? What are the true reasons to support Java 7? Note: if JMeter was a library that is used by some well-known application that is stuck with Java 7, then it would make sense to support Java 7. JMeter is a standalone application, thus I see very little reasons to stick with Java 7 since April 2015 was more than a year ago. I think we should wait a bit longer before dropping java 7 support, or > maybe take milamber's approach of supporting two branches. Java 6 support was dropped after Java 6 was 2 years into EOL. On April 2017 it would be 2 years since Java 7 EOL. Even if we start java 8 migration right away, we would not release earlier than April 2017. I wish I were wrong here, but my experience shows that JMeter does not release often. Vladimir
Re: JMeter : Migrate to Java8
Am 03.08.2016 um 21:34 schrieb Philippe Mouawad: Hello, What do you think of moving next major JMeter release 3.1 or 4 to Java 8, not the next bugfix release. +1 for me as : - lot of libraries are dropping Java7 compat - lambda, streams,nio2 Java 7 is EOL since April 2015 ( http://www.oracle.com/technetwork/java/eol-135779.html) Oracle jdk 7 is eol. There is still openjdk. I don't think that has reached eol yet. I think we should wait a bit longer before dropping java 7 support, or maybe take milamber's approach of supporting two branches. Regards, Felix
Re: JMeter : Migrate to Java8
Am 04.08.2016 um 16:52 schrieb Milamber: On 04/08/2016 12:45, Felix Schumacher wrote: Am 4. August 2016 11:56:20 MESZ, schrieb Milamber : On 03/08/2016 20:40, Philippe Mouawad wrote: Felix wanted a bugfix release ASAP, I support this idea. Which bug(s) need to make a release asap? Well asap is a bit hard, but I would really like to release a version, which has all the currently known glitches fixed. None are real showstopper, but in sum will be annoying for the users. We can release a version 3.1, perhaps at the beginning of September (after the vacation period). From here to September, we can test the current trunk to find bugs, and if possible avoid 5 RC like 3.0 ;-) Fine with me. Felix Regards, Felix We are free to decide to start a release if it's needed. It could be named 3.1 as there are some enhancements, for me it could come soon. But my proposal on Java 8 is for N+2 (3.2 (not 3.1 as I wrote) or 4) release. On Wed, Aug 3, 2016 at 9:36 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: Philippe Mouawad : Hello, What do you think of moving next major JMeter release 3.1 or 4 to Java 8, not the next bugfix release. +1 When 3.1 is due? Vladimir
[GitHub] jmeter issue #222: fixed garbled label in report dashboard
Github user FSchumacher commented on the issue: https://github.com/apache/jmeter/pull/222 This problem was fixed on trunk with r1754436 (f933590417bc for git). Thanks for the report and the fix, though. --- 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: Default engine script language to JSR223 elements
Great idea I will try to implement it asap and make a PR Antonio 2016-08-04 12:02 GMT+02:00 Milamber : > > Why not. > If the script language has not chosen on the UI, add a INFO (or WARN) > message into the log to inform that the script will be interpreted as a > groovy script > > > On 03/08/2016 18:15, Antonio Gomes Rodrigues wrote: > >> Hi all, >> >> I have a proposition about default engine script language to JSR223 >> elements (sampler, timer...) >> >> For the moment when we had a JSR223 elements, there is no default engine >> script language >> >> And if we forgot to add it we have this error message "2016/08/03 17:46:43 >> ERROR - jmeter.protocol.java.sampler.JSR223Sampler: Problem in JSR223 >> script Echantillon JSR223, message:javax.script.ScriptException: Cannot >> find engine named: '', ensure you set language field in JSR223 Test >> Element:Echantillon JSR223" >> >> My proposal is to put Groovy as default engine script language to avoid >> users to check the logs to understand the mistake they have made >> >> Do you think it's a great idea? >> >> Antonio >> >> >
Re: JMeter : Migrate to Java8
On 04/08/2016 12:45, Felix Schumacher wrote: Am 4. August 2016 11:56:20 MESZ, schrieb Milamber : On 03/08/2016 20:40, Philippe Mouawad wrote: Felix wanted a bugfix release ASAP, I support this idea. Which bug(s) need to make a release asap? Well asap is a bit hard, but I would really like to release a version, which has all the currently known glitches fixed. None are real showstopper, but in sum will be annoying for the users. We can release a version 3.1, perhaps at the beginning of September (after the vacation period). From here to September, we can test the current trunk to find bugs, and if possible avoid 5 RC like 3.0 ;-) Regards, Felix We are free to decide to start a release if it's needed. It could be named 3.1 as there are some enhancements, for me it could come soon. But my proposal on Java 8 is for N+2 (3.2 (not 3.1 as I wrote) or 4) release. On Wed, Aug 3, 2016 at 9:36 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: Philippe Mouawad : Hello, What do you think of moving next major JMeter release 3.1 or 4 to Java 8, not the next bugfix release. +1 When 3.1 is due? Vladimir
Re: JMeter : Migrate to Java8
Am 4. August 2016 11:56:20 MESZ, schrieb Milamber : > > >On 03/08/2016 20:40, Philippe Mouawad wrote: >> Felix wanted a bugfix release ASAP, I support this idea. > >Which bug(s) need to make a release asap? Well asap is a bit hard, but I would really like to release a version, which has all the currently known glitches fixed. None are real showstopper, but in sum will be annoying for the users. Regards, Felix > >We are free to decide to start a release if it's needed. > > > >> It could be named 3.1 as there are some enhancements, for me it could >come >> soon. >> >> But my proposal on Java 8 is for N+2 (3.2 (not 3.1 as I wrote) or 4) >> release. >> >> On Wed, Aug 3, 2016 at 9:36 PM, Vladimir Sitnikov < >> sitnikov.vladi...@gmail.com> wrote: >> >>> Philippe Mouawad : >>> Hello, What do you think of moving next major JMeter release 3.1 or 4 to >Java 8, not the next bugfix release. +1 >>> When 3.1 is due? >>> >>> Vladimir >>> >> >>
[GitHub] jmeter pull request #222: fixed garbled label in report dashboard
GitHub user scyiwei opened a pull request: https://github.com/apache/jmeter/pull/222 fixed garbled label in report dashboard When there are some Chinese characters in the label, the content is all messed up. I change the BufferedReader to UTF-8 encoding. Now it works fine. You can merge this pull request into a Git repository by running: $ git pull https://github.com/scyiwei/jmeter trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jmeter/pull/222.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 #222 commit f4696be6d16f6219989b499d724025372e579505 Author: æä¼ Date: 2016-08-04T09:18:48Z fix:encoding bug for csv reader commit 31c3a15e99920b038070405c832719a2596ae665 Author: æä¼ Date: 2016-08-04T11:03:02Z delete test cases --- 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: Default engine script language to JSR223 elements
Why not. If the script language has not chosen on the UI, add a INFO (or WARN) message into the log to inform that the script will be interpreted as a groovy script On 03/08/2016 18:15, Antonio Gomes Rodrigues wrote: Hi all, I have a proposition about default engine script language to JSR223 elements (sampler, timer...) For the moment when we had a JSR223 elements, there is no default engine script language And if we forgot to add it we have this error message "2016/08/03 17:46:43 ERROR - jmeter.protocol.java.sampler.JSR223Sampler: Problem in JSR223 script Echantillon JSR223, message:javax.script.ScriptException: Cannot find engine named: '', ensure you set language field in JSR223 Test Element:Echantillon JSR223" My proposal is to put Groovy as default engine script language to avoid users to check the logs to understand the mistake they have made Do you think it's a great idea? Antonio
Re: JMeter : Migrate to Java8
On 03/08/2016 20:40, Philippe Mouawad wrote: Felix wanted a bugfix release ASAP, I support this idea. Which bug(s) need to make a release asap? We are free to decide to start a release if it's needed. It could be named 3.1 as there are some enhancements, for me it could come soon. But my proposal on Java 8 is for N+2 (3.2 (not 3.1 as I wrote) or 4) release. On Wed, Aug 3, 2016 at 9:36 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: Philippe Mouawad : Hello, What do you think of moving next major JMeter release 3.1 or 4 to Java 8, not the next bugfix release. +1 When 3.1 is due? Vladimir
Re: JMeter : Migrate to Java8
JMeter 3.0 is the first release which drop the Java 6 support. The history of JMeter releases show that the drop of old java version is long (several year after the end of life) Drop the Java 7 support for the 3.1 or 3.2 seems not follow the same strategy that the past. Perhaps, we need to think about 2 branches: * branch 3.0.x, a sort of LTS release with Java 7 support (back-porting some bug patches from the 4.x branch to this branch) * branch 4.x with the last supported Java version, latest frameworks and innovation. Have 2 living branches need more work for the committers. But I think it's a good compromise between the reliability of JMeter and bring innovation inside JMeter. On 04/08/2016 06:56, Antonio Gomes Rodrigues wrote: +1 for Java 8 Antonio 2016-08-03 21:46 GMT+02:00 Vladimir Sitnikov : Philippe Mouawad : Felix wanted a bugfix release ASAP, I support this idea. It could be named 3.1 as there are some enhancements, for me it could come soon. But my proposal on Java 8 is for N+2 (3.2 (not 3.1 as I wrote) or 4) release No problem with that. Even N+3 would be fine provided we invent some way of releasing more often than once a year. Vladimir
