+1 for both.
2) Makes Bindy a lot more pleasant to use.
Cheers,
Mathieu
----------------------------------------
> Date: Wed, 16 Nov 2011 12:40:06 -0800
> Subject: Re: [DISCUSS] - Fix 2 pain issues with camel-bindy for Camel 2.9
> From: christian.muel...@gmail.com
> To: dev@camel.apache.org
>
> I'm +1 for both.
>
> 1) This make sense and it's an easy migration path for our users.
> 2) I share your opinion that this code looks clumsy. And this change can
> also be easily adopted by our users.
>
> But I didn't want see this change back ported into the camel-2.7.x or
> camel-2.8.x branch, because it breaks backwards compatibility. But I think
> this is clear for all of us...
>
> Best,
> Christian
>
> On Mon, Nov 14, 2011 at 4:10 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
>
> > Hi
> >
> > There are two pain issues I see we have with camel-bindy that I would
> > like to address. However as at least 1 of them is non backwards
> > compatible, we have previously targeted that for Camel 3.0. But that
> > was back in the start of the year when Camel 3.0 was more around the
> > corner.
> >
> > Now that Camel 2.9 is a sort of big release I would suggest to move
> > the following two improvements forward to be fixed for Camel 2.9.0.
> >
> > 1)
> > The bindy data format, requires you to define a package name, where
> > bindy will then scan recursively in the package for any bindy model
> > classes (eg annotated with eg @CsvRecord etc.).
> >
> > The problem is that this doesn't work well as you cannot have 2+ model
> > classes in the same package + sub packages.
> > As you cannot explicit define that you marshal to XXX class.
> >
> > So I suggest to remove the package name, and mandate the end user to
> > specify a class type
> >
> > For example to marshal to a Car class
> > .marshal().bindy(Car.class)
> >
> > Then you can have 2+ model in the same package,
> > .marshal().bindy(Train.class)
> > .marshal().bindy(Plane.class)
> >
> >
> > 2)
> > The output of the unmarshal operation is also confusing, as its a
> > List<Map<String, Object>>
> > The List is okay as that would be an entry for each entry. However the
> > Map represents a row.
> >
> > So I suggest to make it simpler and what end users would expect
> > List<T>
> > Where T is the class type, such as List<Car>, List<Train> etc.
> >
> > For example from an unit test where my T is WheatherModel I need this ugly
> > code
> >
> >
> > Map map = (Map)
> > mock.getReceivedExchanges().get(0).getIn().getBody(List.class).get(0);
> > WeatherModel model = (WeatherModel) map.values().iterator().next();
> >
> > assertEquals(123, model.getId());
> > assertEquals("Wednesday November 9 2011", model.getDate());
> > assertEquals("Central California", model.getPlace());
> >
> > Instead of just
> >
> > WeatherModel model = (WeatherModel)
> > mock.getReceivedExchanges().get(0).getIn().getBody(List.class).get(0);
> >
> >
> > We have a number of JIRA tickets and end users mailings on the @user
> > about issues with Bindy.
> > I think if we address these 1+2 here we solve the two major pain
> > points people have when getting started with Bindy.
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > FuseSource
> > Email: cib...@fusesource.com
> > Web: http://fusesource.com
> > Twitter: davsclaus, fusenews
> > Blog: http://davsclaus.blogspot.com/
> > Author of Camel in Action: http://www.manning.com/ibsen/
> >
