Hi
Please see comments inline.
----- Original Message -----
From: "fahman_dude" <[email protected]>
To: <[email protected]>
Sent: Wednesday, February 24, 2010 1:59 PM
Subject: Re: no-annotations RESTfull webservice - a complex use case
Hello,
we have moved the detailed discussion into private convo with Sergey, but
for the record or for those of you who might check thisthread later on, here
is an update:
I have implemented both of Sergeys suggestions but, alas, the parameter
mapping still does not work for me. What I did is this:
1. I am setting now the JAXBElementProvider for the JAXRSServer and setting
its UnmarshallAsJaxbElement property to true;
2. I manually added @Multipart("...") annotations to the parameters of the
JAXB generated Webservice interface;
3. I am creating now two Parts for msgCtx and emailMessage and posting them
over by means of httpclient.
S.B : any chance you can actually show how the message looks like on the wire ? See, the previous message your were sending was not
valid
Unfortunatelly I still get NullPointerException for parameters thus the
param-mapping does not work for me even with the @Multipart hack.
S.B : couple of comments here. First using @Multipart is not a hack - what makes you think it is the one ? You're about to have a
plain HTTP-based multipart request being processed.
Second, hope you realize the info you've provided does not give me a slightest
clue what is happening ?
Please, give me the info. As I said, I'm committed to making things work for
cases like the one you're working upon,
just haven't had a time to investigate yet.
By the way, just would like to clarify one thing : the issue we're dealing with
has nothing to do with the
no-annotations feature. Rather, we're trying to make sure that the same service can have both SOAP-based and plain multipart
requests being processed and eventually the data being handled by JAXB such that the same signature can be reused. The steps 1-3
should lead to uncompressed muitparts being deserialized properly (no 1-3 steps will be required if you don't have the code with
unwrapped signatures generated). It won't work at the moment for MTOM-based parts and I may have a look into supporting MTOM too
given that it's not strictly speaking SOAP-based. Alternatively, building a proper multipart/form-data request would do but in this
case it is unlikely you'll be able to preserve the same signature
cheers, Sergey
cheers
Reinis
Sergey Beryozkin-2 wrote:
<snip/>
S.B : ok, thanks... So ServiceMessageContext and EmailMessage are just
@XmlType(s)...See, JAXRS does not really like multiple
request parameters referring to request bodies (as in sendEmail) thus CXF
JAXRS does not unwrap the way CXF JAXWS does (which is
very JAXWS compliant) but here we're dealing with a multipart request so
even thought it is not standardized in JAXRS, it makes
sense to refer to individual parts through the use of multiple parameters.
But the problem is that ServiceMessageContext and
EmailMessage have no @XmlRootElement - I think you can just register a
JAXRS JAXBElementProvider and set an 'unmarshalAsJaxbElement'
property on it and it should fix the JAXB-related issue...
<snip/>
S.B. Next, given that CXF JAXRS does not unwrap (well, at the moment at
least), one needs to 'attach' @Multipart annotations to
individual method parameters for the MultipartProvider to figure out which
part needs be deserialized. Given that you've chosen to
use a user model this may seem like a step back but lets just make it work
and then I can look at extending the model support... So
now we have :
sendEmail(@Multipart("context") ServiceMessageContext ctx,
@Multipart("email") EmailMessage message)
<snip/>
S.B : In meantime, please ensure you have two parts, the above fragment
just uses a single part but a real multipart/form-data
would have one part containing a service context, the other one containing
the body with this second body part containing
embedded/recursive parts, one per every email attachment. You probably
just do not need this kind of complexity (yet), just create a
multipart/mixed or may be multipart/related (and update @Produces) request
containing two parts, one will 'hold' the context another
one an email message including the binary content.
<snip/>
View this message in context:
http://old.nabble.com/no-annotations-RESTfull-webservice---a-complex-use-case-tp27685209p27686868.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
View this message in context:
http://old.nabble.com/no-annotations-RESTfull-webservice---a-complex-use-case-tp27685209p27714207.html
Sent from the cxf-user mailing list archive at Nabble.com.
