[
https://issues.apache.org/jira/browse/CAMEL-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-4233:
-------------------------------
Component/s: camel-core
Affects Version/s: 2.7.0
Fix Version/s: 2.9.0
Assignee: Claus Ibsen
I got a prototype up and running locally. It supports the FQN in the
TypeConverter file. This ensures we load the classes directly instead of
package scanning it. The prototype will fallback and do package scanning for
entries in the TypeConverter file which is a package. So its fully backwards
compatible.
All there is to do then is to migrate the TypeConverter files in all the Camel
components.
Later we can look into the Java compiler to automatic generate the
TypeConverter file. But for know lets get the first stuff fixed.
This ensures Camel loads much better in environments. For example it may run in
JBoss out of the box, without that special JAR.
> avoid runtime package scanning to discover TypeConverters
> ---------------------------------------------------------
>
> Key: CAMEL-4233
> URL: https://issues.apache.org/jira/browse/CAMEL-4233
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 2.7.0
> Reporter: james strachan
> Assignee: Claus Ibsen
> Fix For: 2.9.0
>
>
> 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
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
