I wanted to share my findings on an issue we've been having with sending multipart/alternative MIME messages using a Camel Mail route deployed in a fabric container on Fuse ESB Enterprise 7.1.0.

The issue boils down to the fact that the javax.activation package (from the JRE) is loaded in the System Bundle of a container. When the camel-mail component tries to send a multipart/alternative message a javax.activation.UnsupportedDataTypeException is thrown (javax.activation from the JRE cannot handle / does not understand the multipart/alternative MIME type).

There is a Apache ServiceMix :: Specs :: Activation API 1.4 bundle that has a javax.activation package which IS able to handle the multipart/alternative MIME type. But of course, the camel-mail component does not use this since it's version is the same as the System Bundle's version, and System Bundle was loaded first.

One option that has been suggested is to edit the etc/jre.properties file, commenting out javax.activation. This obviously works, but it's a manual process for each container you want to deploy your camel-mail route into. And you have to restart the container.

An alternative solution we've found is to define a fabric profile, which you can apply to a container on creation, that replaces the org.osgi.framework.system.packages property in etc/config.properties with a list of packages that you do want loaded into the System Bundle. E.g.

fabric:profile-create no-javax-activation-profile

fabric:profile-edit --config org.osgi.framework.system.packages='' no-javax-activation-profile

I'd be grateful for any comments on possible pitfalls with this approach.

Thanks