Stack trace of javax.transaction.RollbackException missing the cause - java

I have a stack trace with a javax.transaction.RollbackException:
[...] Caused by:
ch.ethz.id.wai.lakshmi.engine.common.LakshmiException: Error
processing user transaction. at
ch.ethz.id.wai.lakshmi.engine.common.TransactionHelper.commitTransaction(TransactionHelper.java:79)
at
ch.ethz.id.wai.lakshmi.stdcmp.persistency.StandardPersistency.registerOrder(StandardPersistency.java:110)
Caused by: javax.transaction.RollbackException: Transaction marked for
rollback. at
com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:473)
at
com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:855)
at
com.sun.enterprise.transaction.UserTransactionImpl.commit(UserTransactionImpl.java:208)
at
ch.ethz.id.wai.lakshmi.engine.common.TransactionHelper.commitTransaction(TransactionHelper.java:74)
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387)
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310)
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1316)
at
org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1510)
at
org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109)
at
org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53)
at
com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:435)
at
org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:54)
at
org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125)
at
org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110)
at
org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:129)
at
org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81)
at com.sun.proxy.$Proxy233.executeUpdate(Unknown Source) at
org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:56)
at
org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3028)
at
org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3469)
at
org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:88)
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
at
org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
at
org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:275)
at
org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326)
at
org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1213) at
org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:402)
at
org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:104)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:439) at
oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:395) at
oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:802) at
oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:436) at
oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186) at
oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:521) at
oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:205)
at
oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1008)
at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1307)
at
oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3449)
at
oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3530)
at
oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.java:1350)
at
com.sun.gjc.spi.base.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:125)
at
org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122)
The RollbackException has a cause that I can see while debugging:
javax.persistence.PersistenceException:
org.hibernate.exception.GenericJDBCException: ORA-22295: cannot bind
more than 4000 bytes data to LOB and LONG columns in 1 statement
which is in turn caused by
org.hibernate.exception.GenericJDBCException: ORA-22295: cannot bind
more than 4000 bytes data to LOB and LONG columns in 1 statement
But the cause of the RollbackExeption is not shown in the stack trace (which would ease the debugging of the errors).
Any idea of the reason?
Edit
I added a try-catch in the test method (JUnit):
#Test
public void foo() throws Throwable {
try {
// test code generating the exception
} catch ( Exception e ) {
// here the exception cause is still there
}
Since this method is called directly by JUnit the exception is still OK when it leaves my code.

If you like to have the cause shown in the exception, I guess your only chance is to open a bug/improvement request at Glassfish. I looked at the source code of JavaEETransactionImpl, which is where the RollbackException is thrown and at line 473 the code is:
rbe = new RollbackException(sm.getString("enterprise_distributedtx.mark_rollback"));
As you can see, I am checking version 3.1.1, so in case you have a different version please take a look to the right source code (which I doubt will differ anyway).

The problem was Ant erroneously filtering part of the exception trace
From the Junit task documentation:
filtertrace Filter out Junit and Ant stack frames from error and failure stack traces.
It defaults to on but it does not only filter Junit and Ant frames: setting it to off the cause of the rollback is shown.

Related

GenericJDBCException: Could not open connection .. caused by javax.resource.ResourceException: IJ000459: Transaction is not active

My Hibernate application starts running fine, but at some point something happens (I suspect some unexpected/unhandled constraint violation) that somehow breaks everything. From that point on I keep getting this huge stacktrace that I have trouble reading.... If I restart the app, or logout and login, the problem disappears for a while...
I found a related question, but was asked in the comments to create a new one for my issue as the exception is a very generic one.
Below a snipped version of the stacktrace. Full stacktrace on pastebin.
2015-11-05 17:27:39,349 ERROR [io.undertow.request] (default task-11) UT005023: Exception handling request to /api/ratings/synch: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: org.hibernate.exception.GenericJDBCException: Could not open connection
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) [resteasy-jaxrs-3.0.10.Final.jar:]
...
Caused by: javax.ejb.EJBTransactionRolledbackException: org.hibernate.exception.GenericJDBCException: Could not open connection
at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
...
at net.bridalapp.db.CrudService$$$view1.find(Unknown Source) [classes:]
...
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Could not open connection
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final]
...
at net.bridalapp.db.CrudServiceBean.find(CrudServiceBean.java:213) [classes:]
at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) [:1.8.0_65]
...
Caused by: org.hibernate.exception.GenericJDBCException: Could not open connection
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:54) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
...
Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000460: Error checking for a transaction
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:154)
...
Caused by: javax.resource.ResourceException: IJ000460: Error checking for a transaction
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:415)
...
Caused by: javax.resource.ResourceException: IJ000459: Transaction is not active: tx=TransactionImple < ac, BasicAction: 0:ffffac1001d4:-67c5b6ff:563b6a43:146d8 status: ActionStatus.ABORT_ONLY >
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:399)
... 348 more
http://pastebin.com/DV7zteED
I had the same error in wildfly/hibernate. For me the problem was that I was running a long transaction and I had a massive amount of hibernate transactions, that filled up my memory. In my case the answer was, that after a specified number of transactions I did this:
em.flush();
em.clear();
HTH

Not able to catch org.hibernate.StaleObjectStateException

Can we not catch the StaleObjectStateException? I have catch block with StaleObjectStateException , so when method is throwing this error it is coming to this catch block but still throwing the same exception again.
I know the reason why this exception is coming but i want to catch the exceptiion and proceed further.
[13/05/15 10:00:07:751 BST] 00000053 TaskUtils$Log E org.springframework.scheduling.support.TaskUtils$LoggingErrorHandler handleError Unexpected error occurred in scheduled task.
org.springframework.orm.hibernate3.HibernateOptimisticLockingFailureException: Object of class [com.lgs.mem.model.MemService] with identifier [3038]: optimistic locking failed; nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.lgs.mem.model.MemService#3038]
at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:676)
at org.springframework.orm.hibernate3.SpringSessionSynchronization.translateException(SpringSessionSynchronization.java:160)
at org.springframework.orm.hibernate3.SpringSessionSynchronization.beforeCommit(SpringSessionSynchronization.java:148)
at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerBeforeCommit(TransactionSynchronizationUtils.java:95)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerBeforeCommit(AbstractPlatformTransactionManager.java:927)
at org.springframework.transaction.jta.WebSphereUowTransactionManager.access$4(WebSphereUowTransactionManager.java:1)
at org.springframework.transaction.jta.WebSphereUowTransactionManager$UOWActionAdapter.run(WebSphereUowTransactionManager.java:338)
at com.ibm.ws.uow.EmbeddableUOWManagerImpl.runUnderNewUOW(EmbeddableUOWManagerImpl.java:786)
at com.ibm.ws.uow.EmbeddableUOWManagerImpl.runUnderUOW(EmbeddableUOWManagerImpl.java:365)
at org.springframework.transaction.jta.WebSphereUowTransactionManager.execute(WebSphereUowTransactionManager.java:281)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:127)
at at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy156.updateRetryCountAndTSP(Unknown Source)
at com.lgs.mem.service.impl.MemDAOServiceImpl.updateRetryCountAndTSP(MemDAOServiceImpl.java:181)
at com.lgs.mem.scheduler.MEMRecoveryScheduler.processFailedNicheRequests(MEMRecoveryScheduler.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:64)
at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:53)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:452)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:328)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:161)
at org.springframework.scheduling.commonj.TimerManagerTaskScheduler$TimerScheduledFuture.timerExpired(TimerManagerTaskScheduler.java:112)
at org.springframework.scheduling.commonj.TimerManagerTaskScheduler$ReschedulingTimerListener.timerExpired(TimerManagerTaskScheduler.java:165)
at com.ibm.ws.asynchbeans.timer.TimerImpl.callListenerMethod(TimerImpl.java:361)
at com.ibm.ws.asynchbeans.timer.GenericTimer.run(GenericTimer.java:228)
at com.ibm.ws.asynchbeans.J2EEContext$RunProxy.run(J2EEContext.java:265)
at java.security.AccessController.doPrivileged(AccessController.java:252)
at javax.security.auth.Subject.doAs(Subject.java:495)
at com.ibm.websphere.security.auth.WSSubject.doAs(WSSubject.java:132)
at com.ibm.websphere.security.auth.WSSubject.doAs(WSSubject.java:90)
at com.ibm.ws.asynchbeans.J2EEContext$DoAsProxy.run(J2EEContext.java:336)
at java.security.AccessController.doPrivileged(AccessController.java:280)
at com.ibm.ws.asynchbeans.J2EEContext.run(J2EEContext.java:1174)
at com.ibm.ws.asynchbeans.timer.TimerImpl.runListenerAsCJWork(TimerImpl.java:490)
at com.ibm.ws.asynchbeans.am._Alarm.fireAlarm(_Alarm.java:333)
at com.ibm.ws.asynchbeans.am._Alarm.run(_Alarm.java:230)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1659)
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.lgs.mem.model.MemService#6768]
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1950)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2595)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2495)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2822)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:113)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:185)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
at org.springframework.orm.hibernate3.SpringSessionSynchronization.beforeCommit(SpringSessionSynchronization.java:145)
... 38 more
Yes you can catch the exception.
Problems like this can occur if the exception does not propagate to the place that you are trying to catch it. For example:
It may be thrown on a different thread.
It may be further up the stack, and then re-thrown as a different exception.
Judging from the stacktrace, I'd say that it is the second explanation. The original exception has been caught and a HibernateOptimisticLockingFailureException has been created that wraps it. It is the latter exception you are seeing.
If you want to specifically handle the original exception, you probably need to catch HibernateOptimisticLockingFailureException (or a superclass), and then call the exception object's getMostSpecificCause() to extract the original exception for diagnosis.
Use This:
#Transactional(propagation = Propagation.REQUIRES_NEW,readOnly=true)

Play framework 1.2.4: NullPointerException in the constructor of play.exceptions.MailException

The problem is the following:
When sending a mail in webapp running on Play framework 1.2.4 exception with following stack trace can be observed in logs:
Execution exception
NullPointerException occured : null
play.exceptions.JavaExecutionException
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:231)
at Invocation.HTTP Request(Play!)
Caused by: java.lang.NullPointerException
at play.exceptions.MailException.<init>(MailException.java:27)
at play.libs.Mail.buildMessage(Mail.java:79)
at play.libs.Mail.send(Mail.java:35)
at play.mvc.Mailer.send(Mailer.java:347)
at play.mvc.Mailer.sendAndWait(Mailer.java:355)
at notifiers.Mails.forgotPassword(Mails.java:19)
at controllers.PasswordReset.requestPasswordReset(PasswordReset.java:102)
at play.mvc.ActionInvoker.invokeWithContinuation(ActionInvoker.java:548)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:502)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:478)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:473)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:161)
... 1 more
The relevant part here is following:
Caused by: java.lang.NullPointerException
at play.exceptions.MailException.<init>(MailException.java:27)
which indicates that NullPointerException was thrown from constructor of play.exceptions.MailException (in 27th line). Source code of this constructor looks like the following:
public MailException(String message, Throwable cause) {
super(message, cause);
StackTraceElement element = getInterestingStrackTraceElement(cause);
if(element != null) {
ApplicationClass applicationClass = Play.classes.getApplicationClass(element.getClassName());
sourceFile = applicationClass.javaFile.relativePath(); // this line is 27th and NPE is thrown from here
source = Arrays.asList(applicationClass.javaSource.split("\n"));
line = element.getLineNumber();
}
}
So either applicationClass local variable or javaFile property is null. Could someone familiar with Play framework weird internals advise what can cause this problem?
Thanks a lot in advance
EDIT after Seb Cesbron answer
We also inspected play.libs.Mail.buildMessage(Mail.java:79) where it is clearly seen that from address is null, but after fixing that, similar exception popped up:
play.exceptions.JavaExecutionException
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:231)
at Invocation.HTTP Request(Play!)
Caused by: java.lang.NullPointerException
at play.exceptions.MailException.<init>(MailException.java:27)
at play.mvc.Mailer.send(Mailer.java:349)
at play.mvc.Mailer.sendAndWait(Mailer.java:355)
at notifiers.Mails.forgotPassword(Mails.java:19)
at controllers.PasswordReset.requestPasswordReset(PasswordReset.java:102)
at play.mvc.ActionInvoker.invokeWithContinuation(ActionInvoker.java:548)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:502)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:478)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:473)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:161)
And there, play.mvc.Mailer.send method contains nearly 200 lines of code enclosed in try-catch block, so it got really tricky to find out what was the problem :)
Line 79 in Mail.java refers to a throw MailException because there is no from address.
The NullPointerException in MailException seems to show that there is no file associated to your mail. Are you sure that the file Mails/forgotPassword.html (or txt) exists ?

Why doesn't Spring throw DataAccessException in the event that Hibernate throws ObjectNotFoundException?

Why doesn't Spring 3.0.4 HibernateTemplate method load() throw DataAccessException or more specifically, ObjectRetrievalFailureException, in the event that Hibernate 3.3.2GA throws ObjectNotFoundException?
2010-12-15 13:16:03,939 133247782 [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO org.hibernate.event.def.DefaultLoadEventListener - Error performing load command
org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.db.spgit.abstrack.model.ConsUsCustomMark#78445AAD8]
at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:375) ~[hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:145) ~[hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:179) ~[hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103) ~[hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878) [hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.impl.SessionImpl.load(SessionImpl.java:795) [hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.impl.SessionImpl.load(SessionImpl.java:788) [hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.springframework.orm.hibernate3.HibernateTemplate$3.doInHibernate(HibernateTemplate.java:558) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:406) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
at org.springframework.orm.hibernate3.HibernateTemplate.load(HibernateTemplate.java:551) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
at org.springframework.orm.hibernate3.HibernateTemplate.load(HibernateTemplate.java:545) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
The exception is being logged, not necessarily thrown. What you see there is a log to info level of the exception stack trace, done by hibernate. If you look at the source code of DefaultLoadEventListener(line 134 in my version of the source) you will notice that it logs the exception and then rethrows.
All we're seeing here is a log of the exception stack trace - there is no evidence here that spring is not transforming the exception.
The org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException() method does check to see if the exception is net.sf.hibernate.ObjectNotFoundException. This means that it should be throwing an UncategorizedDataAccessException.
I do not know if this is a design decision or an oversite (i.e. a bug in spring).

Exception Caught Too Early

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.

Categories

Resources