Static methods and fields are tied to a Class. The class is loaded by a ClassLoader.
The concept of "Singleton" is really questionable, especailly in an AppServer. Here I am refering not so much to Singleton as a design
pattern, but to the traditional implementation of a Singleton that, in
Java, eventually relies on a static "instance" field.
Also, by "questionable", I do not mean that Singletons (and/or static methods) are not applicable or useful. But I mean that the questionable part is "How Single is a Singleton".
The answer is "it depends". It depends on how the class is deployed (made available to ClassLoaders) and also depends on the ClassLoader archtiecture of your appserver.
I can not talk specifically about JBoss because I just don't know. But most AppServers use ClassLoaders to support isolation between EJBs and/or WebApps and/or EARs. ClassLoaders are also used to support dynamic reloading ("hot-deploy").
So it depends on how your code is deployed on the system.
If you put the jar in CLASSPATH before you started the server, then the Class will be loaded by the System ClassLoader, which is a parent to all other ClassLoaders your appserver might create. Thus every session bean,
servlet, etc in that JVM will use the same Class object and run the same static method and share any static fields.
If the jar is referenced from the EJB's Manifest Class-Path (or the class is actually included in the ejb-jar), then it will be loaded by that EJB's ClassLoader. Here things start to becom appserver dependent because the Specs dont talk about this.
In WebLogic, for example, all EJBs in the same Enterprise App will share a ClassLoader, so that Class and its static methods would be shared by everything in the EAR (including ejbs and webapps). But other applications (or EJB jars deployed outside an application) would not use that Class instance - they would either have nothing or have their own copy.
Another questionable thing about Singletons in J2EE is when you start to deploy your applications to a cluster. Then, things get weirder, because even the same EJB is deployed in multiple JVMs and of course has multiple ClassLoader instances - so it can not possibly share the same static fields or methods.
So the things to consider are:
Make sure you understand the architecture of your AppServer
Know how you are deploying the code, and thus how it will loaded by the AppServer
Understand how the above will affect the "Scope" of your "Singletons"