Current Jmeter version -5.2.1
I even tried by setting up the classpath as below in the jmeter.properties file -
user.classpath=/usr/local/Cellar/groovy/3.0.4/libexec/lib
Kindly help
Current JMeter version is 5.3 and according to 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article you should be always using the latest stable JMeter version, it can be obtained from JMeter Downloads page
JMeter 5.2.1 comes with Groovy 2.4.16, it might be better to stick to that version just in case
You need to restart JMeter in order to pick up any properties or classpath changes
If you installed JMeter using Homebrew it might be the case the Groovy library was deleted by someone by accident, you can get it back like brew reinstall jmeter.
And last by not the least you can always drop the library(ies) you need to add to JMeter to /usr/local/Cellar/jmeter/5.2.1/libexec/lib/ folder
Related
I am experiencing difficulties to get started using StormCrawler using the StormCrawler+ElasticSearch archetype. On the StormCrawler website, I see two versions, namely 1x and 2x. Similarly, Apache Storm comes in version 1 and 2.
Should I install StormCrawler using the version 1x or 2x?
What version of JDK does StormCrawler require? Is there a need to use Oracle JDK or can the OpenJDK be used as well?
I want to use StormCrawler to identify and process images and documents. At what place in the topology can these tasks best be added?
Update: According to the following URL (Storm Crawler with Java 11), StormCrawler 2 is advised. What StormCrawler+ElasticSearch archetype should be used when using StormCrawler 2?
SC 1.x is stable and the current version, 2.x is less tested but will be the main version at some point.
The thread mentioned in the question does not advise you to use SC2 as such, it mentions that you should use it if you need Java 11. If you are on Java 8, then you can use whichever version you want.
SC works fine with openjdk.
As for question #3, it depends what you want to do. Can you please elaborate?
I am trying to integrate BDD using Cucumber. But I am really confused what is the difference between io.cucumber and info.cukes libraries. And which one to use and when.
I tried to read and understand the github README.md file still can't make heads or tails.
Still further I am not sure what is cucumber-jvm. Why do we need cucumber-junit (can't the standalone junit library suffice).
Thanks in advance. Any help is much appreciated.
Refer to the release notes for more details. - https://github.com/cucumber/cucumber-jvm/blob/master/CHANGELOG.md.
There has been substantial changes in cucumber 2. Refer to this for more - https://cucumber.io/blog/2017/08/29/announcing-cucumber-jvm-2-0-0
io.cucumber and info.cukes are Maven group ids. info.cukes was for Cucumber version till 1.2.5. The latest version are in io.cucumber starting from 2.0.0. There is also a new version 3 with more goodies in github with the master as mentioned in the release notes.
The reason the groupid was changed because gherkin has changed the groupid similarly.
cucumber-jvm is the java implementation of Cucumber framework. there are many other implementations in other languages - https://github.com/cucumber.
When you use the #RunWith(Cucumber.class) on top of the test class, it means that a specialized runner is being used which will execute the feature files. The default runner of junit will not get you anywhere, though might cough up some exceptions.
I want to package a Groovy CLI application in a form that's easy to distribute, similar to what Java does with JARs. I haven't been able to find anything that seems to be able to do this. I've found a couple of things like this that are intended for one-off scripts, but nothing that can compile an entire Groovy application made up of a lot of separate Groovy files and resource data.
I don't necessarily need to have the Groovy standalone executable be a part of it (though that would be nice), and this is not a library intended to be used by other JVM languages. All I want is a simply packaged version of my application.
EDIT:
Based on the couple of responses I got, I don't think I was being clear enough on my goal. What I'm looking for is basically a archive format that Groovy can support. The goal here is to make this easier to distribute. Right now, the best way is to ZIP it up, have the user unzip it, and then modify a batch/shell file to start it. I was hoping to find a way to make this more like an executable JAR file, where the user just has to run a single file.
I know that Groovy compiles down to JVM-compatible byte-code, but I'm not trying to get this to run as Java code. I'm doing some dynamic addition of Groovy classes at runtime based on the user's configuration and Java won't be able to handle that. As I said in the original post, having the Groovy executable is included in the archive is kind of a nice-to-have. However, I do actually need Groovy to be executable that runs, not Java.
The Gradle Cookbook shows how to make a "fat jar" from a groovy project: http://wiki.gradle.org/display/GRADLE/Cookbook#Cookbook-Creatingafatjar
This bundles up all the dependencies, including groovy. The resulting jar file can be run on the command line like:
java -jar myapp.jar
I've had a lot of success using a combination of the eclipse Fat Jar plugin and Yet Another Java Service Wrapper.
Essentially this becomes a 'Java' problem not a groovy problem. Fat Jar is painless to use. It might take you a couple of tries to get your single jar right, but once all the dependencies are flattened into a single jar you are now off an running it at the command line with
java -jar application.jar
I then wrap these jars as a service. I often develop standalone groovy based services that perform some task. I set it up as a service on Windows server using Yet Another Java Service and schedule it using various techniques to interact with Windows services.
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
How should I package and ship my groovy scripts without assuming groovy to be installed (and on PATH) on client machine? However, JDK/JRE will be available on all client machines.
What I'm currently doing is to groovy-compile & bundle related scripts in a jar with groovy-all-xxx.jar included in the lib (Netbeans does this automatically). But the problem with this approach is - with every independent small script (project), I have to bundle the huge groovy-all jar creating a big binary.
Just wanted to know if there is any better way of doing this.
You might be able to use the extension mechanism for this - that way each client machine would have to download groovy-all-xxx.jar just once.