Hi

I just did an experiment on camel-core to load the core type
converters faster (eg without classpath scanning).

before: 26 min total testing time (default)
after: 24:30 min total testing time (lazy loading enabled)
special: 21:30 total testing time (lazy loading enabled, but forcing
it to never do classpath scanning)

So we have a potential cut down from 1m30s to 4m30s. The latter is a
special where we force Camel to not even try classpath scanning. That
could be a viable approach to do for camel-core testing exclusively as
we know there are no other JARs on the classpath to scan.




Christian Schneider would not like this as the core type converters is
hardcoded, which means there would be package tangle ;)
As those hard coded type converters are in different packages.

    public CorePackageScanClassResolver() {
        converters.add(DomConverter.class);
        converters.add(StaxConverter.class);
        converters.add(StreamSourceConverter.class);
        converters.add(XmlConverter.class);
        converters.add(CamelConverter.class);
        converters.add(CollectionConverter.class);
        converters.add(IOConverter.class);
        converters.add(NIOConverter.class);
        converters.add(ObjectConverter.class);
        converters.add(TimePatternConverter.class);
        converters.add(StreamCacheConverter.class);
        converters.add(BeanConverter.class);
        converters.add(GenericFileConverter.class);
        converters.add(FutureTypeConverter.class);
    }


Likewise we could make camel-spring be able to add to those core type
converters, so we do not have to classpath scanning there as well.
This should cut down testing time as well.


Any thoughts?



-- 
Claus Ibsen
-----------------
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Reply via email to