You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by sreeharsha <sr...@pearson.com> on 2015/10/23 18:28:56 UTC

Re: Failover for JAX-RS clients

hi Sergey,

I am trying to implement the failover to our rest services which take the
header content-type Multipart/formdata.

I have noticed that when I call *Invoke *in ClientProxyImpl.java , the
headers are set from the OperationResourceInfo . After I implement the
failover retry strategy then when the method *retryInvoke * is called then
the previous headers which has Content-type and Accept is now changed to
have just Accept and omitting the Content-Type 	and  hence throwing a null
pointer at
org.apache.cxf.jaxrs.client.ClientProxyImpl$BodyWriter.doWriteBody(ClientProxyImpl.java:801).

CODE SNIPPET.

 InputStream excelInputStream  =
TestUploadFileService.class.getResourceAsStream(TEST_FILE);
//            File spreadsheetURI = new File(url.toURI());
//            excelInputStream = new FileInputStream(spreadsheetURI);

            final ContentDisposition cd = new
ContentDisposition("attachment;filename=spreadsheet.xls");
            final Attachment att = new Attachment("file", excelInputStream,
cd);
            final Attachment spreadsheetType = new
Attachment("spreadsheetType", "text/plain", "SpreadJS");
            final List<Attachment> attachments = new
ArrayList<Attachment>();
            attachments.add(att);
            attachments.add(spreadsheetType);
            final MultipartBody multipartBody = new
MultipartBody(attachments);
            FailoverFeature feature = new FailoverFeature();
            List<String> alternateAddresses = new ArrayList<String>();
           
alternateAddresses.add("http://localhost:8084/SpreadsheetTransformationService");
           
alternateAddresses.add("http://icdwdpvueweb-5:8080/SpreadsheetTransformationService");


            RetryStrategy strategy = new RetryStrategy();
            strategy.setMaxNumberOfRetries(4);
            strategy.setAlternateAddresses(alternateAddresses);
            strategy.setDelayBetweenRetries(5000);
            feature.setStrategy(strategy);
            List<Feature> features = new ArrayList<Feature>();
            features.add(feature);
            List<String> prov = new ArrayList<String>();
            String spreadsheetTransformServiceUrl =
"http://localhost:8085/SpreadsheetTransformationService";

            JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
            bean.setAddress(spreadsheetTransformServiceUrl);
            bean.setFeatures(features);
            bean.setResourceClass(SpreadSheetTransformService.class);
            WebClient  client1 = bean.createWebClient();
           
client1.back(true).path("http://localhost:8084/SpreadsheetTransformationService/import");
            final SpreadSheetTransformService service1 =
bean.create(SpreadSheetTransformService.class);
            final Response response =
service1.transformToJSON(multipartBody);
            final InputStream jsonResponse = (InputStream)
response.getEntity();

setRequestHeaders is the method being called in invoke to set the content
type.  

Idea regarding the retry is right but i think there is bug in forwarding the
headers from the first call to the retry alternate address on failure.

Appreciate your help.

Thanks,
Sree




--
View this message in context: http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762219.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Failover for JAX-RS clients

Posted by sreeharsha <sr...@pearson.com>.
Yes Sergey will let you know.

Thanks

On Thu, Oct 29, 2015 at 5:20 PM, Sergey Beryozkin [via CXF] <
ml-node+s547215n5762379h94@n5.nabble.com> wrote:

> I've updated the existing Failover test to POST a body:
>
> http://git-wip-us.apache.org/repos/asf/cxf/commit/0c7f3e16
>
> works fine in the master, 3.0.x, 2.7.x, I can see in the debug mode
> application/json Content-Type is not lost after retries.
>
> Perhaps you use some old CXF version ?
> Or may be it is related to the use of multiparts, though I'm not seeing
> a connection yet.
> Unfortunately I've no time right now to investigate it further, may be
> later, can you please do a quick test and have a simpler POST request,
> without the multiparts, say echo some json, to check if it is somehow
> related to use of the multiparts, and use the latest version of CXF
>
> Cheers, Sergey
> On 27/10/15 14:52, sreeharsha wrote:
>
> > Yes Sergey.
> >
> >   I have tested this with GET and it works fine and defaults the
> > Content-Type to Application/xml .  But with post it is dropping the
> header
> > in failover.
> >
> > Thanks,
> > Sree
> >
> > On Tue, Oct 27, 2015 at 9:01 AM, Sergey Beryozkin [via CXF] <
> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=5762379&i=0>>
> wrote:
> >
> >> Hi
> >>
> >> I've looked at a CXF JAX-RS Failover test - all the tests use GET,
> hmm...
> >>
> >> Are you saying that when the initial call is made, doChainedInvocation
> >> contains Content-Type but when doChainedInvocation is called by
> >> retryInvoke, Content-Type is no  longer in the request headers ?
> >>
> >> Cheers, Sergey
> >>
> >> On 23/10/15 17:28, sreeharsha wrote:
> >>
> >>> hi Sergey,
> >>>
> >>> I am trying to implement the failover to our rest services which take
> >> the
> >>> header content-type Multipart/formdata.
> >>>
> >>> I have noticed that when I call *Invoke *in ClientProxyImpl.java , the
> >>> headers are set from the OperationResourceInfo . After I implement the
> >>> failover retry strategy then when the method *retryInvoke * is called
> >> then
> >>> the previous headers which has Content-type and Accept is now changed
> to
> >>> have just Accept and omitting the Content-Type and  hence throwing a
> >> null
> >>> pointer at
> >>>
> >>
> org.apache.cxf.jaxrs.client.ClientProxyImpl$BodyWriter.doWriteBody(ClientProxyImpl.java:801).
>
> >>
> >>>
> >>> CODE SNIPPET.
> >>>
> >>>    InputStream excelInputStream  =
> >>> TestUploadFileService.class.getResourceAsStream(TEST_FILE);
> >>> //            File spreadsheetURI = new File(url.toURI());
> >>> //            excelInputStream = new FileInputStream(spreadsheetURI);
> >>>
> >>>               final ContentDisposition cd = new
> >>> ContentDisposition("attachment;filename=spreadsheet.xls");
> >>>               final Attachment att = new Attachment("file",
> >> excelInputStream,
> >>> cd);
> >>>               final Attachment spreadsheetType = new
> >>> Attachment("spreadsheetType", "text/plain", "SpreadJS");
> >>>               final List<Attachment> attachments = new
> >>> ArrayList<Attachment>();
> >>>               attachments.add(att);
> >>>               attachments.add(spreadsheetType);
> >>>               final MultipartBody multipartBody = new
> >>> MultipartBody(attachments);
> >>>               FailoverFeature feature = new FailoverFeature();
> >>>               List<String> alternateAddresses = new
> ArrayList<String>();
> >>>
> >>> alternateAddresses.add("
> >> http://localhost:8084/SpreadsheetTransformationService");
> >>>
> >>> alternateAddresses.add("
> >> http://icdwdpvueweb-5:8080/SpreadsheetTransformationService");
> >>>
> >>>
> >>>               RetryStrategy strategy = new RetryStrategy();
> >>>               strategy.setMaxNumberOfRetries(4);
> >>>               strategy.setAlternateAddresses(alternateAddresses);
> >>>               strategy.setDelayBetweenRetries(5000);
> >>>               feature.setStrategy(strategy);
> >>>               List<Feature> features = new ArrayList<Feature>();
> >>>               features.add(feature);
> >>>               List<String> prov = new ArrayList<String>();
> >>>               String spreadsheetTransformServiceUrl =
> >>> "http://localhost:8085/SpreadsheetTransformationService";
> >>>
> >>>               JAXRSClientFactoryBean bean = new
> JAXRSClientFactoryBean();
> >>>               bean.setAddress(spreadsheetTransformServiceUrl);
> >>>               bean.setFeatures(features);
> >>>
> bean.setResourceClass(SpreadSheetTransformService.class);
> >>>               WebClient  client1 = bean.createWebClient();
> >>>
> >>> client1.back(true).path("
> >> http://localhost:8084/SpreadsheetTransformationService/import");
> >>>               final SpreadSheetTransformService service1 =
> >>> bean.create(SpreadSheetTransformService.class);
> >>>               final Response response =
> >>> service1.transformToJSON(multipartBody);
> >>>               final InputStream jsonResponse = (InputStream)
> >>> response.getEntity();
> >>>
> >>> setRequestHeaders is the method being called in invoke to set the
> >> content
> >>> type.
> >>>
> >>> Idea regarding the retry is right but i think there is bug in
> forwarding
> >> the
> >>> headers from the first call to the retry alternate address on failure.
> >>>
> >>> Appreciate your help.
> >>>
> >>> Thanks,
> >>> Sree
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>
> http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762219.html
> >>> Sent from the cxf-user mailing list archive at Nabble.com.
> >>>
> >>
> >>
> >> --
> >> Sergey Beryozkin
> >>
> >> Talend Community Coders
> >> http://coders.talend.com/
> >>
> >>
> >> ------------------------------
> >> If you reply to this email, your message will be added to the
> discussion
> >> below:
> >>
> >>
> http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762318.html
> >> To unsubscribe from Failover for JAX-RS clients, click here
> >> <
> >> .
> >> NAML
> >> <
> http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
> >>
> >
> >
> >
> >
> > --
> > View this message in context:
> http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762322.html
> > Sent from the cxf-user mailing list archive at Nabble.com.
> >
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762379.html
> To unsubscribe from Failover for JAX-RS clients, click here
> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4494783&code=c3JlZWhhcnNoYS5wYW5ndWx1cmlAcGVhcnNvbi5jb218NDQ5NDc4M3wxODk3NDIyNzAy>
> .
> NAML
> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762420.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Failover for JAX-RS clients

Posted by Sergey Beryozkin <sb...@gmail.com>.
I've updated the existing Failover test to POST a body:

http://git-wip-us.apache.org/repos/asf/cxf/commit/0c7f3e16

works fine in the master, 3.0.x, 2.7.x, I can see in the debug mode 
application/json Content-Type is not lost after retries.

Perhaps you use some old CXF version ?
Or may be it is related to the use of multiparts, though I'm not seeing 
a connection yet.
Unfortunately I've no time right now to investigate it further, may be 
later, can you please do a quick test and have a simpler POST request, 
without the multiparts, say echo some json, to check if it is somehow 
related to use of the multiparts, and use the latest version of CXF

Cheers, Sergey
On 27/10/15 14:52, sreeharsha wrote:
> Yes Sergey.
>
>   I have tested this with GET and it works fine and defaults the
> Content-Type to Application/xml .  But with post it is dropping the header
> in failover.
>
> Thanks,
> Sree
>
> On Tue, Oct 27, 2015 at 9:01 AM, Sergey Beryozkin [via CXF] <
> ml-node+s547215n5762318h3@n5.nabble.com> wrote:
>
>> Hi
>>
>> I've looked at a CXF JAX-RS Failover test - all the tests use GET, hmm...
>>
>> Are you saying that when the initial call is made, doChainedInvocation
>> contains Content-Type but when doChainedInvocation is called by
>> retryInvoke, Content-Type is no  longer in the request headers ?
>>
>> Cheers, Sergey
>>
>> On 23/10/15 17:28, sreeharsha wrote:
>>
>>> hi Sergey,
>>>
>>> I am trying to implement the failover to our rest services which take
>> the
>>> header content-type Multipart/formdata.
>>>
>>> I have noticed that when I call *Invoke *in ClientProxyImpl.java , the
>>> headers are set from the OperationResourceInfo . After I implement the
>>> failover retry strategy then when the method *retryInvoke * is called
>> then
>>> the previous headers which has Content-type and Accept is now changed to
>>> have just Accept and omitting the Content-Type and  hence throwing a
>> null
>>> pointer at
>>>
>> org.apache.cxf.jaxrs.client.ClientProxyImpl$BodyWriter.doWriteBody(ClientProxyImpl.java:801).
>>
>>>
>>> CODE SNIPPET.
>>>
>>>    InputStream excelInputStream  =
>>> TestUploadFileService.class.getResourceAsStream(TEST_FILE);
>>> //            File spreadsheetURI = new File(url.toURI());
>>> //            excelInputStream = new FileInputStream(spreadsheetURI);
>>>
>>>               final ContentDisposition cd = new
>>> ContentDisposition("attachment;filename=spreadsheet.xls");
>>>               final Attachment att = new Attachment("file",
>> excelInputStream,
>>> cd);
>>>               final Attachment spreadsheetType = new
>>> Attachment("spreadsheetType", "text/plain", "SpreadJS");
>>>               final List<Attachment> attachments = new
>>> ArrayList<Attachment>();
>>>               attachments.add(att);
>>>               attachments.add(spreadsheetType);
>>>               final MultipartBody multipartBody = new
>>> MultipartBody(attachments);
>>>               FailoverFeature feature = new FailoverFeature();
>>>               List<String> alternateAddresses = new ArrayList<String>();
>>>
>>> alternateAddresses.add("
>> http://localhost:8084/SpreadsheetTransformationService");
>>>
>>> alternateAddresses.add("
>> http://icdwdpvueweb-5:8080/SpreadsheetTransformationService");
>>>
>>>
>>>               RetryStrategy strategy = new RetryStrategy();
>>>               strategy.setMaxNumberOfRetries(4);
>>>               strategy.setAlternateAddresses(alternateAddresses);
>>>               strategy.setDelayBetweenRetries(5000);
>>>               feature.setStrategy(strategy);
>>>               List<Feature> features = new ArrayList<Feature>();
>>>               features.add(feature);
>>>               List<String> prov = new ArrayList<String>();
>>>               String spreadsheetTransformServiceUrl =
>>> "http://localhost:8085/SpreadsheetTransformationService";
>>>
>>>               JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
>>>               bean.setAddress(spreadsheetTransformServiceUrl);
>>>               bean.setFeatures(features);
>>>               bean.setResourceClass(SpreadSheetTransformService.class);
>>>               WebClient  client1 = bean.createWebClient();
>>>
>>> client1.back(true).path("
>> http://localhost:8084/SpreadsheetTransformationService/import");
>>>               final SpreadSheetTransformService service1 =
>>> bean.create(SpreadSheetTransformService.class);
>>>               final Response response =
>>> service1.transformToJSON(multipartBody);
>>>               final InputStream jsonResponse = (InputStream)
>>> response.getEntity();
>>>
>>> setRequestHeaders is the method being called in invoke to set the
>> content
>>> type.
>>>
>>> Idea regarding the retry is right but i think there is bug in forwarding
>> the
>>> headers from the first call to the retry alternate address on failure.
>>>
>>> Appreciate your help.
>>>
>>> Thanks,
>>> Sree
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>> http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762219.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762318.html
>> To unsubscribe from Failover for JAX-RS clients, click here
>> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4494783&code=c3JlZWhhcnNoYS5wYW5ndWx1cmlAcGVhcnNvbi5jb218NDQ5NDc4M3wxODk3NDIyNzAy>
>> .
>> NAML
>> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762322.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: Failover for JAX-RS clients

Posted by sreeharsha <sr...@pearson.com>.
Yes Sergey.

 I have tested this with GET and it works fine and defaults the
Content-Type to Application/xml .  But with post it is dropping the header
in failover.

Thanks,
Sree

On Tue, Oct 27, 2015 at 9:01 AM, Sergey Beryozkin [via CXF] <
ml-node+s547215n5762318h3@n5.nabble.com> wrote:

> Hi
>
> I've looked at a CXF JAX-RS Failover test - all the tests use GET, hmm...
>
> Are you saying that when the initial call is made, doChainedInvocation
> contains Content-Type but when doChainedInvocation is called by
> retryInvoke, Content-Type is no  longer in the request headers ?
>
> Cheers, Sergey
>
> On 23/10/15 17:28, sreeharsha wrote:
>
> > hi Sergey,
> >
> > I am trying to implement the failover to our rest services which take
> the
> > header content-type Multipart/formdata.
> >
> > I have noticed that when I call *Invoke *in ClientProxyImpl.java , the
> > headers are set from the OperationResourceInfo . After I implement the
> > failover retry strategy then when the method *retryInvoke * is called
> then
> > the previous headers which has Content-type and Accept is now changed to
> > have just Accept and omitting the Content-Type and  hence throwing a
> null
> > pointer at
> >
> org.apache.cxf.jaxrs.client.ClientProxyImpl$BodyWriter.doWriteBody(ClientProxyImpl.java:801).
>
> >
> > CODE SNIPPET.
> >
> >   InputStream excelInputStream  =
> > TestUploadFileService.class.getResourceAsStream(TEST_FILE);
> > //            File spreadsheetURI = new File(url.toURI());
> > //            excelInputStream = new FileInputStream(spreadsheetURI);
> >
> >              final ContentDisposition cd = new
> > ContentDisposition("attachment;filename=spreadsheet.xls");
> >              final Attachment att = new Attachment("file",
> excelInputStream,
> > cd);
> >              final Attachment spreadsheetType = new
> > Attachment("spreadsheetType", "text/plain", "SpreadJS");
> >              final List<Attachment> attachments = new
> > ArrayList<Attachment>();
> >              attachments.add(att);
> >              attachments.add(spreadsheetType);
> >              final MultipartBody multipartBody = new
> > MultipartBody(attachments);
> >              FailoverFeature feature = new FailoverFeature();
> >              List<String> alternateAddresses = new ArrayList<String>();
> >
> > alternateAddresses.add("
> http://localhost:8084/SpreadsheetTransformationService");
> >
> > alternateAddresses.add("
> http://icdwdpvueweb-5:8080/SpreadsheetTransformationService");
> >
> >
> >              RetryStrategy strategy = new RetryStrategy();
> >              strategy.setMaxNumberOfRetries(4);
> >              strategy.setAlternateAddresses(alternateAddresses);
> >              strategy.setDelayBetweenRetries(5000);
> >              feature.setStrategy(strategy);
> >              List<Feature> features = new ArrayList<Feature>();
> >              features.add(feature);
> >              List<String> prov = new ArrayList<String>();
> >              String spreadsheetTransformServiceUrl =
> > "http://localhost:8085/SpreadsheetTransformationService";
> >
> >              JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
> >              bean.setAddress(spreadsheetTransformServiceUrl);
> >              bean.setFeatures(features);
> >              bean.setResourceClass(SpreadSheetTransformService.class);
> >              WebClient  client1 = bean.createWebClient();
> >
> > client1.back(true).path("
> http://localhost:8084/SpreadsheetTransformationService/import");
> >              final SpreadSheetTransformService service1 =
> > bean.create(SpreadSheetTransformService.class);
> >              final Response response =
> > service1.transformToJSON(multipartBody);
> >              final InputStream jsonResponse = (InputStream)
> > response.getEntity();
> >
> > setRequestHeaders is the method being called in invoke to set the
> content
> > type.
> >
> > Idea regarding the retry is right but i think there is bug in forwarding
> the
> > headers from the first call to the retry alternate address on failure.
> >
> > Appreciate your help.
> >
> > Thanks,
> > Sree
> >
> >
> >
> >
> > --
> > View this message in context:
> http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762219.html
> > Sent from the cxf-user mailing list archive at Nabble.com.
> >
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762318.html
> To unsubscribe from Failover for JAX-RS clients, click here
> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4494783&code=c3JlZWhhcnNoYS5wYW5ndWx1cmlAcGVhcnNvbi5jb218NDQ5NDc4M3wxODk3NDIyNzAy>
> .
> NAML
> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762322.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Failover for JAX-RS clients

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi

I've looked at a CXF JAX-RS Failover test - all the tests use GET, hmm...

Are you saying that when the initial call is made, doChainedInvocation
contains Content-Type but when doChainedInvocation is called by 
retryInvoke, Content-Type is no  longer in the request headers ?

Cheers, Sergey

On 23/10/15 17:28, sreeharsha wrote:
> hi Sergey,
>
> I am trying to implement the failover to our rest services which take the
> header content-type Multipart/formdata.
>
> I have noticed that when I call *Invoke *in ClientProxyImpl.java , the
> headers are set from the OperationResourceInfo . After I implement the
> failover retry strategy then when the method *retryInvoke * is called then
> the previous headers which has Content-type and Accept is now changed to
> have just Accept and omitting the Content-Type 	and  hence throwing a null
> pointer at
> org.apache.cxf.jaxrs.client.ClientProxyImpl$BodyWriter.doWriteBody(ClientProxyImpl.java:801).
>
> CODE SNIPPET.
>
>   InputStream excelInputStream  =
> TestUploadFileService.class.getResourceAsStream(TEST_FILE);
> //            File spreadsheetURI = new File(url.toURI());
> //            excelInputStream = new FileInputStream(spreadsheetURI);
>
>              final ContentDisposition cd = new
> ContentDisposition("attachment;filename=spreadsheet.xls");
>              final Attachment att = new Attachment("file", excelInputStream,
> cd);
>              final Attachment spreadsheetType = new
> Attachment("spreadsheetType", "text/plain", "SpreadJS");
>              final List<Attachment> attachments = new
> ArrayList<Attachment>();
>              attachments.add(att);
>              attachments.add(spreadsheetType);
>              final MultipartBody multipartBody = new
> MultipartBody(attachments);
>              FailoverFeature feature = new FailoverFeature();
>              List<String> alternateAddresses = new ArrayList<String>();
>
> alternateAddresses.add("http://localhost:8084/SpreadsheetTransformationService");
>
> alternateAddresses.add("http://icdwdpvueweb-5:8080/SpreadsheetTransformationService");
>
>
>              RetryStrategy strategy = new RetryStrategy();
>              strategy.setMaxNumberOfRetries(4);
>              strategy.setAlternateAddresses(alternateAddresses);
>              strategy.setDelayBetweenRetries(5000);
>              feature.setStrategy(strategy);
>              List<Feature> features = new ArrayList<Feature>();
>              features.add(feature);
>              List<String> prov = new ArrayList<String>();
>              String spreadsheetTransformServiceUrl =
> "http://localhost:8085/SpreadsheetTransformationService";
>
>              JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
>              bean.setAddress(spreadsheetTransformServiceUrl);
>              bean.setFeatures(features);
>              bean.setResourceClass(SpreadSheetTransformService.class);
>              WebClient  client1 = bean.createWebClient();
>
> client1.back(true).path("http://localhost:8084/SpreadsheetTransformationService/import");
>              final SpreadSheetTransformService service1 =
> bean.create(SpreadSheetTransformService.class);
>              final Response response =
> service1.transformToJSON(multipartBody);
>              final InputStream jsonResponse = (InputStream)
> response.getEntity();
>
> setRequestHeaders is the method being called in invoke to set the content
> type.
>
> Idea regarding the retry is right but i think there is bug in forwarding the
> headers from the first call to the retry alternate address on failure.
>
> Appreciate your help.
>
> Thanks,
> Sree
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Failover-for-JAX-RS-clients-tp4494783p5762219.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/