I am running two axis2 services which communicate with each other. On every service startup I get this error:
2014-02-24 13:02:31,258 [INFO ] HTTPSender - Unable to sendViaPost to url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140)
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:125)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:621)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:193)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:404)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:231)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:443)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:406)
at org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run(OutInAxisOperation.java:446)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Since this error is not important, I would like to catch it and to print some better error message instead of the whole stack trace. Where do I catch this error?
Looking at the stack trace, I don't think you can catch it. Catching it would require that you own code somewhere in the Thread where the exception is being thrown.
Looking at the lowest stack in the trace shows this:
at java.lang.Thread.run(Thread.java:724)
To me this says that the exception is occurring in a thread most likely started by Axis. Because of this you can't catch it and show an error message.
If this is expected behavior, the best you can do is to configure your logging framework not to show INFOs from Axis. Be aware that this may mean you'll also miss more useful error messages as well.
All in all, I would focus on how to solve the "Unable to sendViaPost" from happening rather than suppressing the logging statement.
To answer your comment question: As you can see from the stack trace, the exception is not caught by any client code but is bubbled up to Thread itself. This is the stopping point for an Exception and where it stops. If you were going to catch it you'd have to have code in its call stack (which you don't, since when the thread is created by Axis a new call stack is created for the new thread Axis starts).
Read more here. The only difference in your case is that since the exception is not thrown on the main thread the program doesn't exit, but the thread where the exception occurs is terminated.
To sum it up: You have no code in the call stack and therefore cannot catch the exception. The only other option is to turn of INFO statements for Axis.
If I am understanding the question properly you're attempting to catch something that is not the exception that is being thrown.
This:
HTTPSender - Unable to sendViaPost to url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
is what is being attempted. When it failed it's throwing a ConnectException.
Which you can simply catch with
try{
//Code that Makes the Connection
}
catch (ConnectException e)
{
e.printStackTrace();//Or What ever your message may be
}
Without seeing some code it's impossible to give a definitive answer. But this likely will solve the problem.
One Caveat, if you do catch a ConnectException to suppress it, you could suppress when there actually is a problem that would also throw a ConnectException.
If this is happening when you are starting up the server you might want to check why this is happening before trying to suppress it.
If it's refusing the connection that you are attempting you might want to ensure where it is connecting to has an available socket to connect to.
2014-02-24 13:02:31,258 [INFO] HTTPSender - Unable to
sendViaPost to
url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
Well, if you look closely, the message which you are trying to catch isn't an ERROR at all. It's an INFO log generated from HTTPSender. Only thing which you should catch in this entire stacktrace is java.net.ConnectException and check for message Connection refused.
You can make it easier for your clients though and provide a message, by wrapping the java.net.ConnectException with message Connection refused or throwing a custom exception with the original exception as the cause.
UPDATE
java.net.ConnectException is an elementary exception in network transactions. Generally standard libraries do not catch them unless there is something specific to be done.
In this case, if you are unable to catch hold of java.net.ConnectException, then you can look out to catch AxisFault thrown by org.apache.axis2.description.OutInAxisOperationClient.send.
Below snippet may be useful for you.
try {
...
} catch (RemoteException ex) {
if(ex instanceof AxisFault){
logger.error("Axis Fault error: " + ((AxisFault)ex).getFaultString());
throw new CustomExcpetion(" Custom Message ");
}
}
Also note that AxisFault is a subclass of java.rmi.RemoteException and this will not get caught when you use java.lang.Exception in a catch statement.
Shishir
Related
Kind Attn Moderators: Before marking this query as duplicate, please note I have checked these questions...
java.net.SocketException: Connection reset
What's causing my java.net.SocketException: Connection reset?
Getting error "java.net.SocketException: Connection reset"
...and was unable to fix the issue. Also I believe the context & error is different from those, thus seeking help here.
Context: Download a csv file from NSEIndia website to a local folder (Note: Am able to download CSV files from other random websites).
Issue: Returns an error - javax.net.ssl.SSLException: Connection reset (Full error pasted below)
Observation: I am perplexed, as I faced this same issue yesterday, but after a couple of retries, it worked. I made no changes to code or settings.
Question: Is there anything I can do from my end to ensure this error is not seen with this specific website ?
Code:
// Using FileUtils from -> import org.apache.commons.io.FileUtils;
try {
FileUtils.copyURLToFile(new URL("https://www.nseindia.com/content/fo/fo_mktlots.csv"),new File("D:\\Download\\t1.csv"));
} catch (IOException e) {
e.printStackTrace();
}
Error:
javax.net.ssl.SSLException: Connection reset
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:324)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:267)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:262)
at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1652)
at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1038)
at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:245)
at java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:285)
at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:344)
at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:746)
at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689)
at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:717)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1610)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1515)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:224)
at java.base/java.net.URL.openStream(URL.java:1162)
at org.apache.commons.io.FileUtils.copyURLToFile(FileUtils.java:1456)
at main.Test.dummy3(Test.java:327)
at main.Test.main(Test.java:59)
Suppressed: java.net.SocketException: Connection reset by peer
at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:421)
at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:441)
at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:825)
at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1007)
at java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:82)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:355)
... 17 more
Caused by: java.net.SocketException: Connection reset
at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:324)
at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:351)
at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
at java.base/java.net.Socket$SocketInputStream.read(Socket.java:937)
at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:450)
at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:68)
at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1409)
at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1022)
... 13 more
My web application runs on Spring (MVC) 4.2.9.RELEASE, Hibernate 5.1.3.Final, Spring Data 1.8.2.RELEASE, and MS SQL Server (2014).
In the Spring context, I have the following exceptioin hanlder:
<bean id="simpleMappingExceptionResolver" class="myproject.CustomMappingExceptionResolver">
...
</bean>
to catch and save stack trace. I am able to see the following deep in a long stack trace printed in the logs:
......
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
... 113 more
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Transaction (Process ID 73) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:258)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1535)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:467)
How can I find the following exception class in the above exceptioin hanlder (and given an Exception instance) :
com.microsoft.sqlserver.jdbc.SQLServerException
AND the corresponding message:
Transaction (Process ID 73) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
If I understood you correctly you need to catch a nested exception. That's a bit tricky, but doable. You need to have a try-catch block for the top level exception that you expect. In the catch clause, you can use exception.getCause() to step down one nesting level at a time, and see if that level is an instanceof your SQL exception class. You can also check the message if necessary by using getMessage(). If the exception fits your criteria, congratulations you caught it. If not, simply throw it again.
Two things to keep in mind:
this approach may lead to poor performance if many exceptions occur, and only a small fraction of those actually matches your criteria.
if an exception has no cause, then e.getCause() will return e itself. Watch out for infinite recursion here.
I do not have a lot of experience in Java and would appreciate if you bring a light on the question.
I have the following piece of code (method) to establish the JDBC connection with a PostgreSQL database :
public void establishDBConnection() throws SQLException {
try (Connection connection = DriverManager.getConnection(
"jdbc:postgresql://" + dbServer + ":" + dbPort + "/" +
dbDatabase, dbUser, dbPassword))
catch (SQLException e) {
logger.error("Connection to Postgres Database Failed: " +
e.printStackTrace();
}
}
I expect that the SQLException would be caught by the catch block as soon as the method can't establish connection with the database (server is down). The catch block puts the exception on the console but I see that the same exception is displayed earlier right after the getConnection method execution. Thus, I have 2 quite the same exceptions on the console. See below.
The question is what is the reason for this and how to force the application to display only the exception generated by the catch block.
Logs:
Jul 07, 2017 9:11:53 PM org.postgresql.Driver connect
SEVERE: Connection error:
**org.postgresql.util.PSQLException: Connection to localhost:5433 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.**
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:265)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49)
at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:194)
at org.postgresql.Driver.makeConnection(Driver.java:431)
at org.postgresql.Driver.connect(Driver.java:247)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at excel2db.service.impl.DBConnectionPostgresImpl.establishDBConnection(DBConnectionPostgresImpl.java:38)
at excel2db.excel2db.main(excel2db.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at org.postgresql.core.PGStream.<init>(PGStream.java:62)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:144)
... 13 more
21:11:53.465 [main] ERROR e.s.impl.DBConnectionPostgresImpl - **Connection to Postgres Database Failed: Connection to localhost:5433 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.**
There is only one exception being printed in your example: the SQLException being caught. What you think is a second exception is only (as the text shows) the cause of the SQLException: Postgres throws a SQLException, which is itself being thrown because there was a network ConnectException when Portgres tried to connect.
This chain of exceptions is very handy when you need to diagnose a failure. It allows going back to the original, low-level source of a problem. Just like, for example, it can be useful to know that you didn't got your mail (NoMailException) because the post office is on strike (OnStrikeException), because the government decided to lower the wages (WagesTooLowException). If you just had the original NoMailException, you wouldn't be able to know the reason why you got no mail, know that it's probably temporary, etc.
In this particular case, you can deduce that it was impossible to connect to the server, and not for example, that the password was incorrect.
Chaining exceptions is simply achieved by calling one of the exception constructors that take another exception as argument (most exceptions do). See https://docs.oracle.com/javase/8/docs/api/java/lang/Exception.html#Exception-java.lang.String-java.lang.Throwable-.
You need to load the driver's class into memory. Try This code :
try {
Class.forName("org.postgresql.Driver");
Connection connection = DriverManager.getConnection(jdbc:postgresql://server_address:5432/database_name?user=usernam&password=password);
} catch (Exception exception) {
exception.printStackTrace();
}
I'm currently working on a project using the MongoDB Java API. I have been working on this project for a while, but have recently come across an issue that I cannot resolve. I am trying to make a database system that is fault tolerant. To simulate a database crashing, I have my program connect to a Mongodb server that I have made, execute a simple read or write, and then shut down the database server. I had originally thought that this would cause certain methods that I am calling to throw a MongoException that I could catch and then recover from the database crash. However, I am getting a strange stack trace that says I am throwing an EOFException, among other things. Below is the stack trace itself.
Mar 04, 2013 8:06:15 PM com.mongodb.DBPortPool gotError
WARNING: emptying DBPortPool to polaris.cs.wcu.edu/152.30.5.5:12345 b/c of error
java.io.EOFException
at org.bson.io.Bits.readFully(Bits.java:48)
at org.bson.io.Bits.readFully(Bits.java:33)
at org.bson.io.Bits.readFully(Bits.java:28)
at com.mongodb.Response.<init>(Response.java:40)
at com.mongodb.DBPort.go(DBPort.java:124)
at com.mongodb.DBPort.call(DBPort.java:74)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:282)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:256)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:289)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:274)
at com.mongodb.DBCursor._check(DBCursor.java:368)
at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
at com.mongodb.DBCursor.hasNext(DBCursor.java:484)
at edu.wcu.cs.capstone.view.AbstractViewEngine.getView(AbstractViewEngine.java:57)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.getView(ServerTransactionManager.java:52)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.run(ServerTransactionManager.java:183)
at java.lang.Thread.run(Thread.java:722)
Caught exception
Mar 04, 2013 8:06:15 PM com.mongodb.DBPortPool gotError
WARNING: emptying DBPortPool to polaris.cs.wcu.edu/152.30.5.5:12345 b/c of error
java.io.IOException: couldn't connect to [polaris.cs.wcu.edu/152.30.5.5:12345] bc:java.net.ConnectException: Connec
at com.mongodb.DBPort._open(DBPort.java:214)
at com.mongodb.DBPort.go(DBPort.java:107)
at com.mongodb.DBPort.call(DBPort.java:74)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:282)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:256)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:289)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:274)
at com.mongodb.DBCursor._check(DBCursor.java:368)
at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
at com.mongodb.DBCursor.hasNext(DBCursor.java:484)
at edu.wcu.cs.capstone.view.AbstractViewEngine.getView(AbstractViewEngine.java:61)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.getView(ServerTransactionManager.java:52)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.run(ServerTransactionManager.java:183)
at java.lang.Thread.run(Thread.java:722)
DB is down.
Exception in thread "Thread-3" java.lang.NullPointerException
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.run(ServerTransactionManager.java:184)
at java.lang.Thread.run(Thread.java:722)
The Caught Exception and DB is down. are print statements I am using to verify I am catching certain exceptions. Here is the relevant code:
public View getView(Mongo mongo, Query query) throws MongoException,
EOFException {
String connected = "";
try {
connected = mongo.getConnectPoint();
} catch (Exception e) {
throw new MongoException("Error.");
}
System.out.println("Connected: " + connected);
DB db = mongo.getDB(query.getServer());
List<DBObject> viewList = new ArrayList<DBObject>();
DBCollection collection = db.getCollection(query.getCollection());
DBCursor cursor = collection.find(query.getQuery(), excludeID);
try {
cursor.hasNext();
} catch (Exception e) {
System.out.println("Caught exception");
}
while (cursor.hasNext()) {
viewList.add(cursor.next());
}
return new View(viewList);
}
As you can see, the error is occurring when I call cursor.hasNext(). I am also actually still catching the exception that is being thrown because of the Caught exception. However, I am still getting a stack trace as if it was not being caught. I am suspicious that this has something to do with the DBPortPoolgotError() method, but I have looked at the code for this method, and cannot determine what it is actually doing or even how it is being called. (GrepCode link)
As stated above, I thought the behavior for this type of code would have been to throw a MongoException when a call on that specific Mongo object failed because the database was no longer active. Any help that anyone could provide would be greatly appreciated!
this happens due to the driver loosing connection. Here is an issue on the mongo bug tracker referring to it https://jira.mongodb.org/browse/JAVA-481
I had the same issue. It was because I restarted mongod without restart my java server (tomcat in my case). Restarting tomcat solved this issue because the mongo driver was lost
Background: Hibernate connects to a database using a username and password entered into a GUI. Upon failure, instead of propagating the error up as an exception, it comes out as a stack trace in the logger. I don't know where the exception is being caught at. Also a tiny bit troubling is the following block:
if (reason != null) {
println("getConnection failed: " + reason);
throw reason;
}
My breakpoint is set at the throw line (and successfully triggers), but the println statement never generates output (MySQL is using some sort of logger setup I can't find an open file hand for). Any sort of trick for locating where an exception is caught?
EDIT 1:
I call
sessionFactory = /*AnnotationConfiguration*/ ac.buildSessionFactory();
The exception is caught by Hibernate somewhere between the java.sql.DriverManager class and my HibernateUtil class. I presume we can blame Hibernate deciding that I don't really want to see the exception. I want to convince hibernate to let me see the exception.
EDIT 2:
My stack is this:
java.sql.SQLException: Access denied for user 'user'#'machine' (using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3491)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:910)
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:3923)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1273)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2031)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:718)
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:46)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:302)
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:282)
/* Exception is thrown on the next line (1st code block in original post). */
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
/* Begin hidden source calls */
at org.hibernate.connection.DriverManagerConnectionProvider.getConnection(DriverManagerConnectionProvider.java:110)
at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:84)
at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:859)
/* End hidden source calls */
at com.****.****.util.HibernateUtil.initialize(HibernateUtil.java:34)
I can't get the debugger to look at any point above the stack beyond DriverManager.java:582. Everything in the stack beyond that is not visible in the debugger.
First of all, as you mention that there is a logger, you should replace all println statements with log calls.
You can also add further log messages to identify what happens inside the app. Alternatively (or in combination with the above), you can step through the critical code part in the debugger to see where the exception actually happens.
Here's the end result: Line 116 of org.hibernate.cfg.SettingsFactory catches the sql exception and forces it to a log. No configuration is available to change this. It appears I'll be unable to tell my end-user why their connection fails unless I make use of the logs.
Netbeans, for some annoying reason after I gave it the source for Hibernate still wanted to call all of this "hidden source calls." Some time with VIM and reading the line numbers later, I've got it cleared up.
Set a breakpoint for the exception thrown, and when the debugger starts single step to see what happens. You Will probably only need a few steps before the print happens.