camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Thorburn <>
Subject Re: [BINDY[ Adding support for 'fillerWhenNull', parent classes and optional fields for Fixed Length Records?
Date Sat, 11 Aug 2012 03:24:10 GMT
Comments below.

On Fri, Aug 10, 2012 at 9:47 PM, Willem jiang <>wrote:

> It looks like you are planing to do some enhanment on the camel-bindy
> component.
> Please check out my comments in the below email.
> On Thursday, August 2, 2012 at 5:14 PM, Andrew Thorburn wrote:
> > Currently evaluating Camel/Bindy for our needs, and while I've got most
> of
> > the way there, Bindy is simply missing some things that I need. If we
> > decide to go this route (which is looking likely), I will have to modify
> > Bindy to fit our needs, and I'd obviously like to contribute that back.
> > There are a couple of areas where I might have no choice except to fork,
> > given our needs, but we'll see.
> >
> > So, the things I need are:
> >
> > 1) A way to specify that a field should be filled with a particular value
> > when null. e.g. If it's non-null, pad it with spaces, but if it's null,
> > fill with *'s. This is a requirement of an external system we are
> pointing
> > to, so not something we can easily change. This would presumably just be
> > another parameter on the @DataField and @FixedLengthRecord annotations?
> > Applying it to fields with a primitive type should generate an error or
> > warning or something. I don't believe Bindy (or any other solution
> included
> > with Camel) currently supports this.
> Current camel-bindy@DataField supports to set the default value. I don't
> know what kind of error you get when you try to use it.

That could work, but having to define every single field to have a default
value of that field's length's worth of "@"s is not exactly ideal (that is,
for a field of length 5, the default value would be "@@@@@" in my case).
But yes, that could work, assuming that FixedLengthRecords support Optional

> >
> > 2) Support for parent classes. What I mean by this is that, in order to
> > keep the size of the classes down (they're already pretty big), we'd be
> > storing fields common to all records in a super-class. These fields
> should
> > be read first (they are *not* a header - they're just the first 138
> > characters of a record), and the content of the sub class would come
> after
> > these 138 common bytes. Would this be something that Camel/Bindy would
> > accept? Or does it already work, and I'm just blind? I'm open to hearing
> > about other ways to do this too - this is just the first one that leapt
> to
> > mind.
> It could be interesting requirement. I just have a quick look at the
> camel-bindy component, it just looks up the declared fields for @DataField,
> so it doesn't support the parent classes you want.
> For you proposal, It could better to have a fix header, and child class
> cannot override the parent class' field.

Well, remember that this is *not* a header, as far as I understand how the
term is normally used, but more like a prefix. But yes, it would the case
that the child class would only add fields, not override / replace them.

> >
> > 3) The common fields discussed in (2) are sometimes the only fields that
> > are returned, which is awkward. That is, assuming that common+specific is
> > 1138 bytes, we can receive back either 1138 *or* 138 bytes. This only
> > occurs if there is an error on the other end, and the information about
> the
> > error is returned in the common 138 bytes. It won't ever return something
> > that is in a different format to what we're expecting, it's just that it
> > might not send back all the data that's expected. This is the only area
> > where I could see us having to fork Bindy, as it would be pretty specific
> > to us as to exactly what is an error and what is not for determining
> > whether it's OK that we only received back 138 bytes.
> Maybe we can consider to borrow some idea of abstract class, and introduce
> some kind of annotation to camel-bindy component, it will throw exception
> when it just receive 138 bytes as it is just for the abstract class. We
> cannot create a instance of the abstract class.

I think you misunderstand slightly. It is sometimes valid for me to receive
138 bytes, and sometimes it is valid to receive 1138 bytes, and I can't
know in advance which will be sent back. I know it will be one of the two,
but not *which* of the two. As such, throwing an exception isn't very
helpful since I need those 138 bytes mapped to a class... I hope that makes
it a bit clearer?

> >
> > The reason for going with Bindy is that, being Annotation-driven, it's a
> > *lot* less stuff that we need to keep around compared to BeanIO and all
> its
> > XML (or whatever other solutions require).
> >
> > So, any thoughts on whether the above is appropriate for Bindy or not?
> >
> > Thanks,
> >
> > - Andrew Thorburn
> Just my 2 cents.
> --
> Willem Jiang
> FuseSource
> Web: (
> Blog: (
> (English)
> ( (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang


- Andrew Thorburn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message