Comments below. On Fri, Aug 10, 2012 at 9:47 PM, Willem jiang <willem.ji...@gmail.com>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 Fields. > > > > 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: 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 > Thanks, - Andrew Thorburn
