Java EE 6 kontra Spring 3 stack [zamknięty]

90

Rozpoczynam teraz nowy projekt. Muszę wybrać technologie. Potrzebuję czegoś lekkiego, więc nie ma EJB ani Seam. Z drugiej strony potrzebuję JPA (Hibernate lub alternatywa) i JSF z IceFaces.

Czy uważasz, że taki stos w Spring 3 wdrożony na Tomcat to dobry wybór? A może aplikacja internetowa Java EE 6 mogłaby być lepsza? Obawiam się, że Java EE 6 to nowa technologia, jeszcze niezbyt dobrze udokumentowana. Tomcat wydaje się być łatwiejszy w utrzymaniu niż Glassfish 3.

Jaka jest Twoja opinia? Czy masz jakieś doświadczenia?

Piotr Gwiazda
źródło
8
Chciałbym pójść do primefaces.org zamiast ICEfaces jeśli chcesz światło. Jest znacznie szybszy i bardziej uproszczony.
Shervin Asgari
1
Obecnie tylko Glassfish dostarcza JEE6. Firma Resin powoli wdraża profil sieciowy JEE6 , który może Ci wystarczyć w zależności od potrzeb.
Thorbjørn Ravn Andersen
3
@ Thorbjørn Możesz użyć profilu internetowego GlassFish v3, jeśli chcesz mieć tylko profil internetowy.
Pascal Thivent
@Pascal, chodziło o szczegóły, że wkrótce pojawi się alternatywa dla Glassfish, aby uzyskać JEE6, jeśli możesz żyć z profilem internetowym (mogę), nie mówiąc, że Glassfish nie może.
Thorbjørn Ravn Andersen
@ Thorbjørn Zapomniałem usunąć @ Thorbjørn :) Komentarz był skierowany do OP, który wydaje się zakładać, że używanie "full-stack" GFv3 jest jedyną opcją.
Pascal Thivent

Odpowiedzi:

101

Potrzebuję czegoś lekkiego, więc nie ma EJB ani Seam.

Czy mógłbyś wyjaśnić, co sprawia, że ​​EJB są ciężkie od czasu EJB3? Czy zdajesz sobie sprawę, że nie jesteśmy już w 2004 roku? Naprawdę chciałbym przeczytać twoją definicję światła i twoje argumenty (iz przyjemnością zaktualizuję swoją odpowiedź, ponieważ jestem prawie pewien, że chciałbym powiedzieć kilka solidnych rzeczy).

Z drugiej strony potrzebuję JPA (Hibernate lub alternatywa) i JSF z IceFaces.

Java EE 6 Web Profile, który obejmuje JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... byłby do tego idealny i możesz użyć GlassFish v3 Web Profile, aby uruchomić aplikację zbudowaną z Java EE 6 Web Profile .

Czy uważasz, że taki stos na Spring 3 wdrożony na Tomcacie to dobry wybór? A może aplikacja internetowa Java EE 6 mogłaby być lepsza?

Cóż, podoba mi się pomysł uruchamiania mojego kodu na niezastrzeżonej platformie (Java EE), a nie na zastrzeżonym kontenerze (Spring). Myślę, że Java EE 6 jest wystarczająco dobra (i to jest eufemizm, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Zauważ, że byłem sceptykiem JSF, ale przyjrzałem się ponownie i JSF 2.0 z CDI jest tak inny, że nie mogę nawet porównać. A jeśli nie spojrzałeś na CDI, powiem ci, że to rządzi.

Obawiam się, że Java EE 6 to nowa technologia, jeszcze niezbyt dobrze udokumentowana.

Java EE wygląda na całkiem dobrze udokumentowaną. To brzmi jak darmowe roszczenie. Wierz mi lub nie, ale zaczynam uważać, że Spring się komplikuje, a Java EE staje się łatwiejsza.

Tomcat wydaje się być łatwiejszy w utrzymaniu niż Glassfish 3.

Próbowałeś czegoś? Czy napotkałeś jakiś szczególny problem? Znowu brzmi to jak bezpłatne roszczenie.

Pascal Thivent
źródło
2
Jestem tuż po dużym projekcie ratera opracowanym z EJB3.0 + Seam na JBoss z Drools, GraniteDS i kilkoma innymi. Zgadzam się Seam rządzi! Ale spędziłem 50% rozwoju na ponownym wdrożeniu, ponownym uruchomieniu serwerów, błędach wdrażania, czyszczeniu katalogów tymczasowych itp. Z drugiej strony wydajność JBoss Tools była naprawdę słaba (mam na myśli naprawdę - ctrl + spacja i 10s zawiesza się) To naprawdę zniechęca mnie do korzystania z JEE6 który wygląda jak zapożyczony z ramy Seam. Jeśli chodzi o serwer, nie chcę myśleć o puli połączeń, jndi, jms, jmx, depilacji uszu. Potrzebuję czegoś, co mógłbym uruchomić w ciągu kilku sekund.
Piotr Gwiazda
6
@peperg Gaving King jest liderem specyfikacji CDI (Weld to RI), więc znajdziesz podobieństwa między Seam i CDI. Ale CDI! = Szew, Java EE 6! = Szew, twoja percepcja jest błędna. Może wypróbuj GlassFish v3 Web Profile, będziesz zaskoczony (a po zdefiniowaniu puli połączeń nie ma się czym martwić).
Pascal Thivent
8
O co chodzi z ludźmi, którzy twierdzą, że EJB są ciężkie? Używam EJB v3.1 i są one po prostu oznaczone adnotacjami pojos. Kiedy mówią ciężkie, mają na myśli wydajność, czy co?
arg20,
13
@ arg20 - To naprawdę ważne pytanie i Pascal słusznie prosi o wyjaśnienie, co w tym kontekście oznacza termin „ciężki” (lub „lekki”). Najprawdopodobniej jest to pozostałość po dawnym sporze między wiosną a EJB. Na początku EJB1 i 2 były koncepcyjnie ciężkie. Nadmierny nacisk na zdalne i stanowe fasole, absurdalnie gadatliwy deskryptor wdrażania XML i całkowicie szalona liczba wymaganych interfejsów do zaimplementowania dały im bardzo złą reputację. W przypadku EJB3 (2006) sytuacja uległa całkowitej zmianie, ale ludzie, którzy opuścili EJB w 2004 roku na wiosnę, czasami nadal myślą, że rok 2004, a EJB2 jest najnowszy.
Arjan Tijms
7
Zauważ, że na stronie Spring's about jest napisane "Wierzymy, że: J2EE powinno być łatwiejsze w użyciu". Zauważ, że używają terminu „J2EE”, a nie „Java EE”, co było poprawną nazwą od czasu wydania Java EE 5 (chyba). To wiele o nich mówi ...
Vítor E. Silva Souza
32

Nie korzystałem z JavaEE6.

Jednak wszystkie poprzednie wersje JavaEE i EJB dostały mnie na tyle mocno, że nie będę mu ufać, dopóki nie ustali się jako de facto standardu, a nie tylko de iure. Obecnie wiosna nadal jest de facto standardem.

Oszukałeś mnie raz hańba ci. Oszukaj mnie dwa razy, wstyd mi. Oszukaj mnie trzy razy, EJB.

Niektórzy twierdzą, że Spring jest zastrzeżony. Twierdziłbym, że implementacje specyfikacji JavaEE przez dostawców były równie zastrzeżone, jeśli nie bardziej.

Niedawno przeszedłem dużą konwersję, przenosząc kilka aplikacji Java z JBoss do Weblogic. Wszystkie aplikacje Spring / Hibernate zostały przeniesione bez modyfikacji, ponieważ miały wbudowane wszystkie potrzebne biblioteki. Wszystkie aplikacje, które korzystały z JPA, EJB i JSF, były katastrofą. Subtelne różnice w interpretacji JPA, EJB i JSF między serwerami aplikacji powodowały różnego rodzaju paskudne błędy, których naprawa trwała wieczność. Nawet coś tak prostego jak nazewnictwo JNDI było zupełnie inne w przypadku serwerów aplikacji.

Wiosna to realizacja. JavaEE to specyfikacja. To jest OGROMNA różnica. Wolałbym użyć specyfikacji, JEŚLI specyfikacja była w 100% szczelna i nie dawała absolutnie żadnego miejsca na poruszanie się w sposobie, w jaki sprzedawcy wdrażają tę specyfikację. Ale specyfikacja JavaEE nigdy nie była taka. Może JavaEE6 jest bardziej szczelna? Nie wiem Im więcej możesz spakować w swoim WAR i im mniej polegasz na bibliotekach AppServer, tym bardziej przenośna będzie twoja aplikacja i to jest w końcu powód, dla którego używam Javy, a nie Dot-NET.

Nawet JEŚLI specyfikacja była szczelna, byłoby miło móc zaktualizować serwer aplikacji bez konieczności aktualizowania wszystkich moich stosów technologicznych we wszystkich moich aplikacjach wraz z nim. Jeśli chcę zaktualizować JBoss 4.2 do JBoss 7.0, muszę wziąć pod uwagę wpływ nowszej wersji JSF na wszystkie moje aplikacje. Nie muszę brać pod uwagę wpływu na moje aplikacje Spring-MVC (lub Struts).

Zlewka
źródło
1
Dokładnie, to jest świetne rozumowanie.
Palesz
1
Zgadzam się z tym rozumowaniem, wiele problemów, z jakimi się spotkałem, dotyczyło zależności od implementacji specyfikacji przez kontener. Znacznie mniej bólu powodowanego przez wbudowane biblioteki. Trudno się spierać, poza filozoficznymi preferencjami specyfikacji.
Peter Porter,
Wspaniałe rozumowanie. Czy to jednak twoje doświadczenie nawet po JEE 6? Rozumiem, że implementacja specyfikacji serwera App Server może nadal być uciążliwa - stąd ta sama specyfikacja zaimplementowana przez App Server 1 może być prosta i wydajna, podczas gdy nie dla App Server 2
Soumya
1
+1. Ponadto serwer aplikacji zmienia się zgodnie z harmonogramem operacji, gdzie wiosna / hibernacja jest pod kontrolą programistów. w środowisku dużej firmy aktualizacja serwera aplikacji to dużo trudniejsza sprawa.
Nathan Hughes
Tak naprawdę nie rozumiałem, o co chodzi w Dot-Net. Jest tak samo własności jak Spring i jest rozwijany przez jednego dostawcę, którym jest Microsoft. Czy można to wyjaśnić?
user1339260
23

To nie ma znaczenia. Java EE 6 jest wystarczająco dobra i ze względu na dostępne tam profile nie jest „ciężka” - będziesz po prostu używać profilu internetowego.

Osobiście wolę wiosnę. Ale wyczerpują mi się racjonalne argumenty przeciwko Java EE 6 :)

(Jak przypomniał mi komentarz - możesz wypróbować RichFaces , a także ICEfaces i / lub PrimeFaces - w zależności od potrzebnych komponentów).

Bozho
źródło
1
Tak więc pytanie brzmi: „Czy ma sens używanie serwera aplikacji Glassfish z pełnym stosem tylko przy użyciu profilu internetowego”?
Piotr Gwiazda
1
@peperg Użyj profilu internetowego GlassFish v3, jeśli chcesz mieć tylko profil internetowy, zobacz moją odpowiedź.
Pascal Thivent
Umieściłem tutaj kilka argumentów stackoverflow.com/questions/2822812/spring-3-0-vs-j2ee-6-0/… , raczej wziętych z punktu widzenia „jak wziąć to do produkcji”. Więc może to trochę wypełnia twoje argumenty.
Oliver Drotbohm
@peperq, JBoss 6 został wydany w okresie świątecznym.
Thorbjørn Ravn Andersen
17

Niedawno jeden z moich klientów dotyczył oceny Spring Stack Vs Custom Framework w porównaniu ze standardami Java EE. Po miesiącu testów i prototypów nie tylko byłem zadowolony, ale też zachwycił mnie zestaw funkcji Java EE 6. W przypadku każdej nowej architektury projektu „korporacyjnego” w 2011 roku i w przyszłości wybrałbym Java EE 6 i potencjalne rozszerzenia, takie jak Seam 3 lub nadchodzący projekt rozszerzeń Apache JSR299. Architektura Java EE 6 została usprawniona i łączy w sobie najlepsze z wielu pomysłów open source, które ewoluowały w ciągu ostatnich kilku lat.

Rozważ następujące funkcje po wyjęciu z pudełka: zarządzanie zdarzeniami, konteksty i DI, przechwytywacze, dekoratory, usługi sieciowe REST, zintegrowane testowanie z wbudowanym kontenerem, zabezpieczenia i wiele innych.

Większość moich wyników jest publikowana na moim blogu, wyjaśniając kluczowe pojęcia Java EE 6, które mogą okazać się przydatne.

Oczywiście nie ma sztywnej zasady wyboru frameworka. Java EE 6 może być dobrze rozbudowana w przypadku prostszych „witryn internetowych”, które nie wymagają rozbudowanego stanu sesji konwersacyjnej. Równie dobrze możesz wybrać Grails lub Play! Struktura. Ale w przypadku konwersacyjnych aplikacji internetowych nie widzę lepszego argumentu, dlaczego Java EE 6 nie jest dobrym rozwiązaniem.

pri
źródło
Java EE 6 jest po prostu cholernie powolna, profil sieciowy Glassfish i Glassfish jest po prostu bardzo wolny, aby zacząć porównywać je do molo / kocur / cokolwiek. Testowanie osadzalnego kontenera jest również bardzo powolne.
Palesz
15

Teraz, po pewnym czasie, mam doświadczenie ze stosami:

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

Moje wyniki to:

  • Spring 3 jest znacznie prostszy niż Seam (prawie Java EE 6) i działa na Tomcat i Jetty! (Przystań do rozwoju z wtyczką maven to szkoda).
  • Uwielbiam Flex (tak naprawdę byłem programistą Flex przez długi czas, więc jestem stronniczy) i jeśli potrzebujesz bogatego interfejsu i możesz kupić FlashBuilder, użyj tego, ale użyj tego, który backend Spring + GraniteDS lub BlazeDs. Jeśli nie możesz kupić FlashBuildera, nie trać czasu.
  • Vaadin jest świetny !. Proces programowania jest prostszy niż Flex, ale możesz łatwo tworzyć rozbudowane aplikacje bez bałaganu HTML. Nie napiszesz ani jednej linii JS. Potrzebujesz tylko CSS (w Flex też go potrzebujesz). Jeśli więc interfejs Twojej aplikacji będzie zachowywał się jak aplikacja desktopowa i nie możesz (lub nie chcesz) używać Flex - użyj Vaadin. Ostrzeżenie! Vaadin ma duże obciążenie JS dla przeglądarki.
  • Jeśli tworzysz prostszą aplikację podobną do strony internetowej, użyj JSF2.0 (z zapleczem sprężynowym jak powyżej). Będziesz musiał walczyć z HTML (nienawidzę tego), a tworzenie bogatego interfejsu będzie trudniejsze niż w Vaadin (zwłaszcza układy). Otrzymasz lekki HTML dla wolniejszych przeglądarek / komputerów. Lubię PrimeFaces - to łatwe i dobrze udokumentowane. Drugie miejsce to IceFaces
  • Jeśli tworzysz stronę internetową (NIE aplikację internetową), w której chcesz tchnąć życie w HTML (zamiast tworzyć aplikację korporacyjną, która pasuje do przeglądarki), użyj Wicket (jeśli wolisz oparty na komponentach, nastawienie pull) lub SpringMVC (jeśli wolisz oparty na szablonie , nastawienie pchania) lub po prostu użyj Play! struktura. Pamiętaj, że tworzenie bogatych komponentów opartych na danych będzie znacznie trudniejsze, ale będziesz mieć kontrolę nad każdym tagiem HTML (Twój projektant HTML / Graphics pokocha to)
Piotr Gwiazda
źródło
21
Nie rozumiem, jak twoja własna odpowiedź ma się do pytania ...
Pere Villega
1
-1 Wydaje się bardzo niewłaściwe przyjęcie tej odpowiedzi, ponieważ nawet nie wspomina o Java EE 6. Co więcej, nie odnosi się do żadnego z punktów poruszonych w dobrze przemyślanej (i znacznie bardziej wysoko ocenionej) @Pascal Thievent odpowiedź.
user359996
1
Właściwie pytanie nie jest bardziej aktualne. JEE 6 jest teraz bardzo dojrzały, nie było to w marcu 2010 roku, kiedy zadano pytanie.
Piotr Gwiazda
@PiotrGwiazda w jaki sposób zmienił się JEE 6 od tego czasu? Ludzie bali się go wtedy bardziej, ale w zasadzie był to ten sam JEE 6.
ymajoros
1
Chodziło mi o to, że implementacje JEE6 są bardziej dojrzałe i dostępne. JBoss 7 jest teraz stabilny i dostępnych jest więcej implementacji. Społeczność też jest teraz większa. Więcej narzędzi i bibliotek obsługuje teraz stos JEE 6.
Piotr Gwiazda
8

Przeczytaj artykuł Adama Bien's Future Of Enterprise Java ... Is Clear (Java EE z / bez Spring i Vice Versa) , w tym komentarze, aby uzyskać obie strony medalu. Sprężynę wybiorę z kilku powodów, a jeden z nich to kolejny (powielając jeden z komentarzy z postu)

„Nie jestem pewien, o którym serwerze Java EE 6 mówisz. Posiada certyfikat Glassfish i TMAX JEUS. Zajmie trochę czasu (czytaj: lata), zanim wersje WebSphere, WebLogic, JBoss itp. Zgodne z Java EE 6 będą w produkcji i będą mogły być używane w rzeczywistych aplikacjach. Spring 3 potrzebuje tylko Java 1.5 i J2EE 1.4, więc może być z łatwością używany w prawie wszystkich środowiskach ”

Adisesha
źródło
6
Jesteśmy prawie dokładnie rok później, a JBoss AS 6, który obsługuje Java EE 6, jest obecnie używany w produkcji.
Arjan Tijms,
8

Moja opinia jest oparta na czymś, o czym inni nie wspominali, a mianowicie na tym, że kod w mojej pracy ma tendencję do życia przez dziesięciolecia (dosłownie), dlatego utrzymanie jest dla nas bardzo ważne. Utrzymanie własnego kodu i bibliotek, z których korzystamy. Kontrolujemy własny kod, ale w naszym interesie jest, aby biblioteki, z których korzystamy, były utrzymywane przez innych w wyżej wymienionych dekadach lub dłużej.

Krótko mówiąc, doszedłem do wniosku, że najlepszym sposobem na osiągnięcie tego jest użycie implementacji specyfikacji firmy Sun o otwartym kodzie źródłowym, aż do surowej maszyny JVM.

Spośród wdrożeń open source, Apache Jakarta dowiodło, że utrzymuje swoje biblioteki, a ostatnio Sun wykonał dużo pracy w tworzeniu wysokiej jakości wdrożeń dla Glassfish v3. W każdym razie mamy również źródło dla wszystkich modułów, więc jeśli wszystko inne zawiedzie, możemy sami je utrzymać.

Specyfikacje firmy Sun są zwykle bardzo rygorystyczne, co oznacza, że ​​implementacje zgodne ze specyfikacją można łatwo wymieniać. Wystarczy spojrzeć na kontenery serwletów.

W tym konkretnym przypadku sugerowałbym przyjrzenie się JavaServer Faces po prostu dlatego, że jest częścią Java EE 6, co oznacza, że ​​będzie dostępny i utrzymywany przez bardzo, bardzo długi czas. Następnie zdecydowaliśmy się rozszerzyć o MyFaces Tomahawk, ponieważ daje kilka przydatnych dodatków i jest to projekt Dżakarty.

Nie ma nic złego w JBoss Seam lub innych. Po prostu koncentrują się mniej na kwestii utrzymania, która jest dla nas tak ważna.

Thorbjørn Ravn Andersen
źródło
Okazało się, że Java ServerFaces 2 w Java EE 6 może zrobić na własną rękę, co nam potrzebne do Tomahawk z JSF 1. Jest to bardzo zdolny ramy (ale ciężki kawałek XML)
Thorbjørn Ravn Andersen
Świetna uwaga, niestety ludzie często zapominają, że oprogramowanie jest stworzone do życia przez dziesięciolecia, a długoterminowe wsparcie jest kluczowym kluczem.
timmz
6

Widzę, jak używać Springa, jeśli już go masz, ale po co w nowym projekcie? Poszedłbym bezpośrednio z Java EE 6 (ejb3, jsf2.0 itp.)

Jeśli klientowi odpowiada Flex, zrób to. Użyj BlazeDS lub podobnego - bez MVC. Możesz poświęcić więcej czasu na tę część (wymianę danych między serwerem a klientem), ale masz pełną kontrolę po obu stronach.

Nie używaj Vaadin, chyba że chcesz zabić swoją przeglądarkę. Ponadto, gdy strony stają się bardziej złożone, poświęcasz więcej czasu na obejście kodu. Ponadto twój sposób myślenia będzie wymagał całkowitej zmiany, a wszystko, co wiesz o standardowym programowaniu front-endu, będzie marnotrawstwem. Argument, że nie musisz używać HTML lub JS, nie ma większego sensu. Nadal musisz to wiedzieć, nawet jeśli go nie używasz. Ostatecznie renderuje się do HTML i JS. Następnie spróbuj go zdebugować - upewnij się, że masz kilka dni na proste rzeczy. Poza tym nie mogę sobie wyobrazić programisty, który nie zna html / js.

Po prostu nie rozumiem, dlaczego ludzie próbują wszystkich tych abstrakcji zamiast bezpośrednio używać Java EE.

Marcin Koziarski
źródło
5

Dlaczego w 2010 roku wciąż krążą plotki, że EJB jest w wadze ciężkiej? Wygląda na to, że ludzie nie są aktualizowani w technologiach Java EE. Po prostu wypróbuj, będziesz mile zaskoczony, jak upraszcza się rzeczy w Java EE 6.

nash
źródło
4

Odpowiedź na Twoje pytania zależy od wymagań projektu. Jeśli nie potrzebujesz funkcji Java EE, takich jak kolejki wiadomości, globalne transakcje zarządzane przez kontener itp., Wybierz tomcat + spring.

Również z doświadczenia odkryłem, że projekty, które wymagają dużej integracji usług internetowych, planowania i kolejek wiadomości, najlepiej wykonywać przy użyciu części stosu Java EE. Dobrą rzeczą jest to, że korzystając ze Springa możesz nadal integrować się z modułami Java EE działającymi na serwerze aplikacji.

Java EE 6 bardzo różni się od poprzednich wydań i naprawdę ułatwia wszystko. Java EE 6 łączy w sobie najlepsze pomysły ze zróżnicowanej społeczności Java - na przykład Rod Johnson ze Spring był aktywnie zaangażowany w tworzenie Dependency Injection JSR w Java EE 6. Korzyścią z używania Java EE 6 jest to, że programujesz zgodnie z standard, który może być ważny w niektórych organizacjach w zakresie wsparcia dostawcy itp.

GlassFish v3 obsługuje Java EE 6, jest dość lekki i uruchamia się bardzo szybko. Używałem Glassfish v3 do moich opracowań i jest naprawdę łatwy w konfiguracji. Jest wyposażony w bardzo przyjazną dla użytkownika konsolę administracyjną, która umożliwia graficzne administrowanie serwerem.

Jeśli używasz GlassfishV3 i JSF 2, możesz skorzystać z funkcji CDI Java EE 6, które pozwalają łatwo tworzyć konwersacje (np. Strony przypominające kreatora) w JSF.

Mimo to, używanie Java EE 6 wymaga również nauczenia się nowego API. W zależności od dostępnych ram czasowych może to nie być najlepszy wybór dla Ciebie. Tomcat istnieje od wieków, a kombinacja tomcat + spring została przyjęta w wielu projektach internetowych, co oznacza, że ​​istnieje mnóstwo dokumentacji / forów.

Raz
źródło
Nie zgadzam się z Twoim pierwszym zdaniem, wybór nie polega na używaniu JMS czy nie. I nie sądzę, żeby JSR-330 był tak ważny w Javie EE 6 (jest tam bardziej z powodów politycznych), ważną częścią jest JSR-299 (CDI). Przynajmniej taka jest moja opinia.
Pascal Thivent
Zgadzam się, że była pewna polityka dotycząca JSR330 - niemniej jest to dość ważne, ponieważ zapewnia wspólną podstawę do wstrzykiwania zależności w Javie (SE lub EE), a nie czyni z DI technologię tylko JEE. Jest również obsługiwany przez Spring Framework i Google Guice, co oznacza, że ​​kod Spring / Guice będzie łatwy do przeniesienia do JEE6 lub odwrotnie. JSR299 został również zaprojektowany, aby rozszerzyć funkcje JSR330. Masz rację w tym, że dla aplikacji internetowych w JEE6, JSR299 jest absolutnie kluczowe. Dzięki tym dwóm JSR, JEE6 i Spring mają bardzo podobny model programowania. Dzięki za komentarz!
Raz
3

Pracowałem zarówno w Spring, jak i Java EE 6. Z mojego doświadczenia mogę powiedzieć, że jeśli wybierasz stary JSP lub prawnie zastrzeżony Flex, jesteś bezpieczny, jeśli pozostaniesz w Spring.

Ale jeśli chcesz iść naprzód z JSF, to czas przejść na Java EE 6. Z Java EE 6 przechodzisz do Facelets oraz standardowych bibliotek skryptów i bibliotek komponentów. Koniec z niezgodnościami skryptów i macierzami bibliotek komponentów.

Jeśli chodzi o Spring MVC, jest to dobre, o ile twój projekt nie rozrasta się zbytnio. Jeśli jest to ogromna aplikacja dla przedsiębiorstw, trzymaj się Java EE 6. Ponieważ tylko w ten sposób można zarządzać własnymi bibliotekami komponentów i pakietami zasobów w uporządkowany sposób.

user373480
źródło
1
Dzięki za komentarz. Mój wybór padł na Spring + Vaadin.
Piotr Gwiazda
3

Jeśli potrzebujesz pełnego stosu Java EE, polecam GlassFish 3.1. Uruchamia się bardzo szybko w porównaniu do innych kontenerów Java EE, które implementują część lub całość Java EE 6 (JBoss 6, WebLogic 10.3.4), ponowne wdrażanie zajmuje kilka sekund i prawie wszystko można zrobić przez konwencję zamiast konfiguracji, jest bardzo przyjazny.

Jeśli chcesz czegoś „lekkiego”, możesz dostosować Apache Tomcat 7.x do żądanych funkcji. Dużo używałem z następującymi bibliotekami: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - tylko lokalne transakcje zasobów JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Byłem programistą Java EE przez ostatnie 10 lat (cierpię na wczesne EJB, JSF i technologie internetowe), Java EE 6 jest bardzo łatwa, dobrze połączona, a obecny sprzęt działa płynnie, więc oryginalne powody, dla których motywowany Spring nie jest już ważny.

ssamayoa
źródło
1
Podoba mi się twoja odpowiedź. Bardzo rozsądne. Kiedy wysłałem pytanie, JEE6 był bardzo młody, a Tomcat 7 nie był jeszcze ukończony. „oryginalne powody, dla których zmotywowana wiosna nie są już aktualne” - to prawda, ale JEE6 z CDI potrzebuje trochę czasu, aby się załatwić. Na przykład: monitorowanie Javamelody jest dostępne dla Springa i Guice (nie wyobrażam sobie pracy z aplikacjami bez niego). EHcache jest dostępne dla Springa (mam na myśli wyniki metod buforowania). Wiele rzeczy, takich jak programowanie aspektów, jest wciąż łatwiejszych w Spring, ponieważ wiele bibliotek i frameworków innych firm łatwo integruje się ze Springem, ale jeszcze nie z JEE6.
Piotr Gwiazda
1

Nadal wolę wiosnę.

I pominąłbym JSF. Myślę, że to martwa technologia. Spring MVC byłby lepszą alternatywą. Więc Flex. Pomyśl w kategoriach umowy o pierwsze usługi XML i możesz całkowicie oddzielić zaplecze od interfejsu użytkownika.

duffymo
źródło
1
Stworzyłem kilka aplikacji za pomocą Java + Flex i PHP + Flex i zgadzam się, że jest to najlepsze rozwiązanie dla bogatych interfejsów. Ale w tej aplikacji nie mogę używać Flexa :( Potrzebuję jednak jakiegoś wysokopoziomowego interfejsu, więc Spring MVC nie jest rozwiązaniem. Chcę myśleć o sortowalnych datatable albo o <tr> <td> w pętli.
Piotr Gwiazda
1
@duffymo - mogę się spierać, czy flex to dobry wybór. JSF z pewnością nie jest martwy, szczególnie w przypadku bibliotek takich jak richfaces, primefaces, icefaces itp.
Bozho
1
W IceFaces tworzę menu, drzewa, datagridy używają akcji, zdarzeń i nie myślę, czy strona przeładuje się, czy jest to żądanie Ajax. Ładowane drzewo datagrid lub ajax, które można sortować, jest komponentem wbudowanym. W Spring MVC operuję na HTML - tabelach, listach itp. Muszę użyć jakiegoś frameworka javascript innej firmy i ręcznie stworzyć magię AJAX. Chciałbym to zrobić w Flex, ale to decyzja polityczna / biznesowa - nie moja.
Piotr Gwiazda
1
Moje obecne dwa projekty JSF zdecydowanie nie są martwe;) I jestem o wiele bardziej zadowolony ze sposobu tworzenia RIA w JSF („bogaty” w „richfaces” jest do tego celu) niż używanie Flexa. Jeden nawet w przyszłym tygodniu zostanie opublikowany.
Bozho
2
Naprawdę chciałbym wiedzieć, dlaczego nadal wolisz wiosnę, Java EE 6 jest cholernie dobra. Nie sądzisz, że działanie na otwartej platformie jest ważne dla przyszłości Javy?
Pascal Thivent
0

Poleciłbym Spring + Tomcat, chyba że możesz poczekać, aż Glassfish v3 i Weld staną się bardziej dojrzałe. Obecnie występuje kilka problemów z zużyciem pamięci / obciążeniem procesora podczas uruchamiania Glassfish z aplikacjami obsługującymi CDI.


źródło
0

Nie przeczytałem wszystkiego, ale tylko po to, aby powiedzieć, że możesz teraz używać EJB3 w wojnie na Javie EE 6, więc możesz używać EJB3 na Tomcat (tak mi się wydaje).

Sebastien Lorber
źródło
Tak, możesz spakować EJB w WAR w Java EE 6, ale to nie znaczy, że możesz wdrożyć taką WAR na Tomcat. Potrzebujesz kontenera implementującego profil sieciowy, a Tomcat tego nie robi, a społeczność Tomcat właściwie nie ma planu na jego wdrożenie (zobacz old.nabble.com/Java-EE-6-Web-Profile-td27715793.html ). Ale jest profil sieciowy GlassFish v3, będzie Resin ...
Pascal Thivent
2
aktualizacja: spójrz na projekt TomEE
gpilotino
-3

Poleciłem Wam Tomcata ze Springiem, ponieważ:

  1. Spring może tworzyć fasolki podkładowe dla JSP
  2. Sprężyna będzie używana do utrwalania obiektu przez JPA

Warto wybrać Tomcat, ponieważ nie potrzebujesz żadnego ciężkiego przetwarzania

bassem
źródło
1
„Przetwarzanie ciężkie”? Czy mógłbyś to rozwinąć? Jestem ciekawy.
Pascal Thivent