Java EE 6 대 Spring 3 스택

Java EE 6 대 Spring 3 스택

---

지금 새로운 프로젝트를 시작하고 있습니다. 기술을 선택해야합니다. 가벼운 것이 필요하므로 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 Validation, 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에 대한 합리적인 주장이 부족합니다. :)

(As I was reminded by a comment - you might want to try RichFaces, as well as ICEfaces and/or PrimeFaces - depending on what components you need).

---

Recently, one of my client assignments involved evaluating Spring Stack Vs Custom framework stack Vs a Java EE Standards. After a month of evaluation and prototyping, I was not just happy but blown away by the Java EE 6 feature set. For any new "enterprise" project architecture in 2011 and going forward, I would go with Java EE 6 and potential extensions like Seam 3 or the upcoming Apache JSR299 extensions project. Java EE 6 Architecture is streamlined and incorporates best of many open source ideas that have evolved in the last several years.

Consider the following features out of the box: Event Management, Contexts and DI, Interceptors, Decorators, RESTful webservices, integrated testing with embeddable container, Security, and many more.

Most of my results are published in my blog explaining the key concepts of Java EE 6 that you might find useful.

Of course, there is no hard and fast rule for choosing a framework. Java EE 6 could be well bloated for simpler "web sites" that don't require a rich conversational session state. You might as well pick Grails or Play! Framework. But for conversational web applications, I can't see a better argument why Java EE 6 is not a good fit.

---

Now, after some time, I have experience with stacks :

• Java EE 5 + Seam + GraniteDS + Flex
• Spring 3 + Vaadin (on GWT)
• Spring 3 + JSF 2.0 (PrimeFaces)

My colclusions are:

• Spring 3 is much much simpler than Seam (almost Java EE 6) and runs on Tomcat and Jetty! (Jetty for developement with maven plugin is a trasure).
• I love Flex (I actually was a Flex developer for long time so I'm biased) and if you need rich interface and can buy FlashBuilder use this, but use this wich Spring + GraniteDS or BlazeDs backend. If you can't buy FlashBuilder don't waste your time.
• Vaadin is great!. Developement process is simpler than Flex, but you can create rich application easily without HTML mess. You wont't write a singe JS line. You just need some CSS (in Flex you need it too). So if your application interface is going to behave like desktop application and you can't (or dont want to) use Flex - use Vaadin. Warning! Vaadin has big JS overhead for browser.
• If you create simpler website-like application use JSF2.0 (with spring backend as above). You'll need to fight with HTML (I hate it) and creating rich interface will be harder than Vaadin (especially layouts). You will get lightweight HTML for slower browsers/compuetrs. I like PrimeFaces - it's easy and well documented. Second place is IceFaces
• If you create a website (NOT a web application) where you need to put life into HTML (instead of create enterprise application that fits into browser) use Wicket (if you prefer component based, pull attitude) or SpringMVC (if you prefer template based, push attitude) or just use Play! framework. Remember that creating rich data-based components will be much much harder but you will have control over each tag of html (your HTML/Graphics designer will love it)

---

Read Adam Bien's Future Of Enterprise Java ...Is Clear (Java EE with/without Spring and Vice Versa), including comments to get both sides of coin. I will choose Spring for several reasons and following is one of them (reproducing one of the comments from post)

'I am not sure which Java EE 6 server you are talking about. There is Glassfish certified and TMAX JEUS. It will take quite a while (read: years) until Java EE 6 compliant versions of WebSphere, WebLogic, JBoss etc are in production and can be used for real application. Spring 3 just needs Java 1.5 and J2EE 1.4 so can readily be used in almost all environments'

---

My opinion is based on something not mentioned by others, namely that code at my work tend to live for decades (literaly), and hence that maintenance is very important to us. Maintenance of our own code, and the libraries we use. Our own code we control, but it is in our interest that the libraries we use, are maintained by others in the above mentioned decades or more.

To make a long story short, I have concluded that the best way to achieve this is by using open source implementations of Sun specifications all the way down to the raw JVM.

Of the open source implementations Apache Jakarta has proven to maintain their libraries, and recently Sun has done a lot of work in producing high quality implementations for Glassfish v3. In any case, we also have the source for all modules, so if all else fails, we can maintain them ourselves.

Sun specifications are usually very strict meaning that implementations conforming to the spec can be interchanged easily. Just have a look at servlet containers.

In this particular case, I would suggest having a look at JavaServer Faces simply because it is part of Java EE 6 meaning it will be available and maintained for a very, very long time. Then we have chosen to augment with MyFaces Tomahawk as it gives some useful additions, and it is a jakarta project.

There is nothing wrong with JBoss Seam or others. It is just that their focus is less towards the maintenance issue that is so important to us.

---

I can see using Spring if you already have it, but for the new project, what's the point? I would go directly with Java EE 6 (ejb3, jsf2.0, etc.)

If the client is fine with Flex, go for it. Use BlazeDS or similar - no mvc. You might spend more time on that part (exchanging data between server and client) but you have full control on both sides.

Don't use Vaadin, unless you want to kill your browser. Plus, you spend more time on getting around the code once your pages become more complex. Also, your mindset will need to be completely changed and anything you know about standard front end development will be waste. The argument that you don't have to use HTML or JS doesn't make much sense. You still have to know it even if you don't use it. It renders to HTML and JS eventually. Then try to debug it - make sure you got few days for simple stuff. Plus, I cannot imagine web developer who doesn't know html/js.

I just don't understand why people are trying all those abstractions instead of using Java EE directly.

---

Why is there still rumblings about EJB being heavyweight in 2010? It seems people are not being updated in Java EE technologies. Just try it out , you will be pleasantly surprised how things are simplified in Java EE 6.

---

The answer to your questions depends on your project requirements. If you don't require the Java EE features like message queues, container managed global transactions etc then go with tomcat+spring.

Also from experience I have found that projects that require a lot of web service integration, scheduling, message queues are best best done using some of the Java EE stack. The good thing is using spring you can still integrate with Java EE modules running in an application server.

Java EE 6 is very different from the previous releases, and it really makes everything lot easier. Java EE 6 combines the best ideas from the diverse Java community - for instance Rod Johnson from Spring framework was actively involved in the making of the Dependency Injection JSR in Java EE 6. A benefit of using Java EE 6 is that you are coding according to a standard, which could be important in some organizations for vendor support etc.

GlassFish v3 supports Java EE 6 and it is quite light-weight and starts up really fast. I have been using glassfish v3 for my developments, and it is really easy to configure. It comes with a very user-friendly admin console that lets you graphically administer your server.

If you are using GlassfishV3 and JSF 2, then you can take advantage of the CDI features of Java EE 6, that lets you easily create conversations (e.g. wizard like pages) in JSF.

Having said that, using Java EE 6 also requires you to learn a new API. Depending on the timeframe available it might not be the best choice for you. Tomcat has been around for ages, and the tomcat+spring combination has been adopted by many web projects, which means lots of documentation/forums are around.

---

I have worked in both Spring and Java EE 6. What I can say from my experience is that If you are going for the age old JSP or proprietary Flex then you are safe if you stay with Spring.

But if you are to move ahead with JSF then it's time to shift to Java EE 6. With Java EE 6 you are moving to Facelets and standardized script libraries and component libraries. No more script incompatibilities and component library matrices.

Regarding Spring MVC, it's good as long as your project doesn't grow too big. If it's a huge enterprise application stick on to Java EE 6. Because that's the only way you could maintain your own component libraries and resource bundles in an orderly manner.

---

If you need the Java EE full stack I recommend you GlassFish 3.1. It starts very quickly compared to other Java EE containers which implements some part or all Java EE 6 (JBoss 6, WebLogic 10.3.4), redeployment take seconds and almost all can be done by convention over configuration, it is very friendly.

I you want something "Light" you can customize an Apache Tomcat 7.x with the desired features. I used a lot with the following libraries: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - only resource local transactions JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Been a Java EE developer for the past 10 years (I suffer early EJB, JSF and web technologies), Java EE 6 is very easy, well coupled and current hardware runs smooth so original reasons that motivated Spring are no longer valid.

---

I'd still prefer Spring.

And I'd pass on JSF. I think it's a dead technology. Spring MVC would be a better alternative. So would Flex. Think in terms of contract first XML services and you can decouple the back end from the UI completely.

---

I'd recommend Spring + Tomcat unless you can wait the time for glassfish v3 and Weld to become more mature. There are currently a few issues with memory consumption/cpu load when running glassfish with CDI enabled applications.

---

Didn't read everything but just to tell that you can now use EJB3 inside a war on Java EE 6 so you can use EJB3 on Tomcat (I think).

---

I recommended to you Tomcat with Spring because:

1. Spring can create backing beans for JSP
2. You will use Spring to persist object through JPA

It is good choice to choose Tomcat because you don't need any heavyweight processing

참고URL : https://stackoverflow.com/questions/2499323/java-ee-6-vs-spring-3-stack