Hi everyone, I hope this is an easy question. Well, the question IS easy, but the surrounding isn't
Are TicketGrantingTickets, created under 3.4.10, compatible with 3.4.11?
We have been trying to upgrade our local CAS from 3.4.10, to 3.4.11, we are
using the JPA ticket registry, and JPA locking strategy (previously JDBC
locking strategy), with a backend MySQL DB.
When I start 3.4.11, the runs of the ticket cleaner, produce errors like the
following,
2012-02-09 13:14:08,275 INFO
[org.jasig.cas.ticket.registry.support.DefaultTicketRegistryCleaner] -
<Beginning ticket cleanup.>
Hibernate: select jpalocking0_.application_id as applicat1_3_0_,
jpalocking0_.expiration_date as expiration2_3_0_, jpalocking0_.unique_id as
unique3_3_0_ from locks jpalocking0_ where jpalocking0_.application_id=? for
update
Hibernate: update locks set expiration_date=?, unique_id=? where
application_id=?
Hibernate: select ticketgran0_.ID as ID1_, ticketgran0_.NUMBER_OF_TIMES_USED as
NUMBER2_1_, ticketgran0_.CREATION_TIME as CREATION3_1_,
ticketgran0_.EXPIRATION_POLICY as EXPIRATION4_1_, ticketgran0_.LAST_TIME_USED
as LAST5_1_, ticketgran0_.PREVIOUS_LAST_TIME_USED as PREVIOUS6_1_,
ticketgran0_.ticketGrantingTicket_ID as ticketG10_1_,
ticketgran0_.AUTHENTICATION as AUTHENTI7_1_, ticketgran0_.EXPIRED as EXPIRED1_,
ticketgran0_.SERVICES_GRANTED_ACCESS_TO as SERVICES9_1_ from
TICKETGRANTINGTICKET ticketgran0_
Hibernate: select jpalocking0_.application_id as applicat1_3_0_,
jpalocking0_.expiration_date as expiration2_3_0_, jpalocking0_.unique_id as
unique3_3_0_ from locks jpalocking0_ where jpalocking0_.application_id=? for
update
Hibernate: update locks set expiration_date=?, unique_id=? where
application_id=?
2012-02-09 13:14:08,357 ERROR [org.quartz.core.JobRunShell] - <Job
DEFAULT.ticketRegistryCleanerJobDetail threw an unhandled Exception: >
org.springframework.scheduling.quartz.JobMethodInvocationFailedException:
Invocation of method 'clean' on target class [class
org.jasig.cas.ticket.registry.support.DefaultTicketRegistryCleaner] failed;
nested exception is javax.persistence.PersistenceException:
org.hibernate.type.SerializationException: could not deserialize at
org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean$MethodInvokingJob.executeInternal(MethodInvokingJobDetailFactoryBean.java:273)
at
org.springframework.scheduling.quartz.QuartzJobBean.execute(QuartzJobBean.java:86)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:525)
Caused by: javax.persistence.PersistenceException:
org.hibernate.type.SerializationException: could not deserialize
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1214)
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1147)
Plus lots more stack dump
If I remove all the TGTs, start 3.4.11, create a few TGTs, the ticket expiry
runs cleanly.
If that is case, it's not much of an issue, I'm just worried I've mucked
something up while upgrading 3.4.10 to 3.4.11.
=======================================
David Clarke
Java Team
Information Technology Infrastructure
Division of Information
Building 3K
The Australian National University
Canberra ACT 0200 Australia
T: +61 2 6125 8390
www.anu.edu.au
CRICOS Provider #00120C
=======================================
smime.p7s
Description: S/MIME cryptographic signature
