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