camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: About 4 method signatures by the ClassResolver API
Date Tue, 12 Feb 2013 10:18:44 GMT
On Fri, Feb 8, 2013 at 11:42 AM, Babak Vahdat
<> wrote:
> Hi
> Looking at the public ClassResolver API (among others) it provides 4 methods
> taking over the concrete to be loaded Class type:
> However referencing the to be loaded Class type in this way would make the
> given Class object to be already loaded statically through the JVM itself
> :-) so that as soon as the actual parameters are put on the call stack for
> these methods the concrete Class object is already loaded even *before*
> these methods return!
> I think originally the idea behind these methods was to avoid a need to
> (explicitly) type cast for the caller, e.g. like the following method we've
> got by the Exchange interface:
> However in case of the ClassResolver API the same doesn't make much sense
> (correct me if I'm wrong) so IMHO we should better @deprecate these methods
> and remove them in 3.0 because the idea behind the ClassResolver API is to
> *dynamically* load the classes, however using these methods make the given
> classes already being *statically* loaded.
> Thoughts?
> Babak
> --
> View this message in context:
> Sent from the Camel Development mailing list archive at

You may ask for an implementation of a class, and expect it to return
back its interface.
And hence why these methods can make sense.

Component foo = resolveClass("", Component.class);

Claus Ibsen
Red Hat, Inc.
FuseSource is now part of Red Hat
Twitter: davsclaus
Author of Camel in Action:

View raw message