> Obviously CAS didn't have access to the MySQL JDBC Driver. I fixed this by > adding the following to my pom.
Don't do this. Add the driver to the container classpath, e.g. put it in $TOMCAT_HOME/lib for Tomcat. I see this is not documented, so https://wiki.jasig.org/display/CASUM/JpaTicketRegistry should be updated accordingly. > 1) The opening warning about the Hibernate SchemaExport DDL creation tool > failing to create > two indexes seems to no longer be the case, at least for MySQL. Can we remove > this warning or > is it still needed for other databases? I'd like to confirm that this is the case on at least one other platform and if true then I'll update the docs. > Also I think if it stays it should be moved to the "Setting up the Database" > section. > It seems really strange that you are hit with this warning at the start of > the documentation > before you potentially have CAS configured and built. I added it to the beginning because it's a non-obvious step that was affecting several folks that already had JPA setups. I'll consider moving it as you suggested. > 2) The version note about CAS 3.4 and the Spring 3.0 schema was slightly > confusing to me. Maybe we should just provide configuration samples for both versions. > 3) The current ticketRegistry.xml example seems very much geared towards > connecting to MySQL. Agreed. I'll generalize it based on our file, which has every platform-specific value abstracted to a properties file. > 4) As the "ticket.cleaner.database.platform" property needs to be created in > cas.properties > I think it would be appropriate to provide a full example of this file. That file ships with CAS, so it's readily available. > It is also my assumption that a separate WAR needs to be built for each CAS > node using the same JpaTicketRegistry > with the host.name property set so it is unique on each node. Correct. The documentation on the locking strategy could be more thorough, so I'll fill it out. > 5) SQL92 could be a bit ambiguous for newer users. You really should know whether your database is SQL-92 compliant. That said, it would be reasonable to state all available values to provide some context about the best value for a particular platform. I would think the mere existence of SQL_SERVER would suggest that's the appropriate value for that platform, for example. Honestly the javadocs of JdbcLockingStrategy provide the fullest and best explanation, so I may provide a link to that file, or javadocs in the future if we ever start hosting those again. (I'm hopeful it will not only happen, but soon.) > 6) I think the notes regarding "Schema Generation" and the "LOCKS Table" > belong under the "Setting up the Database" section. Good suggestion. > 7) The text in the "Setting up the Database" section regarding changing BLOG > to LONGBLOB > doesn't seem to be correct any more. It seems that only longblobs are used in > the CAS MySQL tables. This may be a version-specific issue. What MySQL version are you using? It certainly was an issue in the past. I can add a version-specific note, but I don't have cycles to do any investigation beyond that. > 9) When I first read the "Database Connection Pooling" section I had thought > that I didn't have database > connection pooling configured at all. I just noticed that example is using org.apache.commons.dbcp.BasicDataSource, which I had missed. Perhaps we should simply provide a more complete example that demonstrates all of the pooling configuration handles of DBCP, then an equivalent with C3P0. The problem is that I honestly don't have practical experience with DBCP, but since the values are specified by placeholders, I suppose that's no obstacle. If you would be willing to provide values for pool configuration in DBCP, I would be happy to use it. Much of the preference for one or the other is simply that, preference. We used C3P0 because it was recommended by the Shib folks in light of poor locking semantics of DBCP at the time. I believe DBCP has corrected this in recent versions. If anyone can confirm DBCP locking improvements, I would appreciate it. > I can certainly work on making some of these changes to the documentation > myself I would appreciate your taking a crack at it and pinging this thread when done so I can follow behind and edit as needed. I sincerely appreciate your willingness to not only describe areas for improvement but work on them. Best, M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
