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-tp25916823p25928772.html
Sent from the cxf-user mailing list archive at Nabble.com.
