Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Wed, 21 Dec 2011 00:55:30 +0000 (UTC)
From: "Benson Margulies (Commented) (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: 
 <1863553764.33468.1324428930633.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <512062194.30638.1324386211264.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CXF-3987) incompatible change in JAX-RS from
 2.5.0 to 2.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173702#comment-13173702 ] 

Benson Margulies commented on CXF-3987:
---------------------------------------

Sergey,

I think that the issue here is the client side. Absolutely none of the constructors for Attachment build something that corresponds to what a browser does. The documented examples on the client side don't work.

Though, breaking working clients in a double-point release might be a cause for concern.

I'll add a constructor or a factory for Attachment.

--benson

                
> incompatible change in JAX-RS from 2.5.0 to 2.5.1
> -------------------------------------------------
>
>                 Key: CXF-3987
>                 URL: https://issues.apache.org/jira/browse/CXF-3987
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.5.1
>            Reporter: Benson Margulies
>
> One of my multipart tests is now failing with a 400. The 400 is thrown from FormUtils in the runtime. It runs just fine in 2.5.0.
> My function looks like:
> {code}
>     @Produces("text/html")
>     @Consumes("multipart/form-data")
>     @Path("/processFormTextToJson")
>     @Descriptions({ 
>         @Description(value = "Accepts text from an HTML form, returns analysis results in JSON.", target = DocTarget.METHOD),
>         @Description(value = "Json containing all of the analysis results", target = DocTarget.RETURN)
>      })
>     public Response processFormTextToJson(@Description(value = "Json specification of the processing options.", target = DocTarget.PARAM)
>                                           @Multipart(value = "options") String optionsString,
>                                           @Description(value = "Input text", target = DocTarget.PARAM)
>                                           @Multipart(value = "data") InputStream data) {
> {code}
> and the code leading to the exception in CXF is:
> {code}
>  public static void populateMapFromMultipart(MultivaluedMap<String, String> params,
>                                                 Annotation[] anns,
>                                                 MultipartBody body, 
>                                                 boolean decode) {
>  
>        List<Attachment> atts = body.getAllAttachments();
>         for (Attachment a : atts) {
>             ContentDisposition cd = a.getContentDisposition();
>             if (cd == null || !MULTIPART_FORM_DATA_TYPE.equalsIgnoreCase(cd.getType())
>                 || cd.getParameter("name") == null) {
>                 Multipart id = AnnotationUtils.getAnnotation(anns, Multipart.class);
>                 
>                 if (id == null || id.required()) {
>                     throw new WebApplicationException(400);
>                 } else {
>                     return;
>                 }
>             }
> {code}
> The annotations present are:
> {noformat}
> [@org.apache.cxf.jaxrs.model.wadl.Description(title=, target=param, value=Json specification of the processing options., lang=, docuri=), @org.apache.cxf.jaxrs.ext.multipart.Multipart(value=options, required=true, type=*/*)]
> {noformat}
> Note that the required flag is on. cd is null. In other words, even if the names match, if there is no content disposition, we get a 400. Is that really right? Why require a cd? What's wrong with the plain old name field of the part?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira