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

Re: [Resteasy-developers] On an implementation detail of org.jboss.resteasy.client.jaxrs.cache.CacheInterceptor

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

Hi Mark,


I’ll look into this and let you know my progress.




Weinan Li / JBoss


> On Apr 18, 2014, at 6:09 AM, Mark Petrovic <msp...@gm...> wrote:
> 
> 
> I'm sorry I do not. I studied the code line by line and the question
> occurred to me.
> 
> 
> On Thu, Apr 17, 2014 at 2:17 PM, Bill Burke <bb...@re...> wrote:
> 
> 
>> You got a test that reproduces this?
>> 
>> 
>> On 4/15/2014 12:43 PM, Mark Petrovic wrote:
>> 
>> 
>>> Good day.
>>> 
>>> 
>>> I am studying HTTP caching, and I have been helped a great deal by
>>> a close reading of the Resteasy CacheInterceptor client filter
>>> example:
>>> 
>>> 
>>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/cache/CacheInterceptor.java
>>> 
>>> 
>>> I am still learning and could easily be missing something. But it
>>> seems to me that if
>>> 
>>> 
>>> 1) the client sets an If-None-Match header with an Etag value
>>> 
>>> 
>>> and
>>> 
>>> 
>>> 2) there is no local cache entry whatsoever, expired or not, as
>>> determined in the ClientRequestFilter implementation
>>> 
>>> 
>>> and
>>> 
>>> 
>>> 3) the server returns 304 by virtue of the If-None-Match header
>>> 
>>> 
>>> then the ClientResponseFilter implementation will try to fetch a
>>> response from cache when it is already determined that there is no
>>> such entry. Consequently, the client is left with no usable response
>>> available from cache or from the origin server.
>>> 
>>> 
>>> If I am correct, then if there is no cache entry as determined in
>>> the ClientRequestFilter implementation, is it appropriate to remove
>>> any If-None-Match -type headers before the request is sent?
>>> 
>>> 
>>> Thank you for your time as I try to understand this.
>>> 
>>> 
>>> 
>> 
>> --
>> 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-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>> 
>> 
>> 
> 
> 
> 
> 
> 
> --
> Mark
> 
> 
> ------------------------------------------------------------------------------
> 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-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> 

Re: [Resteasy-developers] On an implementation detail of org.jboss.resteasy.client.jaxrs.cache.CacheInterceptor

[Mark P. <msp...@gm...>]

I'm sorry I do not.  I studied the code line by line and the question
occurred to me.

On Thu, Apr 17, 2014 at 2:17 PM, Bill Burke <bb...@re...> wrote:
> You got a test that reproduces this?
>
> On 4/15/2014 12:43 PM, Mark Petrovic wrote:
>> Good day.
>>
>> I am studying HTTP caching, and I have been helped a great deal by
>> a close reading of the Resteasy CacheInterceptor client filter
>> example:
>>
>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/cache/CacheInterceptor.java
>>
>> I am still learning and could easily be missing something.  But it
>> seems to me that if
>>
>> 1) the client sets an If-None-Match header with an Etag value
>>
>> and
>>
>> 2) there is no local cache entry whatsoever, expired or not, as
>> determined in the ClientRequestFilter implementation
>>
>> and
>>
>> 3) the server returns 304 by virtue of the If-None-Match header
>>
>> then the ClientResponseFilter implementation will try to fetch a
>> response from cache when it is already determined that there is no
>> such entry.  Consequently, the client is left with no usable response
>> available from cache or from the origin server.
>>
>> If I am correct, then if there is no cache entry as determined in
>> the ClientRequestFilter implementation, is it appropriate to remove
>> any If-None-Match -type headers before the request is sent?
>>
>> Thank you for your time as I try to understand this.
>>
>
> --
> 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-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers



-- 
Mark

Re: [Resteasy-developers] On an implementation detail of org.jboss.resteasy.client.jaxrs.cache.CacheInterceptor

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

You got a test that reproduces this?

On 4/15/2014 12:43 PM, Mark Petrovic wrote:
> Good day.
>
> I am studying HTTP caching, and I have been helped a great deal by
> a close reading of the Resteasy CacheInterceptor client filter
> example:
>
> https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/cache/CacheInterceptor.java
>
> I am still learning and could easily be missing something.  But it
> seems to me that if
>
> 1) the client sets an If-None-Match header with an Etag value
>
> and
>
> 2) there is no local cache entry whatsoever, expired or not, as
> determined in the ClientRequestFilter implementation
>
> and
>
> 3) the server returns 304 by virtue of the If-None-Match header
>
> then the ClientResponseFilter implementation will try to fetch a
> response from cache when it is already determined that there is no
> such entry.  Consequently, the client is left with no usable response
> available from cache or from the origin server.
>
> If I am correct, then if there is no cache entry as determined in
> the ClientRequestFilter implementation, is it appropriate to remove
> any If-None-Match -type headers before the request is sent?
>
> Thank you for your time as I try to understand this.
>

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

[Resteasy-developers] On an implementation detail of org.jboss.resteasy.client.jaxrs.cache.CacheInterceptor

[Mark P. <msp...@gm...>]

Good day.

I am studying HTTP caching, and I have been helped a great deal by
a close reading of the Resteasy CacheInterceptor client filter
example:

https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/cache/CacheInterceptor.java

I am still learning and could easily be missing something.  But it
seems to me that if

1) the client sets an If-None-Match header with an Etag value

and

2) there is no local cache entry whatsoever, expired or not, as
determined in the ClientRequestFilter implementation

and

3) the server returns 304 by virtue of the If-None-Match header

then the ClientResponseFilter implementation will try to fetch a
response from cache when it is already determined that there is no
such entry.  Consequently, the client is left with no usable response
available from cache or from the origin server.

If I am correct, then if there is no cache entry as determined in
the ClientRequestFilter implementation, is it appropriate to remove
any If-None-Match -type headers before the request is sent?

Thank you for your time as I try to understand this.

-- 
Mark

Re: [Resteasy-developers] Standalone installation

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

Ah ok, thanks.  I looked at the wrong version of the book examples earlier.



On Tue, Apr 8, 2014 at 11:04 PM, Bill Burke <bb...@re...> wrote:

> All the examples here use the servlet initializer:
>
>
> https://github.com/resteasy/Resteasy/tree/master/jaxrs/examples/oreilly-jaxrs-2.0-workbook
>
> If you have an Application class that returns empty lists from
> getClasses() and getSingletons(), then scanning will be used.
>
> On 4/8/2014 10:53 AM, Sean Dawson wrote:
> > Hello,
> > Going through the docs and it's not clear to me what's the current
> > correct approach to creating a standalone RestEasy app.  I'm adding this
> > in my pom.xml...
> >     <dependency>
> >     <groupId>org.jboss.resteasy</groupId>
> >     <artifactId>resteasy-servlet-initializer</artifactId>
> >     <version>3.0.7.Final</version>
> >    </dependency>
> > But then what?  Do I use the class scanning, or the application class,
> > or... ?  I'm thinking the former but just want to double-check.
> > Also, just fyi, the Libary class is missing a closing paren at the end
> > of the method signature for removeBook.
> > Thanks.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Put Bad Developers to Shame
> > Dominate Development with Jenkins Continuous Integration
> > Continuously Automate Build, Test & Deployment
> > Start a new project now. Try Jenkins in the cloud.
> > http://p.sf.net/sfu/13600_Cloudbees
> >
> >
> >
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li...
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

Re: [Resteasy-developers] Standalone installation

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

All the examples here use the servlet initializer:

https://github.com/resteasy/Resteasy/tree/master/jaxrs/examples/oreilly-jaxrs-2.0-workbook

If you have an Application class that returns empty lists from 
getClasses() and getSingletons(), then scanning will be used.

On 4/8/2014 10:53 AM, Sean Dawson wrote:
> Hello,
> Going through the docs and it's not clear to me what's the current
> correct approach to creating a standalone RestEasy app.  I'm adding this
> in my pom.xml...
>     <dependency>
>     <groupId>org.jboss.resteasy</groupId>
>     <artifactId>resteasy-servlet-initializer</artifactId>
>     <version>3.0.7.Final</version>
>    </dependency>
> But then what?  Do I use the class scanning, or the application class,
> or... ?  I'm thinking the former but just want to double-check.
> Also, just fyi, the Libary class is missing a closing paren at the end
> of the method signature for removeBook.
> Thanks.
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

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

Re: [Resteasy-developers] Standalone installation

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

If you are using resteasy-servlet-initializer (and I suggest you do) you 
should have an Application class.  Just do the following

@ApplicationPath("/the/root/you/want")
public class MyApplication extends Application {}



On 4/8/2014 10:53 AM, Sean Dawson wrote:
> Hello,
> Going through the docs and it's not clear to me what's the current
> correct approach to creating a standalone RestEasy app.  I'm adding this
> in my pom.xml...
>     <dependency>
>     <groupId>org.jboss.resteasy</groupId>
>     <artifactId>resteasy-servlet-initializer</artifactId>
>     <version>3.0.7.Final</version>
>    </dependency>
> But then what?  Do I use the class scanning, or the application class,
> or... ?  I'm thinking the former but just want to double-check.
> Also, just fyi, the Libary class is missing a closing paren at the end
> of the method signature for removeBook.
> Thanks.
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

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

[Resteasy-developers] Standalone installation

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

Hello,

Going through the docs and it's not clear to me what's the current correct
approach to creating a standalone RestEasy app.  I'm adding this in my
pom.xml...

   <dependency>
   <groupId>org.jboss.resteasy</groupId>
   <artifactId>resteasy-servlet-initializer</artifactId>
   <version>3.0.7.Final</version>
  </dependency>
But then what?  Do I use the class scanning, or the application class,
or... ?  I'm thinking the former but just want to double-check.

Also, just fyi, the Libary class is missing a closing paren at the end of
the method signature for removeBook.

Thanks.

Re: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6

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

What does your web.xml look like?  Are you using HttpServlet30Dispatcher?

I'm still not understanding the problem.  The timeout handler is not 
working or the resume is not working?

On 4/1/2014 6:29 PM, Sean Dawson wrote:
> So, on this...
>
> On Tue, Mar 18, 2014 at 4:12 PM, Sean Dawson <sea...@gm...
> <mailto:sea...@gm...>> wrote:
>
>     On (3 - async), I'm not able to share much of the code related to
>     this and I haven't come up with a way to reproduce it using
>     something similar.  Essentially though, if all I do is change the
>     RestEasy version in my maven dependencies from 2.3.3 to 3.0.6, on
>     timeout (5 seconds) I now get a 503 - service unavailable, instead
>     of previously a 200 ok (this is from firefox directly to jetty
>     server).  If an event comes in to dispatch during the 5 secs, things
>     do work as expected in 3.0.6.  We are running under servlet 3.0.
>
> It looks like the (3.0.7 source code) tests and everything are well
> aware that a 503 is returned.  It certainly wasn't before so I'm not
> sure when/why it changed (probably to follow the spec I suspect).
> Anyway, we were using...
>
> @Suspend(5000) AsynchronousResponse response
> and if there was nothing to return, the response wouldn't get set (and
> eventually timeout returning a 200/ok).  But if there was something,
> then we'd build it along the lines of... (simplified example type here
> though)...
> response.setResponse(Response.ok(new GenericEntity<String>(data, new
> ParameterizedType()
>     {
>      @Override
>      public Type getRawType()
>      {
>       return String.class;
>      }
>      @Override
>      public Type getOwnerType()
>      {
>       return null;
>      }
>      @Override
>      public Type[] getActualTypeArguments()
>      {
>       return new Type[]
>       {
>        String.class
>       };
>      }
>     })).build());
> Now I'm doing...
> @Suspended AsyncResponse response
>    response.setTimeout(10, TimeUnit.SECONDS);
>    response.setTimeoutHandler(timeoutHandler);
> and...
>   response.resume(data);
> Which seems to mostly work - ie. my timeoutHandler does a resume with
> empty data, the timeout is observed, we get a 200/ok, and it returns as
> soon as we do have data - the problem is the data is not making it to
> the client - it ends up being null even though the server resumes with
> valid data.  This is with gwt, RestyGwt, etc.  If I just have the server
> and go directly against it from the Firefox RestEasy client, then either
> I get errors for not having a MessageBodyWriter for text/html, or if
> everything is set to application/json it just never returns on the
> resume (either on timeout or on data - ie. client just hangs), or after
> trying some variations I get a 500 Server Error with no more information
> in the client or the (development environment) server (no exceptions, etc).
> Any ideas/pointers?
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

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

Re: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6

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

So, on this...

On Tue, Mar 18, 2014 at 4:12 PM, Sean Dawson <sea...@gm...>wrote:

>
> On (3 - async), I'm not able to share much of the code related to this and
> I haven't come up with a way to reproduce it using something similar.
> Essentially though, if all I do is change the RestEasy version in my maven
> dependencies from 2.3.3 to 3.0.6, on timeout (5 seconds) I now get a 503 -
> service unavailable, instead of previously a 200 ok (this is from firefox
> directly to jetty server).  If an event comes in to dispatch during the 5
> secs, things do work as expected in 3.0.6.  We are running under servlet
> 3.0.
>
>

It looks like the (3.0.7 source code) tests and everything are well aware
that a 503 is returned.  It certainly wasn't before so I'm not sure
when/why it changed (probably to follow the spec I suspect).  Anyway, we
were using...

@Suspend(5000) AsynchronousResponse response

and if there was nothing to return, the response wouldn't get set (and
eventually timeout returning a 200/ok).  But if there was something, then
we'd build it along the lines of... (simplified example type here though)...

response.setResponse(Response.ok(new GenericEntity<String>(data, new
ParameterizedType()
   {
    @Override
    public Type getRawType()
    {
     return String.class;
    }
    @Override
    public Type getOwnerType()
    {
     return null;
    }
    @Override
    public Type[] getActualTypeArguments()
    {
     return new Type[]
     {
      String.class
     };
    }
   })).build());

Now I'm doing...

@Suspended AsyncResponse response

  response.setTimeout(10, TimeUnit.SECONDS);
  response.setTimeoutHandler(timeoutHandler);

and...

 response.resume(data);

Which seems to mostly work - ie. my timeoutHandler does a resume with empty
data, the timeout is observed, we get a 200/ok, and it returns as soon as
we do have data - the problem is the data is not making it to the client -
it ends up being null even though the server resumes with valid data.  This
is with gwt, RestyGwt, etc.  If I just have the server and go directly
against it from the Firefox RestEasy client, then either I get errors for
not having a MessageBodyWriter for text/html, or if everything is set to
application/json it just never returns on the resume (either on timeout or
on data - ie. client just hangs), or after trying some variations I get a
500 Server Error with no more information in the client or the (development
environment) server (no exceptions, etc).

Any ideas/pointers?

Re: [Resteasy-developers] [Resteasy-users] Resteasy 3.0.7 released

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

Youll have to upgrade Apache Client to 4.2.1 or higher too.

On 3/31/2014 10:48 PM, Ming Hsieh wrote:
> Hi All
>
> Just downloaded 3.0.7, followed the instructions in
> examples/oauth2-as7-example, updated modules, properties, configurations
> and standalone.xml tried to deploy.
>
> auth-server.war and database.war deployed ok.
> deployment failed at "customer-portal.war":
> 09:58:15,925 INFO  [org.jboss.as.server.deployment] (MSC service thread
> 1-4) JBA
> S015876: Starting deployment of "customer-portal.war"
> 09:58:16,008 ERROR [org.apache.catalina.core.StandardContext] (MSC
> service threa
> d 1-2) Context [/customer-portal] startup failed due to previous errors:
> java.la <http://java.la>
> ng.NoClassDefFoundError:
> org/apache/http/impl/conn/PoolingClientConnectionManage
> r
>          at
> org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.initDefaultEngi
> ne(ResteasyClientBuilder.java:428) [resteasy-client-3.0.7.Final.jar:]
>          at
> org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.build(ResteasyC
> lientBuilder.java:333) [resteasy-client-3.0.7.Final.jar:]
>          at
> org.jboss.resteasy.skeleton.key.as7.OAuthManagedResourceValve.init(OA
> uthManagedResourceValve.java:115) [skeleton-key-as7-3.0.7.Final.jar:]
>          at
> org.jboss.resteasy.skeleton.key.as7.OAuthManagedResourceValve.lifecyc
> leEvent(OAuthManagedResourceValve.java:66)
> [skeleton-key-as7-3.0.7.Final.jar:]
>          at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl
> eSupport.java:115) [jbossweb-7.0.13.Final.jar:]
>          at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:3
> 845) [jbossweb-7.0.13.Final.jar:]
>          at
> org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentS
> ervice.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
>          at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(Se
> rviceControllerImpl.java:1811)
>          at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceCont
> rollerImpl.java:1746)
>          at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> java:1145) [rt.jar:1.7.0_25]
>          at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> .java:615) [rt.jar:1.7.0_25]
>          at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
>
> I am Using jboss 7.1.1.Final, resteasy 3.0.7.Final and jdk 1.7.0_25.
>
> Digged into the documentation for httpcomponents
> https://hc.apache.org/httpcomponents-client-4.3.x/httpclient/apidocs/org/apache/http/impl/conn/PoolingClientConnectionManager.html
> it seems like PoolingClientConnectionManager is only available in
> version 4.2.
> jboss as 7.1.1.Final only includes httpcomponents version 4.1.2.
> Updated the httpcomponents in jboss (module.xml):
> <module xmlns="urn:jboss:module:1.1" name="org.apache.httpcomponents">
>      <properties>
>          <property name="jboss.api" value="private"/>
>      </properties>
>
>      <resources>
>          <resource-root path="httpclient-4.3.3.jar"/>
>          <resource-root path="httpcore-4.3.2.jar"/>
>          <resource-root path="httpmime-4.3.3.jar"/>
>          <!-- Insert resources here -->
>      </resources>
>
>      <dependencies>
>          <module name="javax.api"/>
>          <module name="org.apache.commons.codec"/>
>          <module name="org.apache.commons.logging"/>
>          <module name="org.apache.james.mime4j"/>
>      </dependencies>
> </module>
>
> After that deployment success. So maybe the updated modules should be
> included resteasy download.
>
> For anybody that is interested in oauth2.
>
> Regards,
>
> Ming
>
>
>
> On Mon, Mar 31, 2014 at 11:30 PM, Bill Burke <bb...@re...
> <mailto:bb...@re...>> wrote:
>
>     Ron fixed a few bugs in validation.  Netty improvements.  A few other
>     bug fixes here and there.
>
>     As usual, follow links from jboss.org/resteasy
>     <http://jboss.org/resteasy> to download and view
>     documentation and release notes.
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Resteasy-users mailing list
>     Res...@li...
>     <mailto:Res...@li...>
>     https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
>
>
>

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

[Resteasy-developers] Resteasy 3.0.7 released

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

Ron fixed a few bugs in validation.  Netty improvements.  A few other 
bug fixes here and there.

As usual, follow links from jboss.org/resteasy to download and view 
documentation and release notes.

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

Re: [Resteasy-developers] UriBuilder: building URI within queryParam, character '?' is not being encoded

[Luc <use...@gm...>]

For the readers but not Jira followers:
https://issues.jboss.org/browse/RESTEASY-1038?focusedCommentId=12956653&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12956653
(and next one)

--
Lucas



2014-03-26 15:21 GMT+01:00 Bill Burke <bb...@re...>:

> Unfortunately for you:
>
> /some?next=%2Fcome_again?t%3D1234
>
> Is a legal URI.  There's actually a JAXRS TCK testcase for this.
>
> On 3/26/2014 9:29 AM, Bill Burke wrote:
> > You're in luck, I'm working on Resteasy this week and will get to it
> today:
> >
> > https://issues.jboss.org/browse/RESTEASY-1038
> >
> >
> > On 3/26/2014 5:04 AM, Luc wrote:
> >> Watching the archive
> >> (http://sourceforge.net/p/resteasy/mailman/message/32142270/) I see
> that
> >> my message is not seen, so I will send without format. Sorry for spam
> >.<
> >>
> >> ____________________
> >>
> >> I've been using UriBuilder to build redirect URIs inside a web
> application.
> >> Until now, I only builded simple query parameters, but today I wanted to
> >> build an URI inside a queryParam.
> >>
> >> The URI to be used as query is builded like:
> >>   > UriBuilder toQuery =
> >> UriBuilder.fromPath("/come_again").queryParam("t", "1234");
> >>
> >> The main URI which will hold this one is builded:
> >>   > URI builded = UriBuilder.fromPath("/some").queryParam("next",
> >> toQuery.build().toASCIIString()).build();
> >> I've tryied other ways (with build template arguments too, and using
> >> buildFromEncoded) but none of them produced the expected URI.
> >>
> >> Expected should be:
> >>   > /some?next=%2Fcome_again%3Ft%3D1234
> >> But the result is:
> >>   > /some?next=%2Fcome_again?t%3D1234
> >>
> >> All parameters get encoded, except the question mark.
> >> I've attach a JUnit test class.
> >>
> >> The main problem (which I found debugging) is with
> >> 'org.jboss.resteasy.util.Encode.queryNameValueEncoding', which considers
> >> as not encodeable char the question mark. But I think, that it should be
> >> encoded inside a query, if I understand correctly an URI format....
> >>
> >> I'm building incorrectly this URI?
> >> Is a JAX-RS spec problem?
> >> Should file a RESTEasy bug?
> >>
> >> Thanks!
> >> --
> >> Lucas
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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/13534_NeoTech
> >>
> >>
> >>
> >> _______________________________________________
> >> Resteasy-developers mailing list
> >> Res...@li...
> >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> >>
> >
>
> --
> 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/13534_NeoTech
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

Re: [Resteasy-developers] UriBuilder: building URI within queryParam, character '?' is not being encoded

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

Unfortunately for you:

/some?next=%2Fcome_again?t%3D1234

Is a legal URI.  There's actually a JAXRS TCK testcase for this.	

On 3/26/2014 9:29 AM, Bill Burke wrote:
> You're in luck, I'm working on Resteasy this week and will get to it today:
>
> https://issues.jboss.org/browse/RESTEASY-1038
>
>
> On 3/26/2014 5:04 AM, Luc wrote:
>> Watching the archive
>> (http://sourceforge.net/p/resteasy/mailman/message/32142270/) I see that
>> my message is not seen, so I will send without format. Sorry for spam >.<
>>
>> ____________________
>>
>> I've been using UriBuilder to build redirect URIs inside a web application.
>> Until now, I only builded simple query parameters, but today I wanted to
>> build an URI inside a queryParam.
>>
>> The URI to be used as query is builded like:
>>   > UriBuilder toQuery =
>> UriBuilder.fromPath("/come_again").queryParam("t", "1234");
>>
>> The main URI which will hold this one is builded:
>>   > URI builded = UriBuilder.fromPath("/some").queryParam("next",
>> toQuery.build().toASCIIString()).build();
>> I've tryied other ways (with build template arguments too, and using
>> buildFromEncoded) but none of them produced the expected URI.
>>
>> Expected should be:
>>   > /some?next=%2Fcome_again%3Ft%3D1234
>> But the result is:
>>   > /some?next=%2Fcome_again?t%3D1234
>>
>> All parameters get encoded, except the question mark.
>> I've attach a JUnit test class.
>>
>> The main problem (which I found debugging) is with
>> 'org.jboss.resteasy.util.Encode.queryNameValueEncoding', which considers
>> as not encodeable char the question mark. But I think, that it should be
>> encoded inside a query, if I understand correctly an URI format....
>>
>> I'm building incorrectly this URI?
>> Is a JAX-RS spec problem?
>> Should file a RESTEasy bug?
>>
>> Thanks!
>> --
>> Lucas
>>
>>
>> ------------------------------------------------------------------------------
>> 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/13534_NeoTech
>>
>>
>>
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>

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

Re: [Resteasy-developers] UriBuilder: building URI within queryParam, character '?' is not being encoded

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

You're in luck, I'm working on Resteasy this week and will get to it today:

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


On 3/26/2014 5:04 AM, Luc wrote:
> Watching the archive
> (http://sourceforge.net/p/resteasy/mailman/message/32142270/) I see that
> my message is not seen, so I will send without format. Sorry for spam >.<
>
> ____________________
>
> I've been using UriBuilder to build redirect URIs inside a web application.
> Until now, I only builded simple query parameters, but today I wanted to
> build an URI inside a queryParam.
>
> The URI to be used as query is builded like:
>  > UriBuilder toQuery =
> UriBuilder.fromPath("/come_again").queryParam("t", "1234");
>
> The main URI which will hold this one is builded:
>  > URI builded = UriBuilder.fromPath("/some").queryParam("next",
> toQuery.build().toASCIIString()).build();
> I've tryied other ways (with build template arguments too, and using
> buildFromEncoded) but none of them produced the expected URI.
>
> Expected should be:
>  > /some?next=%2Fcome_again%3Ft%3D1234
> But the result is:
>  > /some?next=%2Fcome_again?t%3D1234
>
> All parameters get encoded, except the question mark.
> I've attach a JUnit test class.
>
> The main problem (which I found debugging) is with
> 'org.jboss.resteasy.util.Encode.queryNameValueEncoding', which considers
> as not encodeable char the question mark. But I think, that it should be
> encoded inside a query, if I understand correctly an URI format....
>
> I'm building incorrectly this URI?
> Is a JAX-RS spec problem?
> Should file a RESTEasy bug?
>
> Thanks!
> --
> Lucas
>
>
> ------------------------------------------------------------------------------
> 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/13534_NeoTech
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

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

Re: [Resteasy-developers] UriBuilder: building URI within queryParam, character '?' is not being encoded

[Luc <use...@gm...>]

Watching the archive (
http://sourceforge.net/p/resteasy/mailman/message/32142270/) I see that my
message is not seen, so I will send without format. Sorry for spam >.<

____________________

I've been using UriBuilder to build redirect URIs inside a web application.
Until now, I only builded simple query parameters, but today I wanted to
build an URI inside a queryParam.

The URI to be used as query is builded like:
> UriBuilder toQuery = UriBuilder.fromPath("/come_again").queryParam("t",
"1234");

The main URI which will hold this one is builded:
> URI builded = UriBuilder.fromPath("/some").queryParam("next",
toQuery.build().toASCIIString()).build();
I've tryied other ways (with build template arguments too, and using
buildFromEncoded) but none of them produced the expected URI.

Expected should be:
> /some?next=%2Fcome_again%3Ft%3D1234
But the result is:
> /some?next=%2Fcome_again?t%3D1234

All parameters get encoded, except the question mark.
I've attach a JUnit test class.

The main problem (which I found debugging) is with
'org.jboss.resteasy.util.Encode.queryNameValueEncoding', which considers as
not encodeable char the question mark. But I think, that it should be
encoded inside a query, if I understand correctly an URI format....

I'm building incorrectly this URI?
Is a JAX-RS spec problem?
Should file a RESTEasy bug?

Thanks!
--
Lucas

[Resteasy-developers] Selectively registering providers

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

Hello,

We have another team that's using our REST api's as well as adding their
own.  We registered a json string provider to encode our strings, whereas
they did not and preferred to manually encode returned strings - which
means that if they run everything together in a single jvm, their strings
get double encoded.

Here's what we do...


RegisterBuiltin.*register*(ResteasyProviderFactory.*getInstance*());

ResteasyProviderFactory.*getInstance*().registerProvider(JsonStringProvider.

*class*);

RuntimeDelegate.*setInstance*(ResteasyProviderFactory.*getInstance*());



Is it possible to have that provider enabled only for our REST api's and
not theirs?  Some sort of context path or class annotation or .... ?  A
different way to do this?



Thanks.

[Resteasy-developers] Returning streaming iterables from services

[Josiah H. <jos...@gm...>]

Hi folks,

I have a database access layer that supports live iteration over very large
result sets, and I'd like to be able to stream the results to the client
while retaining the convenience of returning say, a list or other
collection (complete with content-negotiation, etc.). The only difference
is that this would need to use the streaming APIs.  Would anyone be able to
point me in a good direction for this?

Thanks!

Josiah

Re: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6

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

Appreciate the response.

On (1 - matching) unfortunately the context param didn't seem to work for
my case - so will need to figure out something else.  I did read your blog
post and the migration info but not yet sure what the best way to change
our api would be at this point.
On (2 - client/deprecate), will check the docs again for the new client
apis/interfaces.

On (3 - async), I'm not able to share much of the code related to this and
I haven't come up with a way to reproduce it using something similar.
Essentially though, if all I do is change the RestEasy version in my maven
dependencies from 2.3.3 to 3.0.6, on timeout (5 seconds) I now get a 503 -
service unavailable, instead of previously a 200 ok (this is from firefox
directly to jetty server).  If an event comes in to dispatch during the 5
secs, things do work as expected in 3.0.6.  We are running under servlet
3.0.



On Tue, Mar 18, 2014 at 12:37 PM, Bill Burke <bb...@re...> wrote:

>
>
>
>
>
> On 3/18/2014 11:34 AM, Sean Dawson wrote:
> >
> > Hello,
> >
> > We're attempting to move from 2.3.3 (final) to 3.0.6 (final) and
> > experiencing a few issues.  One is an apparent change to the matching
> > algorithm - for example, we have...
> >
> > @Path("path")
> > public interface Resource
> > {
> >   @Path("subresource/{id}")
> >   SubResource get(@PathParam("id") String id);
> >
> >   @PUT
> >   @Path("subresource/{id}")
> >    String open(@PathParam("id") String id);
> > }
> >
> > public interface SubResource
> > {
> >   @DELETE
> >   String close();
> > }
> >
> > Previously that would work fine.  Now we get an exception / 405 code
> > because it finds the PUT (only/instead).  If I comment out the PUT, then
> > the DELETE gets called fine.  What is the best way to address this?
> >
>
> JAX-RS 2.0 TCK got *REALLY STRICT* on testing the matching algorithm
> unfortunately:
>
>
> http://bill.burkecentral.com/2013/05/29/the-poor-jax-rs-request-dispatching-algorithm/
>
> See this:
>
>
> http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Migration_from_older_versions.html
>
>
> The "resteasy.wider.request.matching" context variable set to "true" may
> be able to help you get past this problem.
>
>
>
> > Second, a few things have been deprecated like ClientResponseFailure but
> > I wasn't able to find much documentation on why and what we should use
> > instead.  Where does one find information on these types of changes?
> >
>
> JAX-RS 2.0 has a client API now.  I strongly suggest migrating to it as
> we will be removing the Resteasy client API in later versions.
>
>
> http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Migration_from_older_versions.html
>
>
>
> > Finally, we're having some issues with our async comet-like calls now -
> > they either return immediately or timeout and return Service Unavailable
> > - they were working fine previously.  Interestingly, it seems to mostly
> > work direct from a browser but when accessed from a gwt app through a
> > proxy - that's when we're having the most issues.  I probably need to
> > debug this further but if anyone has pointers, it would be appreciated.
> > We're using AsynchronousResponse in the method signature and
> > AsyncEventConsumer in the body.
> >
>
> If you can some up with something that reproduces the problem that would
> be great.
>
> Also, JAX-RS 2.0 has standardized async HTTP too:
>
> javax.ws.rs.container.AsyncResponse
> javax.ws.rs.Suspended
>
>
>
> --
> 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/13534_NeoTech
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

Re: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6

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

On 3/18/2014 11:34 AM, Sean Dawson wrote:
>
> Hello,
>
> We're attempting to move from 2.3.3 (final) to 3.0.6 (final) and
> experiencing a few issues.  One is an apparent change to the matching
> algorithm - for example, we have...
>
> @Path("path")
> public interface Resource
> {
>   @Path("subresource/{id}")
>   SubResource get(@PathParam("id") String id);
>
>   @PUT
>   @Path("subresource/{id}")
>    String open(@PathParam("id") String id);
> }
>
> public interface SubResource
> {
>   @DELETE
>   String close();
> }
>
> Previously that would work fine.  Now we get an exception / 405 code
> because it finds the PUT (only/instead).  If I comment out the PUT, then
> the DELETE gets called fine.  What is the best way to address this?
>

JAX-RS 2.0 TCK got *REALLY STRICT* on testing the matching algorithm 
unfortunately:

http://bill.burkecentral.com/2013/05/29/the-poor-jax-rs-request-dispatching-algorithm/

See this:

http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Migration_from_older_versions.html


The "resteasy.wider.request.matching" context variable set to "true" may 
be able to help you get past this problem.



> Second, a few things have been deprecated like ClientResponseFailure but
> I wasn't able to find much documentation on why and what we should use
> instead.  Where does one find information on these types of changes?
>

JAX-RS 2.0 has a client API now.  I strongly suggest migrating to it as 
we will be removing the Resteasy client API in later versions.

http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Migration_from_older_versions.html



> Finally, we're having some issues with our async comet-like calls now -
> they either return immediately or timeout and return Service Unavailable
> - they were working fine previously.  Interestingly, it seems to mostly
> work direct from a browser but when accessed from a gwt app through a
> proxy - that's when we're having the most issues.  I probably need to
> debug this further but if anyone has pointers, it would be appreciated.
> We're using AsynchronousResponse in the method signature and
> AsyncEventConsumer in the body.
>

If you can some up with something that reproduces the problem that would 
be great.

Also, JAX-RS 2.0 has standardized async HTTP too:

javax.ws.rs.container.AsyncResponse
javax.ws.rs.Suspended



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

[Resteasy-developers] Upgrading from 2.3.3 to 3.0.6

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

Hello,

We're attempting to move from 2.3.3 (final) to 3.0.6 (final) and
experiencing a few issues.  One is an apparent change to the matching
algorithm - for example, we have...

@Path("path")
public interface Resource
{
 @Path("subresource/{id}")
 SubResource get(@PathParam("id") String id);

 @PUT
 @Path("subresource/{id}")
  String open(@PathParam("id") String id);
}

public interface SubResource
{
 @DELETE
 String close();
}

Previously that would work fine.  Now we get an exception / 405 code
because it finds the PUT (only/instead).  If I comment out the PUT, then
the DELETE gets called fine.  What is the best way to address this?

Second, a few things have been deprecated like ClientResponseFailure but I
wasn't able to find much documentation on why and what we should use
instead.  Where does one find information on these types of changes?

Finally, we're having some issues with our async comet-like calls now -
they either return immediately or timeout and return Service Unavailable -
they were working fine previously.  Interestingly, it seems to mostly work
direct from a browser but when accessed from a gwt app through a proxy -
that's when we're having the most issues.  I probably need to debug this
further but if anyone has pointers, it would be appreciated.  We're using
AsynchronousResponse in the method signature and AsyncEventConsumer in the
body.

Thanks!

Re: [Resteasy-developers] Mock and CDI support

[Ove R. <ora...@gm...>]

Hi Bill,

Well, at least it's lightweight and does not impose a container. Looking forward to the client adapter whenever you get a chance to make it.

Arquillian is great for its purpose, but the mock req/res is a great way to test.

Ove



Sent from my iPad

> On 11. mars 2014, at 13:56, Bill Burke <bb...@re...> wrote:
> 
> Our mock framework sucks...Sorry its so horrible.  I've been meaning to 
> write an in-memory Client adapter for a LOOONNNNG time just never got 
> around to it.
> 
>> On 3/11/2014 6:24 AM, Ove Ranheim wrote:
>> Reading RESTEasy sources is always a great thing!
>> 
>> With Narayana JTA.
>> 
>> // Bind BeanManager to JNDI
>> NAMING_BEAN.getNamingInstance().createSubcontext(new
>> NamingParser().parse("app"));
>> InitialContext context = new InitialContext();
>> context.bind("java:app/BeanManager",
>> BeanManagerProvider.getInstance().getBeanManager());
>> 
>> // Register CdiInjectorFactory
>> Dispatcher dispatcher = MockDispatcherFactory.createDispatcher();
>> dispatcher.getProviderFactory().setInjectorFactory(new
>> CdiInjectorFactory());
>> 
>> Now it works like a charm.
>> 
>> Cheers,
>> Ove
>> 
>> 
>> On 10 Mar 2014, at 23:29, Ove Ranheim <ora...@gm...
>> <mailto:ora...@gm...>> wrote:
>> 
>>> Hi,
>>> 
>>> I'm trying out the RESTEasy Mock framework, but POJOResourceFactory
>>> fails with CDI.
>>> 
>>>        POJOResourceFactory noDefaults = new
>>> POJOResourceFactory(RestUserServiceImpl.class);
>>>        dispatcher.getRegistry().addResourceFactory(noDefaults);
>>> 
>>>        org.jboss.resteasy.spi.UnhandledException:
>>> java.lang.NullPointerException
>>>        at
>>> com.parts.profile.test.rest.user.RestUserServiceImpl.getUser(RestUserServiceImpl.java:38)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> 
>>> Does RESTEasy support CDI in mock?
>>> 
>>> Cheers,
>>> Ove
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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/13534_NeoTech
>> 
>> 
>> 
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> -- 
> 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/13534_NeoTech
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] Mock and CDI support

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

Our mock framework sucks...Sorry its so horrible.  I've been meaning to 
write an in-memory Client adapter for a LOOONNNNG time just never got 
around to it.

On 3/11/2014 6:24 AM, Ove Ranheim wrote:
> Reading RESTEasy sources is always a great thing!
>
> With Narayana JTA.
>
> // Bind BeanManager to JNDI
> NAMING_BEAN.getNamingInstance().createSubcontext(new
> NamingParser().parse("app"));
> InitialContext context = new InitialContext();
> context.bind("java:app/BeanManager",
> BeanManagerProvider.getInstance().getBeanManager());
>
> // Register CdiInjectorFactory
> Dispatcher dispatcher = MockDispatcherFactory.createDispatcher();
> dispatcher.getProviderFactory().setInjectorFactory(new
> CdiInjectorFactory());
>
> Now it works like a charm.
>
> Cheers,
> Ove
>
>
> On 10 Mar 2014, at 23:29, Ove Ranheim <ora...@gm...
> <mailto:ora...@gm...>> wrote:
>
>> Hi,
>>
>> I'm trying out the RESTEasy Mock framework, but POJOResourceFactory
>> fails with CDI.
>>
>>         POJOResourceFactory noDefaults = new
>> POJOResourceFactory(RestUserServiceImpl.class);
>>         dispatcher.getRegistry().addResourceFactory(noDefaults);
>>
>>         org.jboss.resteasy.spi.UnhandledException:
>> java.lang.NullPointerException
>>         at
>> com.parts.profile.test.rest.user.RestUserServiceImpl.getUser(RestUserServiceImpl.java:38)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> Does RESTEasy support CDI in mock?
>>
>> Cheers,
>> Ove
>>
>
>
>
> ------------------------------------------------------------------------------
> 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/13534_NeoTech
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

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

Re: [Resteasy-developers] Mock and CDI support

[Ove R. <ora...@gm...>]

Reading RESTEasy sources is always a great thing!

With Narayana JTA.

// Bind BeanManager to JNDI
NAMING_BEAN.getNamingInstance().createSubcontext(new NamingParser().parse("app"));
InitialContext context = new InitialContext();
context.bind("java:app/BeanManager", BeanManagerProvider.getInstance().getBeanManager());

// Register CdiInjectorFactory
Dispatcher dispatcher = MockDispatcherFactory.createDispatcher();
dispatcher.getProviderFactory().setInjectorFactory(new CdiInjectorFactory());

Now it works like a charm.

Cheers,
Ove


On 10 Mar 2014, at 23:29, Ove Ranheim <ora...@gm...> wrote:

> Hi,
> 
> I'm trying out the RESTEasy Mock framework, but POJOResourceFactory fails with CDI.
> 
>         POJOResourceFactory noDefaults = new POJOResourceFactory(RestUserServiceImpl.class);
>         dispatcher.getRegistry().addResourceFactory(noDefaults);
> 
>         org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> 	        at com.parts.profile.test.rest.user.RestUserServiceImpl.getUser(RestUserServiceImpl.java:38)
>         	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 
> Does RESTEasy support CDI in mock?
> 
> Cheers,
> Ove
> 

[Resteasy-developers] Mock and CDI support

[Ove R. <ora...@gm...>]

Hi,

I'm trying out the RESTEasy Mock framework, but POJOResourceFactory fails with CDI.

        POJOResourceFactory noDefaults = new POJOResourceFactory(RestUserServiceImpl.class);
        dispatcher.getRegistry().addResourceFactory(noDefaults);

        org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
	        at com.parts.profile.test.rest.user.RestUserServiceImpl.getUser(RestUserServiceImpl.java:38)
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Does RESTEasy support CDI in mock?

Cheers,
Ove