You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org> on 2011/12/20 14:07:30 UTC
[jira] [Updated] (CXF-3987) incompatible change in JAX-RS from
2.5.0 to 2.5.1
[ https://issues.apache.org/jira/browse/CXF-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benson Margulies updated CXF-3987:
----------------------------------
Description:
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?
was:
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}
> 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