Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Tue, 12 Feb 2013 03:47:42 -0800 (PST)
From: Babak Vahdat <babak.vahdat@swissonline.ch>
To: dev@camel.apache.org
Message-ID: <1360669662826-5727423.post@n5.nabble.com>
In-Reply-To: 
 <CAGB5yN=QLZ4gd+wY16JiA4mJ+hNtLyCjg6e05NGVkHr_iSzChw@mail.gmail.com>
References: <1360320138019-5727207.post@n5.nabble.com>
 <CAGB5yN=QLZ4gd+wY16JiA4mJ+hNtLyCjg6e05NGVkHr_iSzChw@mail.gmail.com>
Subject: Re: About 4 method signatures by the ClassResolver API
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes but then I think in Camel 3.0 we should better update the Javadoc of this
contract and restrict the usage through adding a check for the passed class
object which would guranntee a correct API usage:

  if (!clazz.isInterface()) {
     throw ...
  }

To avoid the illusion for the end user the class being dynamically loaded.
As far as I remember currently non of this interface implementations does
this check.

Babak


Claus Ibsen-2 wrote
> On Fri, Feb 8, 2013 at 11:42 AM, Babak Vahdat
> &lt;

> babak.vahdat@

> &gt; 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: 

> cibsen@

> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen


--
View this message in context: http://camel.465427.n5.nabble.com/About-4-method-signatures-by-the-ClassResolver-API-tp5727207p5727423.html
Sent from the Camel Development mailing list archive at Nabble.com.