There are a couple of issues that I think are at play here:
- There is no "org.richfaces" module within wildfly, so that is probably something that was created specifically for your application at your company. There is a feature request to have this added, but it never was:
- The module that is defined in the link above has nothing that adds support for TIFF images, so the module you are using is either not that one, or is a modified version of it.
- TIFF images weren't supported through ImageIO until Java 9. Prior to that, the only Sun/Oracle libraries that supported TIFF through ImageIO was Java Advanced Imagery ImageIO (JAI-ImageIO). This is quite old, and Oracle has retired it. It can now be obtained from github.
- The classloader for your war should be isolated from your separate jar deployment, unless the jar adds a specific dependency on the war. I'm not sure why your jar would see it, unless the newly-registered TIFF handler becomes visible to everybody in the VM.
So, my *guess* is that the richfaces module that your war is dependent on contains JAI-ImageIO somewhere within it, and that your jar is dependent on the war. If you can, I suggest upgrading to Java 9 (or later) so that you'll get support for TIFF images directly. Otherwise, you can download JAI-ImageIO, create a module for it, and make your jar dependent on the module.
Thanks Greg! I added jai_imageio as a module but I also had to add it to the jre/lib./ext for some reason. I think that there are just too many things at work here xmlgraphics, jai_imageio, javax.image, and java.awt all being used in this jar. Someday when I have time (never) I'll have to look into why it needs all those things.
Did you add a dependency on the jai_imageio module to your jar? I forgot to mention that in my original response. If you didn't do that, then your deployed jar wouldn't see those classes. Adding it to the jre/lib/ext just bypasses the modules, and makes it available to everybody.