Hello Greg, thx for your quick answer!
> First, what version of Torque are you using? Believe me, I really had in mind _not_ to forget it! Ouch! I'm using Torque 3.1. > Second, what torque.dsfactory.<db>.datasource properties are > set in your Torque.properties file? None? This is all I needed in two or three other Projects, some on Tomcat, some on Bea: ----8<---- torque.applicationRoot = <db> torque.database.default = <db> torque.database.<db>.adapter = oracle ## Using jndi - datasource from container torque.dsfactory.<db>.factory=org.apache.torque.dsfactory.JndiDataSource Factory # 4 Tomcat (unused here) #torque.dsfactory.<db>.jndi.path=java:comp/env/jdbc/ZeusDS # 4 Bea torque.dsfactory.<db>.jndi.path=jdbc/ZeusDS ----8<---- By now I thought the DS comes from the container... > You need to specify a torque.dsfactory.<dbname>.datasource.classname > property in the Torque.properties file. See above. Do I really have to? I didn't had to by now. > Or that your bind string doesn't match what BEA uses internally AFAIK, > there is no true "standard" for how a servlet engine structures JNDI tree > internally. The one used by Tomcat is becoming the "defacto" standard, > but BEA might do things differently. That's what it does, but we handled both Bea and Tomcat earlier. We got a bit further now: we were using Torque not with ist original dependencies, but migrated from commons-configuration-1.0-dev-3.20030607.194155.jar to commons-configuration-1.1.jar and from commons-lang-1.0.1.jar to commons-lang-2.0.jar. Can anybody imagine that this is the cause of the "bind" exception? When returning to the original libs, it seems to work. (We can't do that in our project, however.) Any hints appreciated... ;-) Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
