[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
>**************************************************