Kauri Documentation
 PreviousHomeNext 
13.2.2 Element descriptionBook Index13.4 Spring config reference

13.3 classloading.xml reference

<classLoading>
  <required on-conflict="highest"/><!-- (default)highest|error -->
  <allowed on-conflict="default"/><!-- (default)dontshare|highest|error -->
</classLoading>

required/@on-conflict: What to do when a share-required classloader entry occurs with different versions in different modules.

allowed/@on-conflict: What to do when a share-allowed classloader entry occurs with different versions in different modules.

These properties allow to solve a common source of classloading annoyance: you have a dependency on artifact X, which the runtime decides to put in the shared classloader. But X has a dependency on Y, and some other project also has a dependency on Y, but another version of it. Hence, the runtime decides to put Y not in the shared classloader. Consequence: X does not have access to the classes of Y. The solution before was to add, in the pom(s), an exclusion for one of the versions of Y. This works, but takes effort and is hard to maintain.

To decide what is the highest (most recent) version, we need to know how to compare version numbers. The comparison logic assumes version follow the following format:

major.minor.revision-suffix

in which the minor, revision, and -suffix parts are optional. A missing minor or revision number is the same as it having the value 0.

Concerning the suffix: if the two version numbers are equal, and the one has a suffix and the other not, then the one without suffix is considered to be the most recent. This is because the suffix is usually used to indicate some 'in preparation' release: -alpha, -beta, -r22342, -20101023, ...

If both versions have a suffix, than currently the only supported comparison is if they have the form '-r{number}', which is the format we usually use for Subversion revision-numbered snapshots.

 PreviousHomeNext 
13.2.2 Element description13.4 Spring config reference