You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2011/11/14 13:10:12 UTC
[DISCUSS] - Fix 2 pain issues with camel-bindy for Camel 2.9
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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [DISCUSS] - Fix 2 pain issues with camel-bindy for Camel 2.9
Posted by Hadrian Zbarcea <hz...@gmail.com>.
+1 on point 1)
+0 on point 2). That's actually as good as List<Object>. The joy of type
erasure.
Hadrian
On 11/14/2011 07:10 AM, Claus Ibsen 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.
>
>
>
RE: [DISCUSS] - Fix 2 pain issues with camel-bindy for Camel 2.9
Posted by Mathieu Lalonde <mr...@live.ca>.
+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.mueller@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 <cl...@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: cibsen@fusesource.com
> > Web: http://fusesource.com
> > Twitter: davsclaus, fusenews
> > Blog: http://davsclaus.blogspot.com/
> > Author of Camel in Action: http://www.manning.com/ibsen/
> >
Re: [DISCUSS] - Fix 2 pain issues with camel-bindy for Camel 2.9
Posted by Christian Müller <ch...@gmail.com>.
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 <cl...@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: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>