camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Conceptual 'correctness' of using Camel Unit Tests
Date Fri, 06 May 2011 13:31:00 GMT
Hi

Seems like I am on the right path.

I have implement so the core type converters is always "hardcode" loaded.
And using lazy for unit testing camel-core by default.

That cut time down to about 21-22m.

But there is a big win at camel-spring as well.
I have cut that down from 16m to 10m.




On Fri, May 6, 2011 at 11:02 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> 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: cibsen@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/
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@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/

Mime
View raw message