How to access formatted output of a writer

[raysuliteanu]

I am using FlatFileItemWriter. What I'd like to do is be able to get at the formatted string in write() that results from calling lineAggregator.aggregate(). However, I can't seem to find a way of doing that. ItemWriteListener is given the original object. FlatFileItemWriter itself is not designed for subclassing - lineAggregator is private, fieldSetCreator is private, state is private.

Any suggestions?

Thanks.

[lucasward]

I'm curious what the use case is?

You can always proxy the LineAggregator.

[raysuliteanu]

Thanks.

Basically I want to attach the formatted string back onto the original object which I later persist into a db, so that I have a record of what I generated since the generated flat file is sent to someone outside my organization. I can of course keep the whole file, but I'd like to have it object by object so I have easy programmatic access.

[raysuliteanu]

Intercepting the line aggregator unfortunately doesn't let me do what I need because I don't have access to the current object at that point - all you get is the field set.

What I'd really like is if FlatFileItemWriter was designed to be subclassed since it would be so much easier to do what I need (without having to do double transformation) ...

public class MyFlatFileItemWriter extends FlatFileItemWriter {
    public void write(Object data) throws Exception {
        FieldSet fieldSet = fieldSetCreator.mapItem(data);
        String line = lineAggregator.aggregate(fieldSet);

        ((MyObject) data).setTransformedData(line);

        lineBuffer.add(line + LINE_SEPARATOR);
    }
}

[lucasward]

You're right, you would have to make the aggregator stateful so you could pull the last line it gave from your proxy. It's a little ugly, but its a workaround.

I don't really like the idea of making ItemReaders and ItemWriters designed for inheritance. It's been requested in for a couple of others scenarios, but was generally only necessary to workaround a bug, not because it truly needed to be subclassed. Or, as in your case, it's a very big corner case. What you're trying to do is very far from optimal. I understand the situation you're likely put in, as I have been there before. However, there are some pretty large consequences to designing these classes to be subclassed that I would like to avoid. There would need to be some pretty strong use cases that require subclassing to change my mind. Having said that, I consider myself and the other committers on Spring Batch to be very open minded, and welcome any opposing viewpoints. (Although, it really does help if there are solid use cases that can't be solved better some other way)

In the case of the FlatFileItemWriter, it may be a good idea to potentially offer a write method outside of the ItemWriter interface, that takes a String instead of an object. I can think of a few use cases where someone might just want to write a string to a file, but still wants transactional control and restart without having to code it from scratch. This solution would solve your issue as well. In general we have tried to maintain symmetry between the ItemReader and ItemWriter interfaces, but I see no reason why it can't be stretched to also have an interface such as StringWriter that extends ItemWriter. I'm thinking out loud a bit here, but it's one possible solution that in my mind would be much better than designing the writer for inheritance.

[Dave Syer]

I think this is a good use case for ItemTransformer. If you write a transformer that does the fieldset creation and aggregation, and then enhances and saves the domain object, it only has to pass the String (line) on to a normal FlatFileItemWriter with a passthru mapping to get all the restartability and transactional benefits.

[lucasward]

I think you're right Dave, I forgot about using a passthrough. That's a much better solution that doesn't require a workaround.