I have been trying for two days to understand how JNDI configuration works for the tomcat example provided in the reference documentation. And I have to admit that I have only got more and more confused by the hour. I am starting to think that it may be something else that stops me. Maybe webwork? I have read the Tomcat JNDI Howto's, I've searched and read all related posts on this forum, I have read all configuration related to Configuration in the Hibernate docs and I'm clueless. And I have been trying everything I can think of and I have seen suggested elsewhere.

I have the basic example up and running in a webwork actions doExecute() method. Which should not really make a difference. Or?

I have the Hibernate.cfg.xml in the classpath
I have the Cat.hbm.xml in the classpath.
I have all relevant jars in the WEB-INF/lib dir. All required and most of the optional ones, just to be sure.
I have my JDBC driver jar in the server/common/lib dir.
I have generated the CAT db-table with SchemaExport to be sure that it is not a DB-schema related error.

I've added the DBCP datasource part to the server.xml as described in the Quickstart. And it is recognized by Tomcat as I can find the JNDI name from the admin interface for my context with the correct properties set.

I use the HibernateUtils class suggested to open a session.

And I get the following when just using the currentsession() method (I have my own names for the JNDI Datasource and the FormTest.java class is my webwork class):

INFO [http80-Processor3] (FormTest.java:70) - Executing action!
INFO [http80-Processor3] (Environment.java:432) - Hibernate 2.1.1
INFO [http80-Processor3] (Environment.java:461) - hibernate.properties not foun
d
INFO [http80-Processor3] (Environment.java:481) - using CGLIB reflection optimi
zer
INFO [http80-Processor3] (Configuration.java:843) - configuring from resource:
/hibernate.cfg.xml
INFO [http80-Processor3] (Configuration.java:815) - Configuration resource: /hi
bernate.cfg.xml
INFO [http80-Processor3] (Configuration.java:300) - Mapping resource: Cat.hbm.x
ml
INFO [http80-Processor3] (Binder.java:225) - Mapping class: com.mycompany.Cat
-> CAT
INFO [http80-Processor3] (Configuration.java:998) - Configured SessionFactory:
null
INFO [http80-Processor3] (Configuration.java:584) - processing one-to-many asso
ciation mappings
INFO [http80-Processor3] (Configuration.java:593) - processing one-to-one assoc
iation property references
INFO [http80-Processor3] (Configuration.java:618) - processing foreign key cons
traints
INFO [http80-Processor3] (Dialect.java:82) - Using dialect: net.sf.hibernate.di
alect.HSQLDialect
INFO [http80-Processor3] (SettingsFactory.java:62) - Use outer join fetching: f
alse
INFO [http80-Processor3] (NamingHelper.java:26) - JNDI InitialContext propertie
s:{}
INFO [http80-Processor3] (DatasourceConnectionProvider.java:51) - Using datasou
rce: java:comp/env/jdbc/mycompany
INFO [http80-Processor3] (TransactionManagerLookupFactory.java:33) - No Transac
tionManagerLookup configured (in JTA environment, use of process level read-writ
e cache is not recommended)
INFO [http80-Processor3] (SettingsFactory.java:89) - Use scrollable result sets
: true
INFO [http80-Processor3] (SettingsFactory.java:96) - echoing all SQL to stdout
INFO [http80-Processor3] (SettingsFactory.java:99) - Query language substitutio
ns: {}
INFO [http80-Processor3] (SettingsFactory.java:110) - cache provider: net.sf.eh
cache.hibernate.Provider
INFO [http80-Processor3] (Configuration.java:1057) - instantiating and configur
ing caches
INFO [http80-Processor3] (SessionFactoryImpl.java:119) - building session facto
ry
INFO [http80-Processor3] (SessionFactoryObjectFactory.java:82) - no JNDI name c
onfigured
INFO [http80-Processor3] (FormTest.java:117) - Set the cat!

So I get no errors when just opening the session. What makes me curious though is the INFO log (note: not ERROR) that says "No JNDI name configured". After reading and testing and reading and testing for a couple of hours i don't get WHAT JNDI name is not configured and to who is it not configured. To Tomcat? To my context?

When I try to persist the cat to the seemingly configured session I get a exception stack that originates from the following JDBCException:

Caused by: java.sql.SQLException: Table not found: CAT in statement [insert into CAT (NAME, sex, weight, CAT_ID) values ('Princess', 'F', 7.400000095367432E0, '8ae98056f9d8f08500f9d8f08ade0001')] at org.hsqldb.Trace.getError(Unknown Source) at org.hsqldb.jdbcResultSet.<init>(Unknown Source) at org.hsqldb.jdbcConnection.executeStandalone(Unknown Source) at org.hsqldb.jdbcConnection.execute(Unknown Source) at org.hsqldb.jdbcStatement.fetchResult(Unknown Source) at org.hsqldb.jdbcStatement.executeUpdate(Unknown Source) at org.hsqldb.jdbcPreparedStatement.executeUpdate(Unknown Source) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:233) at net.sf.hibernate.impl.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:22) at net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:469) ... 40 more

I have no problem connecting to my DB from my ANT script (it's a HypersonicSQL DB) and the CAT table is definately there.

My question is this. If the application does not recognize the datasource JNDI, would it get this far? And would't I get an error or a stack when opening the session with the HibernateUtils class?

The strange thing is that before I started to mess around with adding stuff to my web.xml (a Resource-ref for my JNDI datasource). This did NOT dump a stacktrace at all. I could persist my Cat() without a stacktrace but it did not persist to the actual database. It just silently did nothing.

Now when I went back to the original configuration. I get the above dump.

The only difference I can think of at this point (from the provided Quickstart example) is that I execute my code from a webwork 1.x action. Otherwise it *should* be the same.

Forgot:

I'm running Tomcat 4.1.29, webwork 1.4, Hibernate 2.1, SDK 1.4_02 and HSQLDB 1.7

I'm relly confused. Help?

Post your Hibernate.cfg.xml

This is my hibernate.cfg.xml file:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration
PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd">

<hibernate-configuration>

<session-factory>

<property name="connection.datasource">java:comp/env/jdbc/mis</property>
<property name="dialect">net.sf.hibernate.dialect.HSQLDialect</property>
<property name="show_sql">true</property>

<!-- Mapping files -->
<mapping resource="com/mycompany/mis/Cat.hbm.xml"/>

</session-factory>

</hibernate-configuration>


And this is what I added to the tomcat server.xml.


<Context path="/mis" docBase="mis">
<Resource name="jdbc/mis" scope="Shareable" type="javax.sql.DataSource"/>
<ResourceParams name="jdbc/mis">
<parameter>
<name>factory</name>
<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
</parameter>

<parameter>
<name>url</name>
<value>jdbc:hsqldb:db/mis</value>
</parameter>
<parameter>
<name>driverClassName</name><value>org.hsqldb.jdbcDriver</value>
</parameter>
<parameter>
<name>username</name>
<value>sa</value>
</parameter>
<parameter>
<name>password</name>
<value></value>
</parameter>

<parameter>
<name>maxWait</name>
<value>3000</value>
</parameter>
<parameter>
<name>maxIdle</name>
<value>100</value>
</parameter>
<parameter>
<name>maxActive</name>
<value>10</value>
</parameter>
</ResourceParams>
</Context>




This seems to be working since I can view it with all the correct properties from the Tomcat Admin console.

Is there anything specific I have to be thinking about when using the HSQLDB? When I access the DB from my ant script (with the sql task) I can connect and view my table. The actual DB files are in my build directory.

Do I need to expose this JNDI Datasource in any way to my context by fiddling with my web.xml or should I be able to access it directly?

Probably your ant script etc. refers to a different db than the hibernate classloader? db/mis can refer to a different path depending on classloaders. Have you tried using an absolute path? (like c:\db)

OK. Now I feel that I really *deserve* to get this working. I've been at it for four days on an off now. If I can't get this running I think I'm just going with plain JSP/JSTL and JDBC for my app. This is taking waaaaay to much time.

I've tried the following to see if I even get a connection that works from the JNDI listing:

Connection conn = null;
DataSource ds = null;

try {
Context initCtx = new InitialContext();
Context envCtx = (Context)initCtx.lookup("java:comp/env");
ds = (DataSource)envCtx.lookup("jdbc/mis");
} catch (NamingException e) {
throw new RuntimeException("Naming Exception: " + e.getMessage(), e);
}

conn = ds.getConnection();

Statement st = null;
ResultSet rs = null;

st = conn.createStatement();
logger.info("Creating Statement!");

rs = st.executeQuery("select * from CAT");

logger.info("Executing Query!");


Everything is fine until the executeQuery statment.

And no matter what I do (and believe me I've tried a few things!) I keep getting a JDBC exception:

ERROR [http80-Processor3] (ServletDispatcher.java:185) - Could not execute actio
n
java.sql.SQLException: Table not found: CAT in statement [select * from CAT]
at org.hsqldb.Trace.getError(Unknown Source)
at org.hsqldb.jdbcResultSet.<init>(Unknown Source)
at org.hsqldb.jdbcConnection.executeStandalone(Unknown Source)
at org.hsqldb.jdbcConnection.execute(Unknown Source)
at org.hsqldb.jdbcStatement.fetchResult(Unknown Source)
at org.hsqldb.jdbcStatement.executeQuery(Unknown Source)
at org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingSt
atement.java:188)
at com.lehman.mis.actions.FormTest.doExecute(FormTest.java:100)
at webwork.action.ActionSupport.execute(ActionSupport.java:151)
at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.
java:131)
at webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:1
74)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2417)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:19
3)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:781)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ssConnection(Http11Protocol.java:549)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java
:589)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:666)
at java.lang.Thread.run(Thread.java:536)


Have I *totally* misunderstood how HSQLDB works? I build my CAT table with an ANT task and the DB data files are in the build directory (not in the war structure that gets moved to tomcat). Is this wrong? Do I need to move it somewhere else before running?

Or is the only way to get this working to go with a mem only DB and rebuild every time?

If I can't get this to work (the chances seems slim after four days of unsuccessful labour). Can I somehow configure a DB accesible from Tomcat *without* messing with JNDI?

It certainly seems like it. Where and how do I configure the absolute path to the DB? From the DBCP configuration in server.xml?

I seem to be mostly interacting with myself here but what the heck :)

I've confirmed that the DB my ANT script connects to is probably not the same DB that Tomcat ties to a JNDI name. But there is some strange behaviour involved here.

I changed the DB url to an absolute path in my build properties:

db.url=jdbc:hsqldb:e:\dev\mis\db

And exactly the same url to my JNDI <Context/> entery in server.xml

<parameter>
<name>url</name>
<value>jdbc:hsqldb:e:\dev\mis\db</value>
</parameter>

The strange thing is that my ant script writes db files with the name "devmisdb.*" in e:\dev\mis\ while Tomcat writes db files named "db.*" in the same dir. Is this a classloader issue? Because the ANT created db probably uses a local hsqldb.jar while the Tomcat JNDI binding probably uses the /common/lib/hsqldb.jar.

What I don't understand is why my app (from inside Tomcat) has not complained about not even having a DB to connect to. Or do hsqlb always just quitely create the DB when it is defined in server.xml?

This is like my personal development dirary it seems :)

I solved it. After 4 days of grinding.

My Tomcat did not for some reason (unknown exactly why) use the same DB as my ANT script. The URL's where the same and the hsqldb.jar was the same in both cases but Tomcat wanted to open some other database. I changed the URL to an absolute one and it worked.

One thing to note though. The URL in my build.propertes file (standard properties file) had to have forward slashes in the file path. server.xml could parse backward slashes.

I'm exhausted. I just hope that it mostly runs smooth from here.

I mean, this is not rocket science.

Or am I just stupid?