On Fri, Feb 8, 2013 at 11:42 AM, Babak Vahdat
<babak.vah...@swissonline.ch> wrote:
> Hi
>
> Looking at the public ClassResolver API (among others) it provides 4 methods
> taking over the concrete to be loaded Class type:
>
> http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/ClassResolver.html#resolveClass%28java.lang.String,%20java.lang.Class%29
> http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/ClassResolver.html#resolveClass%28java.lang.String,%20java.lang.Class,%20java.lang.ClassLoader%29
> http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/ClassResolver.html#resolveMandatoryClass%28java.lang.String,%20java.lang.Class%29
> http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/ClassResolver.html#resolveMandatoryClass%28java.lang.String,%20java.lang.Class,%20java.lang.ClassLoader%29
>
> 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:
>
> http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Exchange.html#getProperty%28java.lang.String,%20java.lang.Class%29
>
> 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:
> http://camel.465427.n5.nabble.com/About-4-method-signatures-by-the-ClassResolver-API-tp5727207.html
> Sent from the Camel Development mailing list archive at Nabble.com.
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("com.foo.MyFooComponent", Component.class);
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
