ammulder 2005/12/10 23:31:23
Modified: modules/core/src/java/org/openejb/entity/cmp Tag: v2_0
CMPFinder.java
Log:
Port message fix from HEAD
Revision Changes Path
No revision
No revision
1.15.4.1 +15 -2
openejb/modules/core/src/java/org/openejb/entity/cmp/CMPFinder.java
Index: CMPFinder.java
===================================================================
RCS file:
/home/projects/openejb/scm/openejb/modules/core/src/java/org/openejb/entity/cmp/CMPFinder.java,v
retrieving revision 1.15
retrieving revision 1.15.4.1
diff -u -r1.15 -r1.15.4.1
--- CMPFinder.java 13 Sep 2005 02:31:44 -0000 1.15
+++ CMPFinder.java 11 Dec 2005 04:31:23 -0000 1.15.4.1
@@ -95,6 +95,19 @@
return groupHandler.execute(cache, command, arguments, ctx);
}
handler = new CacheFiller(handler, idDefiner, idInjector, cache);
- return command.execute(handler, arguments, ctx);
+ try {
+ return command.execute(handler, arguments, ctx);
+ } catch (IllegalStateException e) {
+ throw new QueryException("Unable to execute finder; perhaps the
cmp-connection-factory was not configured correctly? Error message is:
"+e.getMessage());
+ // The handling for this is kind of awkward -- the user
configured a bad cmp-connection-factory
+ // and we didn't validate it during deployment for various
reasons. So the only way we discover
+ // it is that at runtime TranQL detects that it doesn't have a
database connection. Since it's
+ // a little late to throw a deployment exception, and TranQL
doesn't know specifically about
+ // OpenEJB, it just throws a sort of generic
IllegalStateException. We catch that here and try
+ // to be a little more specific, but it's still not 100% sure
that we got into this situation
+ // exactly because of that initial cause. See GERONIMO-1176 for
a bit more related information.
+ // See TranQL org.tranql.sql.DataSourceDelegate.getConnection
for the exception this is catching.
+ // todo: see if we can detect this when we set the database
connection on TranQL in the first place
+ }
}
}
