Dan Diephouse wrote:
> Hi,
> I am working with the JAXB attachment support and have run into a bit of
> a quandary. When I'm marshalling my JAXB objects, its easy enough to
> pass in my AttachmentMarshaller and receive notification that I have
> attachments. However, that doesn't do me much good as at that point I am
> already in the midst of sending my response. Is there anyone way to
> figure out if there are attachments that need to be written before I
> marshal?
Right. It's a bit of catch-22 situation.
Scanning the whole tree once just to see if there's any binary is
expensive, and we can't do this very nicely today (in short of
marshalling to /dev/null.) But that's an option --- namely, marshal it
once to a dummy OutputStream just to see if you have binary attachment.
Another approach that can be done today is to buffer the marshalling
result until you know if there's an attachment or not. If you do find an
attachment you can stop buffering at that point and do things full
speed. But if your XML is big and attachments aren't often, then this
would slow things down.
The third approach is to always enable the attachment support upfront
(IOW write a MIME envelope for XOP) --- I think this is what JAX-WS RI
is doing.
The fourth approach that requires some changes in the RI is, when we
build a JAXBContext, maybe we can check if a given class may potentially
contain a binary data in its descendants, and give you that information.
Assuming that you are using it for XFire, that would let you say "this
operation has parameters Foo, Bar, and String, and none of them can
contain binary data at all, so let's turn off the attachment". If a tree
can statically contain binary data but it actually didn't then you lose,
but hopefully that's not big enough lose.
Can you think of any other ways to do this better? Do you want the 4th
approach?
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com