ok, I'll investigate the problem with setting UriInfo in readers used as part
of processing jaxrs:client invocations...
> 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 ?
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.
