I met a bizarre issue on my working laptop. Usually, I use my desktop PC for work, but I am in the office today. I am using my working laptop. For some reason, I cannot copy from Windows 10 to JMeter and from JMeter to Windows 10. For example, I am using Notepad++ for creating test cases for interface testing. I am trying to copy-paste from Notepad++ to JMeter. It is not possible.
Something that is very strange for me is that JMeter window has some strange green line at the edge of the window.
I am using JMeter version 5.5
Windows 10 - 64 bit
I tried with JDK 17.0.1 and JDK 1.8_202 (because I wasn't sure if the issue came from Java at all)
I don't think it's connected with JMeter by any means, most probably it's some form of antivirus software which prevents clipboard actions somehow.
You can try increasing JMeter's logging verbosity to DEBUG level just in case and see if there are any suspicious entries in jmeter.log file, however I'm more than sure that the behaviour is caused by some 3rd-party software running on your laptop, if it's not the antivirus it could be something like WRITEit application so do a clean boot and the issue will go away and then add the startup programs and start services one by one unless you detect the one which causes this problem
I had the same problem with JMeter 5.5 when I had changed Option->LookAndFeel->"Metal". Then I returned back to "System" and the problem had gone. Now copy-paste are working well.
I find the solution.
#Dmitri T was right. The issue appears because of antivirus protection. The fix was to run the jmeter.bat file as an administrator.
Related
Last night a new Java 7 update has been released: 7u65. I have a web application where a service applet is loaded, and after the update, my tests on different PCs did not show issues nor wrong behaviors.
Later, I started to receive issue reports related to my product's Java service applet. All the reports came from users who updated Java JRE to 7u65 (from 7u60):
The applet was not loading at all. I display a "Loading" screen when the application starts, and this was not being displayed. Also, all the services provided by my Java applet were unavailable.
After changing the Java Control Panel's advanced configuration to always show the console (in one of the PCs where this issue happened), I discovered that the applet was not even launching the Java console.
Using the same station where the error happens, trying to access java.com to check the current java version, the Java applet is loaded and the console is displayed without errors.
All tests were performed after clearing Browser and Java Cache, and even after removing the installed certificates (mine is a valid signed applet).
I checked the Java 7u65 release notes and none of the mentioned changes seem to affect my applet. Also, there were no issues while using Java 7u60.
I don't have any clues about what is going on, perhaps because the java update was released hours ago. As the Java console can not be displayed even if I configure Java Control Panel to do so, I can not tell if there is any exception. I can not reproduce the issue in my PCs (Windows 8, nor Windows 7, both at 64 bits), but the issue has been reported on Windows 7 PCs.
One of my friends told me that this seems to be happening on machines where Java 7u60 was in use, and then it was updated to Java 7u65 with no deinstallations. Also, this tends to happen in older OS (ie: WinXP) which is more natural.
I write this question because it seems very odd that some PCs have this issue, and some others not. I'd like to know if any one else is having this issue, knows what could be the reason, or has discovered/applied any solution to it. Also, I'd like to share the solution if I ever happen to find it.
Thanks.
Edit:
External references, related to the same Java version (JRE).
Internet Explorer crashing after updated Java to 7u65: An issue with the same JRE version, this time with Internet Explorer and Firefox.
RS Loading Issue (Java) ~ READ: An issue related to the same JRE version update, this time, in a Java Game.
The future of Java on Windows XP:
This end of support announcement has been misread as "Java no longer works on Windows XP" or "Oracle will stop Java updates from being applied on Windows XP". These statements are not correct.
I just ran into this exact problem with one of my applets.
It looks like some changes were made to the handling of the 'java-vm-args' and 'java_arguments' params in 7u65.
'java_arguments' seems to no longer work, when it is specified, my applet will silently fail without even launching the JVM.
I have had the same problem.
I delete C:\Users\${USER}\AppData\LocalLow\Sun
When i reloaded the web page containg the appelets. The JRE recreated this folder again.
And evrything was OK.
There is no big difference between the folders contents .. but it worked.
It seems to be a bug in the jRE
It seems that oracle has changed something with processing default plugin java arguments,
that caused problem in new java.
When upgrading from older version of java it is possible that value for
deployment.javaws.jre.0.args (or deployment.javaws.jre.1.args)
is not defined in
C:\Users\${USER}\AppData\LocalLow\Sun\Java\Deployment\deployment.properties
If you add
deployment.javaws.jre.0.args=
to deployment.properties, applet will work.
It can be done through Java Control panel also:
Java -> View -> double click on Runtime Parameters cell for java 7u65 to enter edit mode -> OK -> Apply
java-jvm-args solution didn't work for me, applet was launched but arguments were ignored.
Oracle has released an update that resolves this specific issue via version 7u67
http://www.oracle.com/technetwork/java/javase/7u67-relnotes-2251330.html
As Miloš Ratković wrote, if customer hasn't string in deployment.properties
deployment.javaws.jre.X.args=
where x is number of java installation for version 7_65 (number of java installation for particular version is X in string deployment.javaws.jre.X.product=1.7.0_65), Java applet failed to start.
For my case I have a solution - don't pass any arguments for my applet.
In my javascript code for starting applet I'm just comment
<param name="java_arguments" value="some arguments">
string
Also, if you delete the directory C:\Users\${USER}\AppData\LocalLow\Sun, during next startup of java applet java write new deployment.properties with correct java args string
Uninstall java 7 update 65 and reinstall java 7 update 55 Download the windows x86 offline version
Go to Java control panel and uncheck: automatic update
When the next window comes up, click on "do not check"
then click on "apply" and "ok"
close all browsers and reopen them to continue your work
This has worked for me every time so far and I have been doing this for the last two weeks now with "0" issues.
Sorry, this is not the answer. I was trying to verify the feedback about JRE 7u65 not able to accept "java_arguments"; however, I setup a Windows x32 and installed (new) 7u65 without upgrade from any older version. With the "java_arguments", the machine is able to load the applet in IE8 and FF30, when few specific PCs do fail the same applet with upgraded u65.
I just wonder something about java applet with awt. I quite disappointed with this problem and want to throw it away sometimes. Below are my descriptions:
I already created one application using java applet with awt controls on my own computer, let's say computerA using Window 7 32bit Operating System. To up and running this application, I update java version to the latest one.
Application is working fine with computerA. However, this application also need to run on the others as well. As my own situation, I run with another computer, let's say computerB using Window 7 64bits Operation System. I knew that the application created with 32bits java version, thus I decided to install this java version on computerB. However, when I run the application it can only display interface on browswer, but some of its function did not work.
Yet I didn't throw it away, I decided to configure in the last computer, let's say computerC. This computer use Window 8 32bits Operating System. I did configure as I did with computerA and computerB. The result is still exact as computerB.
I also checked up this solution on here, but it is not fit my problem.
Here are my questions:
What is the exact problem on here?
Where does the problem come from?
Is it solvable?
How can I solve this kind of problem? Any helps?
Update:
PostgreSQL Database also install in other local computers as well.
I noticed that If I convert my code into eclipse project, it worked fine. No problem at all.
Thanks in Advance.
I've recently had my app moved from Websphere Application Server 6.1 to WAS 7.5, due to end-of-life for 6.1. Consequently, I needed to update my debugging server. I found this to be an opportune time to move my application from an IBM RAD IDE to Eclipse (already had Indigo installed). Or so I thought.
Anyway, the powers that be, here, have recommended taking my debugger all the way to WAS 8.5, since I'm only using it to debug.
But the issue that I'm encountering is that I cannot get the debugger to stop on my breakpoints. I've got approx. 10 breakpoints in my opening page, all in JSP/Java code.
I'm running Java 1.6.0_32 and Java SE Runtime Environment build 1.6.0_32-b05. I really don't know how to check which JDK I've got loaded. I've seen recommendations to "go back" to JDK 1.5, but I can't be certain that's not what I'm running.
And to cover a few other bases, I have JUST started my system for the day, opened the IDE, started the server in debug (says "Debugging, Synchronized"), put focus on the opening page of the application and clicked "Debug on server". The front page opens without stopping at any of the breakpoints.
Does anyone have ideas or suggestions?
If you use eclipse's debugger and running the application outside eclipse environment , we have to configure it as remote java application.
Also check if the code deployed in server is in sync with the one present in workspace.
anything wrong of the ecplise's site.
Run->Skip all breakpoints
Well, I had recently faced this problem, where the code did not use to stop at breakpoints while I was in debugging mode and was sure that the particular piece of code is executing. In order to solve the problem, I did a clean-build-republish but it did not work, recreated the profile and readded the server with new profile, still did not work then finally re-installed RAD and web-sphere but It still did not work. Then I found the below article
https://www-304.ibm.com/support/docview.wss?uid=swg21240896
and realized it could be a problem due to some other OS process interfering with debug process/port so I performed a system restore. After restore when I deployed the application, debugger started working properly.
I'd like to say I found the answer to this, but I never did. I ended up dropping RAD and moving to debugging on Jetty. My local testing isn't EXACTLY as it would be on the test server, but it works. Not sure if this should be flagged as "answered" or not.
UPDATE: I have left this project but before I did, the entire development platform was moved to IDEA and debugging was no longer an issue. I don't know if I should find a way to mark this question as inactive or closed or whatever so that it's not just sitting out here getting views and responses when it's no longer an issue for me.
I have an Applet and when I try to run it on my laptop, a headless exception is thrown by Java at the line where a JFrame is created. Now I know why the JFrame normally causes the exception but my computer was not in headless mode to begin with. I'm also still not sure what headless mode entails exactly.
I'm running Ubuntu and have a pretty recent version of java.
Also, I have successfully created JFrames and such in Eclipse when running Windows on my laptop (if that helps).
Have you tried setting java.awt.headless=true? I have done this once before on Solaris with no x-server in order to use the java.awt print libraries. It worked a treat. However it was more than five years ago and I don't have the source handy.
See Setting java.awt.headless=true programmatically
PS Are you on Ubuntu server or desktop? If the latter, I'd question why Java thinks you are headless.
Look # following link that might help:
http://www.theserverside.com/discussions/thread.tss?thread_id=52535
I've written module that generates excel, and deployed it under Servicemix. In Windows environment everything is fine, but under Linux Servicemix unexpectedly crashes on following call:
for (short i=0;i<=3;i++) {
log.trace("AutoSize column {}", i);
worksheet.autoSizeColumn(i);
}
I'm using POI version 4.2-FINAL, FuseESB 4.2, Java 5.0. There are, however, no hs_err*.pid files. Servicemix logs ends on first autoSizeColumn call.
Did anyone met such behaviour and know, how it is caused and how to come this around?
In order to be able to calculate the column widths, POI needs to get hold of the Font in use, and ask it to size each character in turn. On all JVMs that I know of, this requires a graphical environment, because the actual work is delegated by the JVM to the underlying graphical system.
If you're on Windows, you always have a graphical system so that's fine. On Linux, if you're running on the command line on a server, you may not. (Linux as a desktop is fine though)
If you are running on a linux server without an X server running, you'll need to tell Java to run "headless". As taken from the POI AutoSize documentation
To calculate column width Sheet.autoSizeColumn uses Java2D classes that throw exception if graphical environment is not available. In case if graphical environment is not available, you must tell Java that you are running in headless mode and set the following system property:
java.awt.headless=true
Try setting that when you start your JVM, and I've a hunch it'll fix your issue (which is most likely caused by Java not finding a complete graphical environment)
We haven't tested it as it's not released yet, but since POI 5.2.3 there's a boolean system property that could help: org.apache.poi.ss.ignoreMissingFontSystem
Instructs Apache POI to ignore some errors due to missing fonts and
thus allows to perform more functionality even when no fonts are
installed. Note: Some functionality will still not be possible as it
cannot use default-values, e.g. rendering slides, drawing, ...
Hi I faced a similar problem. I didn't have any crash, but on my development environment (Windows) the autosizecolumn worked. On production environment (Unix-like) it didn't work. I put system property java.awt.headless=true but I had the problem still. I solved following this solution but I added all the Arial Family fonts. Hope it helps anyone.