Java 传入JSON反序列化POJO的CDI

Java 传入JSON反序列化POJO的CDI,java,cdi,payara,Java,Cdi,Payara,我将Payara Microservice用于Java web应用程序,并希望将bean注入到反序列化的JSON对象中,以便添加和执行一些额外的逻辑 到目前为止,我有一个资源类,用@Path和@POST注释,我用一些JSON通过Postman调用它。这个方法调用的很好,但是无论我尝试什么,我都无法让bean注入 JSON对象的类如下所示: public class IncomingJsonRequest { @NotNull private String value;

我将Payara Microservice用于Java web应用程序,并希望将bean注入到反序列化的JSON对象中,以便添加和执行一些额外的逻辑

到目前为止,我有一个资源类,用@Path和@POST注释,我用一些JSON通过Postman调用它。这个方法调用的很好,但是无论我尝试什么,我都无法让bean注入

JSON对象的类如下所示:

public class IncomingJsonRequest {

    @NotNull
    private String value;

    private AdditionalLogicClass additionalLogicBean;

    public String setValue(String value) {
        this.value = value;
    }

    public void performAdditionalLogic() {
        additionalLogicBean.performLogic(value);
    }
}
我想做的是注入
AdditionalLogicClass
bean,这样当我从resource方法调用
performAdditionalLogic()
方法时,它不会抛出空指针异常

我尝试了各种注释,到目前为止,我唯一能做到这一点的方法似乎是让资源类传入bean,但这不是很好的封装。我不想让资源知道这个附加逻辑是如何完成的

另一种方法是通过编程加载bean,但我读到这不是一种好的做法

实现这一目标的最佳方式是什么


谢谢

使用编程CDI方法,您可以通过以下方式实现:

@Path("sample")
public class SampleResource {

    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    public Response message(MyPayload myPayload) {
        return Response.ok(myPayload.getName()).build();
    }

}
一个示例业务逻辑CDIBean

public class BusinessLogic {
    public String doFoo(String name) {
        return name.toUpperCase();
    }
}
有效载荷:

public class MyPayload {

    private String name;
    private BusinessLogic businessLogic;

    public MyPayload() {
        this.businessLogic = CDI.current().select(BusinessLogic.class).get();
    }

    public String getName() {
        return businessLogic.doFoo(this.name);
    }

    public void setName(String name) {
        this.name = name;
    }
}
最后是
beans.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
       bean-discovery-mode="all">
</beans>

点击端点将以大写形式返回预期输入:

curl -v -d '{"name": "duke"}' -H 'Content-Type: application/json' http://localhost:9080/resources/sample
< HTTP/1.1 200 OK
< X-Powered-By: Servlet/4.0
< Content-Type: application/octet-stream
< Date: Thu, 02 Jul 2020 06:16:34 GMT
< Content-Language: en-US
< Content-Length: 4
< 
* Connection #0 to host localhost left intact
DUKE
curl-v-d'{“name”:“duke”}'-H'内容类型:application/json'http://localhost:9080/resources/sample
通过这种方式,您可以将CDIBean注入默认构造函数中,当JSON-B尝试序列化传入的负载时,该构造函数将被JSON-B调用

另一种方法是通过编程加载bean,但我已经读过了 这不是个好习惯


不确定是否有其他解决方案可以实现这一点,并让CDI容器负责注入。

将服务注入模型也不是好的做法。你为什么要这样做?为了增加封装而不是贫血。对象的类具有调用附加逻辑所需的信息。如果我想把它推到一个服务层,那么我必须制作getter,服务层必须协调所有这些。这不是Martin Fowler写的一个反模式吗,或者我误解了这一点。我不是一个真正的模式/反模式的人,更实际;-)为了使注入工作,您需要显式地“管理”类,或者通过配置隐式地消除注入(空构造函数要求),并且实例必须由管理它们的容器创建。那么它可能会起作用。来源:“还值得强调的是,将行为放入域对象不应与使用分层将域逻辑与持久性和表示责任等分离的可靠方法相矛盾。域对象中应该包含的逻辑是域逻辑——验证、计算、业务规则——不管您喜欢称之为什么。(有些情况下,您会提出将数据源或表示逻辑放在域对象中的论点,但这与我的观点是正交的。)“所有这些中的一个混乱来源是,许多OO专家确实建议在域模型之上放置一层过程服务,以形成服务层。但这并不是让域模型没有行为的理由,事实上,服务层倡导者将服务层与行为丰富的域模型结合使用。“所以我很幸运地做到了这一点;-)只是从来没有必要使用复杂的(业务)域模型中的逻辑是由“服务”技术提供的。但也包含有趣的信息('Crtitisism';-)),如下所示: