[jira] [Created] (CXF-6111) JavascriptGetInterceptor.isRecognizedQuery is always false
Ivan Bondarenko created CXF-6111:
Summary: JavascriptGetInterceptor.isRecognizedQuery is always false
Key: CXF-6111
URL: https://issues.apache.org/jira/browse/CXF-6111
Project: CXF
Issue Type: Bug
Components: JavaScript Client
Affects Versions: 3.0.2
Reporter: Ivan Bondarenko
Priority: Blocker
Providing we have an application: http://server/app; and WS running on it
here: http://server/app/ws;. The http://server/app/ws?js; will never be
rendered.
The method
{{org.apache.cxf.javascript.JavascriptGetInterceptor.isRecognizedQuery(...)}}
always returns false, because of the code:
{{endpointInfo.getAddress().contains(UrlUtils.getStem(uri.getSchemeSpecificPart()))}}
In the example {{endpointInfo.getAddress()}} returns / and
{{UrlUtils.getStem(uri.getSchemeSpecificPart())}} returns //server/app, so
{{contains(...)}} always false.
If we look into similar method
{{org.apache.cxf.frontend.WSDLGetInterceptor.isRecognizedQuery(...)}}, it
haven't such part of code.
So I wonder if somebody ever run this Interceptor successfully, unless it is
possible to absolutize addresses somehow.
Proposition: always return true, so replace
{{endpointInfo.getAddress().contains(UrlUtils.getStem(uri.getSchemeSpecificPart()))}}
to {{true}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-5360) Resource classes are selected incorrectly
[
https://issues.apache.org/jira/browse/CXF-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806833#comment-13806833
]
Ivan Bondarenko commented on CXF-5360:
--
Approximately this code (regardless of CXF styling, possible bugs etc) must be
added to ClassResourceInfo comparison:
{code}OperationResourceInfo ori1 = null, ori2 = null;
try {
ori1 = JAXRSUtils.findTargetMethod(cri1, message, httpMethod, values,
requestContentType, acceptContentTypes, false);
}catch (Throwable e) {
}
try {
ori2 = JAXRSUtils.findTargetMethod(cri2, message, httpMethod, values,
requestContentType, acceptContentTypes, false);
}catch (Throwable e) {
}
if (ori1 != ori2) {
return (ori1 == null) ? 1 : -1;
}{code}
Resource classes are selected incorrectly
-
Key: CXF-5360
URL: https://issues.apache.org/jira/browse/CXF-5360
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.7.7
Reporter: Ivan Bondarenko
Priority: Blocker
The problem: the resource is selected incorrectly when multiple classes can
'visually' handle request. For example if we have two classes
{code}@Path(/) class Foo {
@GET @Path(bar) public String bar() { return bar; }
}
@Path(/) class Real {
@GET @Path(hello) public String hello() { return hello; }
}{code}
and their instances are registered in this order (e.g. in
jaxrs:serviceBeans), when I GET the /hello path, the Foo will be selected,
while it is not even able to handle this request.
The starting point to investigate the problem is
org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(ListClassResourceInfo,
String, MultivaluedMapString, String, Message), where 'candidateList'
variable is filled incorrectly. Unfortunately I'm not so familiar with CXF
code to provide a patch, but resource class must be selected basing on full
class description (all methods and annotations must be taken into account).
Why this is a problem: except obvious reason (unexpected behavior), this bug
disallows to make REST service modular. For example we may want to provide
different feature sets for different servers. Right now it is not possible to
implement.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CXF-5360) Resource classes are selected incorrectly
[
https://issues.apache.org/jira/browse/CXF-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805243#comment-13805243
]
Ivan Bondarenko edited comment on CXF-5360 at 10/25/13 11:55 AM:
-
Played a bit with org.apache.cxf.jaxrs.ext.ResourceComparator and looks like it
doesn't solve our problems. We want to check every class with
JAXRSUtils.findTargetMethod (and maybe some other methods) in
ResourceComparator, however:
1) ResourceComparator methods doesn't receive (as arguments or other way) the
information already gathered, first off all these variables: 'httpMethod',
'values', 'requestContentType', 'acceptContentTypes'. We must rewrite almost
whole
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(Message) for
getting them again.
2) To get 'values' variable, we must call
org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(ListClassResourceInfo,
String, MultivaluedMapString, String, Message), which will create Comparator
again and enter it, so this is an infinite stack loop. Or we must rewrite this
method also.
I think by default CXF should check every resource-class whether it is really
fits the request by all data, not only by path.
was (Author: buzzeri):
Played a bit with org.apache.cxf.jaxrs.ext.ResourceComparator and looks like it
doesn't solve our problems. We want to check every class with
JAXRSUtils.findTargetMethod (and maybe some other methods) in
ResourceComparator, however:
1) ResourceComparator methods doesn't receive (as arguments or other way) the
information already gathered, first off all these variables: 'httpMethod',
'values', 'requestContentType', 'acceptContentTypes'. We must rewrite almost
whole
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(Message) for
getting them again.
2) To get 'values', we must call
org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(ListClassResourceInfo,
String, MultivaluedMapString, String, Message), which will Create Comparator
again and enter it, so this is an infinite stack loop. Or we must rewrite this
method also.
I think by default CXF should check every resource-class whether it is really
fits the request by all data, not only by path.
Resource classes are selected incorrectly
-
Key: CXF-5360
URL: https://issues.apache.org/jira/browse/CXF-5360
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.7.7
Reporter: Ivan Bondarenko
Priority: Blocker
The problem: the resource is selected incorrectly when multiple classes can
'visually' handle request. For example if we have two classes
@Path(/) class Foo {
@GET @Path(bar) public String bar() { return bar; }
}
@Path(/) class Real {
@GET @Path(hello) public String hello() { return hello; }
}
and their instances are registered in this order (e.g. in
jaxrs:serviceBeans), when I GET the /hello path, the Foo will be selected,
while it is not even able to handle this request.
The starting point to investigate the problem is
org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(ListClassResourceInfo,
String, MultivaluedMapString, String, Message), where 'candidateList'
variable is filled incorrectly. Unfortunately I'm not so familiar with CXF
code to provide a patch, but resource class must be selected basing on full
class description (all methods and annotations must be taken into account).
Why this is a problem: except obvious reason (unexpected behavior), this bug
disallows to make REST service modular. For example we may want to provide
different feature sets for different servers. Right now it is not possible to
implement.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CXF-5360) Resource classes are selected incorrectly
[
https://issues.apache.org/jira/browse/CXF-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805243#comment-13805243
]
Ivan Bondarenko commented on CXF-5360:
--
Played a bit with org.apache.cxf.jaxrs.ext.ResourceComparator and looks like it
doesn't solve our problems. We want to check every class with
JAXRSUtils.findTargetMethod (and maybe some other methods) in
ResourceComparator, however:
1) ResourceComparator methods doesn't receive (as arguments or other way) the
information already gathered, first off all these variables: 'httpMethod',
'values', 'requestContentType', 'acceptContentTypes'. We must rewrite almost
whole
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(Message) for
getting them again.
2) To get 'values', we must call
org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(ListClassResourceInfo,
String, MultivaluedMapString, String, Message), which will Create Comparator
again and enter it, so this is an infinite stack loop. Or we must rewrite this
method also.
I think by default CXF should check every resource-class whether it is really
fits the request by all data, not only by path.
Resource classes are selected incorrectly
-
Key: CXF-5360
URL: https://issues.apache.org/jira/browse/CXF-5360
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.7.7
Reporter: Ivan Bondarenko
Priority: Blocker
The problem: the resource is selected incorrectly when multiple classes can
'visually' handle request. For example if we have two classes
@Path(/) class Foo {
@GET @Path(bar) public String bar() { return bar; }
}
@Path(/) class Real {
@GET @Path(hello) public String hello() { return hello; }
}
and their instances are registered in this order (e.g. in
jaxrs:serviceBeans), when I GET the /hello path, the Foo will be selected,
while it is not even able to handle this request.
The starting point to investigate the problem is
org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(ListClassResourceInfo,
String, MultivaluedMapString, String, Message), where 'candidateList'
variable is filled incorrectly. Unfortunately I'm not so familiar with CXF
code to provide a patch, but resource class must be selected basing on full
class description (all methods and annotations must be taken into account).
Why this is a problem: except obvious reason (unexpected behavior), this bug
disallows to make REST service modular. For example we may want to provide
different feature sets for different servers. Right now it is not possible to
implement.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CXF-5362) Spring jaxrs scheme and bean definition parser must allow alternative property setting
Ivan Bondarenko created CXF-5362:
Summary: Spring jaxrs scheme and bean definition parser must allow
alternative property setting
Key: CXF-5362
URL: https://issues.apache.org/jira/browse/CXF-5362
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Reporter: Ivan Bondarenko
http://cxf.apache.org/schemas/jaxrs.xsd scheme in conjunction with
JAXRSServerFactoryBeanDefinitionParser class must allow alternative property
set.
For example to set 'serviceBeans' now one must write:
{quote}jaxrs:server
jaxrs:serviceBeans
ref bean=bean1/
...
ref bean=beanN/
/jaxrs:serviceBeans
/jaxrs:server{quote}
However there is no way to set this if number and set of beans is unknown
beforehand (in case of different configurations etc).
The easiest and most non-breaking way I see is to allow in scheme the default
bean tags everywhere properties can be set. So user can do e.g. following:
{quote}jaxrs:server
property name=serviceBeans
_something_here_
property
/jaxrs:server{quote}
Thus user can put almost anything (probably calculated in a complicated way)
into 'serviceBeans' (and other properties).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CXF-5362) Spring jaxrs scheme and bean definition parser must allow alternative property setting
[
https://issues.apache.org/jira/browse/CXF-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805348#comment-13805348
]
Ivan Bondarenko commented on CXF-5362:
--
Schema allows it, but JAXRSServerFactoryBeanDefinitionParser.mapElement(...)
method handles inner elements in a certain way, so any tag inside
jaxrs:serviceBeans will be interpreted as an element of list. xsd:anyType
must be applied one level upper (to jaxrs:server) or something like this.
As for ref attribute, it is better than nothing, but it restricts to using
only ref, while one may want to use tags from util or something else.
Meanwhile, we are creating server in pure spring way: {code}bean
class=org.apache.cxf.jaxrs.spring.JAXRSServerFactoryBeanDefinitionParser$SpringJAXRSServerFactoryBean
init-method=init.../bean{code}
Not bad actually, though using jaxrs:server is kind of higher abstraction level.
Spring jaxrs scheme and bean definition parser must allow alternative
property setting
--
Key: CXF-5362
URL: https://issues.apache.org/jira/browse/CXF-5362
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Reporter: Ivan Bondarenko
http://cxf.apache.org/schemas/jaxrs.xsd scheme in conjunction with
JAXRSServerFactoryBeanDefinitionParser class must allow alternative property
set.
For example to set 'serviceBeans' now one must write:
{code}jaxrs:server
jaxrs:serviceBeans
ref bean=bean1/
...
ref bean=beanN/
/jaxrs:serviceBeans
/jaxrs:server{code}
However there is no way to set this if number and set of beans is unknown
beforehand (in case of different configurations etc).
The easiest and most non-breaking way I see is to allow in scheme the default
bean tags everywhere properties can be set. So user can do e.g. following:
{code}jaxrs:server
property name=serviceBeans
_something_here_
property
/jaxrs:server{code}
Thus user can put almost anything (probably calculated in a complicated way)
into 'serviceBeans' (and other properties).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CXF-5362) Spring jaxrs scheme and bean definition parser must allow alternative property setting
[
https://issues.apache.org/jira/browse/CXF-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805348#comment-13805348
]
Ivan Bondarenko edited comment on CXF-5362 at 10/25/13 2:41 PM:
Schema allows it, but JAXRSServerFactoryBeanDefinitionParser.mapElement(...)
method handles inner elements in a certain way, so any tag inside
jaxrs:serviceBeans will be interpreted as an element of list. xsd:anyType
must be applied one level upper (to jaxrs:server) or something like this.
As for ref attribute, it is better than nothing, but it restricts to using
only ref, while one may want to use tags from util or something else.
Meanwhile, we are creating server in pure spring way: {code}bean
class=org.apache.cxf.jaxrs.spring.JAXRSServerFactoryBeanDefinitionParser$SpringJAXRSServerFactoryBean
init-method=init.../bean{code}
Not bad actually, though using jaxrs:server is kind of higher abstraction level.
As for what I want to do is something like this:
{code}jaxrs:server
property name=serviceBeans
myNameSpace:doSomethingComplicated/
property
/jaxrs:server{code}
was (Author: buzzeri):
Schema allows it, but JAXRSServerFactoryBeanDefinitionParser.mapElement(...)
method handles inner elements in a certain way, so any tag inside
jaxrs:serviceBeans will be interpreted as an element of list. xsd:anyType
must be applied one level upper (to jaxrs:server) or something like this.
As for ref attribute, it is better than nothing, but it restricts to using
only ref, while one may want to use tags from util or something else.
Meanwhile, we are creating server in pure spring way: {code}bean
class=org.apache.cxf.jaxrs.spring.JAXRSServerFactoryBeanDefinitionParser$SpringJAXRSServerFactoryBean
init-method=init.../bean{code}
Not bad actually, though using jaxrs:server is kind of higher abstraction level.
Spring jaxrs scheme and bean definition parser must allow alternative
property setting
--
Key: CXF-5362
URL: https://issues.apache.org/jira/browse/CXF-5362
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Reporter: Ivan Bondarenko
http://cxf.apache.org/schemas/jaxrs.xsd scheme in conjunction with
JAXRSServerFactoryBeanDefinitionParser class must allow alternative property
set.
For example to set 'serviceBeans' now one must write:
{code}jaxrs:server
jaxrs:serviceBeans
ref bean=bean1/
...
ref bean=beanN/
/jaxrs:serviceBeans
/jaxrs:server{code}
However there is no way to set this if number and set of beans is unknown
beforehand (in case of different configurations etc).
The easiest and most non-breaking way I see is to allow in scheme the default
bean tags everywhere properties can be set. So user can do e.g. following:
{code}jaxrs:server
property name=serviceBeans
_something_here_
property
/jaxrs:server{code}
Thus user can put almost anything (probably calculated in a complicated way)
into 'serviceBeans' (and other properties).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CXF-5362) Spring jaxrs scheme and bean definition parser must allow alternative property setting
[
https://issues.apache.org/jira/browse/CXF-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805348#comment-13805348
]
Ivan Bondarenko edited comment on CXF-5362 at 10/25/13 2:50 PM:
Schema allows it, but JAXRSServerFactoryBeanDefinitionParser.mapElement(...)
method handles inner elements in a certain way, so any tag inside
jaxrs:serviceBeans will be interpreted as an element of list. xsd:anyType
must be applied one level upper (to jaxrs:server) or something like this.
As for ref attribute, it is better than nothing, but it restricts to using
only ref, while one may want to use tags from util or something else.
Meanwhile, we are creating server in pure spring way: {code}bean
class=org.apache.cxf.jaxrs.spring.JAXRSServerFactoryBeanDefinitionParser$SpringJAXRSServerFactoryBean
init-method=init.../bean{code}
Not bad actually, though using jaxrs:server is kind of higher abstraction level.
As for what I want to do is something like this:
{code}jaxrs:server
property name=serviceBeans
myNameSpace:doSomethingComplicated/
property
/jaxrs:server{code}
or maybe even
{code}jaxrs:server
myNameSpace:setInComplicatedWay name=serviceBeans /
/jaxrs:server{code}
was (Author: buzzeri):
Schema allows it, but JAXRSServerFactoryBeanDefinitionParser.mapElement(...)
method handles inner elements in a certain way, so any tag inside
jaxrs:serviceBeans will be interpreted as an element of list. xsd:anyType
must be applied one level upper (to jaxrs:server) or something like this.
As for ref attribute, it is better than nothing, but it restricts to using
only ref, while one may want to use tags from util or something else.
Meanwhile, we are creating server in pure spring way: {code}bean
class=org.apache.cxf.jaxrs.spring.JAXRSServerFactoryBeanDefinitionParser$SpringJAXRSServerFactoryBean
init-method=init.../bean{code}
Not bad actually, though using jaxrs:server is kind of higher abstraction level.
As for what I want to do is something like this:
{code}jaxrs:server
property name=serviceBeans
myNameSpace:doSomethingComplicated/
property
/jaxrs:server{code}
Spring jaxrs scheme and bean definition parser must allow alternative
property setting
--
Key: CXF-5362
URL: https://issues.apache.org/jira/browse/CXF-5362
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Reporter: Ivan Bondarenko
http://cxf.apache.org/schemas/jaxrs.xsd scheme in conjunction with
JAXRSServerFactoryBeanDefinitionParser class must allow alternative property
set.
For example to set 'serviceBeans' now one must write:
{code}jaxrs:server
jaxrs:serviceBeans
ref bean=bean1/
...
ref bean=beanN/
/jaxrs:serviceBeans
/jaxrs:server{code}
However there is no way to set this if number and set of beans is unknown
beforehand (in case of different configurations etc).
The easiest and most non-breaking way I see is to allow in scheme the default
bean tags everywhere properties can be set. So user can do e.g. following:
{code}jaxrs:server
property name=serviceBeans
_something_here_
property
/jaxrs:server{code}
Thus user can put almost anything (probably calculated in a complicated way)
into 'serviceBeans' (and other properties).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CXF-5362) Spring jaxrs scheme and bean definition parser must allow alternative property setting
[
https://issues.apache.org/jira/browse/CXF-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805411#comment-13805411
]
Ivan Bondarenko edited comment on CXF-5362 at 10/25/13 4:11 PM:
Looks like in this case (o instanceof Collection) will always be true. But more
important that this affects only serviceBeans property, while there are some
other lists. Also I think non-spring classes must not be touched here.
So the code similar to yours can be provided to
JAXRSServerFactoryBeanDefinitionParser.mapElement(...). for example piece of
code like
{code}List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
bean.addPropertyValue(blahBlah, list);{code}
can be converted to method
{code}protected mapListProperty(el, bean, propName) {
List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
//Here the list is handled somehow
bean.addPropertyValue(propName, list);
}{code}
However writing some code is more close to workaround as for me.
was (Author: buzzeri):
Looks like in this case (o instanceof Collection) will always be true. But more
important that this affects only serviceBeans property, while there are some
other lists. Also I think non-spring classes must not be touched here.
So the code similar to yours can be provided to
JAXRSServerFactoryBeanDefinitionParser.mapElement(...). for example piece of
code like
{code}List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
bean.addPropertyValue(blahBlah, list);{code}
can be converted to method
{code}protected mapListProperty(name) {
List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
//Here the list is handled somehow
bean.addPropertyValue(name, list);
}{code}
However writing some code is more close to workaround as for me.
Spring jaxrs scheme and bean definition parser must allow alternative
property setting
--
Key: CXF-5362
URL: https://issues.apache.org/jira/browse/CXF-5362
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Reporter: Ivan Bondarenko
http://cxf.apache.org/schemas/jaxrs.xsd scheme in conjunction with
JAXRSServerFactoryBeanDefinitionParser class must allow alternative property
set.
For example to set 'serviceBeans' now one must write:
{code}jaxrs:server
jaxrs:serviceBeans
ref bean=bean1/
...
ref bean=beanN/
/jaxrs:serviceBeans
/jaxrs:server{code}
However there is no way to set this if number and set of beans is unknown
beforehand (in case of different configurations etc).
The easiest and most non-breaking way I see is to allow in scheme the default
bean tags everywhere properties can be set. So user can do e.g. following:
{code}jaxrs:server
property name=serviceBeans
_something_here_
property
/jaxrs:server{code}
Thus user can put almost anything (probably calculated in a complicated way)
into 'serviceBeans' (and other properties).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CXF-5362) Spring jaxrs scheme and bean definition parser must allow alternative property setting
[
https://issues.apache.org/jira/browse/CXF-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805411#comment-13805411
]
Ivan Bondarenko edited comment on CXF-5362 at 10/25/13 4:12 PM:
Looks like in this case (o instanceof Collection) will always be true. But more
important that this affects only serviceBeans property, while there are some
other lists. Also I think non-spring classes must not be touched here.
So the code similar to yours can be provided to
JAXRSServerFactoryBeanDefinitionParser.mapElement(...). for example piece of
code like
{code}List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
bean.addPropertyValue(blahBlah, list);{code}
can be converted to method
{code}protected mapListProperty(ctx, el, bean, propName) {
List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
//Here the list is handled somehow
bean.addPropertyValue(propName, list);
}{code}
However writing some code is more close to workaround as for me.
was (Author: buzzeri):
Looks like in this case (o instanceof Collection) will always be true. But more
important that this affects only serviceBeans property, while there are some
other lists. Also I think non-spring classes must not be touched here.
So the code similar to yours can be provided to
JAXRSServerFactoryBeanDefinitionParser.mapElement(...). for example piece of
code like
{code}List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
bean.addPropertyValue(blahBlah, list);{code}
can be converted to method
{code}protected mapListProperty(el, bean, propName) {
List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
//Here the list is handled somehow
bean.addPropertyValue(propName, list);
}{code}
However writing some code is more close to workaround as for me.
Spring jaxrs scheme and bean definition parser must allow alternative
property setting
--
Key: CXF-5362
URL: https://issues.apache.org/jira/browse/CXF-5362
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Reporter: Ivan Bondarenko
http://cxf.apache.org/schemas/jaxrs.xsd scheme in conjunction with
JAXRSServerFactoryBeanDefinitionParser class must allow alternative property
set.
For example to set 'serviceBeans' now one must write:
{code}jaxrs:server
jaxrs:serviceBeans
ref bean=bean1/
...
ref bean=beanN/
/jaxrs:serviceBeans
/jaxrs:server{code}
However there is no way to set this if number and set of beans is unknown
beforehand (in case of different configurations etc).
The easiest and most non-breaking way I see is to allow in scheme the default
bean tags everywhere properties can be set. So user can do e.g. following:
{code}jaxrs:server
property name=serviceBeans
_something_here_
property
/jaxrs:server{code}
Thus user can put almost anything (probably calculated in a complicated way)
into 'serviceBeans' (and other properties).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CXF-5362) Spring jaxrs scheme and bean definition parser must allow alternative property setting
[
https://issues.apache.org/jira/browse/CXF-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805411#comment-13805411
]
Ivan Bondarenko commented on CXF-5362:
--
Looks like in this case (o instanceof Collection) will always be true. But more
important that this affects only serviceBeans property, while there are some
other lists. Also I think non-spring classes must not be touched here.
So the code similar to yours can be provided to
JAXRSServerFactoryBeanDefinitionParser.mapElement(...). for example piece of
code like
{code}List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
bean.addPropertyValue(blahBlah, list);{code}
can be converted to method
{code}protected mapListProperty(name) {
List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
//Here the list is handled somehow
bean.addPropertyValue(name, list);{code}
}
However writing some code is more close to workaround as for me.
Spring jaxrs scheme and bean definition parser must allow alternative
property setting
--
Key: CXF-5362
URL: https://issues.apache.org/jira/browse/CXF-5362
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Reporter: Ivan Bondarenko
http://cxf.apache.org/schemas/jaxrs.xsd scheme in conjunction with
JAXRSServerFactoryBeanDefinitionParser class must allow alternative property
set.
For example to set 'serviceBeans' now one must write:
{code}jaxrs:server
jaxrs:serviceBeans
ref bean=bean1/
...
ref bean=beanN/
/jaxrs:serviceBeans
/jaxrs:server{code}
However there is no way to set this if number and set of beans is unknown
beforehand (in case of different configurations etc).
The easiest and most non-breaking way I see is to allow in scheme the default
bean tags everywhere properties can be set. So user can do e.g. following:
{code}jaxrs:server
property name=serviceBeans
_something_here_
property
/jaxrs:server{code}
Thus user can put almost anything (probably calculated in a complicated way)
into 'serviceBeans' (and other properties).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CXF-5362) Spring jaxrs scheme and bean definition parser must allow alternative property setting
[
https://issues.apache.org/jira/browse/CXF-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805411#comment-13805411
]
Ivan Bondarenko edited comment on CXF-5362 at 10/25/13 4:10 PM:
Looks like in this case (o instanceof Collection) will always be true. But more
important that this affects only serviceBeans property, while there are some
other lists. Also I think non-spring classes must not be touched here.
So the code similar to yours can be provided to
JAXRSServerFactoryBeanDefinitionParser.mapElement(...). for example piece of
code like
{code}List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
bean.addPropertyValue(blahBlah, list);{code}
can be converted to method
{code}protected mapListProperty(name) {
List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
//Here the list is handled somehow
bean.addPropertyValue(name, list);
}{code}
However writing some code is more close to workaround as for me.
was (Author: buzzeri):
Looks like in this case (o instanceof Collection) will always be true. But more
important that this affects only serviceBeans property, while there are some
other lists. Also I think non-spring classes must not be touched here.
So the code similar to yours can be provided to
JAXRSServerFactoryBeanDefinitionParser.mapElement(...). for example piece of
code like
{code}List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
bean.addPropertyValue(blahBlah, list);{code}
can be converted to method
{code}protected mapListProperty(name) {
List? list = ctx.getDelegate().parseListElement(el,
bean.getBeanDefinition());
//Here the list is handled somehow
bean.addPropertyValue(name, list);{code}
}
However writing some code is more close to workaround as for me.
Spring jaxrs scheme and bean definition parser must allow alternative
property setting
--
Key: CXF-5362
URL: https://issues.apache.org/jira/browse/CXF-5362
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Reporter: Ivan Bondarenko
http://cxf.apache.org/schemas/jaxrs.xsd scheme in conjunction with
JAXRSServerFactoryBeanDefinitionParser class must allow alternative property
set.
For example to set 'serviceBeans' now one must write:
{code}jaxrs:server
jaxrs:serviceBeans
ref bean=bean1/
...
ref bean=beanN/
/jaxrs:serviceBeans
/jaxrs:server{code}
However there is no way to set this if number and set of beans is unknown
beforehand (in case of different configurations etc).
The easiest and most non-breaking way I see is to allow in scheme the default
bean tags everywhere properties can be set. So user can do e.g. following:
{code}jaxrs:server
property name=serviceBeans
_something_here_
property
/jaxrs:server{code}
Thus user can put almost anything (probably calculated in a complicated way)
into 'serviceBeans' (and other properties).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CXF-5360) Resource classes are selected incorrectly
Ivan Bondarenko created CXF-5360:
Summary: Resource classes are selected incorrectly
Key: CXF-5360
URL: https://issues.apache.org/jira/browse/CXF-5360
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.7.7
Reporter: Ivan Bondarenko
Priority: Blocker
The problem: the resource is selected incorrectly when multiple classes can
'visually' handle request. For example if we have two classes
@Path(/) class Foo {
@GET @Path(bar) public String bar() { return bar; }
}
@Path(/) class Real {
@GET @Path(hello) public String hello() { return hello; }
}
and their instances are registered in this order (e.g. in jaxrs:serviceBeans),
when I GET the /hello path, the Foo will be selected, while it is not even
able to handle this request.
The starting point to investigate the problem is
org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(ListClassResourceInfo,
String, MultivaluedMapString, String, Message), where 'candidateList'
variable is filled incorrectly. Unfortunately I'm not so familiar with CXF code
to provide a patch, but resource class must be selected basing on full class
description (all methods and annotations must be taken into account).
Why this is a problem: except obvious reason (unexpected behavior), this bug
disallows to make REST service modular. For example we may want to provide
different feature sets for different servers. Right now it is not possible to
implement.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Reopened] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bondarenko reopened CXF-4348:
--
We haven't used this feature for some time, so I couldn't do a testing. Looks
like global Content-Type is still broken:
Content-Type: multipart/related; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
The necessity of 'type', 'start' and 'start-info' params in not described in
spec. At least it is traffic overloading.
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Any
Reporter: Ivan Bondarenko
Assignee: Sergey Beryozkin
Priority: Blocker
Labels: bug, multipart, serialization
Fix For: 2.5.5, 2.6.2, 2.7.0
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488009#comment-13488009
]
Ivan Bondarenko commented on CXF-4348:
--
Not only overload, they just shouldn't be there. But this part of bug has less
priority than the fixed part.
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Any
Reporter: Ivan Bondarenko
Assignee: Sergey Beryozkin
Priority: Blocker
Labels: bug, multipart, serialization
Fix For: 2.5.5, 2.6.2, 2.7.0
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488129#comment-13488129
]
Ivan Bondarenko commented on CXF-4348:
--
I have created a thread here too (guess it is CXF Dev list):
http://cxf.547215.n5.nabble.com/Multipart-serialization-td5717660.html So looks
like the bug is more connected to non-related multiparts. Probably this
should be another report?!
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Any
Reporter: Ivan Bondarenko
Assignee: Sergey Beryozkin
Priority: Blocker
Labels: bug, multipart, serialization
Fix For: 2.5.5, 2.6.2, 2.7.0
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488249#comment-13488249
]
Ivan Bondarenko commented on CXF-4348:
--
I have tested on 2.4.10 version. Cannot switch upper than 2.4.x right now, but
looks like multipart methods are nearly the same. Also probably
multipart/mixed must be used as a default type, not multipart/related.
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Any
Reporter: Ivan Bondarenko
Assignee: Sergey Beryozkin
Priority: Blocker
Labels: bug, multipart, serialization
Fix For: 2.5.5, 2.6.2, 2.7.0
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286486#comment-13286486
]
Ivan Bondarenko commented on CXF-4348:
--
I cannot check application/octet-stream right now, will do it a bit later.
But what spec reflects this in global Content-Type?: type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
As I know the first part should have no impact on the whole content.
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Any
Reporter: Ivan Bondarenko
Priority: Blocker
Labels: bug, multipart, serialization
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
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
[jira] [Created] (CXF-4347) Content-Type is broken in multipart serialization
Ivan Bondarenko created CXF-4347:
Summary: Content-Type is broken in multipart serialization
Key: CXF-4347
URL: https://issues.apache.org/jira/browse/CXF-4347
Project: CXF
Issue Type: Bug
Environment: Any
Reporter: Ivan Bondarenko
Priority: Blocker
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related (or
other multipart).
3) Content-Type of outMessage is changed to the first attachment's Content-Type
and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The same
type must be used.
--
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
[jira] [Created] (CXF-4348) Content-Type is broken in multipart serialization
Ivan Bondarenko created CXF-4348:
Summary: Content-Type is broken in multipart serialization
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Environment: Any
Reporter: Ivan Bondarenko
Priority: Blocker
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related (or
other multipart).
3) Content-Type of outMessage is changed to the first attachment's Content-Type
and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The same
type must be used.
--
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
[jira] [Commented] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13284772#comment-13284772
]
Ivan Bondarenko commented on CXF-4348:
--
I cannot type the exact code, because DataSource objects are constructed in a
complicated internal way, but pseudo-code looks like this:
@POST
@Path()
@Consumes(multipart/*)
@Produces(multipart/*)
public MultipartBody translateDocumentPost() {
ListAttachment retAttachments = new LinkedListAttachment();
MultivaluedMapString, String headers;
headers = new MetadataMapString, String(false, true);
headers.putSingle(Content-Disposition, attachment;
filename=filename1.doc);
retAttachments.add(new Attachment(Attachment_id1, new
FileDataSource(d:/filename1.doc, application/msword), headers));
headers = new MetadataMapString, String(false, true);
headers.putSingle(Content-Disposition, attachment;
filename=filename2.xls);
retAttachments.add(new Attachment(Attachment_id2, new
FileDataSource(d:/filename2.xls, application/vnd.ms-excel), headers));
return new MultipartBody(retAttachments, true);
}
The code
new FileDataSource(d:/filename1.doc, application/msword)
you can consider as following:
a) getInputStream() = the file's content
b) getName() = filename1.doc
c) getContentType() = application/msword
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Environment: Any
Reporter: Ivan Bondarenko
Priority: Blocker
Labels: bug, multipart, serialization
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
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
