Crowd 2.0 : Client API Changes
This page last changed on Mar 03, 2008 by smaddox.
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
Why go to non-static?
But I liked my static calls!
What are my options?
Using the factoriesThe factories, HttpAuthenticatorFactory and SecurityServerClientFactory, provide quick access to implementations of the HttpAuthenticator and SecurityServerClient. They manage singleton instances of the beans. This means that if you do opt to use the factories, then you should never instantiate HttpAuthenticatorImpl or SecurityServerClientImpl directly. The factories naturally assume that there is one application client per classloader, i.e. one SecurityServerClient and one HttpAuthenticator. Using an IoC containerManaging 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 SecurityServerClientImpl and 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: <context-param> <param-name>contextConfigLocation</param-name> <param-value> classpath:/applicationContext-CrowdClient.xml </param-value> </context-param> This file is located in the crowd-integration-client.jar. If you would like to customise your own configuration, modify the bean configuration to suit your needs: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean id="propertyUtils" class="com.atlassian.crowd.util.PropertyUtils"/> <bean id="clientProperties" class="com.atlassian.crowd.integration.service.soap.client.ClientProperties"> <constructor-arg ref="propertyUtils"/> </bean> <bean id="securityServerClient" class="com.atlassian.crowd.integration.service.soap.client.SecurityServerClientImpl"> <constructor-arg ref="clientProperties"/> </bean> <bean id="httpAuthenticator" class="com.atlassian.crowd.integration.http.HttpAuthenticatorImpl"> <constructor-arg ref="securityServerClient"/> </bean> <bean id="verifyTokenFilter" class="com.atlassian.crowd.integration.http.VerifyTokenFilter"> <constructor-arg ref="httpAuthenticator"/> </bean> <bean id="crowdAuthenticationInterceptor" class="com.atlassian.crowd.integration.xwork.CrowdAuthenticationInterceptor"> <constructor-arg ref="httpAuthenticator"/> </bean> </beans> 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 web.xml: <filter> <filter-name>verifyTokenFilter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>verifyTokenFilter</filter-name> <url-pattern>/secure/*</url-pattern> </filter-mapping> This will protect all resources matching the /secure/* pattern. |
![]() |
Document generated by Confluence on Jul 30, 2009 01:30 |