Here is the current plan:
Attachments should return DataHandler instances that expose an interface similar to the StreamingDataHandler class used in the JAX-WS reference implementation, in particular the following method:
This would allow application code to request the attachment to be streamed. This would also be used when an MTOM message is serialized using serializeAndConsume. In all other cases (access using the standard DataHandler methods; multiple attachments that are not accessed sequentially), the attachment would be buffered so that streaming unaware application code will continue to work as usual. It also means that streaming doesn't require any additional configuration.
In principle this is almost trivial to implement. However, there are a couple of constraints related to existing code that need to be taken into account:
- Axiom already defines various custom DataHandler and DataSource implementations/extensions such as CachedFileDataSource and DataHandlerExt. We need to make sure that we continue to support them if we determine that they are still necessary.
- All accesses to temporary files happen through LifecycleManager/FileAccessor. FileAccessor currently also acts as a factory for DataHandler objects for attachments buffered on disk. This is a problem because we need to create DataHandler instances that support streaming, but streaming is not a concern of FileAccessor.
For most of the code related to these classes, unit test coverage is insufficient or non existing (in particular for the changes in
AXIOM-269) [We should forbid committing any code not covered by unit tests :-(]. Therefore we first need to write a couple of unit tests that allow us to ensure non regression for the features we want to preserve.
Note that the solution is suboptimal (but works) in the following scenarios (where Sadeep's patch would simply fail):
- MTOM + data binding + multiple attachments: only the last attachment can be streamed because the data binding requests all DataHandler objects before invoking the service, which means that all attachments except the last one will be buffered
- forwarding an MTOM message where the attachments are in a different order than the xop:Include elements referencing them: in this case, the order in which the serializer requests the data handlers doesn't allow streaming of all attachments