Batch-719

[pirko]

Hi all,
please can anybody review BATCH-719 issue? We are ready to work on it, but hardly without any review or discussion. Thanks

[Dave Syer]

Lucas has that issue for 2.0.0.M1 so I'll leave him to comment on the JIRA. In general though, we don't like alternate interfaces for core features (e.g. like your ReportingItem*) because they always lead to long if/else chains of instanceof checks in multiple places. It is hard to read and maintain, and basically shows a design problem - lack of encapsulation. We'll try and come up with something better for 2.0, but if you have more ideas, please tell us what you are thinking about and we'll kick them around for a while.

[pirko]

Thanks for reaction. In the last point there - I suggest that it is possible to add that functionality to existing interfaces or (alternatively) create the new ones. So if you don't like alternatives we can discuss to change the core (which was what we try to avoid because of consistency). We are ready to cooporate on this in each case, because for us this is the only thing which is missing in the framework to fit our needs.

[lucasward]

I've been out of the office, but I'm back this week and will review the issue.

[pavel.zupa]

Nice day,
I'm pirko's co-worker participating on implementing batch processes for our system. My boss is really standing on my neck to make us move on. So I've got another possible solution of the reporting problem. I've tried to implement reporting for writers the way we've previously proposed and it would require to rewrite pretty much of core classes:-( It is really not the way. The new solution is that readers would encapsulate the item to ItemContext class of some kind and would return this instead of the original object. The only change to your api is that first-in-chain-readers (eg. FlatFileItemReader) would have to have their "Reporting..." variants and the same for last-in-chain-writers. And I believe there are no other changes to API needed. I personally don't like this solution much because it just seems wrong to me to send context for each item even when it's not wanted (99% of items are expected to be without errors), but i think its feasible and pretty straightforward. ... just another solution while you are reviewing the issue.

Thanks in advance for any progress in this issue.
And again we are eager to help you implement this thing. Just need to know how:-)

[Dave Syer]

The plan is to provide the input line from inside the FieldSet (via a meta data object). That way we don't pollute the existing APIs, and the input line is available only when it is needed.

Your workaround in the meantime is to use the values from the FieldSet and aggregate them back into a line wherever you need it. Only a small amount of pain in the short term really.

[pavel.zupa]

Yes, this maybe a good solution, but what about writers. When I create a domain object in some reader in chain, then folowing readers and writers don't get the field set. I don't like the idea of adding such things as input context info to domain objects. So I'll have to wrap the domain object into some context info object and I'm right where I started. But maybe it's beter than returning the wrapped object from the beginning. Sorry for me being so critic, we've been thinking this really thoroughly and just run out of ideas here:-(

[Dave Syer]

I see what you mean. But as you already said, introducing a new context object that everyone has to see, only for a minority of cases to be able to use it is not really acceptable. Is it so bad to wrap your domain object in your own context holder?

Or you could do what a lot of people do, and just write a listener or reader with an instance variable / bean property that carries the extra information you need (like the original line). Since you are reading from a file it has to be single-threaded anyway, so there is no issue with having a stateful listener.

I think we have some ideas about custom scopes that would help in 2.x. Nothing firm yet, but I expect to be able to annotate handlers using something like the @ModelAttribue annotation from Spring MVC (@ChunkAttribute or @ItemAttribute in your case).

[pavel.zupa]

Looking over my existing implementation again I've found that in fact I don't have a problem anymore. We've been trying to come up with some big idea on how to handle this cleanly and "ideally" and add it to Spring Batch. But this implementation (with wrapping a domain object in context holder) seems to work just fine. The only thing not nice is that I have to cut&paste the FlatFileItemReader and change a couple of lines in read method to be able to throw special exception holding my item context in case of error. Not quite my favourite desing pattern but I think I can live with that:-)
Thanks for all ideas and thanks for splendid framework, I'm looking forward to see new features.