Friday, January 7, 2011

[WSS4J 1.6] Action/Processor loading change

Following on from yesterday's post about changes to crypto property files in WSS4J 1.6, this post details some changes that have been made to how Actions and Processors are loaded in WSS4J. These changes do not affect the end user per se, apart from the case of adding custom Actions or Processors, but are probably important enough to take note of.

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%.


  1. I'm assuming you cannot add a custom processor to the any longer using Spring config like it is documented here:

    If not, can you please tell me how you can configure custom processors with Spring xml in WSS4J 1.6.1?

  2. I've found my problem that I posted about setting customized processors using Spring.

    It seems that the parameters for QName were in reverse order and it should've looked like: