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
> 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?
> 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
JBoss, a division of Red Hat