Ah, that makes sense. It does seem to create potential problems, though,
since it relies on the data magically appearing in the byte[] (or in the
case of an unknown size, the byte[] object itself magically appearing)
sometime after the initial unmarshalling. With an DataHandler you can at
least control access to the attachment data with internal hooks.
Is the idea that this will always be populated by the time the
unmarshalling is completed? In other words, the code unmarshals the
document and then processes all attachments, caching them on the file
system if necessary.
- Dennis
Kohsuke Kawaguchi wrote:
Dennis Sosnoski wrote:
Though now that I think about it, I wonder how the
getAttachmentAsByteArray() is handled, given that I'd think this
would be called during unmarshalling - is there buffering of the
input stream going on? Kohsuke, can you comment on this?
This method is intended to be used when the data binding layer knows
that the data is eventually transformed into byte[].
Often the code that implements AttachmentUnmarshaller knows the exact
size of the attachment (such is often the case with MIME attachments),
and if so, byte[] can be created rather efficiently (compared to have
the data binding layer try to build byte[] from DataHandler.)
If not, then most likely you'll have to read InputStream and create
byte[] with reallocation of byte[] to get to the exact size, but
that's no worse than what the data binding layer would have done if
this method didn't exist.
So that's how it's used.
