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/
>
