Mailing-List: contact camel-dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com
 designates 209.85.162.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tkIqFY8w8m8+1XBediS8SUTGgX8YvgbuDP8bgoIlxugRQROh6AepsZMY8HgtcjIPLnM3QqtcE/9OKq3exPZ9LPXUxqI7Zv2F2k7+e78T+R1XSRAx762yqsv/77Y9LZkc27AmMC8vm4eSurm3bpX9XKrk3X/KItkzTH/iE9v1+AY=
Message-ID: <ec6e67fd0804040149y29ed4d1ahebf800d0809e6ff1@mail.gmail.com>
Date: Fri, 4 Apr 2008 09:49:15 +0100
From: "James Strachan" <james.strachan@gmail.com>
To: camel-dev@activemq.apache.org
Subject: Re: [VOTE] Release Apache Camel 1.3.0 (RC4)
In-Reply-To: <b23ecedc0804040104j276c8e2u38ea75329ffbec6d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <ec6e67fd0803312158g32b07ca0wc7973817acbbf100@mail.gmail.com>
	 <16487404.post@talk.nabble.com>
	 <b23ecedc0804040104j276c8e2u38ea75329ffbec6d@mail.gmail.com>

Agreed; lets get something out how, then do 1.3.1 real soon

On 04/04/2008, Guillaume Nodet <gnodet@gmail.com> wrote:
> Well, the vote is already started for the other RC.  I think we *really*
>  need a 1.3.0 of Camel asap and imho, non blocking bugs can be fixed in
>  further bug fix release: I really suggest we release more frequently to
>  avoid such problems.     What about  we do a bug fix release in a few weeks
>  if needed ?  Claus, wanna volunteer as the release manager for 1.3.1 ?
>
>
>  On Fri, Apr 4, 2008 at 9:49 AM, davsclaus <cib_rejse@yahoo.dk> wrote:
>
>  >
>  > I am assuming we are building a new RC for the 1.3 release?>  >
>  > In that respect we have a bug CAMEL-410 that I would like to get fixed and
>  > included. I got the bug nailed down but want to polish and improve the
>  > unit
>  > tests before committing. I anticipate that I will be done at the end of
>  > the
>  > weekend at the latest.
>  >
>  > The bug is basically if you configure Camel to use 2 or more exception
>  > handlers, then Camel could potentially pick the worst candidate for
>  > handling
>  > the thrown exception. By that I mean eg. a top level
>  > .exception(Exception.class) instead of a user specific exception such as
>  > .exception(MyBusinessException.class).
>  >
>  > I am introducing a strategy to resolve which is the best exception type to
>  > handle the thrown exception in questions. The default strategy will be to
>  > use the exception that is the closets match to the thrown exception.
>  >
>  > eg. java.net.ConnectionException will match java.io.IOException
>  > eg. CamelExchangeException will match CamelException
>  > eg. MyBusinessException will match MyBaseBusinessException
>  > eg. NullPointerException will match Exception
>  >
>  > Well you might get the picture.
>  >
>  > A different strategy could be to use the ordering of how the exceptions
>  > was
>  > configured. Use the fist match that can handle it etc (top-down).
>  >
>  > /Claus
>  > --
>  > View this message in context:
>  > http://www.nabble.com/-VOTE--Release-Apache-Camel-1.3.0-%28RC4%29-tp16414633s22882p16487404.html
>  > Sent from the Camel - Development mailing list archive at Nabble.com.
>  >
>  >
>
>
>
> --
>  Cheers,
>  Guillaume Nodet
>  ------------------------
>  Blog: http://gnodet.blogspot.com/
>


-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com