db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <tfisc...@apache.org>
Subject Re: Initialization of JndiDataSourceFactory fails
Date Thu, 17 Nov 2005 21:53:16 GMT
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: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org


Mime
View raw message