To keep this post as short as possible, a detail description of the problem can be found in here and here. What actually happens in my case is that when I reload the web service application in a container, this linkage error occurs. The loader constraint is violated because it happens that two classloaders (the current class loader and the superclass loader) have different class objects for the type javax.activation.DataHandler used in the signature.
There are different ways to fix this problem. For example, unjar geronimo-activation_1.1_spec-1.0.2.jar and remove the associated classes from it. However, this is very intrusive. Another approach is to instruct Jetty to allow the normal java behavior to be used and all classes will be loaded from the system classpath if possible. This can be done by setting the webAppContext's parentLoaderPriority to true in jetty-web.xml. This is fine however it affects all classes behaviors since every class will be loaded from the system classpath if found. A better approach (I think) is to control the class loading behavior in a per class basis. This can be done by setting the webAppContext's systemClasses property to include javax.activation. in the list of classes that cannot be overridden by webapp context classloaders.
A sample of the jetty-web.xml is as follows:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<!-- this is needed to avoid LinkageError: loader constraint violation -->
<Set name="systemClasses">
<Array type="String">
<Item>java.</Item>
<Item>javax.servlet.</Item>
<Item>javax.xml.</Item>
<Item>org.mortbay.</Item>
<Item>org.xml.</Item>
<Item>org.w3c.</Item>
<Item>org.apache.commons.logging.</Item>
<Item>org.apache.log4j.</Item>
<Item>javax.activation.</Item>
</Array>
</Set>
</Configure>
Hope this is helpful to someone else as well. :)
