This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.To start at the beginning, follow the link to the first post.This series is also available as a podcast on iTunes, Google Play, Stitcher, or use the link to the RSS feed.
A few weeks ago we talked about a proposed update to the batch specification that would make the writer optional. Sometimes you just don’t need one. In the absence of that update, what do you do? Well, you create a dummy or no-op writer that implements the interface but doesn’t do anything. If this sort of thing happens to you a lot, you’ll hopefully not go creating a dozen no-op writers that are all pretty much the same. Not that it will require a lot of maintenance, of course, but it just feels sloppy to have a bunch of these useless things lying around. And if you’re going to have your own sort of standard no-op writer, why not just use one somebody else wrote that exists in open source?
And thus, the Apache BatchEE NoopItemWriter. It implements the ItemWriter interface, but does absolutely nothing. Enjoy.
Well, ok, but what if you don’t really NEED to write the results of the processing anywhere, but you might like to know what they were anyway. Maybe just during testing. The ItemProcessor does all the stuff that needs doing, but it does return something. Maybe some indication of how processing went or something like that. Not part of the results and not something you need to keep around when the job is in production, but maybe a nice verification things are going as planned. And maybe something to tuck in that you could turn on dynamically in case there are problems (what? Problems in a production batch job? Say it ain’t so!)
Well, for that sort of thing you should have a look at the MockItemWriter provided by JBeret. By default it does a println of a toString of the objects to write. But you can disable that from an injected parameter so it does nothing at all.
You can also configure it to write the objects into a specified file (again using toString on the object). That may or may not be better than writing into the log depending on your environment.
And finally, you can provide a class and a List attribute of that class and MockItemWriter will add the objects to write into the list. You could have a listener that gets control after each chunk or at the end of the step and looks through the contents of the list and flags anything that looks odd.
Since all this behavior is optional, you can have the job set up to do none of this by default, but easily use job parameters to turn it on if you need it.
And there you have it…a blog post about code that does nothing.