resteasy-developers — The main list for RESTEasy developers to discuss project development

Re: [Resteasy-developers] How the resources (@Path, ...) are scanned

[Weinan Li <we...@re...>]

Hi Charles,

Sorry I'm not sure whether I understand your question correctly, so please forgive me if I'm wrong :-)

To start a Resteasy container, first we need to create a ResteasyDeployment instance and initialize it:

ResteasyDeployment deployment = new ResteasyDeployment();
deployment.start();

Then we can register any resources into it:

deployment.getActualResourceClasses().add(SimpleResource.class);

Or you can also directly add into Registry class:

deployment.getRegistry().addPerRequestResource(Resource.class);

Because in ResteasyDeployment itself it's like:

if (resources != null)
{
   for (Object obj : resources)
   {
      registry.addSingletonResource(obj);
   }
}

for (Class actualResourceClass : actualResourceClasses)
{
   registry.addPerRequestResource(actualResourceClass);
}

for (ResourceFactory factory : resourceFactories)
{
   registry.addResourceFactory(factory);
}

All the scanners are implemented based on above logics. Here are some scanner examples:

https://github.com/wildfly/wildfly/blob/0c68aa0ebef3682e9ded4b473e24463b3e31af07/jaxrs/src/main/java/org/jboss/as/jaxrs/deployment/JaxrsScanningProcessor.java

https://github.com/resteasy/Resteasy/blob/85862364f1464532ceb2e5227fbbb214339fd73d/jaxrs/resteasy-servlet-initializer/src/main/java/org/jboss/resteasy/plugins/servlet/ResteasyServletInitializer.java

Hope the info is useful to you :-)


--
Weinan Li / JBoss

> On Dec 2, 2015, at 3:20 AM, Charles Moulliard <cmo...@re...> wrote:
> 
> Hi,
> 
> I'm currently working on Resteasy to deploy it on JBoss Fuse (= Apache Karaf OSGI container). I have been able to shade the Resteasy project in order to generate the OSGI MANIFEST file and to solve some TCCL issues like also to inject the BeanManager on OSGI but I can't use the option resteasy.scan = true
> 
> Can somebody tell me where into the code of the api we scan the resources ?
> 
> Regards,
> -- 
> Charles Moulliard
> Principal Solution Architect / JBoss Fuse Expert - Global Enablement @redhat
> cmo...@re... | work: +31 205 65 12 84 | mobile: +32 473 604 014
> MC-Square Business "Stockholm", Leonardo Da Vincilaan 19, Diegem 1831 - Belgium
> twitter: @cmoulliard | blog: cmoulliard.github.io
> committer: apache camel, karaf, servicemix, hawtio, fabric8, drools, jbpm, deltaspike
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140_______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

[Resteasy-developers] How the resources (@Path, ...) are scanned

[Charles M. <cmo...@re...>]

Hi,

I'm currently working on Resteasy to deploy it on JBoss Fuse (= Apache 
Karaf OSGI container). I have been able to shade the Resteasy project in 
order to generate the OSGI MANIFEST file and to solve some TCCL issues 
like also to inject the BeanManager on OSGI but I can't use the option 
resteasy.scan = true

Can somebody tell me where into the code of the api we scan the resources ?

Regards,
-- 
Charles Moulliard
Principal Solution Architect / JBoss Fuse Expert - Global Enablement @redhat
cmo...@re... | work: +31 205 65 12 84 | mobile: +32 473 604 014
MC-Square Business "Stockholm", Leonardo Da Vincilaan 19, Diegem 1831 - 
Belgium
twitter: @cmoulliard <http://twitter.com/cmoulliard> | blog: 
cmoulliard.github.io <http://cmoulliard.github.io>
committer: apache camel, karaf, servicemix, hawtio, fabric8, drools, 
jbpm, deltaspike

[Resteasy-developers] PR review status 2015-11-30

[Weinan Li <we...@re...>]

# PR review status 2015-11-30

MERGED:
PR706 - add netty container tests
PR704 - RESTEASY-1202 Bump Jackson to 2.6.3 #704
PR524 - RESTEASY-715 Add prefix support for @QueryParam

IN PROGRESS:
PR697 / PR683 / PR673 / PR704
https://github.com/resteasy/Resteasy/pull/697 <- I feel this is okay, but maybe not complete?
https://github.com/resteasy/Resteasy/pull/683 <- I feel this is okay.
https://github.com/resteasy/Resteasy/pull/673 <- This one looks good to me and just need cleanup.

CLOSED:
PR634 - Tidy up documentation (chapters 24-55)

TODO:
RESTEASY-1202

After Ron checked the relative PRs I'll release 3.0.14.Final this week.

--
Weinan Li / JBoss

Re: [Resteasy-developers] Pull Requests Reviewing Status 2015-11-23

[Weinan Li <we...@re...>]

I'll release 3.0.14 in Decemember. Now I’m waiting for several PRs to be reviewed by Ron. After it’s done we’ll announce 3.0.14.

--
Weinan Li / JBoss



> On Nov 23, 2015, at 10:18 PM, Larry Meadors <lar...@gm...> wrote:
> 
> Will 3.0.14 snapshots be in the maven repo or do we need to roll our own?
> 
> Larry
> 
> 
> On Mon, Nov 23, 2015 at 12:34 AM, Weinan Li <we...@re...> wrote:
>> As many people are concerning what’s the progress of RESTEasy development. Let me send the PR reviewing status here. I can’t make sure I can send it weekly but I’ll try my best :-)
>> 
>> # 2015-11-09
>> 
>> MERGED:
>> 
>> PR693 - Guice fix: Register generic @Providers
>> PR691 - RESTEASY-1248: Fix cache expired time and prevent for NullPointerException #691
>> PR690 - RESTEASY-1247: RESTEasy do not close resources everywhere
>> PR695 - RESTEASY-810 SpringBeanProcessor does not process factory method beans correctly
>> PR688 - RESTEASY-1243 Expose the ability to set max sizes in http requests for Netty 4
>> PR686 - overrided by PR688 so I closed it.
>> PR692 - RESTEASY-166 bugfix - support multiple application classes
>> PR681 - remove use of System.out.println for logging
>> PR684 - Support for not defined Matrix Parameter
>> PR680 - fix map and list form xml types #680
>> 
>> # 2015-11-16
>> 
>> MERGED:
>> 
>> PR675 - Properties from javax.ws.rs.core.Application.getProperties are not registered
>> PR657 - [BZ1247859] Upgrade spring dependency to mitigate security issues inspring. Triggering Travis CI build.
>> PR696 - RESTEASY-1261 Use queryStringEncoding for the fragment #696
>> PR698 - [RESTEASY-1182] DataSourceProvider produces FileNotFoundException
>> PR699 - [JBEAP-1904] DataSourceProvider produces FileNotFoundException
>> PR701 - RESTEASY-1256 missing Configuration resource in context data
>> PR703 - RESTEASY-166 make resteasy wadl work with embedded container
>> PR705 - RESTEASY-166 bug fixes + more tests on wadl module
>> 
>> 
>> This week:
>> 
>> IN PROGRESS:
>> PR697 / PR683 / PR673 / PR704
>> 
>> Any comments to pending PRs is welcomed.
>> 
>> --
>> Weinan Li / JBoss
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Go from Idea to Many App Stores Faster with Intel(R) XDK
>> Give your users amazing mobile app experiences with Intel(R) XDK.
>> Use one codebase in this all-in-one HTML5 development environment.
>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
>> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] Pull Requests Reviewing Status 2015-11-23

[Larry M. <lar...@gm...>]

Will 3.0.14 snapshots be in the maven repo or do we need to roll our own?

Larry


On Mon, Nov 23, 2015 at 12:34 AM, Weinan Li <we...@re...> wrote:
> As many people are concerning what’s the progress of RESTEasy development. Let me send the PR reviewing status here. I can’t make sure I can send it weekly but I’ll try my best :-)
>
> # 2015-11-09
>
> MERGED:
>
> PR693 - Guice fix: Register generic @Providers
> PR691 - RESTEASY-1248: Fix cache expired time and prevent for NullPointerException #691
> PR690 - RESTEASY-1247: RESTEasy do not close resources everywhere
> PR695 - RESTEASY-810 SpringBeanProcessor does not process factory method beans correctly
> PR688 - RESTEASY-1243 Expose the ability to set max sizes in http requests for Netty 4
> PR686 - overrided by PR688 so I closed it.
> PR692 - RESTEASY-166 bugfix - support multiple application classes
> PR681 - remove use of System.out.println for logging
> PR684 - Support for not defined Matrix Parameter
> PR680 - fix map and list form xml types #680
>
> # 2015-11-16
>
> MERGED:
>
> PR675 - Properties from javax.ws.rs.core.Application.getProperties are not registered
> PR657 - [BZ1247859] Upgrade spring dependency to mitigate security issues inspring. Triggering Travis CI build.
> PR696 - RESTEASY-1261 Use queryStringEncoding for the fragment #696
> PR698 - [RESTEASY-1182] DataSourceProvider produces FileNotFoundException
> PR699 - [JBEAP-1904] DataSourceProvider produces FileNotFoundException
> PR701 - RESTEASY-1256 missing Configuration resource in context data
> PR703 - RESTEASY-166 make resteasy wadl work with embedded container
> PR705 - RESTEASY-166 bug fixes + more tests on wadl module
>
>
> This week:
>
> IN PROGRESS:
> PR697 / PR683 / PR673 / PR704
>
> Any comments to pending PRs is welcomed.
>
> --
> Weinan Li / JBoss
>
>
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

[Resteasy-developers] Pull Requests Reviewing Status 2015-11-23

[Weinan Li <we...@re...>]

As many people are concerning what’s the progress of RESTEasy development. Let me send the PR reviewing status here. I can’t make sure I can send it weekly but I’ll try my best :-)

# 2015-11-09

MERGED:

PR693 - Guice fix: Register generic @Providers
PR691 - RESTEASY-1248: Fix cache expired time and prevent for NullPointerException #691
PR690 - RESTEASY-1247: RESTEasy do not close resources everywhere
PR695 - RESTEASY-810 SpringBeanProcessor does not process factory method beans correctly
PR688 - RESTEASY-1243 Expose the ability to set max sizes in http requests for Netty 4
PR686 - overrided by PR688 so I closed it.
PR692 - RESTEASY-166 bugfix - support multiple application classes
PR681 - remove use of System.out.println for logging
PR684 - Support for not defined Matrix Parameter
PR680 - fix map and list form xml types #680

# 2015-11-16

MERGED:

PR675 - Properties from javax.ws.rs.core.Application.getProperties are not registered
PR657 - [BZ1247859] Upgrade spring dependency to mitigate security issues inspring. Triggering Travis CI build.
PR696 - RESTEASY-1261 Use queryStringEncoding for the fragment #696
PR698 - [RESTEASY-1182] DataSourceProvider produces FileNotFoundException
PR699 - [JBEAP-1904] DataSourceProvider produces FileNotFoundException
PR701 - RESTEASY-1256 missing Configuration resource in context data
PR703 - RESTEASY-166 make resteasy wadl work with embedded container
PR705 - RESTEASY-166 bug fixes + more tests on wadl module


This week:

IN PROGRESS:
PR697 / PR683 / PR673 / PR704

Any comments to pending PRs is welcomed.

--
Weinan Li / JBoss

[Resteasy-developers] RESTEasy WADL first draft

[Weinan Li <we...@re...>]

Hi,

I have submitted a first draft of resteasy-wadl[1] It’s now a servlet based one. Next step I plan to rewrite it so it can work for embedded container too. In addition, there are bugs in resteasy subresource locator. Any help/contribution is welcomed.

[1] https://github.com/resteasy/Resteasy/tree/master/jaxrs/resteasy-wadl

--
Weinan Li / JBoss

Re: [Resteasy-developers] What's going on with the contributions?

[Weinan Li <we...@re...>]

We are currently fighting with failed tests that randomly makes TravisCI result “broken”(most are caused by pre-closed connections in tests). Any help on this part is welcomed :-)

--
Weinan Li / JBoss



> On Nov 4, 2015, at 1:07 PM, Farid Zakaria <far...@gm...> wrote:
> 
> Well the framework could definitely use some better/more tests.
> 
> It would be great if the framework was at a higher confidence with respect to tests (specifically for the extension modules).
> 
> That would pull in the PRs faster.
> 
> Also wish list: fix ResteasyDatafactory
> 
> On 3 Nov 2015 8:36 p.m., "William Antônio Siqueira" <wil...@gm...> wrote:
> I want to contribute more, if someone could please coach me for a few minutes per day it would be great, like 30 minutes/day! I am in freenode rest channel with nick "wsiqueir"
> 
> Thanks!
> 
> --
> William Antônio Siqueira
> Java Support Analyst
> 
> http://fxapps.blogspot.com
> http://www.williamantonio.wordpress.com
> http://williamprogrammer.com
> 
> 2015-11-04 0:59 GMT-02:00 Weinan Li <we...@re...>:
> Hi Farid,
> 
> Currently Ron and I are focusing on higher priority bug fixes from Wildfly/EAP sides and new features. We’ll try to put more energy on reviewing PRs in future :-)
> 
> --
> Weinan Li / JBoss
> 
> 
> 
> > On Nov 4, 2015, at 7:00 AM, Farid Zakaria <far...@gm...> wrote:
> >
> > I like resteasy however I noticed a significant build up of pull-requests on the GitHub repo.
> > There doesn't seem to be much activity from the maintainers.
> >
> > What's going on ? Has the project stalled ?
> >
> > Cheers,
> > Farid Zakaria
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li...
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 

Re: [Resteasy-developers] What's going on with the contributions?

[Farid Z. <far...@gm...>]

small edit: I meant ResteasyProviderFactory



Farid Zakaria


On Tue, Nov 3, 2015 at 9:07 PM, Farid Zakaria <far...@gm...>
wrote:

> Well the framework could definitely use some better/more tests.
>
> It would be great if the framework was at a higher confidence with respect
> to tests (specifically for the extension modules).
>
> That would pull in the PRs faster.
>
> Also wish list: fix ResteasyDatafactory
> On 3 Nov 2015 8:36 p.m., "William Antônio Siqueira" <
> wil...@gm...> wrote:
>
>> I want to contribute more, if someone could please coach me for a few
>> minutes per day it would be great, like 30 minutes/day! I am in freenode
>> rest channel with nick "wsiqueir"
>>
>> Thanks!
>>
>> --
>> *William Antônio Siqueira*
>> *Java Support Analyst*
>>
>> *http://fxapps.blogspot.com <http://fxapps.blogspot.com>*
>> *http://www.williamantonio.wordpress.com
>> <http://www.williamantonio.wordpress.com>*
>> *http://williamprogrammer.com <http://williamprogrammer.com>*
>>
>> 2015-11-04 0:59 GMT-02:00 Weinan Li <we...@re...>:
>>
>>> Hi Farid,
>>>
>>> Currently Ron and I are focusing on higher priority bug fixes from
>>> Wildfly/EAP sides and new features. We’ll try to put more energy on
>>> reviewing PRs in future :-)
>>>
>>> --
>>> Weinan Li / JBoss
>>>
>>>
>>>
>>> > On Nov 4, 2015, at 7:00 AM, Farid Zakaria <far...@gm...>
>>> wrote:
>>> >
>>> > I like resteasy however I noticed a significant build up of
>>> pull-requests on the GitHub repo.
>>> > There doesn't seem to be much activity from the maintainers.
>>> >
>>> > What's going on ? Has the project stalled ?
>>> >
>>> > Cheers,
>>> > Farid Zakaria
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > _______________________________________________
>>> > Resteasy-developers mailing list
>>> > Res...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Resteasy-developers mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>>
>>
>>

Re: [Resteasy-developers] What's going on with the contributions?

[Farid Z. <far...@gm...>]

Well the framework could definitely use some better/more tests.

It would be great if the framework was at a higher confidence with respect
to tests (specifically for the extension modules).

That would pull in the PRs faster.

Also wish list: fix ResteasyDatafactory
On 3 Nov 2015 8:36 p.m., "William Antônio Siqueira" <
wil...@gm...> wrote:

> I want to contribute more, if someone could please coach me for a few
> minutes per day it would be great, like 30 minutes/day! I am in freenode
> rest channel with nick "wsiqueir"
>
> Thanks!
>
> --
> *William Antônio Siqueira*
> *Java Support Analyst*
>
> *http://fxapps.blogspot.com <http://fxapps.blogspot.com>*
> *http://www.williamantonio.wordpress.com
> <http://www.williamantonio.wordpress.com>*
> *http://williamprogrammer.com <http://williamprogrammer.com>*
>
> 2015-11-04 0:59 GMT-02:00 Weinan Li <we...@re...>:
>
>> Hi Farid,
>>
>> Currently Ron and I are focusing on higher priority bug fixes from
>> Wildfly/EAP sides and new features. We’ll try to put more energy on
>> reviewing PRs in future :-)
>>
>> --
>> Weinan Li / JBoss
>>
>>
>>
>> > On Nov 4, 2015, at 7:00 AM, Farid Zakaria <far...@gm...>
>> wrote:
>> >
>> > I like resteasy however I noticed a significant build up of
>> pull-requests on the GitHub repo.
>> > There doesn't seem to be much activity from the maintainers.
>> >
>> > What's going on ? Has the project stalled ?
>> >
>> > Cheers,
>> > Farid Zakaria
>> >
>> >
>> ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Resteasy-developers mailing list
>> > Res...@li...
>> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>
>

Re: [Resteasy-developers] What's going on with the contributions?

[Weinan Li <we...@re...>]

Hi William,

Anything you want to know you can email me (we...@re...) and Ron (rs...@re...) :-)

--
Weinan Li / JBoss



> On Nov 4, 2015, at 12:36 PM, William Antônio Siqueira <wil...@gm...> wrote:
> 
> I want to contribute more, if someone could please coach me for a few minutes per day it would be great, like 30 minutes/day! I am in freenode rest channel with nick "wsiqueir"
> 
> Thanks!
> 
> --
> William Antônio Siqueira
> Java Support Analyst
> 
> http://fxapps.blogspot.com
> http://www.williamantonio.wordpress.com
> http://williamprogrammer.com
> 
> 2015-11-04 0:59 GMT-02:00 Weinan Li <we...@re...>:
> Hi Farid,
> 
> Currently Ron and I are focusing on higher priority bug fixes from Wildfly/EAP sides and new features. We’ll try to put more energy on reviewing PRs in future :-)
> 
> --
> Weinan Li / JBoss
> 
> 
> 
> > On Nov 4, 2015, at 7:00 AM, Farid Zakaria <far...@gm...> wrote:
> >
> > I like resteasy however I noticed a significant build up of pull-requests on the GitHub repo.
> > There doesn't seem to be much activity from the maintainers.
> >
> > What's going on ? Has the project stalled ?
> >
> > Cheers,
> > Farid Zakaria
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li...
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 

Re: [Resteasy-developers] What's going on with the contributions?

[William A. S. <wil...@gm...>]

I want to contribute more, if someone could please coach me for a few
minutes per day it would be great, like 30 minutes/day! I am in freenode
rest channel with nick "wsiqueir"

Thanks!

--
*William Antônio Siqueira*
*Java Support Analyst*

*http://fxapps.blogspot.com <http://fxapps.blogspot.com>*
*http://www.williamantonio.wordpress.com
<http://www.williamantonio.wordpress.com>*
*http://williamprogrammer.com <http://williamprogrammer.com>*

2015-11-04 0:59 GMT-02:00 Weinan Li <we...@re...>:

> Hi Farid,
>
> Currently Ron and I are focusing on higher priority bug fixes from
> Wildfly/EAP sides and new features. We’ll try to put more energy on
> reviewing PRs in future :-)
>
> --
> Weinan Li / JBoss
>
>
>
> > On Nov 4, 2015, at 7:00 AM, Farid Zakaria <far...@gm...>
> wrote:
> >
> > I like resteasy however I noticed a significant build up of
> pull-requests on the GitHub repo.
> > There doesn't seem to be much activity from the maintainers.
> >
> > What's going on ? Has the project stalled ?
> >
> > Cheers,
> > Farid Zakaria
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li...
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

Re: [Resteasy-developers] What's going on with the contributions?

[Weinan Li <we...@re...>]

Hi Farid,

Currently Ron and I are focusing on higher priority bug fixes from Wildfly/EAP sides and new features. We’ll try to put more energy on reviewing PRs in future :-)

--
Weinan Li / JBoss



> On Nov 4, 2015, at 7:00 AM, Farid Zakaria <far...@gm...> wrote:
> 
> I like resteasy however I noticed a significant build up of pull-requests on the GitHub repo.
> There doesn't seem to be much activity from the maintainers.
> 
> What's going on ? Has the project stalled ?
> 
> Cheers,
> Farid Zakaria
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

[Resteasy-developers] What's going on with the contributions?

[Farid Z. <far...@gm...>]

I like resteasy however I noticed a significant build up of pull-requests
on the GitHub repo.
There doesn't seem to be much activity from the maintainers.

What's going on ? Has the project stalled ?

Cheers,
Farid Zakaria

[Resteasy-developers] ContainerRequestFilter, ContainerResponseFilter bug

[Adrien <ad...@xc...>]

Hi there, 

I will try to explain a bug, I'm not english so please be indulgent :D.

I'm trying to implement a TimedInterceptor on my project like this one : 
https://github.com/xavierbourguignon/metrics-resteasy/blob/e7fe5326ab1b98616619f129813b89f49624b494/src/main/java/com/github/xavierbourguignon/metrics/resteasy/TimedInterceptor.java
My problem, is when I have the method :filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) called, my timer is null because the TimedInterceptor is not pointing to the same object as before.
I checked on RestEasy source to understand and I came up here :https://github.com/resteasy/Resteasy/blob/3.0.13.Final/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/ResourceMethodInvoker.java#L105L105 and L106, my requestFilters and responseFilters are pointing on the same object (TimedInterceptor).
But at this line : 
https://github.com/resteasy/Resteasy/blob/3.0.13.Final/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/spi/ResteasyDeployment.java#L249
A new Singleton is added and that call "public void registryUpdated(JaxrsInterceptorRegistry registry)" on RessourceMethodInvoker. This function rebuild the filters, and by the way loosing my reference to TimedInterceptor...

So I wonder why AcceptHeaderByFileSuffixFilter is added after ? Should be add before ? or maybe the (mediaTypeMappings != null) condition L249 should not pass we don't need this feature...
Or maybe when we rebuild the filters, if it's already exist, juste reassign the previous object ?
If I'm not clear, don't hesitate to tell meThank you

Adrien Carreira






+33(0) 677 452 813
 		 	   		  

Re: [Resteasy-developers] NettyHttpAsyncResponse & HTTP Keep-Alive

[Weinan Li <we...@re...>]

Hi Jamie,

Please feel free to submit PR and please create a JIRA issue relate with the PR: https://issues.jboss.org/projects/RESTEASY

--
Weinan Li / JBoss



> On Oct 26, 2015, at 8:54 PM, Jamie Astin <jam...@gm...> wrote:
> 
> All,
> 
> I write in reference to the Asynchronous HTTP capability of RestEasy. Specifically the NettyHttpAsyncResponse implementation.
> 
> There are numerous ways to complete the NettyHttpAsyncResponse, by calling one of the two overridden resume(...) implementations, or via the cancel() method. Regardless of which of these methods are invoked, they all (in turn) invoke nettyFlush() from their finally blocks.
> 
> The implementation of NettyHttpAsyncResponse.nettyFlush(), within it's own finally block, includes a call to ChannelHandlerContext.close(). This does not check for the presence of a HTTP keep-alive header.
> 
> Thus, I believe that any asynchronous response will result in the HTTP connection being discarded, regardless of requested keep-alive. 
> 
> Is there something I'm missing? Or would it be sensible to send over a pull request with a fix?
> 
> Any thoughts / pointers would be greatly appreciated.
> 
> Jamie.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

[Resteasy-developers] NettyHttpAsyncResponse & HTTP Keep-Alive

[Jamie A. <jam...@gm...>]

All,

I write in reference to the Asynchronous HTTP capability of RestEasy.
Specifically the NettyHttpAsyncResponse implementation.

There are numerous ways to complete the NettyHttpAsyncResponse, by calling
one of the two overridden resume(...) implementations, or via the cancel()
method. Regardless of which of these methods are invoked, they all (in
turn) invoke nettyFlush() from their finally blocks.

The implementation of NettyHttpAsyncResponse.nettyFlush(), within it's own
finally block, includes a call to ChannelHandlerContext.close(). This does
not check for the presence of a HTTP keep-alive header.

Thus, I believe that any asynchronous response will result in the HTTP
connection being discarded, regardless of requested keep-alive.

Is there something I'm missing? Or would it be sensible to send over a pull
request with a fix?

Any thoughts / pointers would be greatly appreciated.

Jamie.

Re: [Resteasy-developers] Json String handling differences in RE versions

[Weinan Li <we...@re...>]

Hi Sean,

If you can create a JIRA issue here: https://issues.jboss.org/projects/RESTEASY and attach the test case that would be very helpful :-)

--
Weinan Li / JBoss



> On Oct 23, 2015, at 2:30 AM, Sean Dawson <sea...@gm...> wrote:
> 
> 
> Am putting together a couple very simplified testcases - where can I put/upload them to ?
> 
> 
> On Wed, Oct 14, 2015 at 4:11 AM, Weinan Li <we...@re...> wrote:
> 
> --
> Weinan Li / JBoss
> 
> 
> 
> > On Oct 14, 2015, at 3:01 AM, Sean Dawson <sea...@gm...> wrote:
> >
> >
> > Ok here's what I've figured out so far:
> >
> > 1.
> > - I can leave off our JsonStringProvider for most things and they just work
> > - so sending and returning Boolean, Integer, String all work fine (boolean and int have issues)
> > - I can't send or receive Object
> >      - somehow, with the old way of doing things, there was an ObjectReader involved that would check JSON tokens or something and figure out that it was a String (for eg)
> >
> > 2.
> > In the past, this got used in BodyEntityExtractor:
> >      Object obj = response.getEntity(method.getReturnType(), method.getGenericReturnType());
> >
> > The new code uses:
> >          GenericType gt = null;
> >          if (method.getGenericReturnType() != null)
> >          {
> >             gt = new GenericType(method.getGenericReturnType());
> >          }
> >          else
> >          {
> >             gt = new GenericType(method.getReturnType());
> >          }
> >          Object obj = ClientInvocation.extractResult(gt, response, method.getAnnotations());
> >
> > And now (due to Java8 or?), the generic return type is T which means it's not null but then cannot be used...
> >
> > java.lang.IllegalArgumentException: Type parameter T not a class or parameterized type whose raw type is a class
> >  at javax.ws.rs.core.GenericType.getClass(GenericType.java:179)
> >  at javax.ws.rs.core.GenericType.<init>(GenericType.java:136)
> >  at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:53)
> >
> > If I say to skip Generic Return Type's with the name T, then it mostly works fine.
> >
> > Any help on any of this?  Thanks.
> >
> >
> 
> Yeah this is useful info. Thanks Sean! Let me think about a solution to this.
> 
> >
> > On Mon, Oct 12, 2015 at 8:40 AM, Sean Dawson <sea...@gm...> wrote:
> >
> > We just wrote our own (I think) and then do...
> >
> > ResteasyProviderFactory.getInstance().providerFactory.registerProvider(JsonStringProvider.class);
> >
> > Client and server side.
> >
> > import java.io.IOException;
> > import java.io.InputStream;
> > import java.io.OutputStream;
> > import java.lang.annotation.Annotation;
> > import java.lang.reflect.Type;
> > import javax.ws.rs.Consumes;
> > import javax.ws.rs.Produces;
> > import javax.ws.rs.WebApplicationException;
> > import javax.ws.rs.core.MediaType;
> > import javax.ws.rs.core.MultivaluedMap;
> > import javax.ws.rs.ext.MessageBodyReader;
> > import javax.ws.rs.ext.MessageBodyWriter;
> > import javax.ws.rs.ext.Provider;
> > import com.fasterxml.jackson.databind.ObjectMapper;
> > @Provider
> > @Produces(MediaType.APPLICATION_JSON)
> > @Consumes(MediaType.APPLICATION_JSON)
> > public class JsonStringProvider implements MessageBodyWriter<String>, MessageBodyReader<String>
> > {
> >  @Override
> >  public boolean isWriteable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType)
> >  {
> >   return type == String.class && MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
> >  }
> >  @Override
> >  public long getSize(String t, Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType)
> >  {
> >   return -1;
> >  }
> >  private static final ObjectMapper mapper = new ObjectMapper();
> >  @Override
> >  public void writeTo(String t, Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType,
> >          MultivaluedMap<String, Object> httpHeaders, OutputStream entityStream) throws IOException, WebApplicationException
> >  {
> >   // TODO: issue of encoding here?
> >   mapper.writeValue(entityStream, t);
> >  }
> >  @Override
> >  public boolean isReadable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType)
> >  {
> >   return type == String.class && MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
> >  }
> >  @Override
> >  public String readFrom(Class<String> type, Type genericType, Annotation[] annotations, MediaType mediaType,
> >          MultivaluedMap<String, String> httpHeaders, InputStream entityStream) throws IOException, WebApplicationException
> >  {
> >   // TODO: issue of encoding here?
> >     return mapper.readValue(entityStream, String.class);
> >  }
> > }
> >
> >
> > On Sat, Oct 10, 2015 at 4:38 AM, Weinan Li <we...@re...> wrote:
> > Hi Sean,
> >
> > Which RESTEasy JSON provider you are using?
> >
> > In addition, could you please provide me some codes so I can verify it?
> >
> > --
> > Weinan Li / JBoss
> >
> >
> >
> > > On Oct 10, 2015, at 1:12 AM, Sean Dawson <sea...@gm...> wrote:
> > >
> > >
> > > There seems to be very little info online about this but I'm guessing most people here know that if you send a String value in the body of a REST call to RestEasy, Jackson complains.
> > >
> > > One of our other devs made a JsonStringProvider which seems super simple (it's readable/writable if it's a String _and_ the type is Json) and it uses a standard ObjectMapper to read/write the value/stream.
> > >
> > > In RE 3.0.11, it seems to work fine in our unit tests - ie. we can makes calls with Strings and things just work - both writeTo and readFrom methods get called.  But in later versions (3.0.13 & 3.0.14), only the writeTo method gets hit and Jackson complains, unless we double quote the strings ("\"message\"").  Most of our code is the same in both places with the exception of moving from the deprecated way of creating proxies to the new/recommended way.
> > >
> > > Any ideas? Is it maybe a classpath issue? Or a different way the provider needs to be registered? Or.... ?
> > >
> > > Thanks.
> > >
> > > ------------------------------------------------------------------------------
> > > _______________________________________________
> > > Resteasy-developers mailing list
> > > Res...@li...
> > > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> >
> >
> >
> 
> 

Re: [Resteasy-developers] Json String handling differences in RE versions

[Sean D. <sea...@gm...>]

Am putting together a couple very simplified testcases - where can I
put/upload them to ?


On Wed, Oct 14, 2015 at 4:11 AM, Weinan Li <we...@re...> wrote:

>
> --
> Weinan Li / JBoss
>
>
>
> > On Oct 14, 2015, at 3:01 AM, Sean Dawson <sea...@gm...>
> wrote:
> >
> >
> > Ok here's what I've figured out so far:
> >
> > 1.
> > - I can leave off our JsonStringProvider for most things and they just
> work
> > - so sending and returning Boolean, Integer, String all work fine
> (boolean and int have issues)
> > - I can't send or receive Object
> >      - somehow, with the old way of doing things, there was an
> ObjectReader involved that would check JSON tokens or something and figure
> out that it was a String (for eg)
> >
> > 2.
> > In the past, this got used in BodyEntityExtractor:
> >      Object obj = response.getEntity(method.getReturnType(),
> method.getGenericReturnType());
> >
> > The new code uses:
> >          GenericType gt = null;
> >          if (method.getGenericReturnType() != null)
> >          {
> >             gt = new GenericType(method.getGenericReturnType());
> >          }
> >          else
> >          {
> >             gt = new GenericType(method.getReturnType());
> >          }
> >          Object obj = ClientInvocation.extractResult(gt, response,
> method.getAnnotations());
> >
> > And now (due to Java8 or?), the generic return type is T which means
> it's not null but then cannot be used...
> >
> > java.lang.IllegalArgumentException: Type parameter T not a class or
> parameterized type whose raw type is a class
> >  at javax.ws.rs.core.GenericType.getClass(GenericType.java:179)
> >  at javax.ws.rs.core.GenericType.<init>(GenericType.java:136)
> >  at
> org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:53)
> >
> > If I say to skip Generic Return Type's with the name T, then it mostly
> works fine.
> >
> > Any help on any of this?  Thanks.
> >
> >
>
> Yeah this is useful info. Thanks Sean! Let me think about a solution to
> this.
>
> >
> > On Mon, Oct 12, 2015 at 8:40 AM, Sean Dawson <sea...@gm...>
> wrote:
> >
> > We just wrote our own (I think) and then do...
> >
> >
> ResteasyProviderFactory.getInstance().providerFactory.registerProvider(JsonStringProvider.class);
> >
> > Client and server side.
> >
> > import java.io.IOException;
> > import java.io.InputStream;
> > import java.io.OutputStream;
> > import java.lang.annotation.Annotation;
> > import java.lang.reflect.Type;
> > import javax.ws.rs.Consumes;
> > import javax.ws.rs.Produces;
> > import javax.ws.rs.WebApplicationException;
> > import javax.ws.rs.core.MediaType;
> > import javax.ws.rs.core.MultivaluedMap;
> > import javax.ws.rs.ext.MessageBodyReader;
> > import javax.ws.rs.ext.MessageBodyWriter;
> > import javax.ws.rs.ext.Provider;
> > import com.fasterxml.jackson.databind.ObjectMapper;
> > @Provider
> > @Produces(MediaType.APPLICATION_JSON)
> > @Consumes(MediaType.APPLICATION_JSON)
> > public class JsonStringProvider implements MessageBodyWriter<String>,
> MessageBodyReader<String>
> > {
> >  @Override
> >  public boolean isWriteable(Class<?> type, Type genericType,
> Annotation[] annotations, MediaType mediaType)
> >  {
> >   return type == String.class &&
> MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
> >  }
> >  @Override
> >  public long getSize(String t, Class<?> type, Type genericType,
> Annotation[] annotations, MediaType mediaType)
> >  {
> >   return -1;
> >  }
> >  private static final ObjectMapper mapper = new ObjectMapper();
> >  @Override
> >  public void writeTo(String t, Class<?> type, Type genericType,
> Annotation[] annotations, MediaType mediaType,
> >          MultivaluedMap<String, Object> httpHeaders, OutputStream
> entityStream) throws IOException, WebApplicationException
> >  {
> >   // TODO: issue of encoding here?
> >   mapper.writeValue(entityStream, t);
> >  }
> >  @Override
> >  public boolean isReadable(Class<?> type, Type genericType, Annotation[]
> annotations, MediaType mediaType)
> >  {
> >   return type == String.class &&
> MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
> >  }
> >  @Override
> >  public String readFrom(Class<String> type, Type genericType,
> Annotation[] annotations, MediaType mediaType,
> >          MultivaluedMap<String, String> httpHeaders, InputStream
> entityStream) throws IOException, WebApplicationException
> >  {
> >   // TODO: issue of encoding here?
> >     return mapper.readValue(entityStream, String.class);
> >  }
> > }
> >
> >
> > On Sat, Oct 10, 2015 at 4:38 AM, Weinan Li <we...@re...> wrote:
> > Hi Sean,
> >
> > Which RESTEasy JSON provider you are using?
> >
> > In addition, could you please provide me some codes so I can verify it?
> >
> > --
> > Weinan Li / JBoss
> >
> >
> >
> > > On Oct 10, 2015, at 1:12 AM, Sean Dawson <sea...@gm...>
> wrote:
> > >
> > >
> > > There seems to be very little info online about this but I'm guessing
> most people here know that if you send a String value in the body of a REST
> call to RestEasy, Jackson complains.
> > >
> > > One of our other devs made a JsonStringProvider which seems super
> simple (it's readable/writable if it's a String _and_ the type is Json) and
> it uses a standard ObjectMapper to read/write the value/stream.
> > >
> > > In RE 3.0.11, it seems to work fine in our unit tests - ie. we can
> makes calls with Strings and things just work - both writeTo and readFrom
> methods get called.  But in later versions (3.0.13 & 3.0.14), only the
> writeTo method gets hit and Jackson complains, unless we double quote the
> strings ("\"message\"").  Most of our code is the same in both places with
> the exception of moving from the deprecated way of creating proxies to the
> new/recommended way.
> > >
> > > Any ideas? Is it maybe a classpath issue? Or a different way the
> provider needs to be registered? Or.... ?
> > >
> > > Thanks.
> > >
> > >
> ------------------------------------------------------------------------------
> > > _______________________________________________
> > > Resteasy-developers mailing list
> > > Res...@li...
> > > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> >
> >
> >
>
>

Re: [Resteasy-developers] Json String handling differences in RE versions

[Weinan Li <we...@re...>]

--
Weinan Li / JBoss



> On Oct 14, 2015, at 3:01 AM, Sean Dawson <sea...@gm...> wrote:
> 
> 
> Ok here's what I've figured out so far:
> 
> 1.
> - I can leave off our JsonStringProvider for most things and they just work
> - so sending and returning Boolean, Integer, String all work fine (boolean and int have issues)
> - I can't send or receive Object
>      - somehow, with the old way of doing things, there was an ObjectReader involved that would check JSON tokens or something and figure out that it was a String (for eg)
> 
> 2.
> In the past, this got used in BodyEntityExtractor:
>      Object obj = response.getEntity(method.getReturnType(), method.getGenericReturnType());
> 
> The new code uses:
>          GenericType gt = null;
>          if (method.getGenericReturnType() != null)
>          {
>             gt = new GenericType(method.getGenericReturnType());
>          }
>          else
>          {
>             gt = new GenericType(method.getReturnType());
>          }
>          Object obj = ClientInvocation.extractResult(gt, response, method.getAnnotations());
> 
> And now (due to Java8 or?), the generic return type is T which means it's not null but then cannot be used...
> 
> java.lang.IllegalArgumentException: Type parameter T not a class or parameterized type whose raw type is a class
>  at javax.ws.rs.core.GenericType.getClass(GenericType.java:179)
>  at javax.ws.rs.core.GenericType.<init>(GenericType.java:136)
>  at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:53)
> 
> If I say to skip Generic Return Type's with the name T, then it mostly works fine.
> 
> Any help on any of this?  Thanks.
> 
> 

Yeah this is useful info. Thanks Sean! Let me think about a solution to this.

> 
> On Mon, Oct 12, 2015 at 8:40 AM, Sean Dawson <sea...@gm...> wrote:
> 
> We just wrote our own (I think) and then do...
> 
> ResteasyProviderFactory.getInstance().providerFactory.registerProvider(JsonStringProvider.class);
> 
> Client and server side.
> 
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.lang.annotation.Annotation;
> import java.lang.reflect.Type;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.Produces;
> import javax.ws.rs.WebApplicationException;
> import javax.ws.rs.core.MediaType;
> import javax.ws.rs.core.MultivaluedMap;
> import javax.ws.rs.ext.MessageBodyReader;
> import javax.ws.rs.ext.MessageBodyWriter;
> import javax.ws.rs.ext.Provider;
> import com.fasterxml.jackson.databind.ObjectMapper;
> @Provider
> @Produces(MediaType.APPLICATION_JSON)
> @Consumes(MediaType.APPLICATION_JSON)
> public class JsonStringProvider implements MessageBodyWriter<String>, MessageBodyReader<String>
> {
>  @Override
>  public boolean isWriteable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType)
>  {
>   return type == String.class && MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
>  }
>  @Override
>  public long getSize(String t, Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType)
>  {
>   return -1;
>  }
>  private static final ObjectMapper mapper = new ObjectMapper();
>  @Override
>  public void writeTo(String t, Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType,
>          MultivaluedMap<String, Object> httpHeaders, OutputStream entityStream) throws IOException, WebApplicationException
>  {
>   // TODO: issue of encoding here?
>   mapper.writeValue(entityStream, t);
>  }
>  @Override
>  public boolean isReadable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType)
>  {
>   return type == String.class && MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
>  }
>  @Override
>  public String readFrom(Class<String> type, Type genericType, Annotation[] annotations, MediaType mediaType,
>          MultivaluedMap<String, String> httpHeaders, InputStream entityStream) throws IOException, WebApplicationException
>  {
>   // TODO: issue of encoding here?
>     return mapper.readValue(entityStream, String.class);
>  }
> }
> 
> 
> On Sat, Oct 10, 2015 at 4:38 AM, Weinan Li <we...@re...> wrote:
> Hi Sean,
> 
> Which RESTEasy JSON provider you are using?
> 
> In addition, could you please provide me some codes so I can verify it?
> 
> --
> Weinan Li / JBoss
> 
> 
> 
> > On Oct 10, 2015, at 1:12 AM, Sean Dawson <sea...@gm...> wrote:
> >
> >
> > There seems to be very little info online about this but I'm guessing most people here know that if you send a String value in the body of a REST call to RestEasy, Jackson complains.
> >
> > One of our other devs made a JsonStringProvider which seems super simple (it's readable/writable if it's a String _and_ the type is Json) and it uses a standard ObjectMapper to read/write the value/stream.
> >
> > In RE 3.0.11, it seems to work fine in our unit tests - ie. we can makes calls with Strings and things just work - both writeTo and readFrom methods get called.  But in later versions (3.0.13 & 3.0.14), only the writeTo method gets hit and Jackson complains, unless we double quote the strings ("\"message\"").  Most of our code is the same in both places with the exception of moving from the deprecated way of creating proxies to the new/recommended way.
> >
> > Any ideas? Is it maybe a classpath issue? Or a different way the provider needs to be registered? Or.... ?
> >
> > Thanks.
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li...
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> 

Re: [Resteasy-developers] Json String handling differences in RE versions

[Sean D. <sea...@gm...>]

Ok here's what I've figured out so far:

1.
- I can leave off our JsonStringProvider for most things and they just work
- so sending and returning Boolean, Integer, String all work fine (boolean
and int have issues)
- I can't send or receive Object
     - somehow, with the old way of doing things, there was an ObjectReader
involved that would check JSON tokens or something and figure out that it
was a String (for eg)

2.
In the past, this got used in BodyEntityExtractor:
     Object obj = response.getEntity(method.getReturnType(),
method.getGenericReturnType());

The new code uses:
         GenericType gt = null;
         if (method.getGenericReturnType() != null)
         {
            gt = new GenericType(method.getGenericReturnType());
         }
         else
         {
            gt = new GenericType(method.getReturnType());
         }
         Object obj = ClientInvocation.extractResult(gt, response,
method.getAnnotations());

And now (due to Java8 or?), the generic return type is T which means it's
not null but then cannot be used...

java.lang.IllegalArgumentException: Type parameter T not a class or
parameterized type whose raw type is a class
 at javax.ws.rs.core.GenericType.getClass(GenericType.java:179)
 at javax.ws.rs.core.GenericType.<init>(GenericType.java:136)
 at
org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:53)

If I say to skip Generic Return Type's with the name T, then it mostly
works fine.

Any help on any of this?  Thanks.



On Mon, Oct 12, 2015 at 8:40 AM, Sean Dawson <sea...@gm...>
wrote:

>
> We just wrote our own (I think) and then do...
>
> ResteasyProviderFactory.getInstance().providerFactory.registerProvider(JsonStringProvider.class);
>
>
> Client and server side.
>
>
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.lang.annotation.Annotation;
> import java.lang.reflect.Type;
>
> import javax.ws.rs.Consumes;
> import javax.ws.rs.Produces;
> import javax.ws.rs.WebApplicationException;
> import javax.ws.rs.core.MediaType;
> import javax.ws.rs.core.MultivaluedMap;
> import javax.ws.rs.ext.MessageBodyReader;
> import javax.ws.rs.ext.MessageBodyWriter;
> import javax.ws.rs.ext.Provider;
>
> import com.fasterxml.jackson.databind.ObjectMapper;
>
> @Provider
> @Produces(MediaType.APPLICATION_JSON)
> @Consumes(MediaType.APPLICATION_JSON)
> public class JsonStringProvider implements MessageBodyWriter<String>, MessageBodyReader<String>
> {
>  @Override
>  public boolean isWriteable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType)
>  {
>   return type == String.class && MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
>  }
>
>  @Override
>  public long getSize(String t, Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType)
>  {
>   return -1;
>  }
>
>  private static final ObjectMapper mapper = new ObjectMapper();
>
>  @Override
>  public void writeTo(String t, Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType,
>          MultivaluedMap<String, Object> httpHeaders, OutputStream entityStream) throws IOException, WebApplicationException
>  {
>   // TODO: issue of encoding here?
>   mapper.writeValue(entityStream, t);
>  }
>
>  @Override
>  public boolean isReadable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType)
>  {
>   return type == String.class && MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
>  }
>
>  @Override
>  public String readFrom(Class<String> type, Type genericType, Annotation[] annotations, MediaType mediaType,
>          MultivaluedMap<String, String> httpHeaders, InputStream entityStream) throws IOException, WebApplicationException
>  {
>   // TODO: issue of encoding here?
>     return mapper.readValue(entityStream, String.class);
>  }
> }
>
>
>
> On Sat, Oct 10, 2015 at 4:38 AM, Weinan Li <we...@re...> wrote:
>
>> Hi Sean,
>>
>> Which RESTEasy JSON provider you are using?
>>
>> In addition, could you please provide me some codes so I can verify it?
>>
>> --
>> Weinan Li / JBoss
>>
>>
>>
>> > On Oct 10, 2015, at 1:12 AM, Sean Dawson <sea...@gm...>
>> wrote:
>> >
>> >
>> > There seems to be very little info online about this but I'm guessing
>> most people here know that if you send a String value in the body of a REST
>> call to RestEasy, Jackson complains.
>> >
>> > One of our other devs made a JsonStringProvider which seems super
>> simple (it's readable/writable if it's a String _and_ the type is Json) and
>> it uses a standard ObjectMapper to read/write the value/stream.
>> >
>> > In RE 3.0.11, it seems to work fine in our unit tests - ie. we can
>> makes calls with Strings and things just work - both writeTo and readFrom
>> methods get called.  But in later versions (3.0.13 & 3.0.14), only the
>> writeTo method gets hit and Jackson complains, unless we double quote the
>> strings ("\"message\"").  Most of our code is the same in both places with
>> the exception of moving from the deprecated way of creating proxies to the
>> new/recommended way.
>> >
>> > Any ideas? Is it maybe a classpath issue? Or a different way the
>> provider needs to be registered? Or.... ?
>> >
>> > Thanks.
>> >
>> >
>> ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Resteasy-developers mailing list
>> > Res...@li...
>> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>>
>

Re: [Resteasy-developers] Json String handling differences in RE versions

[Sean D. <sea...@gm...>]

We just wrote our own (I think) and then do...

ResteasyProviderFactory.getInstance().providerFactory.registerProvider(JsonStringProvider.class);


Client and server side.


import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.lang.annotation.Annotation;
import java.lang.reflect.Type;

import javax.ws.rs.Consumes;
import javax.ws.rs.Produces;
import javax.ws.rs.WebApplicationException;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.MultivaluedMap;
import javax.ws.rs.ext.MessageBodyReader;
import javax.ws.rs.ext.MessageBodyWriter;
import javax.ws.rs.ext.Provider;

import com.fasterxml.jackson.databind.ObjectMapper;

@Provider
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class JsonStringProvider implements MessageBodyWriter<String>,
MessageBodyReader<String>
{
 @Override
 public boolean isWriteable(Class<?> type, Type genericType,
Annotation[] annotations, MediaType mediaType)
 {
  return type == String.class &&
MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
 }

 @Override
 public long getSize(String t, Class<?> type, Type genericType,
Annotation[] annotations, MediaType mediaType)
 {
  return -1;
 }

 private static final ObjectMapper mapper = new ObjectMapper();

 @Override
 public void writeTo(String t, Class<?> type, Type genericType,
Annotation[] annotations, MediaType mediaType,
         MultivaluedMap<String, Object> httpHeaders, OutputStream
entityStream) throws IOException, WebApplicationException
 {
  // TODO: issue of encoding here?
  mapper.writeValue(entityStream, t);
 }

 @Override
 public boolean isReadable(Class<?> type, Type genericType,
Annotation[] annotations, MediaType mediaType)
 {
  return type == String.class &&
MediaType.APPLICATION_JSON_TYPE.isCompatible(mediaType);
 }

 @Override
 public String readFrom(Class<String> type, Type genericType,
Annotation[] annotations, MediaType mediaType,
         MultivaluedMap<String, String> httpHeaders, InputStream
entityStream) throws IOException, WebApplicationException
 {
  // TODO: issue of encoding here?
    return mapper.readValue(entityStream, String.class);
 }
}



On Sat, Oct 10, 2015 at 4:38 AM, Weinan Li <we...@re...> wrote:

> Hi Sean,
>
> Which RESTEasy JSON provider you are using?
>
> In addition, could you please provide me some codes so I can verify it?
>
> --
> Weinan Li / JBoss
>
>
>
> > On Oct 10, 2015, at 1:12 AM, Sean Dawson <sea...@gm...>
> wrote:
> >
> >
> > There seems to be very little info online about this but I'm guessing
> most people here know that if you send a String value in the body of a REST
> call to RestEasy, Jackson complains.
> >
> > One of our other devs made a JsonStringProvider which seems super simple
> (it's readable/writable if it's a String _and_ the type is Json) and it
> uses a standard ObjectMapper to read/write the value/stream.
> >
> > In RE 3.0.11, it seems to work fine in our unit tests - ie. we can makes
> calls with Strings and things just work - both writeTo and readFrom methods
> get called.  But in later versions (3.0.13 & 3.0.14), only the writeTo
> method gets hit and Jackson complains, unless we double quote the strings
> ("\"message\"").  Most of our code is the same in both places with the
> exception of moving from the deprecated way of creating proxies to the
> new/recommended way.
> >
> > Any ideas? Is it maybe a classpath issue? Or a different way the
> provider needs to be registered? Or.... ?
> >
> > Thanks.
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li...
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>

Re: [Resteasy-developers] Json String handling differences in RE versions

[Weinan Li <we...@re...>]

Hi Sean,

Which RESTEasy JSON provider you are using?

In addition, could you please provide me some codes so I can verify it?

--
Weinan Li / JBoss



> On Oct 10, 2015, at 1:12 AM, Sean Dawson <sea...@gm...> wrote:
> 
> 
> There seems to be very little info online about this but I'm guessing most people here know that if you send a String value in the body of a REST call to RestEasy, Jackson complains.
> 
> One of our other devs made a JsonStringProvider which seems super simple (it's readable/writable if it's a String _and_ the type is Json) and it uses a standard ObjectMapper to read/write the value/stream.
> 
> In RE 3.0.11, it seems to work fine in our unit tests - ie. we can makes calls with Strings and things just work - both writeTo and readFrom methods get called.  But in later versions (3.0.13 & 3.0.14), only the writeTo method gets hit and Jackson complains, unless we double quote the strings ("\"message\"").  Most of our code is the same in both places with the exception of moving from the deprecated way of creating proxies to the new/recommended way.
> 
> Any ideas? Is it maybe a classpath issue? Or a different way the provider needs to be registered? Or.... ?
> 
> Thanks.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

[Resteasy-developers] Json String handling differences in RE versions

[Sean D. <sea...@gm...>]

There seems to be very little info online about this but I'm guessing most
people here know that if you send a String value in the body of a REST call
to RestEasy, Jackson complains.

One of our other devs made a JsonStringProvider which seems super simple
(it's readable/writable if it's a String _and_ the type is Json) and it
uses a standard ObjectMapper to read/write the value/stream.

In RE 3.0.11, it seems to work fine in our unit tests - ie. we can makes
calls with Strings and things just work - both writeTo and readFrom methods
get called.  But in later versions (3.0.13 & 3.0.14), only the writeTo
method gets hit and Jackson complains, unless we double quote the strings
("\"message\"").  Most of our code is the same in both places with the
exception of moving from the deprecated way of creating proxies to the
new/recommended way.

Any ideas? Is it maybe a classpath issue? Or a different way the provider
needs to be registered? Or.... ?

Thanks.

Re: [Resteasy-developers] Patch to include previous patch, and to skip Java 8 default methods

[Weinan Li <we...@re...>]

Hi Sean,

Sure please go ahead to create PR and send me the link.

--
Weinan Li / JBoss



> On Oct 3, 2015, at 2:39 AM, Sean Dawson <sea...@gm...> wrote:
> 
> 
> Hello,
> 
> I think I emailed previously about a patch that was submitted awhile ago to skip "as" methods that's in 3.0.11.Final but was left out when refactoring was done in newer version(s).  That omission has prevented us from upgrading.
> 
> Even more problematic is that we aren't able to move to Java 8 because it includes default interface methods that do not include annotations which causes RestEasy (at least in the above version) ProxyFactory to fail with "You must use at least one, but no more than one http method annotation".  I can't think of another way around this except to put the following in ProxyBuilder...
> 
>    if (method.isDefault())
>     continue;
> 
> Can we submit a patch for both of these to be incorporated in the latest version?
> 
> Thank you.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers