Re: About 4 method signatures by the ClassResolver API

2013-02-12 Thread Babak Vahdat
ese >> 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? >> &g

Re: About 4 method signatures by the ClassResolver API

2013-02-12 Thread Claus Ibsen
e 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

Re: About 4 method signatures by the ClassResolver API

2013-02-12 Thread Babak Vahdat
;> >> 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*

Re: About 4 method signatures by the ClassResolver API

2013-02-11 Thread Christian Müller
> > 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. > --

Re: About 4 method signatures by the ClassResolver API

2013-02-11 Thread Babak Vahdat
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 th

About 4 method signatures by the ClassResolver API

2013-02-08 Thread Babak Vahdat
tically* 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.