Hi,
It ignores profilePolicyReaderProvider for a CustomType ProfilePolicy and
gives me an error that no message reader is found.
I'm still confused about this one. Does the jaxrs:server with the address
"/sync" ever receives ProfilePolicy ? Or is it jaxrs:client which receives
it ?
Or perhaps, you have types like ProfilePolicy and SuperProfilePolicy which extends ProfilePolicy ? If yes then it will definitely
work in 2.3-SNAPSHOT and indeed in 2.4, even though sorting message body providers by types they suppor is a jaxrs 1.1. requirement
If not then if you can send me two sample providers and a resource class then
it would help in narrowing the problem down
cheers, Sergey
cheers, SErgey
rkam wrote:
I declared as follows in my class. ui doesn't get set when called thru
jaxrs:client but works fines otherwise.
private UriInfo ui;
@Context
public void setUriInfo(UriInfo ui) {
this.ui = ui;
}
Also, when a jaxrs server contains multiple providers for different custom
types, it kind of ignores if there are is more than 1 type.
for ex
<jaxrs:server id="syncService" address="/sync">
<jaxrs:serviceBeans>
<ref bean="syncServiceBean" />
</jaxrs:serviceBeans>
<jaxrs:features>
<cxf:logging/>
</jaxrs:features>
<jaxrs:providers>
<ref bean="syncRequestReader"/> <!-- for reading type SyncRequest-->
<ref bean="downloadWriter"/> <!-- for writing type
DownloadSyncResponse -->
<ref bean="profilePolicyReaderProvider"/> <!-- for
reading ProfilePolicy type-->
</jaxrs:providers>
</jaxrs:server>
It ignores profilePolicyReaderProvider for a CustomType ProfilePolicy and
gives me an error that no message reader is found. This limits the
ability for an endpoint to read/write different custom types.
Yeah.. I have to check out continuations.
Version: 2.2.3 Project work started from 2.1.x
Sergey Beryozkin-2 wrote:
No, UriInfo was not set and was giving null pointer .. So I had to check
Null
Pointer before I used it
I'd really appreciate if you could give more infor about it (send me some
code please showing how UriInfo is declared, is it
injected as a filed, etc). I have a WebClient test which uses
XSLTJaxbProvider on the inbound path, as a reader and it can get
access to an injected UriInfo (though through a MessageContext). May be I
need to add another test with a jaxrs:client being
involved...
By the way, what CXF version you're using ?
I was under the assumption that ClientAPI uses colocation .. may be not
yet.
But for intra service messaging we definitely want colocation rather
than go
down the tcp stack.
sure...
Also, can you please comment on the other question I had in the same
thread.
about performance ? I guess the fact that jaxrs:clients use TCP affects
the performance a bit...
By the way, perhaps it's on overkill for your case, but have you thought
about using continuations in your service code ?
cheers, Sergey
Thanks a lot for the quick response
rkam
Sergey Beryozkin-2 wrote:
Hi
jaxrs:client solution that you have provided worked perfectly fine.
great...
I had to do a NP check on the UriInfo
can you give me some more info please ? Is it not injected into your
custom reader when the jaxrs client starts processing the
response ?
Now, I get the colocation performance benefit.
Unfortunately not, not yet... I think it still goes over HTTP at the
moment - one of the tasks for 2.3 is to support a local
transport for JAXRS as well
cheers, Sergey
rkam
--
View this message in context:
http://www.nabble.com/Multiple-Custom-Providers-tp25916823p25926686.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/Multiple-Custom-Providers-tp25916823p25928219.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/Multiple-Custom-Providers-tp25916823p25932338.html
Sent from the cxf-user mailing list archive at Nabble.com.
