You must place all the libraries needed for each provider in separate a ClassLoader. If you intend to use many providers then problems can occur because one provider may rely on a dependent library that is incompatable with another provider. Not only that but if you wish to access multiple versions of the same provider then they'll share the same Java package so cannot exist within the same ClassLoader. I especially find it useful to support multiple versions of a provider within the same JVM. This certainly complicates matters for the casual user who knows and cares little about such detail but the benefits can be very handy. If you only ever use your JMS provider via JNDI then you can happily edit the hermes.sh or hermes.bat scripts and tailor them to your environment via the CLASSPATH.

To manage the classpaths, Hermes has the concept of a Classpath Group. Each loader is configured with a collection of libraries and then each session is assigned its own ClassLoader. The Classpath Groups are managed via the Preferences -> Providers dialog, for example this shows a selection of different providers.

In the following session configuration note how the ClassLoader is referenced from the session configuration dialog via the Loader property when configuring a session.

Exactly the same approach to classloading JMS is taken with JNDI. In order to be able to lookup the correct objects in JNDI you need both the correct properties and the code to instantiate the classes whose objects are bound there. Typically if you're missing a JAR then when you lookup a binding you'll get back Reference rather than the real object. Note how following configuration for a JNDI InitialContext includes a reference to the ClassLoader to use.