방금 Core JavaServer Faces, 3rd Ed를 통해 읽기 시작했습니다 . 그리고 그들은 이것을 말합니다 (강조 내) :

JSF 페이지에서 사용할 수있는 Bean에 대해 두 개의 별도 메커니즘 인 CDI Bean과 JSF 관리 Bean이 있다는 것은 역사적 사고입니다. 애플리케이션이 Tomcat과 같은 일반 서블릿 실행기에서 작동해야하는 경우가 아니면 CDI Bean을 사용하는 것이 좋습니다 .

왜? 그들은 제공하지 않는 어떤 정당성을. @ManagedBeanGlassFish 3에서 실행되는 프로토 타입 애플리케이션의 모든 빈에 대해 사용해 왔지만 실제로이 문제를 발견하지 못했습니다. 에서 @ManagedBean로 마이그레이션하는 것은 특별히 신경 쓰지 @Named않지만 왜 귀찮게 해야하는지 알고 싶습니다 .

CDI는 JavaEE 전체 종속성 주입을 허용하기 때문에 일반 JSF보다 선호됩니다. POJO를 주입하고 관리 할 수도 있습니다. JSF를 사용하면 CDI로 할 수있는 것의 일부만 주입 할 수 있습니다.

CDI를 사용하십시오.

JSF 2.3 당으로 @ManagedBean되어 사용되지 . 사양 문제 1417 도 참조하세요 . 더 이상 선택하는 이유가 아니라고이 수단 @ManagedBean이상 @Named. 이것은 Mojarra 2.3.0 베타 버전 m06에서 처음 구현되었습니다.

역사

핵심적인 차이점은 @ManagedBeanJSF 프레임 워크에 의해 관리되며 @ManagedProperty다른 JSF 관리 Bean을 통해서만 사용할 수 있다는 것입니다. @NamedCDI 프레임 워크를 통해 애플리케이션 서버 (용기)에 의해 관리된다 경유 @Inject같은 컨테이너 관리 아티펙트의 종류를 사용할 수 @WebListener, @WebFilter, @WebServlet, @Path, @Stateless, 등 심지어 JSF @ManagedBean. 다른 쪽에서는 내부 또는 다른 컨테이너 관리 아티팩트 내부에서 작동 @ManagedProperty하지 않습니다@Named . 그것은 실제로 내부에서만 작동합니다 @ManagedBean.

또 다른 차이점은 CDI가 실제로 요청 / 스레드 단위로 대상 범위의 현재 인스턴스에 위임하는 프록시를 주입한다는 것입니다 (예 : EJB가 주입되는 방식). 이 메커니즘은 JSF로는 불가능한 더 넓은 범위의 빈에 더 좁은 범위의 빈을 주입 할 수있게합니다 @ManagedProperty. JSF는 setter를 호출하여 여기에 물리적 인스턴스를 직접 "주입"합니다 (이것이 바로 setter가 필요한 이유이지만 에서는 필요 하지 않음@Inject ).

직접적인 단점은 아니지만-다른 방법이 있습니다-범위 @ManagedBean는 단순히 제한됩니다. 다른 관점에서 보면에 대해 "너무 많이"노출하지 않으려면 @Inject관리되는 Bean을 그대로 유지할 수도 있습니다 @ManagedBean. 그것은처럼 protected대 public. 그러나 그것은 실제로 중요하지 않습니다.

적어도 JSF 2.0 / 2.1에서 CDI로 JSF 백킹 빈을 관리 할 때의 주요 단점은 @ViewScoped. 은 @ConversationScoped가깝게 있지만, 수동으로 시작 및 중지 요구하고 못생긴 추가 cid결과 URL에 대한 요청 매개 변수를. MyFaces CODI는 JSF javax.faces.bean.ViewScoped를 CDI 에 완전히 투명하게 브리징하여 더 쉽게 만들 수 있습니다 @Named @ViewScoped.하지만 이렇게하면 windowId결과 URL에 추악한 요청 매개 변수 가 추가 되며 일반 페이지 간 탐색에서도 마찬가지입니다. OmniFaces 는 @ViewScoped빈의 범위를 임의의 요청 매개 변수 대신 JSF보기 상태에 실제로 연결 하는 진정한 CDI로이 모든 것을 해결합니다 .

(3 년이 질문 / 대답 한 후 해제) JSF 2.2은 새로운 완전히 CDI 호환 제공 @ViewScoped의 맛에 상자 밖으로 주석을 javax.faces.view.ViewScoped. JSF 2.2 @FlowScoped에는 @ManagedBean동등한 기능 이없는 CDI 전용도 함께 제공되어 JSF 사용자를 CDI로 이동시킵니다. 예상 @ManagedBean대로 및 친구들은 Java EE 8에 따라 더 이상 사용되지 않을 것입니다. 현재 여전히을 사용중인 경우 @ManagedBean향후 업그레이드 경로에 대비하기 위해 CDI로 전환하는 것이 좋습니다. CDI는 WildFly, TomEE 및 GlassFish와 같은 Java EE 웹 프로필 호환 컨테이너에서 쉽게 사용할 수 있습니다. Tomcat의 경우 JSF에 대해 이미했던 것과 똑같이 별도로 설치해야합니다. Tomcat에 CDI를 설치하는 방법 도 참조하십시오 .

Java EE 6 및 CDI를 사용하면 Managed Bean에 대해 다른 옵션이 있습니다.

• @javax.faces.bean.ManagedBeanJSR 314를 참조하며 JSF 2.0과 함께 도입되었습니다. 주요 목표는 JSF 페이지 내에서 빈을 사용하기 위해 faces-config.xml 파일의 구성을 피하는 것이 었습니다.
• @javax.annotation.ManagedBean(“myBean”) JSR 316에 의해 정의됩니다. Java EE의 다른 곳에서 사용하기 위해 JSF 관리 Bean을 일반화합니다.
• @javax.inject.Named(“myBean”) CDI를 활성화하려면 web / WEB-INF 폴더에 beans.xml 파일이 필요하다는 점을 제외하면 위의 것과 거의 같습니다.

GlassFish 3.0.1에서 CDI를 사용하고 있었지만 제대로 작동하려면 Seam 3 프레임 워크 (Weld)를 가져와야했습니다. 꽤 잘 작동했습니다.

GlassFish 3.1에서는 CDI가 작동을 멈추고 Seam Weld가 작동을 멈췄습니다. 이 버그를 열었 지만 아직 수정되지 않았습니다. 모든 코드를 javax.faces. * 주석을 사용하도록 변환해야했지만 작동하게되면 CDI로 돌아갈 계획입니다.

CDI를 사용해야한다는 데 동의하지만 아직 해결되지 않은 한 가지 문제는 @ViewScoped 주석으로 수행 할 작업입니다. 나는 그것에 의존하는 많은 코드를 가지고 있습니다. @ManagedBean을 사용하지 않는 경우 @ViewScoped가 작동하는지 여부는 명확하지 않습니다. 누구든지 이것을 명확히 할 수 있다면 감사하겠습니다.

CDI로 전환해야하는 한 가지 좋은 이유 @Inject는 JSF 관리 Bean과 REST 서비스 (예 : Jersey / JAX-RS)에 공통 세션 범위 리소스 (예 : 사용자 프로필)를 포함 할 수 있다는 것 입니다.

반면에 @ViewScopedJSF를 고수해야하는 설득력있는 이유는 @ManagedBean특히 중요한 AJAX가있는 모든 경우에 그렇습니다. CDI에는 이에 대한 표준 대체가 없습니다.

@ViewScopedCDI bean 에 대한 유사한 주석을 지원할 수있는 것 같지만 개인적으로 사용하지는 않았습니다.

http://seamframework.org/Seam3/FacesModule