Ok, Scott, I found the cause of the problem -- there were a couple of small but significant details in the sar setup which I failed to include in the problem report. Firstly, the jars are actually layered as 8 war-specific jars which employ code from 5 generic code jars. Sequencer, the class with the static data, was in one of the generic jars (ws-c.jar). Secondly, the war files and war-specific jar files employ Classpath entries in the manifest to refer to the jars they rely on. So, for example, ws-c11.war refers to ws-c11.jar which refers to ws-c.jar (contains Sequencer), while ws-t11.war refers to ws-t11.jar and ws-c11.jar and ws-t11.jar refers to ws-t.jar and ws-c.jar. I worked out by trial and error that removing the classpath entries in the war file manifest solves the class duplication problem. I assume this is because the war class loader grabs its own copy of classes in the the jars (recursively) mentioned in the classpath rather than delegating to the sar loader. I did not actually need to remove the jar classpath entries to fix the problem and assume this would not be strictly necessary since the entries only reference jars contained within the same sar i.e. they do not intercede between the loader of the referencing class and some other loader. Is that a valid assumption or was I just lucky? I'll still remove the classpath entries anyway -- the app works fine without them. I don't know whether this needs to be documented as a bug, change of behaviour or just useful thing someone might want to know some day. Anyway, it probably ought to be noted somewhere where AS users or the support team can find it (well, it is noted here at least :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163813#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...