You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "james strachan (JIRA)" <ji...@apache.org> on 2011/07/15 10:14:59 UTC
[jira] [Created] (CAMEL-4233) avoid runtime package scanning to
discover TypeConverters
avoid runtime package scanning to discover TypeConverters
---------------------------------------------------------
Key: CAMEL-4233
URL: https://issues.apache.org/jira/browse/CAMEL-4233
Project: Camel
Issue Type: Improvement
Reporter: james strachan
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
[jira] [Resolved] (CAMEL-4233) avoid runtime package scanning to
discover TypeConverters
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-4233.
--------------------------------
Resolution: Fixed
Committed and updated documentation as well
> 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.8.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
[jira] [Commented] (CAMEL-4233) avoid runtime package scanning to
discover TypeConverters
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066032#comment-13066032 ]
Claus Ibsen commented on CAMEL-4233:
------------------------------------
Got it all up and running. Will do a full test before committing.
> 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.8.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
[jira] [Commented] (CAMEL-4233) avoid runtime package scanning to
discover TypeConverters
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066383#comment-13066383 ]
Claus Ibsen commented on CAMEL-4233:
------------------------------------
Okay the OSGi pieces is also in place, and all tests passes.
> 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.8.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
[jira] [Updated] (CAMEL-4233) avoid runtime package scanning to
discover TypeConverters
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (CAMEL-4233) avoid runtime package scanning to
discover TypeConverters
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-4233:
-------------------------------
Fix Version/s: (was: 2.9.0)
2.8.0
> 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.8.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