Bump... Anyone out there got any thoughts on this? Thanks,
- Andrew Thorburn On Thu, Aug 2, 2012 at 9:14 PM, Andrew Thorburn <nzi...@gmail.com> 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. > > 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 >
