Client API Changes
Crowd 1.3 brings a rework of the internals of the Crowd Client library — see CWD-622. This page gives a summary of the API changes.
Description of the changes
- The static implementations of HttpAuthenticator and SecurityServerClient have been removed. They have been replaced with instantiable objects.
- The GenericClient has been removed and its functions have been absorbed into the new SecurityServerClient and the ClientProperties objects.
- The relationships in the new class structure are represented below:
Why go to non-static?
- Makes it easier to unit test your applications. Simply mock out the SecurityServerClient or HttpAuthenticator interfaces to test business logic without being tied to the collaborators.
- Allows you to have multiple 'applications' in one classloader.
But I liked my static calls!
- SecurityServerClientFactory and HttpAuthenticatorFactory are provided to allow for a fast migration to the new API. The logical functionality of the client and authenticator are unchanged.
- So for example, instead of: you could use:
What are my options?
- Use the supplied factory methods to manage singleton instances, OR
- Externally manage singleton instances, e.g. via an IoC container like Spring.
Using the factories
SecurityServerClientFactory, provide quick access to implementations of the
SecurityServerClient. They manage singleton instances of the beans. This means that if you do opt to use the factories, then you should never instantiate
The factories naturally assume that there is one application client per classloader, i.e. one
SecurityServerClient and one
Using an IoC container
Managing the singleton implementations externally may be a convenient approach for applications that use an IoC container. For example, Spring could be used to manage the instances of
HttpAuthenticatorImpl. In Crowd, internally, we use this approach.
If you would like to use the standard Spring configuration, which loads the client properties from
crowd.properties, simply add the
applicationContext-CrowdClient.xml from the classpath to your Spring configuration:
This file is located in the
If you would like to customize your own configuration, modify the bean configuration to suit your needs:
Make sure that you do not use the factories (either directly or implicitly) when externally managing singletons.
If you would like to use the
VerifyTokenFilter, you can use Spring to autowire the servlet filter by defining it in your
This will protect all resources matching the
Was this helpful?
Thanks for your feedback!