You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2007/05/25 17:08:06 UTC
SwA and JAXB in CXF [was Re: svn commit: r541462....]
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("http://ws-i.org/profiles/basic/1.1/xsd")
!= 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
@XmlAttachmentRef?)
So I think we should stay with #1. If anyone has any better ideas, I'm all
ears.
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, dandiep@apache.org <da...@apache.org> wrote:
>
> Author: dandiep
> Date: Thu May 24 15:33:40 2007
> New Revision: 541462
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=541462
> 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
http://envoisolutions.com | http://netzooid.com/blog
Re: SwA and JAXB in CXF [was Re: svn commit: r541462....]
Posted by Jeff Genender <jg...@apache.org>.
No worries...I bumped us up to 2.0.5. We should be good.
Jeff
Dan Diephouse wrote:
> 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("http://ws-i.org/profiles/basic/1.1/xsd") != 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 @XmlAttachmentRef?)
>
> So I think we should stay with #1. If anyone has any better ideas, I'm
> all ears.
>
> 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.5 for this feature in the future.
>
> - Dan
>
> On 5/24/07, * dandiep@apache.org <ma...@apache.org>*
> <dandiep@apache.org <ma...@apache.org>> wrote:
>
> Author: dandiep
> Date: Thu May 24 15:33:40 2007
> New Revision: 541462
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=541462
> <http://svn.apache.org/viewvc?view=rev&rev=541462>
> 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
> http://envoisolutions.com | http://netzooid.com/blog
Re: SwA and JAXB in CXF [was Re: svn commit: r541462....]
Posted by Jeff Genender <jg...@apache.org>.
No worries...I bumped us up to 2.0.5. We should be good.
Jeff
Dan Diephouse wrote:
> 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("http://ws-i.org/profiles/basic/1.1/xsd") != 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 @XmlAttachmentRef?)
>
> So I think we should stay with #1. If anyone has any better ideas, I'm
> all ears.
>
> 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.5 for this feature in the future.
>
> - Dan
>
> On 5/24/07, * dandiep@apache.org <ma...@apache.org>*
> <dandiep@apache.org <ma...@apache.org>> wrote:
>
> Author: dandiep
> Date: Thu May 24 15:33:40 2007
> New Revision: 541462
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=541462
> <http://svn.apache.org/viewvc?view=rev&rev=541462>
> 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
> http://envoisolutions.com | http://netzooid.com/blog