Re: [cas-user] Getting CAS 6.4.5 to run on Wildfly 24

[Pablo Vidaurri]

I have included the "weld" exclusion  seems to be working. My complete 
jboss-deployment-structure.xml below:








**




On Monday, June 13, 2022 at 11:18:05 PM UTC-5 shanec...@gmail.com wrote:

> It appears to be preventing Apache's bval library from adding its own 
> ValidatorBean implementation:
>
>
> https://github.com/apache/bval/blob/master/bval-jsr/src/main/java/org/apache/bval/cdi/BValExtension.java
>
> The presence of two ValidatorBeans was causing an ambiguous dependency 
> error; adding the variable was a work around. I didn't try adding an 
> exclusion but it might be a better solution.
>
> Let us know if you get it to work that way.
>
> On Jun 13, 2022, at 1:03 PM, Pablo Vidaurri  wrote:
>
> Also running on wildfly. After upgrade from 6.3.x to 6.5.4 getting the 
> validator error too. What does *bval.in-container=true* actually do? I 
> would think adding an exclusion to jboss-deployement-structure.xml would be 
> a better solution.
>
> -psv
> On Saturday, February 19, 2022 at 11:23:35 AM UTC-6 shanec...@gmail.com 
> wrote:
>
>> Thank you Ray, that clarifies things. We don’t use CAS to manage LDAP 
>> passwords so the one without password management is the right choice for us.
>>
>>
>> On Feb 10, 2022, at 12:40 PM, Ray Bon  wrote:
>>
>> Shane,
>>
>> The line with 'pm' is the password management feature; The one without is 
>> login.
>>
>> Ray
>>
>> On Thu, 2022-02-10 at 09:54 -0800, Shane Claggett wrote:
>>
>> Notice: This message was sent from outside the University of Victoria 
>> email system. Please be cautious with links and sensitive information. 
>>
>> As an addendum, I was unable to get LDAP to work until I changed the 
>> dependency of the autogenerated LDAP CAS WAR overlay from:
>>
>>   implementation "org.apereo.cas:cas-server-support-pm-ldap" 
>>
>> to:
>>
>>   implementation "org.apereo.cas:cas-server-support-ldap" 
>>
>> I'm not sure what the difference between the two is or if that's a bug in 
>> the autogenerated overlay or not.
>>
>> On Wednesday, February 9, 2022 at 5:14:17 PM UTC-8 Shane Claggett wrote:
>>
>> Hi all,
>>
>> I've just worked through getting CAS 6.4.5 to run on Wildfly 24 and want 
>> to post the steps and the issues encountered for two reasons: to see if 
>> anyone has a better idea of how to solve them, and to document the process 
>> for anyone else that needs to do the same.
>>
>> I started with an autogenerated LDAP CAS WAR overlay from here 
>> ,
>>  
>> then applied the external servlet container configuration from here 
>> .
>>  
>> Specifically, this was added to build.gradle:
>>
>>   implementation 
>> "org.apereo.cas:cas-server-webapp:${project.'cas.version'}"
>>
>> And the file jboss-deployment-structure.xml was added to 
>> src/main/webapp/WEB-INF:
>>
>>   
>>   
>> 
>>   
>> 
>>   
>> 
>>   
>>
>> Additionally, both appServer and tomcatVersion in gradle.properties were 
>> set to blank as suggested by a recent thread on this mailing list here 
>> 
>> .
>>
>> However, cas.war failed to deploy on Wildfly 24 with a series of 
>> exceptions. Several appeared to be related and were all similar to:
>>
>> 2022-02-08 14:21:39,715 WARN  [org.jboss.modules.define] (Weld Thread 
>> Pool -- 3) Failed to define class 
>> org.springframework.http.server.reactive.ServletHttpHandlerAdapter$HandlerResultSubscriber
>>  
>> in Module "deployment.cas.war" from Service Module Loader: 
>> java.lang.NoClassDefFoundError: Failed to link 
>> org/springframework/http/server/reactive/ServletHttpHandlerAdapter$HandlerResultSubscriber
>>  
>> (Module "deployment.cas.war" from Service Module Loader): 
>> org/reactivestreams/Subscriber
>>
>> A bit of searching lead to the idea to add the following dependency to 
>> build.gradle:
>>
>>   implementation "org.reactivestreams:reactive-streams"
>>
>> That fixed the above-mention exceptions. One more exception was present 
>> and stopping the webapp from deploying:
>>
>> 2022-02-08 14:28:12,800 ERROR [org.jboss.msc.service.fail] (MSC service 
>> thread 1-2) MSC01: Failed to start service 
>> jboss.deployment.unit."cas.war".WeldStartService: 
>> org.jboss.msc.service.StartException in service 
>> jboss.deployment.unit."cas.war".WeldStartService: Failed to start service
>>   at 
>> org.jb...@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
>>   at 
>> org.jb...@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
>>   at 
>> org.jbos...@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
>>   at 
>> 

Re: [cas-user] Re: Migrating services from version 5 to 6

[Trevor Fong]

Thanks a lot for your reply Francois.

Dammit - that sucks that we both had such a poor experience!
I fear you might be right and I'll have to abandon the 300+ rules we've
built up over the years due to inadequate support and documentation; it's
not like they discontinued support for JPA - they just didn't provide any
support at all for migration, which feels worse!  It's like saying "Sure
you can do it, see all the cool things you can do" and not say how to do
it.
I'll give myself to the end of the week and "cut bait" if I can't find a
way out.  I'll reply if I should find anything of use.

Thanks again,
Trev

On Wed, 15 Jun 2022 at 08:11, fjannin4  wrote:

> Hi Trev
>
> Alas I didn't found anything to simply convert structured data from JPA to
> JSON... It was too tedious and time consuming and I gave up... None of cues
> and hints was working.
>
> The whole online documentation of CAS 5.x has been removed (i have never
> seen so many Google results issueing 404 errors... dunno why they don't
> remove links ?) , to enforce difficulty to find relevant informations, and
> I mess up working with partial remains in webarchives.
>
> Instead I am going to replace my fine tuned granularity of service
> descriptions with one wildcard by domains name of internal applications, in
> JSON format, the only one that really has support from CAS Team and
> documented.
>
> Doing this therefore, I will lost all level of details for each service :
> descriptions, logo and contacts, thas was before used in CAS and CAS
> management application...
>
> High price to paid, just for CAS developpers team's taste to follow the
> fahsion for JSON and unilateral deprection for JPA ...
>
> So, to keep your CAS installation working is a question of chance : if you
> bet on the good techno that wil survive to annual elegation, you won... We
> bet on JPA and lost...
> Good luck !
> Regards
>
> Le 10/06/2022 à 19:45, Trevor Fong a écrit :
>
> Hi Francois,
>
> Just wondering if you were able to resolve your situation and if so, how?
> I'm also facing a similar thing.
>
> Thanks a lot,
> Trev
>
> On Thursday, March 31, 2022 at 10:54:41 AM UTC-7 fjan...@gmail.com wrote:
>
>> Thank you for the response.
>>
>> We actually use CAS Management application, and I will follow your
>> suggestion.
>>
>> We have a bunch of services  to migrate : 140+, with their own contacts,
>> policies and release attriibute settings.
>>
>> I have tried the actuator end point /services from CAS Server , wich
>> export all services in one file, but  JSON format seems different from the
>> import format used in CAS 6.4.
>>
>> i will try the management application way, with hopefully more success...
>>
>> Best regards
>>
>> Francois
>> Le 31/03/2022 à 17:35, 'Richard Frovarp' via CAS Community a écrit :
>>
>> The tables in the post are for the service registry. If you don't migrate
>> those, you will have to reconfigure from scratch.
>>
>> I do not know what the plans are for the project with respect to the
>> service registry. It's changed a bit between versions, and usually seems
>> like a pain. We made the change in a previous upgrade to just drop JSON
>> files on the filesystem and have CAS pick those up. It keeps us free of
>> changes in the JPA method (which we had been using), and free from
>> management app changes. In addition, we can keep service configuration in
>> git, which is extremely nice.
>>
>> What I gather from that post is you are going to need to change the
>> source code of RegisteredServicesReportController either changing that
>> method, or adding that method. Looks like it is adding the method. Compile,
>> put into your deployment (or download your DB and run locally), and then
>> hit that point to get the exported JSON services. If you are running the
>> management application in 5.3, I think you can export services as JSON as
>> well, just by clicking a bunch of times and possibly doing copy and paste.
>> Depending on your number of services, it might be simpler to just export
>> via the management application, which I'm assuming that you are using. That
>> would save you from editing code and having to deploy a new class file.
>>
>> Richard
>>
>> On 3/31/22 09:32, Pablo Vidaurri wrote:
>>
>> There is no need to migrate the data. These tables are for various type
>> of tickets. Worst case when you cut over to v6.4 your users will have to
>> login again.
>>
>> -psv
>>
>>
>> On Wednesday, March 30, 2022 at 9:43:58 AM UTC-5 fjan...@gmail.com wrote:
>>
>>> Hi,
>>>
>>> I need to migrate JPA service registry  from Apereo CAS  5.2.2 to 6.4,
>>> but in this last version , data structures seem to have been replaced by
>>> just one table with flat JSON field in a column : no more relationnal
>>> structure, or I missed something.
>>> Has anyone here observe the same ?
>>> If the JPA migration is not possible, does it mean I have to use JSON in
>>> any way ?
>>>
>>> The best hit had met my searches till now is this page :
>>> 

Re: [cas-user] Re: Migrating services from version 5 to 6

[fjannin4]

Hi Trev

Alas I didn't found anything to simply convert structured data from JPA 
to JSON... It was too tedious and time consuming and I gave up... None 
of cues and hints was working.


The whole online documentation of CAS 5.x has been removed (i have never 
seen so many Google results issueing 404 errors... dunno why they don't 
remove links ?) , to enforce difficulty to find relevant informations, 
and I mess up working with partial remains in webarchives.


Instead I am going to replace my fine tuned granularity of service 
descriptions with one wildcard by domains name of internal applications, 
in JSON format, the only one that really has support from CAS Team and 
documented.


Doing this therefore, I will lost all level of details for each service 
: descriptions, logo and contacts, thas was before used in CAS and CAS 
management application...


High price to paid, just for CAS developpers team's taste to follow the 
fahsion for JSON and unilateral deprec    tion for JPA ...


So, to keep your CAS installation working is a question of chance : if 
you bet on the good techno that wil survive to annual elegation, you 
won... We bet on JPA and lost...


Good luck !
Regards

Le 10/06/2022 à 19:45, Trevor Fong a écrit :

Hi Francois,

Just wondering if you were able to resolve your situation and if so, 
how?  I'm also facing a similar thing.


Thanks a lot,
Trev

On Thursday, March 31, 2022 at 10:54:41 AM UTC-7 fjan...@gmail.com wrote:

Thank you for the response.

We actually use CAS Management application, and I will follow your
suggestion.

We have a bunch of services  to migrate : 140+, with their own
contacts, policies and release attriibute settings.

I have tried the actuator end point /services from CAS Server ,
wich export all services in one file, but  JSON format seems
different from the import format used in CAS 6.4.

i will try the management application way, with hopefully more
success...

Best regards

Francois

Le 31/03/2022 à 17:35, 'Richard Frovarp' via CAS Community a écrit :

The tables in the post are for the service registry. If you don't
migrate those, you will have to reconfigure from scratch.

I do not know what the plans are for the project with respect to
the service registry. It's changed a bit between versions, and
usually seems like a pain. We made the change in a previous
upgrade to just drop JSON files on the filesystem and have CAS
pick those up. It keeps us free of changes in the JPA method
(which we had been using), and free from management app changes.
In addition, we can keep service configuration in git, which is
extremely nice.

What I gather from that post is you are going to need to change
the source code of RegisteredServicesReportController either
changing that method, or adding that method. Looks like it is
adding the method. Compile, put into your deployment (or download
your DB and run locally), and then hit that point to get the
exported JSON services. If you are running the management
application in 5.3, I think you can export services as JSON as
well, just by clicking a bunch of times and possibly doing copy
and paste. Depending on your number of services, it might be
simpler to just export via the management application, which I'm
assuming that you are using. That would save you from editing
code and having to deploy a new class file.

Richard

On 3/31/22 09:32, Pablo Vidaurri wrote:

There is no need to migrate the data. These tables are for
various type of tickets. Worst case when you cut over to v6.4
your users will have to login again.

-psv


On Wednesday, March 30, 2022 at 9:43:58 AM UTC-5
fjan...@gmail.com wrote:

Hi,

I need to migrate JPA service registry  from Apereo CAS 
5.2.2 to 6.4,
but in this last version , data structures seem to have been
replaced by
just one table with flat JSON field in a column : no more
relationnal
structure, or I missed something.
Has anyone here observe the same ?
If the JPA migration is not possible, does it mean I have to
use JSON in
any way ?

The best hit had met my searches till now is this page :

https://fawnoos.com/2021/01/19/cas53-service-registry-migration-to-cas63/

But its content is pretty elliptic and I don't see where to
apply the
snippet showed in it :  I have an installation based on
cas-overlay,
there is no  java file named
RegisteredServicesReportController to
override...

In short my purpose is as follow : migration services from
JPA to JSON

Does anyone faced the same issue ?

Thanks a lot for any clue.


-- 
- Website: https://apereo.github.io/cas

- Gitter Chatroom: https://gitter.im/apereo/cas
- List 

[cas-user] Re: Logout Redirect Issue

[Dan S]

I have some more information after testing yesterday.

I thought it was specific to the logout sent from my app but it's not. If I 
go to cas/login I can see all my information. If I use the logout link 
there with no redirect, it logs out of cas. I

If I enter cas/logout with a service redirect url in the browser, it goes 
to a blank screen. If I press enter on the url again while on the blank 
screen - it works. The only difference I can see in debug is that it 
recognizes that there is no cas session to terminate and it continues on to 
the service redirect. The debug for the first entry appears to work 
correctly -- the only part that seems to be missing is the last line that 
indicates it redirected to the external url.

If I use the cas.logout.redirect-url= parameter, the logout link on the 
page doesn't work. It just goes to the blank page. I can tell that cas has 
been logged out. It definitely doesn't continue to the redirect url or 
correctly show the cas logout page.

I am using a delegated login. In testing today, I am planning to enable to 
regular login and see if logout works with that.

Dan

On Tuesday, June 14, 2022 at 10:30:42 AM UTC-5 Dan S wrote:

> I am working on upgrading our CAS instance from 6.1 to 6.5. I have been 
> able to get everything working as expected except the logout redirect.
>
> I am using the parameter:
> cas.logout.follow-service-redirects=true
>
> I have tried using the parameter for a redirect and setting the global 
> redirect.
>
> If you enter the logout url directly in the browser, it correctly sends 
> back a 302 and the browser is redirected.
>
> If we have an app that sends the browser to the cas logout url, cas sends 
> back a 200 response with a blank screen.
>
> Anyone have any ideas?
>
> Thanks,
>
> Dan
>
>

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/76af157d-8a07-4a4f-ba54-1ad54ce3a695n%40apereo.org.