JSF2管理bean注释+范围+注入混乱

时间:2011-03-14 06:37:57

标签: spring jsf jsf-2 jboss-weld

我想实现这种理想主义:

  1. 只有1个JSF Bean容器实现,比如只使用Spring或Weld,但不能同时使用两者。目前我使用Spring作为后端,所以我更喜欢Spring。
  2. 只有1个注释,可在@ManagedBean,@ Name,@ Model
  3. 之间进行选择
  4. 能够使用所有支持的范围,例如@RequestScoped,@ SessionScoped,@ ViewScoped,@ FlashScoped,也许@ConversationScoped
  5. 可以使用@Inject或@Autowired
  6. 向JSF Beans注入spring-managed-services(后端服务)

    到目前为止,我一直没有找到最佳组合来实现这些目标,因为据我所知,如果我错了,请纠正我:

    1. @ManagedBean不能注入spring服务吗?
    2. @Named可以使用@Inject注入spring服务,但@Named使用Weld。我可以用spring来管理@Named而不是Weld吗?
    3. @Named不支持@ViewScoped和FlashScope吗?
    4. 请分享您的想法和经验。

      谢谢: - )


      2011年3月15日更新

      发现了一个有趣的page,它描述了如何用Spring替换Jboss Weld作为JSR 299 CDI实现。所以基本上,回答问题2。数字1也是间接回答的,因为我现在可以注入弹簧服务。

      但是,问题仍然存在。如果我可以在@Named中使用@ViewScoped和Flash Scope,我将会发现非常有用,例如this article。 Flash范围的实现还有待观察,但到目前为止我能得到的最接近的是this page

      希望用jsr 299实现替换spring with spring仍然可以让我使用@ConversationScoped。

      现在要测试一下,祝我好运: - )


      2011年3月18日更新

      成功使用Spring 3代替焊接来执行@Named,@ Inject。重要的是在faces-config.xml中设置el-resolver。

      AFAIK,Spring 3目前还不支持CDI,所以bye2 @ConversationScoped。

      对于范围界定,我仍然必须使用@Scope(“request”)或@Scope(“session”),但如果我更喜欢@RequestScoped(javax.enterprise.context.RequestScoped)和@SessionScoped,我可以制作使用this article提供的桥梁。

      来自this article的弹簧的范围(“视图”)就像魔法一样: - )

      但仍有一个问题,如何在Scope(“view”) - bean之间传递对象.. 祝我好运!


      更新

      啊,啊......终于做到了.. 使用JSF2提供的Flash传递变量确实像魔术一样。 我不需要第三方实现。

      所以基本上,我可以不用焊接,但是使用spring,可以使用常见的范围,包括视图范围,dan可以使用flash对象在bean之间传递。

      缺少的一件事是会话范围,这对我来说不是一个主要问题。 希望未来的春天可以支持这个对话范围。

      干杯: - )

2 个答案:

答案 0 :(得分:3)

我可以使用ManagedProperty注释成功注入Spring bean,如下所示。这是在JSF Managed Bean上。 Spring bean用于后端,我更喜欢spring作为后端。

@ManagedProperty(name="userRepository", value="#{userRepository}")
private UserRepository userRepository;
//Setter and/or Getter

价值是这里最重要的事情。它实际上是春天的豆子名称。我希望这会有所帮助。

答案 1 :(得分:2)

Weld(实际上,reference implementationJSR-299 Context and Dependency Injection,也称为Java EE 6 CDI)在Java EE 6环境中用于取代Spring的次数越来越少。我建议使用Java EE 6 CDI而不是Spring。当Java EE 6提供相同的功能时,为什么要使用第三方框架?

如果Spring后端确实无法更改,那么我建议坚持使用它,而不是与Java EE 6 CDI注释混合使用,以避免混淆和维护问题。