Menu
▾
▴
resteasy-developers
|
From: Ron S. <rs...@re...> - 2013-02-16 18:54:17
|
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
|
|
From: Bill B. <bb...@re...> - 2013-02-17 23:43:50
|
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
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Ron S. <rs...@re...> - 2013-02-18 19:14:23
|
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. |
|
From: Ron S. <rs...@re...> - 2013-02-19 21:30:55
|
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
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
|
Thanks for helping keep SourceForge clean.
X