> Feel free to include me (or let me know how to include myself) in release
> candidate testing.
It's really a matter of simply taking initiative to test your overlays
against release candidates when we announce them. If you're on
cas-user, you should see the announcements.
I appreciate your wi
Thanks for the update Marvin. I try do try to stay current with the
desired/best practice when releases come out. If not, I end up down the road
asking why isn't XXX not working now, only to learn that "we haven't done it
that way in years". :)
I did start messing around, and I switching to:
> I came across https://issues.jasig.org/browse/CAS-930. The last comment by
> Marvin indicates that the JdbcLockingStrategy should be deprecated.
It is indeed deprecated:
https://github.com/Jasig/cas/blob/master/cas-server-core/src/main/java/org/jasig/cas/ticket/registry/support/JdbcLockingStrat
Hi John,
Yes, I see what you mean now.
I've updated my locking strategy to JPA and it seems to run fine:
Thanks
Paul
On 9 Nov 2011, at 18:11, Gasper, John wrote:
> Hi Paul,
>
> Yes, this also fixed my issue getting CAS to work for me... But if you look
> lower in the documentation a
Hi Paul,
Yes, this also fixed my issue getting CAS to work for me... But if you look
lower in the documentation at the cleaner bean, it uses the
JdbcLockingStrategy. In trying to track down what I broke doing the install, I
came across https://issues.jasig.org/browse/CAS-930. The last comment b
Hi John,
If you follow the updated wiki instructions it works perfectly. All my
integration tests passed.
Thanks
Paul Vitty
Apache/MySQL Web Platform Engineer
Application Platform Delivery
Information Services Directorate
University of Ulster
Tel: 02890 366273
Email: p.vi...@ulster.ac.uk
Web:
Hi guys,
I'm also trying to get my CAS install upgraded 3.4.11. Before going through the
trouble of blowing my stuff up would it make sense to change the cleanerLock to
just the JpaLockingStrategy? Or, should JdbcLockingStrategy be left per the
documentation/example on https://wiki.jasig.org/di
> Adding class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"
> /> to the ticketRegistry.xml resolves the issue and appears to ensure that
> the entityManager is wired up.
That's absolutely right. It's sitting right there in my overlay and I
simply forgot that confi
Marvin,
I believe I may have solved the issue, for some reason PersistenceContext is
not being set via annotation
https://github.com/Jasig/cas/blob/v3.4.11/cas-server-core/src/main/java/org/jasig/cas/ticket/registry/JpaTicketRegistry.java#L38
so the entityManager is null causing the null pointe
Thanks for getting back to me Marvin. I'd be more than willing to QA our JPA
overlay in the future.
Thanks
Paul
On 9 Nov 2011, at 16:28, Marvin Addison wrote:
>> I've modified the vanilla cas-server-webapp to reproduce the issue,
>> see:
>> https://github.com/pvitty/cas/commit/d28f811ccd02eb8
> I've modified the vanilla cas-server-webapp to reproduce the issue,
> see: https://github.com/pvitty/cas/commit/d28f811ccd02eb838a4de17f0a056bb5c410add2 for
> details. It creates the database tables correctly but still throws the
> errors above, you can use mvn integration-test jetty::run to repr
I have tried without auditing and there is no more information in the log
output.
With all log levels up to DEBUG:
2011-11-09 14:38:24,628 DEBUG
[org.springframework.transaction.annotation.AnnotationTransactionAttributeSource]
-
2011-11-09 14:38:24,628 DEBUG
[org.springframework.orm.jpa.JpaT
> I switched log4j up to debug, the area that seems to be causing the issue is:
>
> 2011-11-09 02:21:49,422 DEBUG
> [org.springframework.transaction.annotation.AnnotationTransactionAttributeSource]
> - [PROPAGATION_REQUIRED,ISOLATION_DEFAULT]>
> 2011-11-09 02:21:49,422 DEBUG
> [org.springfram
13 matches
Mail list logo
