solution:
after a few emails with Daniel Kulp he determined that
writeTo() is only being called when MTOM is enabled.
Which is what I really wanted, I just didn't have it
configured right. Without MTOM it is handled by JAXB
and therefore out of the control of the CXF developers.
However, the code below will work either with or without MTOM:
public DataHandler getObjectsAsAttachment(...) ... {
try {
final File tempFile = ...;
FileDataSource ds = new FileDataSource(tempFile) {
@Override
public InputStream getInputStream() throws IOException {
return new FileInputStream(tempFile) {
@Override
public void close() throws IOException {
super.close();
tempFile.delete();
}
};
}
};
return new DataHandler(ds);
} catch (Exception e) {
...
}
}
Note: close is also called when FileInputStream is
finalized by the garbage collector, and I also called
tempFile.deleteOnExit(), so I am not bothering to try
to cleanup the file in the catch block.
Thanks for your help.
- Dan
On Friday 05 December 2008 3:22 pm Daniel Kulp wrote:
>
> On Thursday 04 December 2008 7:21:36 pm Daniel Lipofsky wrote:
> > Are those changes in 2.1.3 or are they unreleased?
> > I upgraded to 2.1.3, and using the code below I can
> > see that it is not calling either writeTo() or
> > getInputStream() on the DataHandler. It is calling
> > getInputStream() on the DataSource. I see output from
> > the first 2 log calls but not any of the others.
>
> Interesting. Anychance you could put a Thread.dumpStack() in there
> and let me know where that's being called?
>
> The AttachmentOut stuff calls writeTo, but it's possible one of the
> other interceptors is remapping things someplace.
>
> > Also, do you think this code below is acceptable.
> > Notice I am NOT calling super on getInputStream().
> > This is because I wanted to create my own InputStream
> > rather than wrap the one that was returned by super.
> > Do you see any problems? (it works)
>
> Yea, that's fine and probably preferable since if we do take the
> DataSource out of the DataHandler, it would still work.
>
> Dan
