RESTEasy

I know what the problem is, please log a jira to remind me, thanks.

Currently I create a brand new ResteasyProviderFactory every time you 
create a Client.  This has been done for classloader reasons and because 
you're not really supposed to initialize a Client with scanned providers.

On 2/16/2013 1:54 PM, Ron Sigal wrote:
> Ok, I've run into my first client framework issue.  In
> resteasy-cdi-ejb-test, I've got a test that looks at the interaction of
> decorators, interceptors, interceptor decorators, etc.  Each of these
> leaves a record of its execution, and the test does three things:
>
>    1) uploads an entity,
>    2) retrieves the entity, and
>    3) calls a resource test method that compares the actual sequence of
> provider executions with the expected sequence.
>
> The entity I'm sending back and forth is a JAXB Book class which is read by
>
>
>     @Provider
>     @Consumes(Constants.MEDIA_TYPE_TEST_XML)
>     public class BookReader implements MessageBodyReader<Book>
>     {
>          ...
>         @Inject private Logger log;
>         ...
>
>
> The test is failing because, in the old Resteasy client framework, the
> second step leads to some decorator, etc., executions on the client side
> when BookReader.readFrom() is called, while, in the new framework, that
> isn't happening.  Now, thinking about it, I see that this test has a
> pretty subgenius design because I've got the resource on the server
> checking for events on the client side, but that's a little besides the
> point.  The reason for the different behavior is that CDI is not acting
> on the client side.  In particular, the ResteasyProviderFactory  in the
> client framework is using the default ConstructorInjector and the server
> side is using CdiConstructorInjector.
>
> Bill, I seem to remember that somewhere you said that Resteasy should
> support CDI only on the server.  Do I remember correctly? Now, the
> consequence of using CDI only on the server is that BookReader fails on
> the client side with a NPE because log is null. In order for BookReader
> to work on both sides, it would have to forego the use of CDI.
> Alternatively, I would need two versions of BookReader.  Neither of
> these seems desirable.
>
> Any thoughts?
>
> -Ron
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Resteasy-developers@...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

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

Cool.  Done:  RESTEASY-829 "CDI doesn't work in client framework".

On 02/17/2013 07:43 PM, Bill Burke wrote:
> Currently I create a brand new ResteasyProviderFactory every time you
> create a Client.  This has been done for classloader reasons and because
> you're not really supposed to initialize a Client with scanned providers.

This isn't an issue, just an observation.  I had a test that looked like

       ClientRequest request = new 
ClientRequest("http://localhost:8080/resteasy-cdi-ejb-test/rest/concrete/decorators/clear");
       ClientResponse<?>  response = request.get();
       assertEquals(200, response.getStatus());
       request = new 
ClientRequest("http://localhost:8080/resteasy-cdi-ejb-test/rest/concrete/decorators/execute");
       response = request.get();

which I rewrote as

       WebTarget target = 
ClientBuilder.newClient().target("http://localhost:8080/resteasy-cdi-ejb-test/rest/concrete/decorators");
       Response response = target.path("clear").request().get();
       assertEquals(200, response.getStatus());
       response = target.path("execute").request().get();

The latter failed with

    Caused by: java.lang.IllegalStateException: Invalid use of 
SingleClientConnManager: connection still allocated.
    Make sure to release the connection before allocating another one.

because I didn't call Response.close().  The analogous call 
(ClientResponse.releaseConnection) wasn't necessary in the original 
version (though I probably should have done it anyway) because I created 
a new ClientRequest for the second call.

The point is that the client framework encourages factoring and reuse, 
which led to a problem I didn't have before.  Or, really, it exposed a 
problem I had before without realizing it.

That's all.  Just saying.

-Ron

On 02/18/2013 03:14 PM, Ron Sigal wrote:
> Cool.  Done:  RESTEASY-829 "CDI doesn't work in client framework".
>
> On 02/17/2013 07:43 PM, Bill Burke wrote:
>> Currently I create a brand new ResteasyProviderFactory every time you
>> create a Client.  This has been done for classloader reasons and because
>> you're not really supposed to initialize a Client with scanned providers.
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Resteasy-developers mailing list
> Resteasy-developers@...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers