resteasy-developers

[Resteasy-developers] JAX-RS 2 Client side filters for service with interesting response codes

[Michael M. <mic...@ga...>]

Hi all,

I'm using the new JAX-RS 2 client API to communicate with a system that has an interesting take on response codes, which basically means it will return 200 for everything and the body will include a fault element to indicate something has gone wrong. As an example, given an XML response from a POST  to create a pet I might get:

<pet><name>Fido</name></pet>

Or I might get

<fault><error-code>3423423</error-code></fault>

My take on this is that I should provide an interceptor/filter to look at the message body response, determine if there is a fault in there, and throw a WebApplicationException, or at the very least change the status code so that a WebApplicationException is thrown further down the line..

My questions are, which filter or interceptor is correct in this use case? I would imagine where I want it to kick in is at the point where it has the response body but hasn't tried to marshall it.

The second question was, am I right to register it at the point I build my client, e.g.
ClientBuilder.newBuilder().register(new MyCustomInterceptor()).build()

The intention is that this would be a client specifically for dealing with the quirks of those endpoints, other clients would not have those filters applied. I'm leaving off the Provider annotation purposely so it doesn't get picked up automagically anywhere else.

Appreciate any advice as ever.

[Resteasy-developers] JAX-RS 2 Client side filters for service with interesting response codes

[Michael M. <mic...@ga...>]

Thanks Bill, that worked a treat.

On 17/04/2013 23:51, "res...@li..."
<res...@li...> wrote:

>Send Resteasy-developers mailing list submissions to
>	res...@li...
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>or, via email, send a message with subject or body 'help' to
>	res...@li...
>
>You can reach the person managing the list at
>	res...@li...
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Resteasy-developers digest..."
>
>
>Today's Topics:
>
>   1. JAX-RS 2 Client side filters for service with interesting
>      response codes (Michael McCarthy)
>   2. Re: Work on RESTEasy-795 (Weinan Li)
>   3. 2.3.6 and 3.0-beta-4 release tomorrow (Bill Burke)
>   4. 3.0-beta-4 and 2.3.6 released (Bill Burke)
>   5. Test - ignore (Ron Sigal)
>   6. spring bean processor bug (Gendler, Samuel)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 26 Mar 2013 08:21:37 +0000
>From: Michael McCarthy <mic...@ga...>
>Subject: [Resteasy-developers] JAX-RS 2 Client side filters for
>	service with interesting response codes
>To: "res...@li..."
>	<res...@li...>
>Message-ID: <CD770B0B.1A44E%mic...@ga...>
>Content-Type: text/plain; charset="us-ascii"
>
>Hi all,
>
>I'm using the new JAX-RS 2 client API to communicate with a system that
>has an interesting take on response codes, which basically means it will
>return 200 for everything and the body will include a fault element to
>indicate something has gone wrong. As an example, given an XML response
>from a POST  to create a pet I might get:
>
><pet><name>Fido</name></pet>
>
>Or I might get
>
><fault><error-code>3423423</error-code></fault>
>
>My take on this is that I should provide an interceptor/filter to look at
>the message body response, determine if there is a fault in there, and
>throw a WebApplicationException, or at the very least change the status
>code so that a WebApplicationException is thrown further down the line..
>
>My questions are, which filter or interceptor is correct in this use
>case? I would imagine where I want it to kick in is at the point where it
>has the response body but hasn't tried to marshall it.
>
>The second question was, am I right to register it at the point I build
>my client, e.g.
>ClientBuilder.newBuilder().register(new MyCustomInterceptor()).build()
>
>The intention is that this would be a client specifically for dealing
>with the quirks of those endpoints, other clients would not have those
>filters applied. I'm leaving off the Provider annotation purposely so it
>doesn't get picked up automagically anywhere else.
>
>Appreciate any advice as ever.
>-------------- next part --------------
>An HTML attachment was scrubbed...
>
>------------------------------
>
>Message: 2
>Date: Tue, 26 Mar 2013 18:54:57 +0800
>From: Weinan Li <we...@re...>
>Subject: Re: [Resteasy-developers] Work on RESTEasy-795
>To: Michael Pasternak <mpa...@re...>
>Cc: resteasy-developers <res...@li...>
>Message-ID: <2C2...@re...>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hi Michael,
>
>	Next release of RESTEasy 3.x will include it(3.0-beta-4).
>
>	It will not supported in 2.3.6.Final(next release of 2.3.x) because it
>breaks the @NoJackson support.
>
>	For 3.x the jettison support will be removed soon so we don't have to
>consider the backward compatibility.
>
>
>
>- Weinan Li
>JBoss, Redhat
>
>
>
>
>
>
>
>
>
>
>On Mar 26, 2013, at 4:25 PM, Michael Pasternak <mpa...@re...>
>wrote:
>
>> 
>> 
>> Hi Guys,
>> 
>> i see RESTEasy-795 is closed, in what upstream/downstream version this
>>change
>> will be available?
>> 
>> (btw thanks for fixing this)
>> 
>> On 02/27/2013 03:44 AM, Weinan Li wrote:
>>> 
>>> - Weinan Li
>>> JBoss, Redhat
>>> 
>>> 
>>> On Feb 26, 2013, at 11:37 PM, Bill Burke <bb...@re...
>>><mailto:bb...@re...>> wrote:
>>> 
>>>> We could also retire Jettison support in Resteasy 3.0.  In my book
>>>>revision I'm removing the section on Jettision and replacing it with
>>>>Jackson.
>>> 
>>> Cool! If Jettison is no longer supported, then seems my previous patch
>>>is fine to use, and I will also remove the @NoJackson support and
>>>resubmit the pull request. Does
>>> that sound reasonable ?
>>> 
>>>> 
>>>> On 2/26/2013 4:11 AM, Weinan Li wrote:
>>>>> Hi Bill,
>>>>> 
>>>>> Currently I'm working on RESTEASY-795: Add Jackson JAXB support to
>>>>>RESTEasy
>>>>> 
>>>>> Ron has helped me find out the problem of my previous patch[1] is
>>>>>that
>>>>> it will cause compatiblity problem if Jettison and Jackson co-exists
>>>>>in
>>>>> a project. We are not sure if this is the backward compatibility you
>>>>> were referring to, could you please help to confirm this?
>>>>> 
>>>>> Here is my solution to fix this: Add a @UseJackson annotation for
>>>>>user
>>>>> to annotate on JAXB annotated resources. If the JAXB resource is
>>>>> annotated by it, RESTEasy will use Jackson to deal with it,
>>>>>otherwise it
>>>>> will use Jettison. And we'll make sure @UseJackson and @NoJackson
>>>>>cannot
>>>>> be used at same time. Do you like this idea? If it's okay  I'll start
>>>>> coding.
>>>>> 
>>>>> [1]
>>>>> 
>>>>>https://github.com/resteasy/Resteasy/commit/6c1f9bd07e9b31d9b73746cad2
>>>>>f6a0b6846f42e6
>>>>> 
>>>>> - Weinan Li
>>>>> JBoss, Redhat
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> -- 
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>> 
>> 
>> 
>> -- 
>> 
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>
>------------------------------
>
>Message: 3
>Date: Tue, 09 Apr 2013 10:38:45 -0400
>From: Bill Burke <bb...@re...>
>Subject: [Resteasy-developers] 2.3.6 and 3.0-beta-4 release tomorrow
>To: resteasy-developers <Res...@li...>
>Message-ID: <516...@re...>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>fyi
>
>-- 
>Bill Burke
>JBoss, a division of Red Hat
>http://bill.burkecentral.com
>
>
>
>------------------------------
>
>Message: 4
>Date: Wed, 10 Apr 2013 10:22:44 -0400
>From: Bill Burke <bb...@re...>
>Subject: [Resteasy-developers] 3.0-beta-4 and 2.3.6 released
>To: resteasy-developers <Res...@li...>
>Message-ID: <516...@re...>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>See jboss.org/resteasy for relevant links for downloads/documentation.
>
>3.0-beta-4 is our last beta!  JAX-RS 2.0 Final is being voted on for
>JCP.  We'll be obtaining the TCK soon and starting work on getting
>certified.  There's also some architectural work that needs to be
>finished for 3.0.  We'll have a short RC release sometime in May, then a
>3.0 Final Release early June.
>
>2.3.6 is just a maintenance release.
>
>-- 
>Bill Burke
>JBoss, a division of Red Hat
>http://bill.burkecentral.com
>
>
>
>------------------------------
>
>Message: 5
>Date: Sat, 13 Apr 2013 13:49:10 -0400
>From: Ron Sigal <rs...@re...>
>Subject: [Resteasy-developers] Test - ignore
>To: res...@li...
>Message-ID: <516...@re...>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Test.
>
>
>
>------------------------------
>
>Message: 6
>Date: Wed, 17 Apr 2013 15:35:59 -0700
>From: "Gendler, Samuel" <Sam...@we...>
>Subject: [Resteasy-developers] spring bean processor bug
>To: "'res...@li...'"
>	<res...@li...>
>Cc: "'res...@li...'"
>	<res...@li...>
>Message-ID:
>	<CD4...@PA....l
>ocal>
>	
>Content-Type: text/plain; charset="us-ascii"
>
>I recently upgraded a project from 2.2.3.GA to 2.3.6.FINAL and
>encountered a bug that appears to originate in the SpringBeanProcessor
>and which breaks property placeholder variable replacement in certain
>spring beans.
>
>I haven't completely unwound the bug to the root cause, but I've gotten
>close enough to be confident that someone with more resteasy knowledge
>can likely address it much more quickly than I can.
>
>First, the symptoms:
>
>I have a bean of class org.springframework.jndi.JndiTemplate declared as
>follows:
>
>  <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
>    <property name="environment">
>      <props>
>        <prop 
>key="java.naming.factory.initial">com.sonicsw.jndi.mfcontext.MFContextFact
>ory</prop>
>        <prop key="java.naming.provider.url">${jndi.url}</prop>
>        <prop key="java.naming.security.principal">${jndi.user}</prop>
>        <prop 
>key="java.naming.security.credentials">${jndi.password}</prop>
>        <prop 
>key="com.sonicsw.jndi.mfcontext.domain">${jndi.domain}</prop>
>        <prop key="clientId">${jndi.clientId}</prop>
>        <prop key="subscriptionDurable">true</prop>
>        <prop 
>key="durableSubscriptionName">${jndi.durableSubscriptionName}</prop>
>        <prop key="timeToLive">${jndi.timeToLive}</prop>
>        <prop 
>key="com.sonicsw.jndi.mfcontext.idleTimeout">${jndi.timeout}</prop>
>      </props>
>    </property>
>  </bean>
>
>I have a property placeholder that is most definitely initialized with
>values for all of those properties.  I can set the same values in a test
>object and see that they are correctly replaced.  However, for reasons
>that I'll get into in a moment, the jndiTemplate properties are NOT
>replaced and it receives the raw ${...} strings instead.  Needless to
>say, this breaks my project.  Switching back to 2.2.3.GA definitely fixes
>it without making any other changes.
>
>What I've discovered so far about the cause:
>
>In SpringBeanProcessor.postProcessBeanFactory(), a method called
>findResteasyRegistrations() is called.  That method, in turn, calls the
>following:
>
>beanFactory.getBeansOfType(ResteasyRegistration.class);
>
>That method call causes some beans (but not all beans) to be
>instantiated, and any beans that are instantiated at that point do not
>have property placeholder values replaced in them, because the property
>placeholder processor has (apparently) not yet executed.  What I haven't
>figured out is why my jndiTemplate bean is impacted by this, while
>another bean that I created simply to test the creation of properties
>inside of a bean definition is not.  It is apparently skipped over by the
>getBeansOfType(ResteasyRegistration.class) and property replacement
>happens correctly in that case.
>
>Initially, I suspected that this was a problem with post processor
>ordering.  This was somewhat vexing as the SpringBeanProcessor does
>implement the PriorityOrdered interface, but exposes no mechanism for
>modifying the order value.  I created my own version of
>SpringContextLoaderListener which forgoes the use of
>SpringContextLoaderSupport and performs the same work, but also calls
>setOrder(x) on the SpringBeanProcessor before adding it to the
>postprocessors and application listeners.  However, that didn't seem to
>have any impact, no matter in which relative order I placed the property
>placeholder and the spring bean processor.
>
>For one final data point, if I don't use a property placeholder, but
>instead reference a properties object via Spring-EL in the XML, then the
>values are correctly replaced, because the spring-el is evaluated when
>the xml is parsed (I assume), while property placeholders are definitely
>evaluated lazily, long after the bean definitions are created by the xml
>parsing process.
>
>  <util:properties id="jmsProperties"
>location="file:${catalina.base}/conf/jms.properties"/>
>
>  <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
>    <property name="environment">
>      <props>
>        <prop 
>key="java.naming.factory.initial">com.sonicsw.jndi.mfcontext.MFContextFact
>ory
>        </prop>
>        <prop 
>key="java.naming.provider.url">#{jmsProperties['jndi.url']}</prop>
>        <prop 
>key="java.naming.security.principal">#{jmsProperties['jndi.user']}</prop>
>        <prop 
>key="java.naming.security.credentials">#{jmsProperties['jndi.password']}</
>prop>
>        <prop 
>key="com.sonicsw.jndi.mfcontext.domain">#{jmsProperties['jndi.domain']}</p
>rop>
>        <prop key="clientId">#{jmsProperties['jndi.clientId']}</prop>
>        <prop key="subscriptionDurable">true</prop>
>        <prop 
>key="durableSubscriptionName">#{jmsProperties['jndi.durableSubscriptionNam
>e']}</prop>
>        <prop key="timeToLive">#{jmsProperties['jndi.timeToLive']}</prop>
>        <prop 
>key="com.sonicsw.jndi.mfcontext.idleTimeout">#{jmsProperties['jndi.timeout
>']}</prop>
>      </props>
>    </property>
>  </bean>
>
>This works, but is a kludge.  I'd much prefer to have
>property-placeholding actually functional, especially since it is
>apparently impossible to predict which beans will fail to have properties
>replaced.  Looking at the sourec code to jndiTemplate, I can see no
>obvious reason why it is treated differently than my own test bean.  Both
>have no annotations and both receive a java.util.Properties object as a
>property.  The behavior is consistent no matter what order they appear in
>my context xml file.
>
>I've attached my replacement SpringContextLoaderListener just for
>reference, in case someone else wants to modify the ordering of the
>placeholders while testing or fixing this.  The relevant web.xml entries
>are below:
>
>  <context-param>
>    <param-name>resteasy.postprocessor.order</param-name>
>    <param-value>0</param-value>
>  </context-param>
>
>  <listener>
>    <listener-class>
>      
>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-clas
>s>
>  </listener>
>
>  <listener>
>    <!-- 
>listener-class>org.jboss.resteasy.plugins.spring.SpringContextLoaderListen
>er</listener-class-->
>    <listener-class>
>        com.westernasset.compliance.util.SpringContextLoaderListener
>    </listener-class>
>  </listener>
>
>
>
>**********************************************************************
>E-mail sent through the Internet is not secure. Western Asset
>therefore recommends that you do not send any confidential or
>sensitive information to us via electronic mail, including social
>security numbers, account numbers, or personal identification
>numbers. Delivery, and or timely delivery of Internet mail is not
>guaranteed. Western Asset therefore recommends that you do not send
>time sensitive or action-oriented messages to us via electronic
>mail. 
>**********************************************************************
>-------------- next part --------------
>An HTML attachment was scrubbed...
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: SpringContextLoaderListener.java
>Type: application/octet-stream
>Size: 3098 bytes
>Desc: SpringContextLoaderListener.java
>
>------------------------------
>
>--------------------------------------------------------------------------
>----
>Precog is a next-generation analytics platform capable of advanced
>analytics on semi-structured data. The platform includes APIs for building
>apps and a phenomenal toolset for data science. Developers can use
>our toolset for easy data analysis & visualization. Get a free account!
>http://www2.precog.com/precogplatform/slashdotnewsletter
>
>------------------------------
>
>_______________________________________________
>Resteasy-developers mailing list
>Res...@li...
>https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>
>End of Resteasy-developers Digest, Vol 62, Issue 1
>**************************************************