Q1. jaxen: universal Java XPath engine - FAQ
Clarity/PPM relies heavily on the parsing and executing of XML. Every request/response likely goes through multiple XSL Transformations, several XPath queries to connect data and configurations for generating responses, and 'DOM walking' to traverse through the nodes (elements) of XML data and XML code files. Jaxen is one of the libraries we make use of.
Q2. Such is the problem with classpath clashes unfortunately. When Clarity/PPM starts up, it absorbs all the .jar files in the $NIKU_HOME/lib and $NIKU_HOME/customlib folders. The order that those files are absorbed can vary from environment to environment, system to system. Internally in those files, if they were to be extracted to disk, the 'class path' to a given class is identical (e.g. org/jaxen/etc/etc/someclassfile.class) and they'd basically overwrite each other - Java in memory is doing something similar (or actually it's a first-come, first-serve basis, and any duplicate paths/classes that come later get skipped as though they are not allowed to 'overwrite' the existing files).
It typically means that on a given system, the same behaviour will repeat until it is addressed, and other systems will not have the problem at all - I suspect there is something at the OS level (file header tables in a directory) that just has the files in the directory in a given order, and this leads to the issue sticking or not sticking as it does.
Q3. Why would you have those older version lib files (unasked but thought I'd take a stab at pre-empting it)?
Normally these clashes come from a couple of reasons.
1) Some customers make 'backup copies' of some jar files in the $NIKU_HOME/lib folder, not realising that these backups will also be loaded into memory just the same. When newer versions then come to update/overwrite the older files, you then have multiple files with multiple versions of the same classes and a race to see which gets loaded first. Probably NOT the cause in your case though, as I believe those other jaxen jar files are just the legitimate names of older versions of the libraries.
2) Which brings us to custom interfaces/jobs/addins to Clarity/PPM, that are also able to deploy .jar files where they are using capabilities like the XML parsing themselves. For the version those interfaces/jobs are initially written for, there's usually no clash (due to the developer testing all works well in that version), but when it comes to upgrades, then they can manifest whether they are carrying old libraries with the same names or new. It also doesn't matter if those interfaces/jobs install those .jar files to the $NIKU_HOME/lib or $NIKU_HOME/customlib as Java (and Clarity/PPM) gives both locations an equal weighting and place when it comes to the loading of those files and classes. So you can't have older versions in $NIKU_HOME/customlib and Clarity's own upgraded ones in $NIKU_HOME/lib either; the only reconciliations here are to stop using and uninstall the interfaces/jobs, or have them updated to work with the newer libraries Clarity is carrying, or have them built to use other libraries completely (which could still clash in future if Clarity/PPM chooses to later use those other libraries too - there's no fully upgrade-proof strategy here other than diligence and experience).
Hope that helps.