|
This configuration doesn't work for me.
The application tries to connect to a default datasource which it didn't do before. The typical error message for something like this in the Torque-log is: --- 2005-09-21 17:40:42,930 [main] WARN org.apache.torque.oid.IDBroker - IDBroker is being used with db 'default', which does not support transactions. IDBroker attempts to use transactions to limit the possibility of duplicate key generation. Without transactions, duplicate key generation is possible if multiple JVMs are used or other means are used to write to the database. --- This usually means connection problems with a database. Another hint that something strange is going on: I've got two ID-Broker threads running where one should suffice. I use a JNDI DataSource with mysql. Which version of Torque are you using? I have the latest 3.2-rc2. I tried to debug the login request (which fails in my case) and got the following:
- The mapping of the default database is ok. TorqueInstance.getDefaultDB() returns "turbine" - In the BaseTurbineUserPeer-class, there is the following method: private static void setDbName(Criteria crit) { // Set the correct dbName if it has not been overridden // crit.getDbName will return the same object if not set to // another value so == check is okay and faster if (crit.getDbName() == Torque.getDefaultDB()) { crit.setDbName(DATABASE_NAME); } } - As the Criteria contains the correct default database name ("turbine") the comparison is true and the databse name of the class ("default") is set in the criteria. This key, however, doesn't exist in the dsFactoryMap of TorqueInstance and we get no connection. Boom. You are using Torque 3.2-rc2 and I use Torque 3.1.1. Turbine also uses 3.1.1 to generate the OM classes. That might be the problem. Can you try with the 3.1.1 runtime?
If this is the problem, then IMHO it is a Torque problem, because it should be backwards compatible between the 3.1.1 release and 3.2. I don't intend to build the OM classes with 3.2-rc<x>, because I do want to stick to released versions for 2.3.2, which might be the last release for a longer time. Another thing that you can try is to build custom peer objects for an application (again, get the secdemo and just substitute the 3.1.1 for 3.2 versions) and check whether the Torque Security Service chokes on the 3.2 built peer objects. Currently I tend to point the finger at Torque. ;-) Right you are:
---8<--- Filename: db/torque/trunk/src/java/org/apache/torque/TorqueInstance.java Revision 229755 - (view) (download) (as text) - [select for diffs] Modified Fri Jul 8 17:53:34 2005 UTC (2 months, 2 weeks ago) by tfischer File length: 29281 byte(s) Diff to previous 229745 (colored) Updated runtime configuration process to do stricter checking, and removed the automatic configuration of the DataSourceFactory with the name "default". See xdocs/changes.xml for details. Solves issue TRQS308. ---8<--- I will open an issue in the Torque bugtracker This is a backward compatibility issue with Torque. Torque 3.1.1 which is the current recommended version to use for Turbine works.
The corresponding Torque issue tracker is
http://issues.apache.org/scarab/issues/id/TRQS322 I would consider it cleaner if either - Turbine would define the data souce called "default" if it is needed or - Turbine would use Torque.getDefaultDB() to find out the name of the default data source |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
TorqueSecurityService relies on a datasource named "default"
--- cut --- torque.properties --- cut ---
torque.dsfactory.secdemo.connection.driver = org.postgresql.Driver
torque.dsfactory.secdemo.connection.url = jdbc:postgresql://localhost/secdemo
torque.dsfactory.secdemo.connection.user = postgres
torque.dsfactory.secdemo.connection.password =
torque.database.default = secdemo
torque.database.secdemo.adapter = postgresql
torque.dsfactory.secdemo.factory = org.apache.torque.dsfactory.SharedPoolDataSourceFactory
--- cut --- torque.properties --- cut ---
--- cut --- TurbineResources.properties --- cut ---
services.SecurityService.classname=org.apache.turbine.services.security.torque.TorqueSecurityService
services.SecurityService.user.manager = org.apache.turbine.services.security.torque.TorqueUserManager
services.SecurityService.user.class = org.apache.turbine.services.security.torque.TorqueUser
services.SecurityService.group.class = org.apache.turbine.services.security.torque.TorqueGroup
services.SecurityService.permission.class = org.apache.turbine.services.security.torque.TorquePermission
services.SecurityService.role.class = org.apache.turbine.services.security.torque.TorqueRole
--- cut --- TurbineResources.properties --- cut ---
You can test this by getting the secdemo application from http://henning.schmiedehausen.org/eyewiki/attach/TurbineSecurityExampleUsingMETA/secdemo-1.0-src.tar.gz
and removing the following lines from conf/turbine-om.properties:
services.SecurityService.torque.userPeer.class = org.apache.turbine.app.secdemo.om.TurbineUserPeer
services.SecurityService.torque.groupPeer.class = org.apache.turbine.app.secdemo.om.TurbineGroupPeer
services.SecurityService.torque.permissionPeer.class = org.apache.turbine.app.secdemo.om.TurbinePermissionPeer
services.SecurityService.torque.rolePeer.class = org.apache.turbine.app.secdemo.om.TurbineRolePeer
Doing so will let the Security Service fall back to the internal, om generated classes. If I remove the line
torque.database.default = secdemo
from the torque.properties, then it no longer works. So it seems to do the mapping correctly.