If an invalid message comes in with no version string, HAPI tries to send a response back using a default version. This will fail if the user doesn't have the 2.4 structures JAR on their classpath.
I'm thinking maybe the best behaviour would be to use the lowest version available (but favour 2.2 over 2.1 because nobody uses that anymore)? Or maybe the highest?
We should also do an audit of all of the hardcoded "2.4" strings, because it looks like there are lots. It might also be worth checking if HAPI can even function without any structures JARs at all, and if not we should throw a warning if none are found.
If a structures JAR can be found, why not read it from that bundle - In case of multiple bundles, read it from the highest/lowest ranking bundle? - Or remove the hardcoded string entirely from the core package. It can't be many people actually using the exact "2.4" version, that would simply be too unlikely IMHO
Locally I have added something to check whether ANY version of structure libraries are present on the classpath and log a warning if not. I could remember the lowest/highest available version and use this version instead of "2.4".
Any objections?
Sounds great.
I've actually got some uncommitted work related to this bug as well, and it sounds like the two things would go well together. I've been trying to get HAPI to work cleanly with no structure jars at all on the classpath, and I've been thinking it would be nice to have a warning when we are in that state.
OK. I committed my stuff (rev 694) so you can continue to cover the cases when no structure libs are available at all (so far throws IndexOutOfBoundsException in Version.lowestAvailableVersion)
This has all been checked in.