No ConditionalOnMissingBean for argumentExtractor

51 views
Skip to first unread message

Geoff

unread,
Jun 23, 2017, 5:30:56 PM6/23/17
to CAS Community
Hello,

I'd like to implement my own version of WebApplicationServiceFactory and SamlServiceFactory in CAS 5.1.0 however I don't see a way to make CAS my implementations instead of the out of the box versions.  

In my CAS 4 implementation this was accomplished by specifying custom ArgumentExtractors in argumentExtractorsConfiguration.xml.  In CAS 5 it looks like a single argument extractor is defined in CasCoreWebConfiguration and it effectively uses ServiceFactories found on any configuration classes that implement ServiceFactoryConfigurer.  This provides a nice mechanism to add new ServiceFactories but I don't see a way to override the existing ones.

It seems like an easy way to allow this sort of customization would be to annotate the ArgumentExtractor defined in CasCoreWebConfiguration with ConditionalOnMissingBean so that it could be overriden.  Or maybe I'm overlooking an easier way of modifying the behavior in WebApplicationServiceFactory and SamlServiceFactory?

Thanks!

Geoff

Yaroslav Panych

unread,
Jun 23, 2017, 6:18:59 PM6/23/17
to cas-...@apereo.org
Well,sometimes redefining bean in deployerContextConfig.xml works.
Just override configuration itself. Copy it from cas sources into your
project, modify and build it. Final .war will contain your .class in
root(/WEB-INF/classes/..), which has higher priority than one packed
in .jar. Unfortunatelly it is only possible way to customize
cas(except forking), since devs got rid of xml spring context
configurations. I already have patched two dozens of classes this way
in cas 5.0.x branch. In modern cas Spring plays role of web framework,
but not as component (de)coupling mechanism, since component wiring
hardcoded into class files, and cannot be done in xml files by
declareing new bean and changing references. Overlay method of using
cas is actually hell for customizer. Every other bean you have
override using described here method, becuase other methods to patch
components DI are not working. The same can be applied for
login-webflow.xml - it is almost empty, most states are dynamically
build during cas startup, and it is impossible to control flow.
> --
> - CAS gitter chatroom: https://gitter.im/apereo/cas
> - CAS mailing list guidelines:
> https://apereo.github.io/cas/Mailing-Lists.html
> - CAS documentation website: https://apereo.github.io/cas
> - CAS project website: https://github.com/apereo/cas
> ---
> 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+u...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/e415701d-7aa7-46d9-b529-a27dfafd30f4%40apereo.org.

dkopy...@unicon.net

unread,
Jun 23, 2017, 6:36:03 PM6/23/17
to cas-...@apereo.org
I'll just add my 2c. here.

The "CAS5 overlay is the hell for deployers..." is of course a highly subjective statement. First and foremost, CAS5 generation was designed with ease of deployment and "intention-driven configuration" model in mind, and NOT as a software "leaking" its internals to everyone enabling them to "easily" re-write every aspect of it.

Second, the Spring annotation-based configuration model is very much a modern DI that STILL enables you to wire, re-wire, inject, re-inject, and all that other goodness of Spring DI if you desire to - just in the more powerful and modern fashion. Besides, if you HAVE TO for whatever reason re-implement and re-wire dozens of CAS classes, why not let Java instead of XML assemble them together in a type-safe fashion.

And finally, here's a good blog post touching upon the rational behind CAS5 config design decisions: https://apereo.github.io/2017/02/21/cas-autocfg-strategy/

Good weekend!

D.

Geoff

unread,
Jun 24, 2017, 4:24:57 PM6/24/17
to CAS Community
I'll let you two hash that one out :)

I was just hoping I was missing an easy way to get CAS to use my service factory implementations instead of the built in versions and if not to test the waters for a feature request to add the ConditiinalOnMissingBean annotation to the argument extractor.

Geoff White

unread,
Jun 25, 2017, 10:52:48 PM6/25/17
to cas-...@apereo.org
I'll let you two hash that one out :)

I was just hoping I was missing an easy way to get CAS to use my service factory implementations instead of the built in versions and if not to test the waters for a feature request to add the ConditiinalOnMissingBean annotation to the argument extractor.
Reply all
Reply to author
Forward
0 new messages