As it does not make any effective difference, I've removed final for consistency across components.
Thx, Luca --- Luca Burgazzoli On Tue, May 10, 2016 at 5:51 PM, Matt Sicker <boa...@gmail.com> wrote: > I personally wouldn't extend it (I use camel-hazelcast for caching), but > I'm just looking at consistency with the rest of the camel components. Do > you think more components should follow this pattern, or is the ehcache one > an exception? > > On 10 May 2016 at 10:17, Luca Burgazzoli <lburgazz...@gmail.com> wrote: > >> Yep, I've added it to enforce the idea that the producer/consumer are >> not supposed to be extended (imho, the should also be package private) >> but no problem to remove them, could you raise a JIRA if you think >> final should be removed ? >> --- >> Luca Burgazzoli >> >> >> On Tue, May 10, 2016 at 5:02 PM, Matt Sicker <boa...@gmail.com> wrote: >> > Not necessarily, but I don't see other components using final like that. >> > >> > On 10 May 2016 at 09:19, Luca Burgazzoli <lburgazz...@gmail.com> wrote: >> > >> >> Not mandatory but are component's consumer/producer supposed to be >> >> extended ? >> >> --- >> >> Luca Burgazzoli >> >> >> >> >> >> On Tue, May 10, 2016 at 4:05 PM, Matt Sicker <boa...@gmail.com> wrote: >> >> > Do EhcacheConsumer and EhcacheProducer have to be final? >> >> > >> >> > On 10 May 2016 at 08:18, Luca Burgazzoli <lburgazz...@gmail.com> >> wrote: >> >> > >> >> >> Hello, >> >> >> >> >> >> I've merged a first cut of camel-ehcache >> >> >> ( >> >> >> >> >> >> https://github.com/apache/camel/commit/9a473f3980f679b62a22fc6a191b54164ad38001 >> >> >> ) >> >> >> Let me know if you find something wrong or that could be improved. >> >> >> >> >> >> >> >> >> --- >> >> >> Luca Burgazzoli >> >> >> >> >> >> >> >> >> On Wed, Apr 20, 2016 at 7:52 AM, Andrea Cosentino >> >> >> <ancosen1...@yahoo.com.invalid> wrote: >> >> >> > +1 :-) >> >> >> > -- >> >> >> > Andrea Cosentino >> >> >> > ---------------------------------- >> >> >> > Apache Camel PMC Member >> >> >> > Apache Karaf Committer >> >> >> > Apache Servicemix Committer >> >> >> > Email: ancosen1...@yahoo.com >> >> >> > Twitter: @oscerd2 >> >> >> > Github: oscerd >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Wednesday, April 20, 2016 7:41 AM, Luca Burgazzoli < >> >> >> lburgazz...@gmail.com> wrote: >> >> >> > Yep, that was one of the main reasons :-) >> >> >> > --- >> >> >> > Luca Burgazzoli >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Tue, Apr 19, 2016 at 11:10 PM, Bilgin Ibryam <bibr...@gmail.com >> > >> >> >> wrote: >> >> >> >> Good idea. Also may be we should name the component this time >> ehcache >> >> >> >> rather than just cache as we have many cache implementations. >> >> >> >> >> >> >> >> On 19 April 2016 at 17:17, Claus Ibsen <claus.ib...@gmail.com> >> >> wrote: >> >> >> >>> On Tue, Apr 19, 2016 at 5:42 PM, Luca Burgazzoli < >> >> >> lburgazz...@gmail.com> wrote: >> >> >> >>>> Hello, >> >> >> >>>> >> >> >> >>>> As Ehcache has released version 3.0 of their caching solution >> >> >> >>>> (http://www.ehcache.org/) it may make sense to make a new >> >> component >> >> >> >>>> camel-ehcache and deprecating the old camel-cache component. >> >> >> >>>> >> >> >> >>>> Thoughts ? >> >> >> >>>> >> >> >> >>> >> >> >> >>> Yeah that is a good idea. >> >> >> >>> >> >> >> >>>> >> >> >> >>>> --- >> >> >> >>>> Luca Burgazzoli >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> -- >> >> >> >>> Claus Ibsen >> >> >> >>> ----------------- >> >> >> >>> http://davsclaus.com @davsclaus >> >> >> >>> Camel in Action 2: https://www.manning.com/ibsen2 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Bilgin Ibryam >> >> >> >> Camel Committer at ASF & Integration Architect at Red Hat >> >> >> >> Blog: http://ofbizian.com | Twitter: @bibryam >> >> >> >> >> >> >> >> Camel Design Patterns https://leanpub.com/camel-design-patterns >> >> >> >> Instant Apache Camel Message Routing >> >> >> http://www.amazon.com/dp/1783283475 >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Matt Sicker <boa...@gmail.com> >> >> >> > >> > >> > >> > -- >> > Matt Sicker <boa...@gmail.com> >> > > > > -- > Matt Sicker <boa...@gmail.com>
