cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject SwA and JAXB in CXF [was Re: svn commit: r541462....]
Date Fri, 25 May 2007 15:08:06 GMT
I was just talking to Dan Kulp and he mentioned that my latest commit broke
things for Geronimo because G is using JAXB 2.0.2 yet and this commit
depends on an API in JAXB 2.0.5. We're using this JAXB 2.0.5 feature because
we need a way to detect that there might be an attachment being written. The
problem is that we only know that there is an attachment after JAXB calls
AttachmentMarshaller.addSwaRefAttachment() though, which happens while we're
streaming the output message :-\

Short of caching the whole output message every single time and then
checking if an attachment was written (which would be disastorous to
performance) , the options seem to be:
1. Call JAXBContextImpl.hasSwaRef() which is only in JAXB 2.0.5 - This
checks to see if any classes in the context might have attachment references
that will be written.
2. Check to see if there is the SwA WS-I schema around (i.e. we would write
MIME messages if service.getSchema("")
!= null)

The problem with #2 that I see is that I don't think it works for
"code-first" services. Although to be honest I don't 100% understand how
code first SwAs is supposed to work yet (how do we detect that an operation
argument is supposed to be an attachment? Do users always need to put

So I think we should stay with #1. If anyone has any better ideas, I'm all

I will be changing the code inside CXF today to use reflection. If we deploy
on Java6, then this hasSwaRef method won't be there, so we need to fail in a
more friendly manner for JAXB versions less than 2.0.5. While this may help
the G build breakage today, I would encourage the G team to update to
2.0.5for this feature in the future.

- Dan

On 5/24/07, <> wrote:
> Author: dandiep
> Date: Thu May 24 15:33:40 2007
> New Revision: 541462
> URL:
> Log:
> Get basic SwA working. The SwA tests now ensure that both the swaRef and
> the normal <mime:content> attachment mechanisms work.
> We still need to do the following:
> 1. CXF-677
> 2. Ensure the Content-Types are correct for the messages (i.e. no XOP
> content types)
> 3. Ensure that code first (@XmlAttachmentRef?) attachments are working
> 4. Translate DataHandlers into Images, OctetStreams, etc and vis a versa
> where appropriate.
> Others can feel free to pick up any of these pieces, I'll be plugging away
> at them more
> tomorrow and next week.
Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message