resteasy-users — A general discussion list for the projects end users of RESTEasy.

Re: [Resteasy-users] ClientErrorInterceptor and JAX-RS 2.0 clients

[Peter W. <me...@pe...>]

Hi Bill,

I did, yes - this is the code:

https://github.com/petergeneric/stdlib/blob/e09fc586edbee4d7ff3b5040742726e4bb9a595c/guice/restclient/src/main/java/com/peterphi/std/guice/restclient/resteasy/impl/ResteasyClientErrorInterceptor.java

On 6/30/2014 5:17 PM, Bill Burke wrote:
>What did you do in your clienterrorinterceptor? Convert it to an exception?
>
>
>On 6/30/2014 12:48 PM, Peter Wright wrote:
>> Hi,
>>
>> I’ve been using the (now deprecated) proxy client since resteasy 2. I’m
>> using 3.0.7.Final and am wanting to use WebTarget to build the dynamic
>> proxy using ResteasyClient.target(url).proxy(interface).
>>
>> I use a server-side ExceptionMapper that produces a structured
>> representation of the exception which is then used by the client to
>> produce more descriptive client-side errors about what failed on the
>> server, which server and why. I had been using ClientErrorInterceptor
>> for this, but I see that the new dynamic proxy client no longer uses
>> ClientErrorInterceptor… is there a way to do this in the new dynamic
>> proxy client? I’ve tried using a ReaderInterceptor and DynamicFeature
>> but it doesn’t seem to get called when (for example) a 404 error is
>> returned.
>>
>> Any pointers would be much appreciated.
>>
>> --
>> Peter
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>>
>>
>>
>> _______________________________________________
>> Resteasy-users mailing list
>> Resteasy-users@...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>
>--  
>Bill Burke
>JBoss, a division of Red Hat
>http://bill.burkecentral.com

>  

Re: [Resteasy-users] ClientErrorInterceptor and JAX-RS 2.0 clients

[Bill B. <bb...@re...>]

What did you do in your clienterrorinterceptor?  Convert it to an exception?


On 6/30/2014 12:48 PM, Peter Wright wrote:
> Hi,
>
> I’ve been using the (now deprecated) proxy client since resteasy 2. I’m
> using 3.0.7.Final and am wanting to use WebTarget to build the dynamic
> proxy using ResteasyClient.target(url).proxy(interface).
>
> I use a server-side ExceptionMapper that produces a structured
> representation of the exception which is then used by the client to
> produce more descriptive client-side errors about what failed on the
> server, which server and why. I had been using ClientErrorInterceptor
> for this, but I see that the new dynamic proxy client no longer uses
> ClientErrorInterceptor… is there a way to do this in the new dynamic
> proxy client? I’ve tried using a ReaderInterceptor and DynamicFeature
> but it doesn’t seem to get called when (for example) a 404 error is
> returned.
>
> Any pointers would be much appreciated.
>
> --
> Peter
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
>
>
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-users] ClientErrorInterceptor and JAX-RS 2.0 clients

[Peter W. <me...@pe...>]

Hi,

I’ve been using the (now deprecated) proxy client since resteasy 2. I’m using 3.0.7.Final and am wanting to use WebTarget to build the dynamic proxy using ResteasyClient.target(url).proxy(interface).

I use a server-side ExceptionMapper that produces a structured representation of the exception which is then used by the client to produce more descriptive client-side errors about what failed on the server, which server and why. I had been using ClientErrorInterceptor for this, but I see that the new dynamic proxy client no longer uses ClientErrorInterceptor… is there a way to do this in the new dynamic proxy client? I’ve tried using a ReaderInterceptor and DynamicFeature but it doesn’t seem to get called when (for example) a 404 error is returned. 

Any pointers would be much appreciated.

-- 
Peter

Re: [Resteasy-users] Stacktrace in logs when throwing WebApplicationException

[Bill B. <bb...@re...>]

Resteasy logs these exceptions.  You'd ahve to filter out this in your
logger config.

On 6/24/2014 11:48 PM, Johnson, Shawn [USA] wrote:
> I am using Resteasy 2.3.3, bundled with JBoss-AS-7.1.3.  I'm trying to
> throw a new WebAppliationException, and the output (to the client) seems
> fine, but I'm left with an unwanted stack trace in my log.  I have a few
> other Exceptions mapped, and I was wondering if the mapping was somehow
> causing an issue ­ trying to wrap this Exception.
> 
> Simple example:
> 
> public class SimpleService {
> 
> 	@GET
> 	@Path("stuff")
> 	public String getStuff(final @QueryParam("param1") String param1,
> @QueryParam("param2") String param2) throws ActionException {
> 	if (param1==null && param2==null) {
> 			throw new WebApplicationException();
> 	}
> 
> I get the following exception: [WARN]
> org.jboss.resteasy.core.SynchronousDispatcher#error - failed to execute:
> javax.ws.rs.WebApplicationException
> 
> Any ideas what this error might mean?
> 
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
> 

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-users] Stacktrace in logs when throwing WebApplicationException

[Johnson, S. [USA] <joh...@ba...>]

I am using Resteasy 2.3.3, bundled with JBoss-AS-7.1.3.  I'm trying to
throw a new WebAppliationException, and the output (to the client) seems
fine, but I'm left with an unwanted stack trace in my log.  I have a few
other Exceptions mapped, and I was wondering if the mapping was somehow
causing an issue ­ trying to wrap this Exception.

Simple example:

public class SimpleService {

	@GET
	@Path("stuff")
	public String getStuff(final @QueryParam("param1") String param1,
@QueryParam("param2") String param2) throws ActionException {
	if (param1==null && param2==null) {
			throw new WebApplicationException();
	}

I get the following exception: [WARN]
org.jboss.resteasy.core.SynchronousDispatcher#error - failed to execute:
javax.ws.rs.WebApplicationException

Any ideas what this error might mean?

Re: [Resteasy-users] How to remove headers from resteasy Response

[Weinan Li <l.w...@gm...>]

Maybe you can use ResponseBuilder to build a custom response?

In addition:

"While @Cache builds a complex Cache-Control header, @NoCache is a simplified notation to say that you don't want anything cached i.e. Cache-Control: nocache.”

On Jun 24, 2014, at 10:34 PM, ignou_mca <bbs...@co...> wrote:

> Hi Team,
>      On one of my application I don't want the headers Pragma and Cache-
> Control but these headers are always coming in  Response as below
> 
> Pragma: No-cache 
> Cache-Control: no-cache
> How I can remove those?
> 
> 
> Thanks
> BBSR
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users

[Resteasy-users] How to remove headers from resteasy Response

[ignou_mca <bbs...@co...>]

Hi Team,
      On one of my application I don't want the headers Pragma and Cache-
Control but these headers are always coming in  Response as below

Pragma: No-cache 
Cache-Control: no-cache
How I can remove those?


Thanks
BBSR

Re: [Resteasy-users] Performance issue resteasy+s-ramp

[Eric W. <eri...@re...>]

Sure thing:

https://issues.jboss.org/browse/RESTEASY-1074

I'm not sure about timeframe.  I have a workaround (see the jira for 
details) that should be sufficient unless running with a security 
manager.  The impact on our app is relatively low, as "any other jaxb 
object" is not used in the context of a Feed in too many use cases.

Also, you might have us confused with someone else - we're definitely 
not using Jersey.  :)

-Eric

On 6/13/2014 10:26 AM, Bill Burke wrote:
> So, it should use the jaxb context cache.
>
> Log a jira?  Timeframe for fix?  I promised Mark I'd meet any of your
> requirements so you could get off of Jersey.
>
> On 6/13/2014 10:12 AM, Eric Wittmann wrote:
>> We're using RE to provide the Atom API in our jboss overlord s-ramp
>> implementation.  Something we've run into is a performance problem
>> iterating over certain Atom Feeds.  In some circumstances each Entry in
>> the atom Feed can wrap an additional jaxb object.  We get access to this
>> via Entry's getAnyOtherJAXBObject.
>>
>> This all works great except that there is no JAXBContextFinder set on
>> the Entry, so a new JAXBContext is created for each Entry.
>>
>> I think the root of this problem is here:
>>
>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/providers/resteasy-atom/src/main/java/org/jboss/resteasy/plugins/providers/atom/AtomFeedProvider.java#L65-L68
>>
>> Perhaps the finder should be set on the Entry either in all cases or
>> maybe only when Entry:getAnyOtherElement() returns a non-null?
>>
>> -Eric
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>

Re: [Resteasy-users] Performance issue resteasy+s-ramp

[Bill B. <bb...@re...>]

So, it should use the jaxb context cache.

Log a jira?  Timeframe for fix?  I promised Mark I'd meet any of your 
requirements so you could get off of Jersey.

On 6/13/2014 10:12 AM, Eric Wittmann wrote:
> We're using RE to provide the Atom API in our jboss overlord s-ramp
> implementation.  Something we've run into is a performance problem
> iterating over certain Atom Feeds.  In some circumstances each Entry in
> the atom Feed can wrap an additional jaxb object.  We get access to this
> via Entry's getAnyOtherJAXBObject.
>
> This all works great except that there is no JAXBContextFinder set on
> the Entry, so a new JAXBContext is created for each Entry.
>
> I think the root of this problem is here:
>
> https://github.com/resteasy/Resteasy/blob/master/jaxrs/providers/resteasy-atom/src/main/java/org/jboss/resteasy/plugins/providers/atom/AtomFeedProvider.java#L65-L68
>
> Perhaps the finder should be set on the Entry either in all cases or
> maybe only when Entry:getAnyOtherElement() returns a non-null?
>
> -Eric
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-users] Performance issue resteasy+s-ramp

[Eric W. <eri...@re...>]

We're using RE to provide the Atom API in our jboss overlord s-ramp 
implementation.  Something we've run into is a performance problem 
iterating over certain Atom Feeds.  In some circumstances each Entry in 
the atom Feed can wrap an additional jaxb object.  We get access to this 
via Entry's getAnyOtherJAXBObject.

This all works great except that there is no JAXBContextFinder set on 
the Entry, so a new JAXBContext is created for each Entry.

I think the root of this problem is here:

https://github.com/resteasy/Resteasy/blob/master/jaxrs/providers/resteasy-atom/src/main/java/org/jboss/resteasy/plugins/providers/atom/AtomFeedProvider.java#L65-L68

Perhaps the finder should be set on the Entry either in all cases or 
maybe only when Entry:getAnyOtherElement() returns a non-null?

-Eric

[Resteasy-users] How to use XmlNamespacePrefixMapper

[<ti...@tw...>]

Hello,

Can anyone tell me how to use the XmlNamespacePrefixMapper included in RestEasy?
I tried different approaches, but it did not work and documentation seem to be
very rare...

Anyone having any experiance with altering the namespace prefixes for the
resulting XML from a ReatEasy call?

Best Regards,
Till

Re: [Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?

[Bill B. <bb...@re...>]

On 6/7/2014 5:51 PM, Heiko W.Rupp wrote:
> Hey Bill,
>
> thanks for your reply.
>
> Am 07.06.2014 um 22:08 schrieb Bill Burke <bb...@re...>:
>
>> Unfortunately, the JAX-RS TCK expects that the MBW is not matched until
>> after the WriterInterceptor is invoked.   We used to match prior to
>
> What a c$%@!
>
>> invoking the interceptor chain...
>
> Which makes so much sense
>
>>
>> So, you have 2 options:
>>
>> 1. In your WriterInterceptor buffer the json marshalling, change the
>> content header, flush the buffer.
>
> I have this block in aroundWriteTo:
>
>              try {
>                  context.proceed();
>              } finally {
>                  context.getHeaders().get("Content-Type").clear();
>                  context.getHeaders().putSingle("Content-Type",APPLICATION_JAVASCRIPT);
>              }
>


> But that header change is not recorded in the output.
> And when I understand you correctly above, this would be an issue anyway,
> because the changed header would influence the MBW matcher which runs after the interceptor.
>

Headers get flushed and can't be changed after the entity has been 
written to the stream.

Again, you'll have to buffer the entity and rewrite it to the actual 
stream after you've changed the content-type header.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-users] question about CORS

[Bill B. <bb...@re...>]

There is no good way to implement this in 2.3.x.  You would have to 
write a resource class to handle all preflight OPTIONS requests. 
Depending on how you want to validate origins, you'd have to write a 
PreProcessInterceptor and PostProcessInterceptor and @Context inject a 
HttpResponse or HttpRequest respectively.

FYI, 2.3.x is retired in the community and support and updates are only 
available by subscription.  3.0.x has been out for a year and can be 
installed on top of AS7 or EAP 6.x


On 6/9/2014 11:50 AM, Gervasio Amy wrote:
> Hello all,
>
> I'm a RESTEasy 2.3.5 version user and I experiencing some issues while
> trying to enable CORS.
> I'm using this CORS filter implementation
> <http://software.dzhuvinov.com/cors-filter.html> (which is basically a
> servlet filter) and it works well for successful responses, but when I
> have to handle errors through ExceptionMapper, which returns a new
> response (for ex. Response.status(Response.Status.FORBIDDEN).build()) it
> removes the CORS headers previously set by the filter mentioned.
>
> I saw there a new CorsFilter
> <https://github.com/resteasy/Resteasy/blob/70e918d9bbcd534ce177ae5b0a62b46408cf51e5/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/plugins/interceptors/CorsFilter.java> created
> in 3.0.7 version, based on interceptors.
>
> So, my question is: how would I implement CORS in a application which
> uses previous version of RESTEasy?
>
> Thanks in advance,
>
> Gervasio
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://www.hpccsystems.com
>
>
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-users] question about CORS

[Gervasio A. <ger...@gl...>]

Hello all,

I'm a RESTEasy 2.3.5 version user and I experiencing some issues while
trying to enable CORS.
I'm using this CORS filter implementation
<http://software.dzhuvinov.com/cors-filter.html> (which is basically a
servlet filter) and it works well for successful responses, but when I have
to handle errors through ExceptionMapper, which returns a new response (for
ex. Response.status(Response.Status.FORBIDDEN).build()) it removes the CORS
headers previously set by the filter mentioned.

I saw there a new CorsFilter
<https://github.com/resteasy/Resteasy/blob/70e918d9bbcd534ce177ae5b0a62b46408cf51e5/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/plugins/interceptors/CorsFilter.java>
created
in 3.0.7 version, based on interceptors.

So, my question is: how would I implement CORS in a application which uses
previous version of RESTEasy?

Thanks in advance,

Gervasio

Re: [Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?

[Heiko W.R. <hr...@re...>]

Hey Bill,

thanks for your reply.

Am 07.06.2014 um 22:08 schrieb Bill Burke <bb...@re...>:

> Unfortunately, the JAX-RS TCK expects that the MBW is not matched until 
> after the WriterInterceptor is invoked.   We used to match prior to 

What a c$%@!

> invoking the interceptor chain...

Which makes so much sense

> 
> So, you have 2 options:
> 
> 1. In your WriterInterceptor buffer the json marshalling, change the 
> content header, flush the buffer.

I have this block in aroundWriteTo:

            try {
                context.proceed();
            } finally {
                context.getHeaders().get("Content-Type").clear();
                context.getHeaders().putSingle("Content-Type",APPLICATION_JAVASCRIPT);
            }

But that header change is not recorded in the output.
And when I understand you correctly above, this would be an issue anyway,
because the changed header would influence the MBW matcher which runs after the interceptor.


> 2. Write a special MBW that delegates to the JSON writer and sets the 
> content header before doing this.

Sounds like a plan to investigate.

Thanks
  Heiko

> 
> Make sense?
> 
> On 6/7/2014 1:00 PM, Heiko W.Rupp wrote:
>> Hey,
>> 
>> I have a use case where the user is requesting jsonp encoding e.g. via custom media type or a .jsonw ending.
>> 
>> Anyway. I can intercept the call and surround with "jsonp();" successfully, but the returned
>> content-type needs to be changed to "application/javascript".
>> 
>> I could accept that as incoming type, but then RE is complaining about no matching MessageBodyWriter.
>> 
>> So I am thinking of using ContainerWriteFilter to re-write this, but the calls seem to be
>> 
>> MessageHandler method (@GET foo() {} )  (1)
>> ContainerWriteFilter   (2)
>> <message body writer> (3)
>> WriterInterceptor. (4)
>> (5)
>> 
>> So when I rewrite the content header in (2) a the mbw in (3) complains about wrong type and
>> in (4) I can not check if the desired content type is my custom one to request the wrapping or not.
>> 
>> So I would need to run a ContainerWriteFilter at (5) to rewrite the header *after* the interceptor has run.
>> 
>> In RHQ I solved that with a normal servlet filter, but it looks like this does not work here because
>> of Async processing (and rewriting the filter with an AsyncListener has its own issues )
>> 
>> Thanks
>>    Heiko
>> 
>> 
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, 
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters

Re: [Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?

[Bill B. <bb...@re...>]

Unfortunately, the JAX-RS TCK expects that the MBW is not matched until 
after the WriterInterceptor is invoked.   We used to match prior to 
invoking the interceptor chain...

So, you have 2 options:

1. In your WriterInterceptor buffer the json marshalling, change the 
content header, flush the buffer.

2. Write a special MBW that delegates to the JSON writer and sets the 
content header before doing this.

Make sense?

On 6/7/2014 1:00 PM, Heiko W.Rupp wrote:
> Hey,
>
> I have a use case where the user is requesting jsonp encoding e.g. via custom media type or a .jsonw ending.
>
> Anyway. I can intercept the call and surround with "jsonp();" successfully, but the returned
> content-type needs to be changed to "application/javascript".
>
> I could accept that as incoming type, but then RE is complaining about no matching MessageBodyWriter.
>
> So I am thinking of using ContainerWriteFilter to re-write this, but the calls seem to be
>
> MessageHandler method (@GET foo() {} )  (1)
> ContainerWriteFilter   (2)
> <message body writer> (3)
> WriterInterceptor. (4)
> (5)
>
> So when I rewrite the content header in (2) a the mbw in (3) complains about wrong type and
> in (4) I can not check if the desired content type is my custom one to request the wrapping or not.
>
> So I would need to run a ContainerWriteFilter at (5) to rewrite the header *after* the interceptor has run.
>
> In RHQ I solved that with a normal servlet filter, but it looks like this does not work here because
> of Async processing (and rewriting the filter with an AsyncListener has its own issues )
>
> Thanks
>     Heiko
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?

[Heiko W.R. <hr...@re...>]

Hey,

I have a use case where the user is requesting jsonp encoding e.g. via custom media type or a .jsonw ending.

Anyway. I can intercept the call and surround with "jsonp();" successfully, but the returned
content-type needs to be changed to "application/javascript".

I could accept that as incoming type, but then RE is complaining about no matching MessageBodyWriter.

So I am thinking of using ContainerWriteFilter to re-write this, but the calls seem to be

MessageHandler method (@GET foo() {} )  (1)
ContainerWriteFilter   (2)
<message body writer> (3)
WriterInterceptor. (4)
(5)

So when I rewrite the content header in (2) a the mbw in (3) complains about wrong type and
in (4) I can not check if the desired content type is my custom one to request the wrapping or not.

So I would need to run a ContainerWriteFilter at (5) to rewrite the header *after* the interceptor has run.

In RHQ I solved that with a normal servlet filter, but it looks like this does not work here because
of Async processing (and rewriting the filter with an AsyncListener has its own issues )

Thanks
   Heiko

[Resteasy-users] Performing XSD validation on incoming REST calls - implementing MessageBodyReaderInterceptor...question about MessageBodyReaderContext.getInputStream()

[Scot F. <sf...@re...>]

All, 

I am attempting to perform XSD validation on incoming XML to REST. I'm using REST 2.3.7.Final (in EAP 6.2.2.GA). 

I found a few decent articles...one discussing @Decorator / @DecoratorTypes ( http://stackoverflow.com/questions/7570326/jboss-resteasy-jax-rs-jaxb-schema-validation-with-decorator/ )..also found a few references to defining a MessageBodyReaderInterceptor (additionally noting its in the 2.3.7 docs - http://docs.jboss.org/resteasy/docs/2.3.7.Final/userguide/html_single/#MessageBodyInterceptors ). 

I initially considered using the @Decorator option - but decided against it as I'll need to annotate a bunch of params on a bunch of methods across a bunch of classes. Truthfully, I'll want XSD validation enabled for all calls - which is why I'm leaning toward MessageBodyReaderInterceptor. 

As a side note, I was able to get both options working. Only caveat is with the MessageBodyReaderInterceptor - it works, but I am hesitant to consider the "working" version working "correctly." I'll explain shortly... 

I note the documentation states " You must call MessageBodyReaderContext.proceed() or MessageBodyWriterContext.proceed() to go to the next interceptor or, if there are no more interceptors to invoke, the readFrom() or writeTo() method of the MessageBodyReader or MessageBodyWriter." In order for me to XSD validate the XML coming over, I have 2 options - I can use a Schema creating a new Validator and having it validate using the MessageBodyReaderContext's input stream...or I can set the schema on an unmarshaller and have it unmarshal an object. The problem is, in both instances I am consuming the input stream. 

I could return the unmarshalled object - but then no more interceptors (if there are any) will get an opportunity to process. If I attempt to return MessageBodyReaderContext.proceed(), the stream is now closed as I consumed it via the unmarshal. I had no luck trying to reset the input stream as I get an IOException "mark/reset not supported." 

I'm certain I'm not seeing the proper way to do this, or am approaching this problem incorrectly. As I mentioned above the MessageBodyReaderContext version I have works if I return the unmarshalled object - but while it works, I think its improper way to deal with this scenario. 

Thanks ahead of time! 

Flossy 





-- 
Make It So Number One 

Re: [Resteasy-users] Why no client.close()?

[Bill B. <bb...@re...>]

THere is a finalize in ApacheHttpClient4Engine.  We actually have a unit 
test that tests GC for responses and clients.

But, you should never rely on finalize.  Its really bad practice.  The 
examples are a poor job on my end if they don't do close.

On 5/28/2014 5:16 PM, Guy Rouillier wrote:
> Thanks for the reply, Bill.  I cloned the RESTEasy repo so I could look
> at the latest source.  I see that ResteasyClient.java has a close()
> method, but no finalize().  So, I suppose the most conservative course
> of action would be to specifically invoke ResteasyClient.close() in a
> finally block for any code that creates an instance.
>
> On 5/28/2014 8:06 AM, Bill Burke wrote:
>> Oh, one more thing.  ResteasyClient does implement finalize and will
>> close during garbage collection.
>>
>> On 5/28/2014 12:49 AM, Guy Rouillier wrote:
>>> The RESTEasy documentation specifically says (section 48.3):
>>>
>>> "Finally, if your javax.ws.rs.client.Client class has created the engine
>>> automatically for you, you should call Client.close() and this will
>>> clean up any socket connections."
>>>
>>> Yet the overwhelming majority of examples I can find, including those
>>> shipped with RESTEasy, do not explicitly invoke Client.close().  Is this
>>> because resource cleanup will eventually be done automatically during
>>> garbage collection?
>>>
>>> We are using the ResteasyClient proxy approach, but that class extends
>>> Client, so I'm assuming the same discussion holds for the proxy.
>>>
>>> Thanks.
>>>
>>
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-users] Why no client.close()?

[Guy R. <guy...@gm...>]

Thanks for the reply, Bill.  I cloned the RESTEasy repo so I could look 
at the latest source.  I see that ResteasyClient.java has a close() 
method, but no finalize().  So, I suppose the most conservative course 
of action would be to specifically invoke ResteasyClient.close() in a 
finally block for any code that creates an instance.

On 5/28/2014 8:06 AM, Bill Burke wrote:
> Oh, one more thing.  ResteasyClient does implement finalize and will
> close during garbage collection.
>
> On 5/28/2014 12:49 AM, Guy Rouillier wrote:
>> The RESTEasy documentation specifically says (section 48.3):
>>
>> "Finally, if your javax.ws.rs.client.Client class has created the engine
>> automatically for you, you should call Client.close() and this will
>> clean up any socket connections."
>>
>> Yet the overwhelming majority of examples I can find, including those
>> shipped with RESTEasy, do not explicitly invoke Client.close().  Is this
>> because resource cleanup will eventually be done automatically during
>> garbage collection?
>>
>> We are using the ResteasyClient proxy approach, but that class extends
>> Client, so I'm assuming the same discussion holds for the proxy.
>>
>> Thanks.
>>
>


-- 
Guy Rouillier

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: [Resteasy-users] Why no client.close()?

[Bill B. <bb...@re...>]

Oh, one more thing.  ResteasyClient does implement finalize and will 
close during garbage collection.

On 5/28/2014 12:49 AM, Guy Rouillier wrote:
> The RESTEasy documentation specifically says (section 48.3):
>
> "Finally, if your javax.ws.rs.client.Client class has created the engine
> automatically for you, you should call Client.close() and this will
> clean up any socket connections."
>
> Yet the overwhelming majority of examples I can find, including those
> shipped with RESTEasy, do not explicitly invoke Client.close().  Is this
> because resource cleanup will eventually be done automatically during
> garbage collection?
>
> We are using the ResteasyClient proxy approach, but that class extends
> Client, so I'm assuming the same discussion holds for the proxy.
>
> Thanks.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-users] Why no client.close()?

[Bill B. <bb...@re...>]

The examples are bad examples of clean code.

On 5/28/2014 12:49 AM, Guy Rouillier wrote:
> The RESTEasy documentation specifically says (section 48.3):
>
> "Finally, if your javax.ws.rs.client.Client class has created the engine
> automatically for you, you should call Client.close() and this will
> clean up any socket connections."
>
> Yet the overwhelming majority of examples I can find, including those
> shipped with RESTEasy, do not explicitly invoke Client.close().  Is this
> because resource cleanup will eventually be done automatically during
> garbage collection?
>
> We are using the ResteasyClient proxy approach, but that class extends
> Client, so I'm assuming the same discussion holds for the proxy.
>
> Thanks.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-users] Why no client.close()?

[Guy R. <guy...@gm...>]

The RESTEasy documentation specifically says (section 48.3):

"Finally, if your javax.ws.rs.client.Client class has created the engine 
automatically for you, you should call Client.close() and this will 
clean up any socket connections."

Yet the overwhelming majority of examples I can find, including those 
shipped with RESTEasy, do not explicitly invoke Client.close().  Is this 
because resource cleanup will eventually be done automatically during 
garbage collection?

We are using the ResteasyClient proxy approach, but that class extends 
Client, so I'm assuming the same discussion holds for the proxy.

Thanks.

-- 
Guy Rouillier

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: [Resteasy-users] Injecting an EJB in a Resteasy Resource authenticated with OAuth 2.0

[JOSÉ I. DA S. J. <ina...@pr...>]

Thank you for your answer?

What's the better solution?

In my architeture each application is on a specific jboss profile.
Each application has several rest services inside it.
I need a SSO solution including browser authetication and rest access in another application.
The transactional control is implemented with EJB, so I need security context propagation too.
My users and roles backend is in a OpenLDAP Server and I have a customized login module to access it.

Resteasy OAUTH2 doesn't deal with ejb authentication.
SSO valve works well, but only between apps in the same profile.

What's the better solution to my environment? PicketLink, Keycloack or another one?


Thanks in advance!
Inácio

Re: [Resteasy-users] RESTEasy Client in OSGi Environment

[Eric W. <eri...@re...>]

I think I can confirm that this is the problem.  We ran into this same 
issue when using the RE client in Fuse (also an OSGi environment).  It 
is not possible to export META-INF/* resources in an OSGi bundle.  This 
makes java ServiceLoader useless as a dynamic service discovery 
mechanism.  As a workaround we had to add the RE client's Providers spec 
file to our own WAR:

https://github.com/Governance/s-ramp/tree/master/s-ramp-ui/s-ramp-ui-war-fuse61/src/main/resources/META-INF/services

It's not ideal, but it's the only way we could get it working without 
modifying RE to support OSGi.

For the record, the latter wouldn't be too hard - but would likely 
require that RE look for providers in both 
META-INF/services/javax.ws.rs.ext.Providers as well as the OSGi Service 
Registry.

-Eric

On 5/23/2014 10:57 AM, Bill Burke wrote:
> I know nothing about OSGi.
>
> My guess is that Resteasy automatic provider lookup is not working.  The
> way it works is that it does a
> Classloader.getResources("META-INF/javax.ws.rs.ext.Providers") and
> iterates througha nd loads all those files.  Those files contain Java
> class names which represent the providers.
>
> On 5/23/2014 9:26 AM, Rohrberg, Timo wrote:
>> Hello everybody,
>>
>> I am currently trying to use the RESTEasy client framework within an
>> OSGi environment (Eclipse Equinox). To provide the required
>> dependencies, I created a separate Eclipse Plug-In containing the
>> required JAR libraries and exporting the contained packages to
>> downstream bundles. Then, I am using the RESTEasy client framework as
>> follows within my main bundle which includes the before mentioned bundle
>> as required bundle:
>>
>> ResteasyClient client = *new*ResteasyClientBuilder().build();
>>
>> ResteasyWebTarget target = client
>>
>> .target(
>> _"http://192.168.100.181:5952/RXT_RESTWebService-2.1/jobtemplates/Vitaphone
>> 300 BT/386340"_);
>>
>> RxtDevice device = target.request().get( RxtDevice.*class*);
>>
>> System./out/.println( device.getId() );
>>
>> Unfortunately, I always get the following error:
>>
>> _javax.ws.rs.client.ResponseProcessingException_:
>> _javax.ws.rs.ProcessingException_: Unable to find a MessageBodyReader of
>> content-type application/xml and type class
>> com.vitasystems.remosxt.rest.client.model.RxtDevice
>>
>>         at
>> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(_ClientInvocation.java:140_)
>>
>>         at
>> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(_ClientInvocation.java:444_)
>>
>>         at
>> org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.get(_ClientInvocationBuilder.java:165_)
>>
>>         at
>> de.vitasystems.example.resteasy.client.Activator.start(_Activator.java:25_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(_BundleContextImpl.java:711_)
>>
>>         at java.security.AccessController.doPrivileged(_Native Method_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(_BundleContextImpl.java:702_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(_BundleContextImpl.java:683_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(_BundleHost.java:381_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(_AbstractBundle.java:390_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(_Framework.java:1176_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(_StartLevelManager.java:559_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(_StartLevelManager.java:544_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(_StartLevelManager.java:457_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(_StartLevelManager.java:243_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(_StartLevelManager.java:438_)
>>
>>         at
>> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(_StartLevelManager.java:1_)
>>
>>         at
>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(_EventManager.java:230_)
>>
>>         at
>> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(_EventManager.java:340_)
>>
>> Caused by: _javax.ws.rs.ProcessingException_: Unable to find a
>> MessageBodyReader of content-type application/xml and type class
>> com.vitasystems.remosxt.rest.client.model.RxtDevice
>>
>>         at
>> org.jboss.resteasy.core.interception.ClientReaderInterceptorContext.throwReaderNotFound(_ClientReaderInterceptorContext.java:39_)
>>
>>         at
>> org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.getReader(_AbstractReaderInterceptorContext.java:73_)
>>
>>         at
>> org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(_AbstractReaderInterceptorContext.java:50_)
>>
>>         at
>> org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom(_GZIPDecodingInterceptor.java:59_)
>>
>>         at
>> org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(_AbstractReaderInterceptorContext.java:53_)
>>
>>         at
>> org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom(_ClientResponse.java:245_)
>>
>>         at
>> org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readEntity(_ClientResponse.java:179_)
>>
>>         at
>> org.jboss.resteasy.specimpl.BuiltResponse.readEntity(_BuiltResponse.java:211_)
>>
>>         at
>> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(_ClientInvocation.java:104_)
>>
>>         ... 18 more
>>
>> By debugging the included libraries, I tracked the problem down to the
>> following location:
>>
>> ResteasyProviderFactory.java
>>
>> *protected*<T> MessageBodyReader<T> resolveMessageBodyReader(Class<T>
>> type, Type genericType, Annotation[] annotations, MediaType mediaType,
>> MediaTypeMap<SortedKey<MessageBodyReader>> availableReaders)
>>
>> {
>>
>> List<SortedKey<MessageBodyReader>> readers =
>> availableReaders.getPossible(mediaType, type);
>>
>> //logger.info("******** getMessageBodyReader *******");
>>
>> *for*(SortedKey<MessageBodyReader> reader : readers)
>>
>> {
>>
>> //logger.info("     matching reader: " + reader.getClass().getName());
>>
>> *if*(reader.obj.isReadable(type, genericType, annotations, mediaType))
>>
>> {
>>
>> *return*(MessageBodyReader<T>) reader.obj;
>>
>> }
>>
>> }
>>
>> *return**null*;
>>
>> }
>>
>> The problem is a little weired: The readers list of MessageBodyReader
>> instances contains the
>> org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlRootElementProvider,
>> but the reader.obj.isReadable() method returns false for that reader.
>>
>> In another setup as a plain Maven project outside of the OSGi world, the
>> the referred method reader.obj.isReadable() returns true and the same
>> piece of code works.
>>
>> I am at the end of my knowledge… Do you guys have any hints?
>>
>> Best regards,
>>
>> Timo Rohrberg
>>
>>
>> ------------------------------------------------------------------------
>> Hinweis: Diese Email enthält evtl. vertrauliche und rechtlich geschützte
>> Informationen. Sollten Sie nicht der richtige Adressat sein oder diese
>> Email irrtümlich erhalten haben, informieren Sie bitte sofort den Absender,
>> und löschen Sie anschließend diese E-Mail. Das unerlaubte Kopieren sowie
>> die unbefugte Weitergabe des Inhalts dieser Email sind nicht gestattet.
>>
>> Attention: This e-mail may contain confidential and/or privileged
>> information. If you are not the intended recipient or if you have received
>> this e-mail in error, please notify the sender immediately and delete this
>> e-mail. Any unauthorized copying, disclosure or distribution of the
>> contents of this e-mail is strictly prohibited.
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>>
>>
>>
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>