camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian M├╝ller <christian.muel...@gmail.com>
Subject Re: About 4 method signatures by the ClassResolver API
Date Mon, 11 Feb 2013 22:47:43 GMT
+1
I see your point. Doesn't make sense to me too.

Best,
Christian

On Fri, Feb 8, 2013 at 11:42 AM, Babak Vahdat
<babak.vahdat@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.
>



--

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message