Develop Reference

Not able to record in Jmeter after OS reinstallation

I am using Jmeter 2.13 version and with that I used to record many scripts earlier successfully without any issue . Now, my OS has been reinstalled and I am holding Windows 8.1 , 64 bit version.After re installation, I am not able to record HTTPS web applications even though my proxy configuration is correct. After I setup everything in Jmeter, and click on start from work bench and I navigate to the browser try to access the application, it shows "Server not found" message.
However, the scripts which I saved earlier are working fine without any issues. only the new recording is not working.
Help me with the possible solutions.

"Server not found" indicates that browser is unable to access Internet (or intranet).
Most likely you're sitting behind the corporate proxy server and in previous JMeter installation you had these proxy server details specified in system.properties file like:
http.proxyHost=10.20.30.40
http.proxyPort=3128
https.proxyHost=10.20.30.40
https.proxyPort=3128
Double check with your network administrator if this is the case, if yes - take steps from Using JMeter behind a proxy User Manual chapter.
You can also try out JMeter Chrome Extension as an alternative solution - in that case you don't have to worry about proxies and SSL certificates substitution.

How do I set up Glassfish to go via a proxy server?

I have been having issues with running a Glassfish v2.1.1 instance on my local machine from within the office, where we have a proxy server for outgoing connections. My initial workaround has been to work from home.
I am calling a SOAP service on a HTTPS server outside of the company. As Glassfish is not going via the company's proxy server, I get the following error when trying to initialise my SOAP clients:
javax.xml.ws.WebServiceException: Failed to access the WSDL at: https://www.hostname.com...
and
Caused by: java.net.UnknownHostException: www.hostname.com
I have proxy environment variables set on my command line, as well as my system proxy settings all working correctly so that I can get to the WSDL with the browser. How should I configure Glassfish?

I had a lot of trouble finding an answer to this, as the topic isn't covered in a lot of detail on the web. One link told me how to configure the HTTP proxy, but mentioned nothing about HTTPS, so it took me a while to figure it out.
Open up the admin console on your Glassfish server and go to:
Application Server -> JVM Settings -> JVM Options. Click "Add JVM Option" 4 times and enter the following 4 options
-Dhttp.proxyHost=proxyhostname
-Dhttp.proxyPort=8080
-Dhttps.proxyHost=proxyhostname
-Dhttps.proxyPort=8080
Where proxyhostname and the port number are correct for your setup. Then you need to restart the server.
Note that I couldn't find any options for setting up the proxy from a PAC file, nor for proxies which require auth. In this case, you may need to install a local auth proxy handler like Authoxy for Mac OS X, which turns your localhost into a non-auth proxy and masks the authentication request from the central auth proxy.
Also, this link was good for various proxy options to the JVM:
http://download.oracle.com/javase/6/docs/technotes/guides/net/proxies.html

You have to explicitly set the proxy server. Several options are available depending on the Glassfish version. In general you can set the proxy by either using JVM arguments or the Glassfish Admin console. An intro for GF3 is available here (sorry for only providing a link, but I do not want to repeat all the details here).

Just to make the answer complete, if the proxy requires user name and password, set the following in Glassfish:
-Dhttp.proxyUser=someUserName
-Dhttp.proxyPassword=somePassword

The host cannot be resolved, are you sure you use a hostname resolvable by an internet DNS server or are you using something that can only be resolved from within your network or even worse, a hosts entry local to your machine?
Aside from that, the proxy server might be denying you access to some ports, but this is probably not your problem right now. If the proxy allows access to port 80, try running your Glassfish on port 80 as well if you get any connection timeout errors.

Java Applet: JDBC-mysql work in eclipse but not in the browser

I have a weird problem. My java applet work fine in my IDE (Eclipse), no errors whatsoever. It still "work" when I run the applet in my browser, but it can't connect to my remote mysql database. Is there any reason as to why it wont connect to a remote mysql-database in the browser, while it will in Eclipse? Where are the error logs placed? Are there any good applet debugging tools?
connect = DriverManager.getConnection("jdbc:mysql://178.0.0.0:3306/database","username", >"password" );

Is your applet unsigned? There are security restrictions around applets that prevent them from connecting to servers other than the ones they were downloaded from.
http://download.oracle.com/javase/tutorial/deployment/applet/security.html

I'm guessing it a permissions problem in MySQL. It needs to know the machine from which you connect in addition to credentials.

Socket connection to originating server of an unsigned Java applet

I have read everywhere that unsigned Java applets are not allowed to make network connections to any server but the one which originated the applet. This is OK for my application since my applet only needs to talk to the server. However, when I wrote a test applet to try opening a socket to communicate with a process on my development machine, it throws the following exception:
Error establishing socket connection:
java.security.AccessControlException:
access denied (java.net.SocketPermission 127.0.0.1:11000 connect,resolve)
The code which caused the exception:
private void sendMsg(String msg) {
Socket s = null;
try {
s = new Socket("localhost", 11000);
}
catch (Exception e) {
System.err.println("Error establishing socket connection:");
e.printStackTrace();
return;
}
try {
OutputStream out = s.getOutputStream();
out.write(msg.getBytes());
out.flush();
s.shutdownOutput();
s.close();
}
catch (Exception e) {
System.err.println("Error in writing to the socket:");
e.printStackTrace();
}
At first I thought it was a problem in my code that my inexperience had caused me to miss. However, I get the same exception when trying to run the Talk Server example from the official Java Tutorials. This leads me to believe that I actually have a setup problem, or a misunderstanding of the default security restrictions. Does the default security manager prevent you from opening sockets to the machine running the applet even if it is also the machine serving the applet? If so, that is a problem for me because the deployed system will need to allow a user logged in on the actual server to use the same applet that a remote user would use. Is there a way around the exception I'm getting that doesn't involve signing the applet? I don't want to go to the trouble if not necessary.
NOTE: I know it would be better not to have users access the applet from the server. That wasn't the original design, but practical considerations unfortunately forced this implementation compromise on me.
UPDATE: Viewing the applet's page from a webserver solves the problem. Even if the server is localhost. The security update in Java 1.6.0_11 only applies to applets loaded directly from the local file system.

This is due to a change in the PlugIn introduced in a recent security update. Sorry! Applets loaded from the local file system are no longer granted socket permissions to localhost.
Solution 246387 : A Security Vulnerability in the Java Runtime Environment may Allow Code Loaded From the Local Filesystem to Access LocalHost
The Java Runtime Environment (JRE)
allows code loaded from the local
filesystem to access localhost. This
may allow code that is maliciously
placed on the local filesystem and
then subsequently run, to have network
access to localhost that would not
otherwise be allowed if the code were
loaded from a remote host. This may be
leveraged to steal cookies and hijack
sessions (for domains that map a name
to the localhost).

I suspect you're running the applet from a local HTML file (eg applet.html), which brings up the error Tom Hawtin mentions.
Instead run a webserver (eg Tomcat) on your machine and access the file through http://localhost/applet.html
It would be probably be better to open the socket port from a servlet in your webserver too. This way your webserver manages your whole system, and it can be simpler to transfer between machines.
I use the same setup regularly with socket connection between applet and servlet on both localhost and live.

Oracle knows of this Java problem that severely restricts use of Applets: A Security Vulnerability in the Java Runtime Environment may Allow Code Loaded From the Local Filesystem to Access LocalHost is what they're saying. This was Bug Id 6704154
And their solution is: There is no workaround for this issue; this 'workaround' was issued 03-Dec-2008. So, if you wish to use Applets with Tomcat or any like server, you'll have to go back to Java 1.4.2
It took me over a week to fully document these facts and since I'm in the same boat.

How do I permit my Java applet to use MySQL?

I've recently gotten my hobby java project embedded into a page thanks to this very site, but now I'm having some security issues.
I have the include:
import java.sql.*;
and the line:
Class.forName("com.mysql.jdbc.Driver").newInstance();
as well as a mysql .jar file in my src directory, it works from the console, and in the applet works fine from the applet - up until that forName() line in my code, where it throws the exception:
Exception: com.mysql.jdbc.Driverjava.lang.ClassNotFoundException: com.mysql.jdbc.Driver
java.security.AccessControlException: access denied (java.lang.RuntimePermission exitVM.-1)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkExit(Unknown Source)
at java.lang.Runtime.exit(Unknown Source)
at java.lang.System.exit(Unknown Source)
at applet.Database.connectDB(Database.java:80)
etc...
I think I may be able to fix it with a client.policy file, otherwise I might need to write an abstraction layer which uses a server-client network connection to query from the server-side...
I'm sure the Java gurus here probably know the best way about it.

I think the security exception is actually from a System.exit() call in your applet, after the Class.forName(). Generally you are not allowed to call System.exit() in unsigned applets as it shuts the whole JVM down. Have you checked if line 80 is actually the Class.forName() line, or does line 80 have some kind of exception handler which tries to call System.exit() if the driver does not load?
Anyway, in order to load the mysql jar file in your applet, you need to include it in an ARCHIVE attribute like this:
<APPLET ARCHIVE="mysql.jar" CODEBASE="./src/" ...
Once you get past this stage, you will still need to host the mysql server at the same IP number/hostname as the webserver, and open it to all the same people who can access your applet. As Tony said, this isn't how people normally do it, for security reasons. Better to write something on the server side, if you have control of the app server, and use XML or some other data exchange method to get the data out to the applet. Of course if you are just experimenting to learn about applets, then it's probably fine - but do take care to keep mysql behind your firewall if possible.

If you're trying to use the a JDBC driver from the applet, then the applet needs to be signed with a certificate, and your server needs to deliver this certificate when the applet is loaded on the client side.

The accepted way to do this is to make HTTP requests for data from the server from which the applet was loaded, and run the queries from the server. JSON or XML are good ways to exchange data between the applet and the server (similar to the way you do an AJAX application, sending XML or JSON between the browser and the server).

As mentioned in one of the other answers (#Leigh Caldwell), I would strongly recommend not doing things this way. If your applet has access to MySQL then so does everyone else in the world. Decompilation is so trivial these days that it would only be a moment's work for an industrious hacker to get the applet credentials to the database. Also, MySQL's user/pass authentication is fairly weak, most of its security is IP-based. By opening it up to the world, you're throwing away your first line of deference.
A better approach would be to build some sort of frontend protocol on the server side (XMLRPC would be a good foundation and easy to use). If the applet absolutely needs access to a database, your best bet would be HSQLDB in memory. This doesn't require any file permissions and can be run completely in-sandbox. The local in memory database could be synchronized with the server as necessary using the aforementioned XMLRPC facade.

Try getting rid of the newInstance() part. I think just having the Class.forName() does it for loading the driver.

The exception tells you that the applet has been unable to load the driver class. Your applet needs to download the jar containing the class at runtime, via HTTP, so you must have the jar (mysql.jar or whatever it is called) available on the webserver.
Once you solve this problem the user will have to allow the applet permissions so that it can make a TCP socket connection to the mysql db server. They will prompted with a dialog box...