지금 새 프로젝트를 시작하고 있습니다. 기술을 선택해야합니다. 가벼운 것이 필요하므로 EJB 또는 Seam이 없습니다. 반면에 JPA (Hibernate 또는 대안)와 IceFaces가있는 JSF가 필요합니다.
Tomcat에 배포 된 Spring 3의 이러한 스택이 좋은 선택이라고 생각하십니까? 아니면 Java EE 6 웹 애플리케이션이 더 좋을까요? Java EE 6이 아직 잘 문서화되지 않은 새로운 기술인 것이 두렵습니다. Tomcat은 Glassfish 3보다 유지 관리가 더 쉬운 것 같습니다.
당신의 의견은 무엇입니까? 경험이 있습니까?
답변:
가벼운 것이 필요하므로 EJB 또는 Seam이 없습니다.
EJB3 이후 EJB를 무겁게 만드는 이유를 설명해 주시겠습니까? 우리가 2004 년이 아니라는 사실을 알고 있습니까? 나는 빛에 대한 당신의 정의와 당신의 주장 을 읽고 싶습니다 (그리고 제가 몇 가지 확실한 말을 할 것이라 확신하기 때문에 기꺼이 제 답변을 업데이트하겠습니다).
반면에 JPA (Hibernate 또는 대안)와 IceFaces가있는 JSF가 필요합니다.
JSF 2.0, JPA 2.0, Bean 유효성 검사, EJB 3.1 Lite, CDI 등을 포함하는 Java EE 6 웹 프로필은이를 위해 완벽하며 GlassFish v3 웹 프로필 을 사용하여 Java EE 6 웹 프로필로 빌드 된 응용 프로그램을 실행할 수 있습니다. .
Tomcat에 배포 된 Spring 3의 이러한 스택이 좋은 선택이라고 생각하십니까? 아니면 Java EE 6 웹 애플리케이션이 더 좋을까요?
글쎄요, 저는 독점 컨테이너 (Spring) 보다는 비 독점 플랫폼 (Java EE) 에서 내 코드를 실행하는 아이디어를 좋아합니다 . 그리고 저는 Java EE 6이 충분히 좋다고 생각합니다 (그리고 이것은 완곡 어법, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI 킥 엉덩이입니다). 내가 JSF 회의론자 였지만 다시 한 번 살펴 보았고 CDI가 포함 된 JSF 2.0은 너무 다르기 때문에 비교할 수도 없습니다. 그리고 CDI를 보지 않았다면 그것이 흔들린다 고 말씀 드리겠습니다.
Java EE 6이 아직 잘 문서화되지 않은 새로운 기술인 것이 두렵습니다.
Java EE는 나에게 꽤 잘 문서화되어 있습니다. 이것은 무료 청구처럼 들립니다. 그리고 저를 믿거 나 말거나 저는 Spring이 복잡해지고 Java EE가 쉬워지는 것을 발견하기 시작합니다.
Tomcat은 Glassfish 3보다 유지 관리가 더 쉬운 것 같습니다.
뭔가 해봤 어? 특별한 문제가 있었습니까? 다시 말하지만 이것은 무료 청구처럼 들립니다.
JavaEE6를 사용하지 않았습니다.
그러나 저는 JavaEE 및 EJB의 모든 이전 버전에 의해 충분히 심하게 구타를 당하여 법적 표준이 아닌 사실상의 표준으로 자리 잡을 때까지 신뢰하지 않을 것입니다. 현재 Spring은 여전히 사실상의 표준입니다.
한 번만 속여, 부끄러워. 날 두 번 속이고 부끄러워 세 번 속여, EJB.
일부는 Spring이 독점적이라고 주장 할 것입니다. 저는 JavaEE 사양의 공급 업체 구현이 그 이상은 아니지만 독점적이라고 주장합니다.
저는 최근에 JBoss에서 Weblogic으로 많은 Java 애플리케이션을 이동하는 주요 변환을 거쳤습니다. 모든 Spring / Hibernate 앱은 필요한 모든 라이브러리가 내장되어 있기 때문에 수정없이 이식되었습니다. JPA와 EJB 및 JSF를 사용하는 모든 앱은 이식에 재앙이었습니다. 애플리케이션 서버 간의 JPA, EJB 및 JSF 해석의 미묘한 차이로 인해 영구적으로 수정하는 데 필요한 모든 종류의 불쾌한 버그가 발생했습니다. JNDI 이름 지정과 같은 단순한 것조차도 AppServer마다 완전히 달랐습니다.
Spring은 구현입니다. JavaEE는 사양입니다. 그것은 엄청난 차이입니다. 사양이 100 % 밀폐되어 있고 공급 업체가 해당 사양을 구현하는 방식에 흔들림이 전혀없는 경우 사양을 사용하는 것이 좋습니다. 그러나 JavaEE 사양은 결코 그렇지 않습니다. JavaEE6가 더 밀폐 된 것일까 요? 모르겠어요. WAR에서 더 많이 패키징 할 수 있고 AppServer 라이브러리에 덜 의존할수록 응용 프로그램의 이식성이 향상되며 결국 Dot-NET이 아닌 Java를 사용하는 이유입니다.
사양이 완벽하더라도 모든 애플리케이션의 모든 기술 스택을 업그레이드하지 않고도 애플리케이션 서버를 업그레이드 할 수 있다면 좋을 것입니다. JBoss 4.2에서 JBoss 7.0으로 업그레이드하려면 최신 버전의 JSF가 모든 애플리케이션에 미치는 영향을 고려해야합니다. Spring-MVC (또는 Struts) 애플리케이션에 미치는 영향을 고려할 필요가 없습니다.
상관 없습니다. Java EE 6은 충분하며 거기에있는 프로필 때문에 "무거운"것이 아닙니다. 웹 프로필 만 사용하게됩니다.
개인적으로 저는 Spring을 선호합니다. 하지만 Java EE 6에 대한 합리적인 주장이 부족합니다. :)
(댓글을 통해 상기했듯이- 필요한 구성 요소에 따라 RichFaces , ICEfaces 및 / 또는 PrimeFaces 를 사용해 볼 수 있습니다).
최근에 내 클라이언트 할당 중 하나는 Spring Stack Vs Custom 프레임 워크 스택 Vs a Java EE 표준 평가와 관련이 있습니다. 한 달 간의 평가와 프로토 타이핑을 마친 후 저는 행복 할뿐만 아니라 Java EE 6 기능 세트에 놀랐습니다. 2011 년 이후의 새로운 "엔터프라이즈"프로젝트 아키텍처의 경우 Java EE 6 및 Seam 3 또는 곧 출시 될 Apache JSR299 확장 프로젝트와 같은 잠재적 확장을 사용합니다. Java EE 6 아키텍처는 간소화되었으며 지난 몇 년 동안 발전해온 많은 오픈 소스 아이디어 중 최고의 아이디어를 통합합니다.
이벤트 관리, 컨텍스트 및 DI, 인터셉터, 데코레이터, RESTful 웹 서비스, 내장형 컨테이너를 사용한 통합 테스트, 보안 등의 기능을 즉시 고려하십시오.
내 결과의 대부분은 유용 할 수있는 Java EE 6의 주요 개념을 설명하는 내 블로그에 게시됩니다 .
물론 프레임 워크를 선택하는 데있어 엄격하고 빠른 규칙은 없습니다. Java EE 6은 풍부한 대화 세션 상태를 필요로하지 않는 단순한 "웹 사이트"에 적합합니다. Grails 또는 Play를 선택하는 것이 좋습니다! 뼈대. 그러나 대화 형 웹 애플리케이션의 경우 Java EE 6이 적합하지 않은 이유를 더 잘 알 수 없습니다.
이제 얼마 후 스택에 대한 경험이 있습니다.
내 공모는 다음과 같습니다.
Adam Bien의 Future Of Enterprise Java ... Is Clear (Java EE with / without Spring and Vice Versa)를 읽어 보세요. 나는 몇 가지 이유로 Spring을 선택할 것이며 다음은 그중 하나입니다 (게시물에서 댓글 중 하나를 재현).
'어떤 Java EE 6 서버에 대해 이야기하고 있는지 잘 모르겠습니다. Glassfish 인증 및 TMAX JEUS가 있습니다. Java EE 6 호환 버전의 WebSphere, WebLogic, JBoss 등이 생산되고 실제 응용 프로그램에 사용될 수 있으려면 꽤 오랜 시간이 걸립니다 (읽기 : 몇 년). Spring 3에는 Java 1.5 및 J2EE 1.4 만 필요하므로 거의 모든 환경에서 쉽게 사용할 수 있습니다.
내 의견은 다른 사람이 언급하지 않은 것, 즉 내 작업의 코드가 수십 년 동안 (문자 그대로) 유지되는 경향이 있으므로 유지 관리가 우리에게 매우 중요하다는 점에 기반합니다. 우리 자신의 코드와 우리가 사용하는 라이브러리의 유지 관리. 우리가 제어하는 우리 자신의 코드이지만 우리가 사용하는 라이브러리가 위에서 언급 한 수십 년 이상 동안 다른 사람들 이 유지 관리하는 것이 우리의 관심사입니다 .
간단히 말해서,이를 달성하는 가장 좋은 방법은 원시 JVM까지 Sun 사양의 오픈 소스 구현을 사용하는 것이라고 결론지었습니다.
오픈 소스 구현 중 Apache Jakarta는 라이브러리를 유지하는 것으로 입증되었으며 최근 Sun은 Glassfish v3에 대한 고품질 구현을 생성하는 데 많은 작업을 수행했습니다. 어쨌든 우리는 또한 모든 모듈의 소스를 가지고 있으므로 다른 모든 모듈이 실패하면 우리가 직접 유지할 수 있습니다.
Sun 사양은 일반적으로 사양을 준수하는 구현이 쉽게 교환 될 수 있다는 것을 의미하는 매우 엄격한 의미입니다. 서블릿 컨테이너를 살펴보십시오.
이 특별한 경우에는 Java EE 6의 일부이기 때문에 JavaServer Faces를 살펴 보는 것이 좋습니다. 이는 매우 오랫동안 사용할 수 있고 유지 관리 될 것임을 의미합니다. 그런 다음 MyFaces Tomahawk를 사용하여 유용한 추가 기능을 제공하기로 선택했으며 이는 자카르타 프로젝트입니다.
JBoss Seam이나 다른 사람들에게는 잘못된 것이 없습니다. 그들의 초점은 우리에게 매우 중요한 유지 보수 문제에 덜 집중되어 있다는 것입니다.
이미 가지고 있다면 Spring을 사용하는 것을 볼 수 있지만 새 프로젝트의 경우 요점이 무엇입니까? Java EE 6 (ejb3, jsf2.0 등)으로 직접 이동합니다.
클라이언트가 Flex를 사용해도 괜찮다면 선택하십시오. BlazeDS 또는 이와 유사한 것을 사용하십시오. 해당 부분 (서버와 클라이언트간에 데이터 교환)에 더 많은 시간을 할애 할 수 있지만 양쪽에서 모든 권한을 가지고 있습니다.
브라우저를 죽이고 싶지 않다면 Vaadin을 사용하지 마십시오. 또한 페이지가 복잡해지면 코드를 살펴 보는 데 더 많은 시간을 할애합니다. 또한 사고 방식을 완전히 바꿔야하며 표준 프런트 엔드 개발에 대해 아는 모든 것은 낭비가 될 것입니다. HTML이나 JS를 사용할 필요가 없다는 주장은별로 의미가 없습니다. 사용하지 않더라도 여전히 알아야합니다. 결국 HTML과 JS로 렌더링됩니다. 그런 다음 디버깅을 시도하십시오. 간단한 작업을 위해 며칠이 있는지 확인하십시오. 게다가 html / js를 모르는 웹 개발자는 상상할 수 없습니다.
사람들이 Java EE를 직접 사용하는 대신 모든 추상화를 시도하는 이유를 이해하지 못합니다.
질문에 대한 답변은 프로젝트 요구 사항에 따라 다릅니다. 메시지 큐, 컨테이너 관리 글로벌 트랜잭션 등과 같은 Java EE 기능이 필요하지 않은 경우 tomcat + spring을 사용하십시오.
또한 경험을 통해 많은 웹 서비스 통합, 스케줄링, 메시지 대기열이 필요한 프로젝트는 일부 Java EE 스택을 사용하는 것이 가장 좋습니다. 좋은 점은 Spring을 사용하여 애플리케이션 서버에서 실행되는 Java EE 모듈과 여전히 통합 할 수 있다는 것입니다.
Java EE 6은 이전 릴리스와 매우 다르며 모든 것을 훨씬 쉽게 만듭니다. Java EE 6은 다양한 Java 커뮤니티의 최고의 아이디어를 결합합니다. 예를 들어 Spring 프레임 워크의 Rod Johnson은 Java EE 6에서 Dependency Injection JSR을 만드는 데 적극적으로 참여했습니다. 일부 조직에서 공급 업체 지원 등을 위해 중요 할 수있는 표준입니다.
GlassFish v3는 Java EE 6을 지원하며 매우 가볍고 매우 빠르게 시작됩니다. 나는 내 개발을 위해 glassfish v3를 사용하고 있으며 구성하기가 정말 쉽습니다. 서버를 그래픽으로 관리 할 수있는 매우 사용자 친화적 인 관리 콘솔이 함께 제공됩니다.
GlassfishV3 및 JSF 2를 사용하는 경우 Java EE 6의 CDI 기능을 활용하여 JSF에서 대화 (예 : 페이지와 같은 마법사)를 쉽게 작성할 수 있습니다.
하지만 Java EE 6을 사용하려면 새로운 API를 배워야합니다. 사용 가능한 기간에 따라 최선의 선택이 아닐 수 있습니다. Tomcat은 오랫동안 사용되어 왔으며 tomcat + spring 조합은 많은 웹 프로젝트에서 채택되어 많은 문서 / 포럼이 주변에 있음을 의미합니다.
저는 Spring과 Java EE 6에서 일했습니다. 제 경험에서 말할 수있는 것은 오래된 JSP 또는 독점 Flex를 사용하는 경우 Spring에 머물러도 안전하다는 것입니다.
그러나 JSF로 진행하려면 Java EE 6으로 전환해야합니다. Java EE 6에서는 Facelet과 표준화 된 스크립트 라이브러리 및 구성 요소 라이브러리로 이동합니다. 더 이상 스크립트 비 호환성 및 구성 요소 라이브러리 매트릭스가 없습니다.
Spring MVC와 관련하여 프로젝트가 너무 커지지 않는 한 좋습니다. 거대한 엔터프라이즈 애플리케이션이라면 Java EE 6을 고수해야합니다. 이것이 고유 한 구성 요소 라이브러리와 리소스 번들을 순서대로 유지할 수있는 유일한 방법이기 때문입니다.
Java EE 풀 스택이 필요한 경우 GlassFish 3.1을 권장합니다. Java EE 6 (JBoss 6, WebLogic 10.3.4)의 일부 또는 전체를 구현하는 다른 Java EE 컨테이너에 비해 매우 빠르게 시작되며 재배포에는 몇 초가 걸리며 거의 모든 작업이 구성보다 관례에 따라 수행 될 수 있습니다. 매우 친숙합니다.
원하는 기능으로 Apache Tomcat 7.x를 사용자 정의 할 수있는 "Light"를 원합니다. 다음 라이브러리에서 많이 사용했습니다. Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x)-리소스 로컬 트랜잭션 만 JSF 2.x (Mojarra) RichFaces 4.0 BIRT 런타임
지난 10 년 동안 Java EE 개발자였으며 (저는 초기 EJB, JSF 및 웹 기술에 시달림) Java EE 6은 매우 쉽고 잘 결합되어 있으며 현재 하드웨어가 원활하게 실행되므로 동기 부여 된 Spring이 더 이상 유효하지 않습니다.
나는 여전히 봄을 선호한다.
그리고 JSF를 전달합니다. 죽은 기술이라고 생각합니다. Spring MVC가 더 나은 대안이 될 것입니다. Flex도 마찬가지입니다. 계약 우선 XML 서비스의 관점에서 생각하면 UI에서 백엔드를 완전히 분리 할 수 있습니다.
glassfish v3와 Weld가 더 성숙해질 때까지 기다릴 수 없다면 Spring + Tomcat을 추천합니다. 현재 CDI 지원 애플리케이션으로 glassfish를 실행할 때 메모리 소비 / cpu로드와 관련된 몇 가지 문제가 있습니다.
모든 것을 읽지는 않았지만 이제 Java EE 6의 전쟁에서 EJB3를 사용할 수 있으므로 Tomcat에서 EJB3을 사용할 수 있다는 것을 알리기 위해서입니다 (제 생각에).
다음과 같은 이유로 Spring과 함께 Tomcat을 추천했습니다.
무거운 처리가 필요하지 않기 때문에 Tomcat을 선택하는 것이 좋습니다.