It's not sufficient since the encoder would need both appending and fileSize to decide whether or not to create header or footer. It is not a simple boolean decision. It would also couple the general Encoder interface to the specific FileAppender/OutputStreamAppender, at least implicitly by means of the concepts appending and fileSize. This isn't necessary or helpful. Further, I assume that this init method would have to be called in the appenders (I assume). So they would already have to include logic to decide about the values to be given to the init method. They could instead use that information to simply decide whether or not to actually call headerBytes()/footerBytes() methods at all. I think the Encoder interface is fine as it is if you interpret its headerBytes()/footerBytes() methods as unconditional "these would be the bytes if you are actually interested in them" methods. I'd suggest to instead make the encoderInit and encoderClose methods in OutputStreamAppender protected and overwrite the current implementation in FileAppender (that already knows about the concept of "appending") as described:
Nothing special would need to be done in case of append=false:
- write header (if available) when the appender is started
- write events
- write footer (if available) when the appender is stopped.
In case of append=true, behavior would have to be different, though:
- write header when the appender is started, but only if the file was still empty, otherwise do nothing
- write events
- do nothing when the appender is stopped, i.e. don't write the footer!
This would be relatively trivial for FileAppender and I think (from a first glance) that RollingFileAppender would probably "just work". |