In WSS4J 1.5.x, WSSConfig stores a <QName, String> map of default Processors. On processing a security header, it tries to match the QName of the child elements with the Map keys, and then uses the corresponding Map value to load the Processor class and then create a new instance of it.
The problem with this approach is that every time a message is received, each processor that is required gets class loaded again, which is highly inefficient. See this JIRA for more details. The same problem also exists for Action classes that are also loaded by WSSConfig.
The simple solution is to change the default Action/Processor maps in WSSConfig to store Class instances rather than Strings. Each time an Action/Processor object is required, it is simply created with <Class>.newInstance(). It is still possible to add custom Action/Processor objects to the custom Action/Processor maps. It is claimed in the JIRA above that:
The patch brings a massive performance enhancement, at least in the jetty-environment (I didn't test other application server) due to not looking up the classes on every invocation. The CPU-time of the wss4j library went from ~50% down to 2%.