Hello,
Using the Maven2 WAR overlay method has fixed the
java.lang.IncompatibleClassChangeError I was getting. A big thanks to Marvin
Addison and Scott Battaglia for getting me to this point.
The only other problem I ran into was the following:
Cannot load JDBC driver class 'com.mysql.jdbc.Driver'
Obviously CAS didn't have access to the MySQL JDBC Driver. I fixed this by
adding the following to my pom.
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysql.connector.java.version}</version>
<scope>runtime</scope>
</dependency>
<properties>
<mysql.connector.java.version>5.1.17</mysql.connector.java.version>
</properties>
Could someone confirm that this is correct and recommend way to include the
MySQL JDBC Driver in CAS. I'm also wondering if this wouldn't be worth
mentioning in JpaTicketRegistry documentation.
At this point I would like to run through the JpaTicketRegistry documentation
and discuss possible updates, and improvements that still may be needed.
https://wiki.jasig.org/display/CASUM/JpaTicketRegistry
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? If
it stays should a note be added that is not a problem for MySQL? 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.
mysql> show index from SERVICETICKET where
column_name='ticketGrantingTicket_ID';
+---------------+------------+--------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name
| Collation | Cardinality | Sub_part | Packed | Null | Index_type |
Comment |
+---------------+------------+--------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+
| SERVICETICKET | 1 | FK7645ADE132A2C0E5 | 1 |
ticketGrantingTicket_ID | A | NULL | NULL | NULL | YES |
BTREE | |
+---------------+------------+--------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+
1 row in set (0.03 sec)
mysql> show index from TICKETGRANTINGTICKET where
column_name='ticketGrantingTicket_ID';
+----------------------+------------+--------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index |
Column_name | Collation | Cardinality | Sub_part | Packed | Null |
Index_type | Comment |
+----------------------+------------+--------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+
| TICKETGRANTINGTICKET | 1 | FKB4C4CDDE32A2C0E5 | 1 |
ticketGrantingTicket_ID | A | NULL | NULL | NULL | YES |
BTREE | |
+----------------------+------------+--------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+
1 row in set (0.00 sec)
2) The version note about CAS 3.4 and the Spring 3.0 schema was slightly
confusing to me. As I am not familiar with either version 2 or 3 of the Spring
schema I wasn't sure if the ticketRegistry.xml example given would work with
CAS 3.4 or not. As no example is given of the ticketRegistry.xml for older
versions of CAS I think it might be more appropriate if the note read.
"The ticketRegistry,xml example will only work for CAS 3.4 as it uses the
Spring 3.0 locations. Previous versions of CAS use the Spring 2.0 schema
namespace. This example must be adapted to use the Spring 2.0 namespace
locations for previous versions of CAS."
3) The current ticketRegistry.xml example seems very much geared towards
connecting to MySQL. The database server I'm using is MySQL so this worked out
rather well for me, however I can see users trying to implement the
JpaTicketRegistry on another SQL servers having issues. Could the
ticketRegistry.xml example be made more vanilla with a text explanation of what
needs changing for common database platforms? I would be willing to help
provide testing for configurations against MSSQL, and PostgreSQL.
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. 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. Can someone confirm this assumption is correct?
If this is correct it might be worth noting in the documentation.
5) SQL92 could be a bit ambiguous for newer users. I think it might be
appropriate to add some sort of text basically stating "this is what you want
for MySQL etc..." At the same time maybe this is overkill. Any thoughts?
6) I think the notes regarding "Schema Generation" and the "LOCKS Table" belong
under the "Setting up the Database" section.
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. Should we just get rid of this, or make a note
that older versions had this problem?
mysql> show columns from SERVICETICKET;
+-------------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------------+--------------+------+-----+---------+-------+
| ID | varchar(255) | NO | PRI | NULL | |
| NUMBER_OF_TIMES_USED | int(11) | YES | | NULL | |
| CREATION_TIME | bigint(20) | YES | | NULL | |
| EXPIRATION_POLICY | longblob | NO | | NULL | |
| LAST_TIME_USED | bigint(20) | YES | | NULL | |
| PREVIOUS_LAST_TIME_USED | bigint(20) | YES | | NULL | |
| FROM_NEW_LOGIN | bit(1) | NO | | NULL | |
| TICKET_ALREADY_GRANTED | bit(1) | NO | | NULL | |
| SERVICE | longblob | NO | | NULL | |
| ticketGrantingTicket_ID | varchar(255) | YES | MUL | NULL | |
+-------------------------+--------------+------+-----+---------+-------+
10 rows in set (0.00 sec)
mysql> show columns from TICKETGRANTINGTICKET;
+----------------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+--------------+------+-----+---------+-------+
| ID | varchar(255) | NO | PRI | NULL | |
| NUMBER_OF_TIMES_USED | int(11) | YES | | NULL | |
| CREATION_TIME | bigint(20) | YES | | NULL | |
| EXPIRATION_POLICY | longblob | NO | | NULL | |
| LAST_TIME_USED | bigint(20) | YES | | NULL | |
| PREVIOUS_LAST_TIME_USED | bigint(20) | YES | | NULL | |
| AUTHENTICATION | longblob | NO | | NULL | |
| EXPIRED | bit(1) | NO | | NULL | |
| SERVICES_GRANTED_ACCESS_TO | longblob | NO | | NULL | |
| ticketGrantingTicket_ID | varchar(255) | YES | MUL | NULL | |
+----------------------------+--------------+------+-----+---------+-------+
10 rows in set (0.00 sec)
8) I can now confirm that using version 3.6.0.Final of hibernate-core
successfully replaces hibernate-commons-annotations and hibernate-annotations.
Yay for shorter dependency lists. Thank you Marvin for updating the
documentation on this.
9) When I first read the "Database Connection Pooling" section I had thought
that I didn't have database connection pooling configured at all. After looking
closer at the text in this section and reviewing the ticketRegistry.xml example
I realise that connection pooling is set up through Apache's commons-dbcp
library. I wish this section more clearly stated that it is simply an
alternative method for pooling database connections. I think it would also be
good if it provided some explanation as to why you would want to use the c3p0
library over commons-dbcp.
I can certainly work on making some of these changes to the documentation
myself but I wanted to have some discussion around these changes first before
digging into wiki article.
Thanks,
Jonathan
________________________________________
From: Jonathan Windle [[email protected]]
Sent: Tuesday, September 13, 2011 12:56
To: [email protected]
Subject: RE: [cas-user] JpaTicketRegistry
Thanks for looking.
I am rebuilding and redeploying my custom CAS WAR every time. CAS is completely
dumped from Tomcat before deploying the new copy with each test iteration.
I'm not using the Maven2 WAR overlay method. It seemed like more of pain than
it was worth, but as this is your recommendation I'll try and get it set up.
Thanks again for your help. I'll e-mail back to the list with the results.
Jonathan
________________________________________
From: Marvin Addison [[email protected]]
Sent: Tuesday, September 13, 2011 11:53
To: [email protected]
Subject: Re: [cas-user] JpaTicketRegistry
> I could use a second set of eyes again.
> I'm not seeing anything obvious but I'm also not completely sure what I'm
> looking for.
I don't see any mixed versions, so a version mismatch is likely not the problem.
Are you rebuilding and redeploying your custom CAS war file every
time? Are you removing all remnants of the previously-deployed
version? I hope you're using
https://wiki.jasig.org/display/CASUM/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven2+WAR+Overlay+Method
to manage your customizations, which helps alleviate these kinds of
problems.
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
--
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
--
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
