After reading "Java Concurrency In Practice" I am verifying thread safety of my own classes which use Spring and I may be mistaken, but it seems to me that Spring is not 100% thread safe. I think that many setters are intended for use in constructing the Spring context and should not be used afterwards making these objects "effectively immutable". But I don't see the use of volatile anywhere so how do these beans get published safely?

There are also some examples of classes that are intended for use by multiple threads and don't use volatile or synchronization so in theory have visibility problems.

Examples:
Code:
....
 * @version $Id: SessionInformation.java 3550 2009-04-13 13:43:23Z ltaylor $
 */
public class SessionInformation implements Serializable {
    //~ Instance fields ================================================================================================

    private Date lastRequest;
    private Object principal;
    private String sessionId;
    private boolean expired = false;

....
Ok I can understand that the principal and sessionId are set at construction and never changed. But I think code for a session can run in any thread, so calling the setters for lastRequest and expired fields should at least be volatile.

Another example:
Code:
/* Copyright 2004, 2005, 2006 Acegi Technology Pty Limited
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.springframework.security.core.context;

import org.springframework.util.Assert;


/**
 * A <code>static</code> field-based implementation of {@link SecurityContextHolderStrategy}.
 * <p>
 * This means that all instances in the JVM share the
 * same <code>SecurityContext</code>. This is generally useful with rich clients, such as Swing.
 *
 * @author Ben Alex
 * @version $Id: GlobalSecurityContextHolderStrategy.java 3555 2009-04-14 11:04:49Z ltaylor $
 */
final class GlobalSecurityContextHolderStrategy implements SecurityContextHolderStrategy {
    //~ Static fields/initializers =====================================================================================

    private static SecurityContext contextHolder;

    //~ Methods ========================================================================================================

    public void clearContext() {
        contextHolder = null;
    }

    public SecurityContext getContext() {
        if (contextHolder == null) {
            contextHolder = new SecurityContextImpl();
        }

        return contextHolder;
    }

    public void setContext(SecurityContext context) {
        Assert.notNull(context, "Only non-null SecurityContext instances are permitted");
        contextHolder = context;
    }

    public SecurityContext createEmptyContext() {
        return new SecurityContextImpl();
    }
}
It is well known (at least from JCIP) that two threads concurrently calling getContext() might result in two SecurityContextImpls being created. Or is this just far fetched because this method should be called when initializing the context, and no one should call clearContext() or something?

Also contextHolder is not volatile while it can be called from multiple threads.