+1. I'd also like us to make this dependency upgrade ASAP; then we can work on the longer term changes to Camel at a slower pace & not be faced with dual-patching pain (back porting to slf4j and commons-logging in parallel etc).
On 24 January 2011 14:49, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > > > On Mon, Jan 24, 2011 at 3:29 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: >> Hi, >> >> Camel-2.6.0 is being build while I write this. One of the things that was >> informally discussed and I am formally proposing now is dropping support for >> java 1.5 starting with the next release. It hasn't been supported for a >> while and the survey showed almost no interest in it. >> >> If needed (which I personally doubt), we could have 2.6.x releases on java >> 1.5. Other Apache projects already dropped support for java 1.x on trunk as >> well. >> >> Thoughts? >> >> Hadrian > > Yeah I think its a good time to discuss this, now that Camel 2.6 is one its > way. > > We had the Camel 3.0 roadmap outlined here > http://camel.apache.org/camel-30-roadmap.html > > > In light of this I would like to propose the idea of moving some of > the todo's from the Camel 3.0 roadmap into Camel 2.7, specifically: > - switching to slf4j as logger > - upgrading to jdk 1.6 as minimum > - upgrading to spring 3.0 as minimum > > > The reason for this is that many enterprise companies is asking for > this move. They are not using JDK 1.5 at all. They want to leverage > some of the new stuff in Spring 3. And most importantly they want to > use MDC with the logger (http://logback.qos.ch/manual/mdc.html). > Switching to slf4j allows us to offer MDC capabilities. Not only with > Apache Camel but also with some of the related Apache projects such as > ActiveMQ, ServiceMix and possibly CXF. ActiveMQ and SMX will switch to > using sfl4j in their next major releases (ActiveMQ 5.5, ServiceMix > 4.4). Also ActiveMQ 5.5 is upgrading to JDK 1.6 / spring 3.0 as > minimum. > > What the MDC then allows enterprise companies is to much better > correlate and trace messages as they are being processed, not only > within Camel itself, but also between the projects. That allows you to > much better diagnose and visualize what's going on with the messages. > See more details at: http://logback.qos.ch/manual/mdc.html. > > > If we agree upon this we can implement this in Camel 2.7.0 in the next > release cycle (3 months). > > > And if we are concerned about JDK 1.5 / spring 2.x users we can keep > Camel 2.6.0 as a branch and merge important bug fixes to this branch. > And thus be able to release a patch releases (2.6.1, 2.6.2 and so on) > at Apache? > > > That allows us in the longer run to plan for Camel 3.0 and do the > architectural refactorings that Christian have suggested. > http://camel.465427.n5.nabble.com/Some-thoughts-about-the-architecture-of-camel-td3217183.html > > As well as implement the performance optimizations in the routing > engine, which may entail a slight API chance / behavior on the EIPs > and Exchange. And some of the other improvements we have listed on the > roadmap. > > That kind of work requires longer time to do. > > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ > -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration
