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

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?

  1. Use the supplied factory methods to manage singleton instances, OR
  2. Externally manage singleton instances, e.g. via an IoC container like Spring.

Using the factories

The 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 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 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, simply add the applicationContext-CrowdClient.xml from the classpath to your Spring configuration:


This file is located in the crowd-integration-client.jar.

If you would like to customize your own configuration, modify the bean configuration to suit your needs:

<?xml version="1.0" encoding="UTF-8"?>


    <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 id="securityServerClient" class="com.atlassian.crowd.integration.service.soap.client.SecurityServerClientImpl">
        <constructor-arg ref="clientProperties"/>

    <bean id="httpAuthenticator" class="com.atlassian.crowd.integration.http.HttpAuthenticatorImpl">
        <constructor-arg ref="securityServerClient"/>

    <bean id="verifyTokenFilter" class="com.atlassian.crowd.integration.http.VerifyTokenFilter">
        <constructor-arg ref="httpAuthenticator"/>

    <bean id="crowdAuthenticationInterceptor" class="com.atlassian.crowd.integration.xwork.CrowdAuthenticationInterceptor">
        <constructor-arg ref="httpAuthenticator"/>


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:



This will protect all resources matching the /secure/* pattern.

最終更新日 2016 年 5 月 26 日


Powered by Confluence and Scroll Viewport.