Develop Reference

Server closes connection when trying to connect Java application to Redshift database

I'm trying to connect a Java application to a Redshift database. When I run DriverManager.getConnection(), it sits for a long time (minutes) and finally throws an exception:
Exception in thread "main" java.sql.SQLException:
[Amazon](600001) The server closed the connection.
at com.amazon.support.channels.TLSSocketChannel.readBytes(Unknown Source)
at com.amazon.support.channels.TLSSocketChannel.doHandshake(Unknown Source)
at com.amazon.support.channels.TLSSocketChannel.<init>(Unknown Source)
at com.amazon.redshift.client.PGClient.checkSSL(Unknown Source)
at com.amazon.redshift.client.PGClient.<init>(Unknown Source)
at com.amazon.redshift.core.PGJDBCConnection.connect(Unknown Source)
at com.amazon.jdbc.common.BaseConnectionFactory.doConnect(Unknown Source)
at com.amazon.jdbc.common.AbstractDriver.connect(Unknown Source)
at com.amazon.redshift.jdbc.Driver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
I can connect using the same connection string and credentials from SQL Workbench on the same machine. Also, if I supply bad credentials to the connection, it gives an authentication error. So I don't believe this is an Amazon security issue, which seems to be the most common reason for an inability to connect.
Other ideas?
Update: The mystery deepens. Other members of the team are able to check out the code and run it successfully. We have the driver in our team's shared maven repository.

Well... not sure what the problem was. But I did an Eclipse update and it went away.

How to write log file for applet application? [duplicate]

This question already has an answer here:
How to write to a file in applets in java?
(1 answer)
Closed 6 years ago.
I am getting an exception while I am trying to write a log using log4j.
Here is the exception that is thrown:
java.security.AccessControlException: access denied ("java.io.FilePermission" "D:\appletServer\bqapplet.log" "write")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkWrite(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)
at org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java:207)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165)
at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307)
at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172)
at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104)
at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842)
at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768)
at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:648)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:514)
at org.apache.log4j.PropertyConfigurator.configure(PropertyConfigurator.java:440)
at com.bqurious.applet.CommandExecutor.<init>(CommandExecutor.java:41)
at com.bqurious.applet.BqAppletMainAppender.waitForConnections(BqAppletMainAppender.java:604)
at com.bqurious.applet.BqAppletMainAppender.run(BqAppletMainAppender.java:195)
at java.lang.Thread.run(Unknown Source)
Error! - java.security.AccessControlException: access denied ("java.io.FilePermission" "D:\appletServer\bqapplet.log" "write")

Applets will per default run in a sandboxed environment. In order to allow it to access local files you will have to sign it. Depending on your use case, a different approach may be to log to standard out (which will be available on the java console).
There is a tutorial at Oracle where you can read more about What Applets Can and Cannot Do.

Additional Permission required if Java Console is open?

I've found an interesting behaviour in my Java Applet.
All seems to work fine, but when i have the Java Console Window the Applet does nothing and i can see the following exception to be thrown in the Java Console:
Exception in thread "Thread-33" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.deploy.uitoolkit.impl.awt.ui")
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.checkPackageAccess(Unknown Source)
at sun.plugin2.applet.SecurityManagerHelper.checkPackageAccessHelper(Unknown Source)
(...)
So my question is now, why does the Application need more permissions when the console is open than when its closed? I've tried to google the permission but no one seems to have had any problems with this.

"access denied" when using JDBC from a browser applet

I have a java applet that queries an Oracle database for data. When run from inside an IDE, it functions just fine. But when I run it as an applet embedded in a webpage, I get an "access denied" error in the class loader, and I haven't the foggiest notion what it is requiring of me:
Sep 06, 2011 12:58:48 PM oracle.jdbc.driver.OracleDriver registerMBeans
WARNING: Error while registering Oracle JDBC Diagnosability MBean.
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.Thread.getContextClassLoader(Unknown Source)
at oracle.jdbc.driver.ClassRef.<init>(ClassRef.java:75)
at oracle.jdbc.driver.ClassRef.newInstance(ClassRef.java:51)
at oracle.jdbc.driver.OracleDriver.registerMBeans(OracleDriver.java:311)
at oracle.jdbc.driver.OracleDriver$1.run(OracleDriver.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.jdbc.driver.OracleDriver.<clinit>(OracleDriver.java:195)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.binderton.oracle.ConnectionManager.open(ConnectionManager.java:17)
at com.sun.javafx.applet.FXApplet2$2.run(Unknown Source)
at com.sun.javafx.application.PlatformImpl$3.run(Unknown Source)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.access$100(Unknown Source)
at com.sun.glass.ui.win.WinApplication$1$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.binderton.oracle.ConnectionManager.open(ConnectionManager.java:17)
at com.sun.javafx.applet.FXApplet2$2.run(Unknown Source)
at com.sun.javafx.application.PlatformImpl$3.run(Unknown Source)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.access$100(Unknown Source)
at com.sun.glass.ui.win.WinApplication$1$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" getClassLoader")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.Thread.getContextClassLoader(Unknown Source)
at oracle.jdbc.driver.ClassRef.<init>(ClassRef.java:75)
at oracle.jdbc.driver.ClassRef.newInstance(ClassRef.java:51)
at oracle.jdbc.driver.OracleDriver.<clinit>(OracleDriver.java:260)
... 12 more
Got ErrorEvent[url=null label=Failed to start application. cause=null

Applets runs in an environment with very restrictive security rules. You need at least to sign your applet.
But, the problem is bigger here, doing JDBC inside an applet is a very bad idea. The applet's source code is publicitly available and is thus sensitive for easy hacks. You should really create a webservice for that instead and then let your applet access that webservice instead. With a webservice, your applet will be able to exchange information with the DB by just HTTP requests/responses. With a webservice you hide the DB access details, JDBC and SQL code from the public.
How exactly to create a webservice depends on the server environment and the programming language used. In Java EE for example, you could already use a simple Servlet for this, but also JAX-RS and JAX-WS is supported for restful (XML/JSON) and XML webservices respectively. An applet is without any security restrictions allowed to connect with its host whose address is available by getCodeBase() E.g.
InputStream response = new URL(getCodeBase(), "servlet?foo=bar").openStream();
// ...

Note that if you follow the advice of BalusC and hide the DB behind a an active page (e.g. a servlet, PHP, ASP etc.) that is on the same server as the applet, the applet could most probably remain sand-boxed. It would be the active page that is trying to access class-loaders (as well as the DB).

Testing JCTerm, java applet terminal emulator, works in Eclipse, but not in browsers

Testing an unmodified version of JCTerm (terminal emulator, can be used as an applet; I would like to use the applet functionality), everything seems to be working fine in Eclipse's AppletViewer, but testing the resulting jar file in an web page, all options display a message box with a flashing yellow warning symbol and do nothing. Some options display a "Establish the connection before this setting" error.
The option I'm interested in using is 'Open SHELL Session...' from the File menu. When trying 'Open SHELL Session...' option, the Java Console for the applet displays this stuff, which seems directly related. I don't have a clue as to what it means though.
network: Connecting http://xxx.xx.xx.xxx/crossdomain.xml with proxy=DIRECT
network: Connecting http://xxx.xx.xx.xxx:80/ with proxy=DIRECT
java.security.PrivilegedActionException: java.net.ConnectException: Connection refused: connect
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source)
at sun.plugin2.applet.Applet2SecurityManager.checkConnect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at com.jcraft.jsch.Util$1.run(Util.java:354)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at com.sun.deploy.net.CrossDomainXML$2.run(Unknown Source)
... 10 more
An example of this program working correctly can be found here, http://wiredx.net/jcterm/

I'm the author of jcterm.
The jar files at http://wiredx.net/jcterm/ have been digitally signed.
So, if you copy and intstall those files into your web server, it will work.

This looks like a security problem.
By default, an unsigned Java applet can only connect to the host if was loaded from. Additionally, if the host you want to connect to allows this with it's crossdomain.xml file, you can also connect to other hosts.
Judging from the stack trace, you want to connect to a host which does not have an HTTP server, and thus can't provide a crossdomain.xml file. For this reason, you get this exception here.
There are these ways out of this:
Put the applet on the same web server which you want to connect to with SSH later. (Every applet can connect to its own host.)
Let the SSH server have a minimal web server with a crossdomain.xml. (The crossdomain.xml must allow content from the applet's server to access this server.)
Sign the applet (and let the user trust it). (Signed and trusted applets are allowed to do everything.)
The official WiredX sample applet you linked uses the last method, this is why it works even when connecting to your server.