Package scanning to discover classes annotated with @Converter is slow. Plus on many containers (especially commercial JEE containers) its not even possible; since ClassLoader.getResource() doesn't often return file system based URIs you can easily convert to a java.io.File so you can list files in a directory.
Finding known resources/classes in class loaders generally works; scanning packages is generally more problematic - as well as being slow.
So it would be better if Camel could use a text file per jar containing all the fully qualified class names of the converters to use. Then no package scanning is required. Or rather we only need to use package scanning if a text file contains packages (rather than fully qualified classes). i.e. do the package scanning at build time (when you have full access to the file system rather than at runtime when you generally don't have access to the files - and expanding jars to look inside them is awfully slow.
In addition it'd be great if we added a maven plugin - or Java compiler AnnotationProcessor we can use with the compile step - to generate the META-INF/services/org/apache/camel/TypeConverter file automatically as part of the build. Then users don't even have to think about it; they just add @Converter to a class and the plugin generates the text file as part of the build., using fully qualified class names - so no package scanning required at runtime - and much faster startup times too