Improve resource resolution #161
Description
Jenkins Dependencies and Class Loading shows a classloader tree where for example JAF-API is not able to locate JakartaMail (plug-in C) mailcap.file resolved from JAF-API (plugin A) because the context classloader is Jenkins core. See: #145 (comment)
When I removed the workaround, your new code correctly kicked in and used the calling class loader from Jenkins Jakarta Activation plugin, but since that class loader could not see the Jenkins Jakarta Mail plugin, the mailcap was empty.
Mail uses JAF but Mail jar contains the mailcap resource file.
More thought needs to be put in to this but there are some options:
- Add constructors for MailcapCommandMap and MimetypesFileTypeMap that take a ClassLoader. Then modify mail to use the newer constructor. Need to examine call sites.
- Use StackWalker to find the calling class loader and probe that class loader after the context class loader and before that application classloader.
- Have mail locate and parse the mailcap file and add the entries manually.
- Force the context classloader to the mail classloader when interacting with JAF. This would work but, I think this is the wrong approach as in some cases user might want the CCL to load the resource.
Metadata
Metadata
Assignees
Labels
No labels