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. > > 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. > > 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. > > 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: http://www.fusesource.com (http://www.fusesource.com/) Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: willemjiang
