I remember that upgrading to commons-configuration-1.1 has caused some
problems in the past. It was something like returning empty lists instead
of null asking for a subset-configuration, but I cannot remember exactly.
Just a shot in the air: Maybe you want to take over the initialisation
code (i.e.TorqueImpl.java) from 3.2-rc3 and repackage the Torque runtime
jar (no idea whether it is binary compatible at all).
If you have the possibility to debug the initialisation methods in
TorqueImpl, you should do so. The code is not difficult tu understand.
If you cannot debug easily, you might want to get the source, plaster it
with log messages, and recompile it.
Maybe this is also the time to switch to a newer Torque version ? I have
3.2-rc1 in production (with some customisation) using oracle (with the
lob-enhanced village) and it runs with configuration-1.1 without any
problems.
Hope that helps,
Thomas
On Thu, 17 Nov 2005, Vitzethum, Daniel wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
