CDI proxy class serialization not supported

Consider a simple POJO called Biz:

public class Biz {

    private String foo;

    public String getFoo() {
        return foo;
    }

    public void setFoo(String foo) {
        this.foo = foo;
    }    
}

An instance of Biz, with request scope, is created in a CDI producer method:

@RequestScoped
public class BizProducer {

    @Produces
    @RequestScoped
    public Biz produceBiz() {
        return new Biz();
    }
}

The Biz instance is injected into a JAX-RS resource class and then returned in the response:

@Path("/biz")
public class BizResource {

    @Inject
    private Biz biz;

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public Response get() {
        return Response.ok(biz).build();
    }
}

When returning a response with biz, I get the following exception:

Caused by: com.fasterxml.jackson.databind.JsonMappingException: No serializer found for class org.jboss.weld.bean.StringBeanIdentifier and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) ) (through reference chain: com.example.model.Biz$Proxy$_$$_WeldClientProxy["handler"]->org.jboss.weld.bean.proxy.ProxyMethodHandler["bean"]->org.jboss.weld.bean.ProducerField["identifier"])
    at com.fasterxml.jackson.databind.ser.impl.UnknownSerializer.failForEmpty(UnknownSerializer.java:59)
    at com.fasterxml.jackson.databind.ser.impl.UnknownSerializer.serialize(UnknownSerializer.java:26)
    at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:575)
    at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:666)
    at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:156)
    at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:575)
    at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:666)
    at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:156)
    at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:575)
    at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:666)
    at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:156)
    at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:129)
    at com.fasterxml.jackson.databind.ObjectWriter.writeValue(ObjectWriter.java:851)
    at org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.writeTo(ResteasyJackson2Provider.java:207)
    at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:131)
    at org.jboss.resteasy.core.interception.ServerWriterInterceptorContext.writeTo(ServerWriterInterceptorContext.java:60)
    at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:120)
    at org.jboss.resteasy.security.doseta.DigitalSigningInterceptor.aroundWriteTo(DigitalSigningInterceptor.java:145)
    at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
    at org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100)
    at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
    at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:98)
    at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:466)
    ... 33 more

Looks like Jackson 2.8.2. is not getting well with CDI proxies.

[ljnelson]

Resurrecting this thread a bit, the hypothetical CDI datatype module really probably wouldn’t have to be that complicated. Rather than, say, looking for Weld proxies specifically, a serializer could detect whether a given type is synthetic. If so, then it would simply walk the superclass hierarchy and stop at the first non-synthetic class: that’s the “real” one to use. See this forum response for more details.

[cowtowncoder]

Thank you for the work-around suggestion. I’ll leave this open if anyone might have the itch to work on adding datatype module (or, whatever form the extension would take) to support this use case.