Stack Java EE 6 e Spring 3 [chiuso]

Sto iniziando un nuovo progetto adesso. Devo scegliere le tecnologie. Ho bisogno di qualcosa di leggero, quindi niente EJB o Seam. D'altra parte ho bisogno di JPA (Hibernate o alternativa) e JSF con IceFaces.

Pensi che un simile stack su Spring 3 distribuito su Tomcat sia una buona scelta? O un'applicazione web Java EE 6 potrebbe essere migliore? Temo che Java EE 6 sia una nuova tecnologia, non ancora ben documentata. Tomcat sembra essere più facile da mantenere rispetto a Glassfish 3.

Qual'è la tua opinione? Hai qualche esperienza?

Ho bisogno di qualcosa di leggero, quindi niente EJB o Seam.

Vorresti spiegare cosa rende pesanti gli EJB da EJB3? Ti rendi conto che non siamo più nel 2004? Mi piacerebbe molto leggere la tua definizione di luce e le tue argomentazioni (e aggiornerò la mia risposta con piacere perché sono abbastanza sicuro che avrei alcune cose concrete da dire).

D'altra parte ho bisogno di JPA (Hibernate o alternativa) e JSF con IceFaces.

Java EE 6 Web Profile che include JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... sarebbe perfetto per questo ed è possibile utilizzare GlassFish v3 Web Profile per eseguire un'applicazione creata con Java EE 6 Web Profile .

Pensi che tale stack su Spring 3 distribuito su Tomcat sia una buona scelta? O un'applicazione web Java EE 6 potrebbe essere migliore?

Bene, mi piace l'idea di eseguire il mio codice su una piattaforma non proprietaria (Java EE) piuttosto che su un contenitore proprietario (Spring). E penso che Java EE 6 sia abbastanza buono (e questo è un eufemismo, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Nota che ero uno scettico JSF ma ho dato una seconda occhiata e JSF 2.0 con CDI è così diverso che non posso nemmeno confrontare. E se non hai guardato CDI, lascia che ti dica che è fantastico.

Temo che Java EE 6 sia una nuova tecnologia, non ancora ben documentata.

Java EE mi sembra abbastanza ben documentato. Sembra una rivendicazione gratuita. E, mi creda o no, io inizio a trovare primavera farsi complicata mentre Java EE sempre più facile.

Tomcat sembra essere più facile da mantenere rispetto a Glassfish 3.

Hai provato qualcosa? Hai affrontato qualche problema particolare? Ancora una volta, questo suona come un reclamo gratuito.

Non ho usato JavaEE6.

Tuttavia, sono stato picchiato abbastanza gravemente da tutte le versioni precedenti di JavaEE e EJB che non mi fiderò di esso finché non si affermerà come standard de facto, non solo come standard de jure. In questo momento, la primavera è ancora lo standard de facto.

Ingannami una volta, vergogna per te. Ingannami due volte, vergognami. Ingannami tre volte, EJB.

Alcuni affermeranno che la primavera è proprietaria. Direi che le implementazioni del fornitore delle specifiche JavaEE sono state altrettanto proprietarie, se non di più.

Recentemente sono passato attraverso un'importante conversione di spostare un gruppo di applicazioni Java da JBoss a Weblogic. Tutte le app Spring / Hibernate sono state portate senza modifiche, perché avevano tutte le librerie di cui avevano bisogno integrate. Tutte le app che utilizzavano JPA, EJB e JSF sono state un disastro da portare. Sottili differenze nelle interpretazioni di JPA, EJB e JSF tra i server delle app hanno causato tutti i tipi di bug fastidiosi che hanno richiesto un'eternità per essere risolti. Anche qualcosa di semplice come la denominazione JNDI era completamente diverso tra gli AppServer.

La primavera è un'implementazione. JavaEE è una specifica. Questa è una differenza enorme. Preferirei usare una specifica SE la specifica fosse a tenuta d'aria al 100% e non lasciasse assolutamente alcun margine di manovra nel modo in cui i fornitori implementano quella specifica. Ma la specifica JavaEE non è mai stata quella. Forse JavaEE6 è più a tenuta d'aria? Non lo so. Più pacchetti puoi inserire nel tuo WAR e meno dipendi dalle librerie di AppServer, più la tua applicazione sarà portabile, e questo, dopotutto, è il motivo per cui uso Java e non Dot-NET.

Anche SE le specifiche fossero a tenuta stagna, sarebbe bello poter aggiornare il server app senza dover aggiornare tutti i miei stack tecnologici in tutte le mie applicazioni insieme ad esso. Se desidero eseguire l'aggiornamento da JBoss 4.2 a JBoss 7.0, devo considerare l'impatto della versione più recente di JSF su tutte le mie applicazioni. Non devo considerare l'impatto sulle mie applicazioni Spring-MVC (o Struts).

Non importa. Java EE 6 è abbastanza buono e, a causa dei profili presenti, non è "pesante": utilizzerai solo il profilo web.

Personalmente preferisco la primavera. Ma sto esaurendo gli argomenti razionali contro Java EE 6 :)

(Come mi è stato ricordato da un commento, potresti provare RichFaces , ICEfaces e / o PrimeFaces , a seconda dei componenti di cui hai bisogno).

Recentemente, uno dei miei incarichi di cliente ha coinvolto la valutazione di Spring Stack Vs Custom framework stack Vs a Java EE Standards. Dopo un mese di valutazione e prototipazione, non ero solo felice, ma anche sbalordito dal set di funzionalità di Java EE 6. Per qualsiasi nuova architettura di progetto "aziendale" nel 2011 e in futuro, sceglierei Java EE 6 e potenziali estensioni come Seam 3 o il prossimo progetto di estensioni Apache JSR299. L'architettura Java EE 6 è semplificata e incorpora il meglio di molte idee open source che si sono evolute negli ultimi anni.

Considera le seguenti funzionalità fuori dagli schemi: gestione eventi, contesti e DI, intercettatori, decoratori, servizi web RESTful, test integrati con contenitore incorporabile, sicurezza e molti altri.

La maggior parte dei miei risultati sono pubblicati nel mio blog che spiegano i concetti chiave di Java EE 6 che potresti trovare utili.

Naturalmente, non esiste una regola rigida e veloce per la scelta di un framework. Java EE 6 potrebbe essere gonfio per "siti Web" più semplici che non richiedono un ricco stato di sessione di conversazione. Potresti anche scegliere Grails o Play! Struttura. Ma per le applicazioni web conversazionali, non riesco a vedere un argomento migliore per cui Java EE 6 non è adatto.

Ora, dopo un po 'di tempo, ho esperienza con gli stack:

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

Le mie collezioni sono:

• Spring 3 è molto più semplice di Seam (quasi Java EE 6) e gira su Tomcat e Jetty! (Il molo per lo sviluppo con il plugin Maven è un tesoro).
• Adoro Flex (in realtà sono stato uno sviluppatore Flex per molto tempo, quindi sono di parte) e se hai bisogno di un'interfaccia ricca e puoi acquistare FlashBuilder, usa questo, ma usa questo backend Spring + GraniteDS o BlazeDs. Se non puoi acquistare FlashBuilder, non perdere tempo.
• Vaadin è fantastico !. Il processo di sviluppo è più semplice di Flex, ma puoi creare facilmente applicazioni ricche senza confusione HTML. Non scriverai una sola riga JS. Hai solo bisogno di un po 'di CSS (in Flex ne hai bisogno anche tu). Quindi, se l'interfaccia della tua applicazione si comporta come un'applicazione desktop e non puoi (o non vuoi) usare Flex, usa Vaadin. Avvertimento! Vaadin ha un grande overhead JS per il browser.
• Se crei un'applicazione simile a un sito web più semplice, usa JSF2.0 (con il backend a molla come sopra). Dovrai combattere con l'HTML (lo odio) e creare un'interfaccia ricca sarà più difficile di Vaadin (specialmente i layout). Otterrai HTML leggero per browser / computer più lenti. Mi piace PrimeFaces: è facile e ben documentato. Il secondo posto è IceFaces
• Se crei un sito Web (NON un'applicazione web) in cui devi dare vita all'HTML (invece di creare un'applicazione aziendale che si adatta al browser) usa Wicket (se preferisci basato su componenti, attitudine pull) o SpringMVC (se preferisci basato su modello , spingere l'atteggiamento) o semplicemente usare Play! struttura. Ricorda che creare componenti ricchi di dati sarà molto più difficile ma avrai il controllo su ogni tag di html (il tuo designer HTML / grafico lo adorerà)

Leggi il Future Of Enterprise Java di Adam Bien ... Is Clear (Java EE con / senza Spring e Vice Versa) , inclusi i commenti per ottenere entrambe le facce della medaglia. Sceglierò la Primavera per diversi motivi e di seguito uno di questi (riproducendo uno dei commenti del post)

'Non sono sicuro di quale server Java EE 6 stai parlando. C'è Glassfish certificato e TMAX JEUS. Ci vorrà un po 'di tempo (leggi: anni) prima che le versioni compatibili con Java EE 6 di WebSphere, WebLogic, JBoss ecc. Siano in produzione e possano essere utilizzate per applicazioni reali. Spring 3 necessita solo di Java 1.5 e J2EE 1.4, quindi può essere facilmente utilizzato in quasi tutti gli ambienti '

La mia opinione si basa su qualcosa non menzionato da altri, vale a dire che il codice al mio lavoro tende a vivere per decenni (letteralmente), e quindi che la manutenzione è molto importante per noi. Manutenzione del nostro codice e delle librerie che utilizziamo. Il nostro codice controlliamo, ma è nel nostro interesse che le librerie che utilizziamo siano mantenute da altri nei decenni sopra menzionati o più.

Per farla breve, ho concluso che il modo migliore per raggiungere questo obiettivo è utilizzare le implementazioni open source delle specifiche Sun fino alla JVM grezza.

Delle implementazioni open source Apache Jakarta ha dimostrato di mantenere le proprie librerie e recentemente Sun ha svolto molto lavoro nella produzione di implementazioni di alta qualità per Glassfish v3. In ogni caso, abbiamo anche il sorgente per tutti i moduli, quindi se tutto il resto fallisce, possiamo mantenerli noi stessi.

Le specifiche Sun sono generalmente molto rigide, il che significa che le implementazioni conformi alle specifiche possono essere facilmente scambiate. Dai un'occhiata ai contenitori servlet.

In questo caso particolare, suggerirei di dare un'occhiata a JavaServer Faces semplicemente perché fa parte di Java EE 6, il che significa che sarà disponibile e mantenuto per un tempo molto, molto lungo. Quindi abbiamo scelto di aumentare con MyFaces Tomahawk in quanto fornisce alcune utili aggiunte, ed è un progetto jakarta.

Non c'è niente di sbagliato in JBoss Seam o altri. È solo che la loro attenzione è meno concentrata sul problema della manutenzione che è così importante per noi.

Posso vedere l'utilizzo di Spring se lo hai già, ma per il nuovo progetto, qual è il punto? Vorrei andare direttamente con Java EE 6 (ejb3, jsf2.0, ecc.)

Se il cliente sta bene con Flex, fallo. Usa BlazeDS o simili - no mvc. Potresti dedicare più tempo a quella parte (scambio di dati tra server e client) ma hai il pieno controllo su entrambi i lati.

Non usare Vaadin, a meno che tu non voglia uccidere il tuo browser. Inoltre, trascorri più tempo per aggirare il codice una volta che le tue pagine diventano più complesse. Inoltre, la tua mentalità dovrà essere completamente cambiata e tutto ciò che sai sullo sviluppo del front-end standard sarà uno spreco. L'argomento secondo cui non devi usare HTML o JS non ha molto senso. Devi ancora saperlo anche se non lo usi. Alla fine esegue il rendering in HTML e JS. Quindi prova a eseguire il debug: assicurati di avere pochi giorni per cose semplici. Inoltre, non riesco a immaginare uno sviluppatore web che non conosca html / js.

Non capisco perché le persone provino tutte quelle astrazioni invece di usare direttamente Java EE.

Perché ci sono ancora voci sul fatto che EJB sia dei pesi massimi nel 2010? Sembra che le persone non vengano aggiornate nelle tecnologie Java EE. Provalo, sarai piacevolmente sorpreso di come le cose siano semplificate in Java EE 6.

La risposta alle tue domande dipende dai requisiti del tuo progetto. Se non hai bisogno delle funzionalità Java EE come code di messaggi, transazioni globali gestite dal contenitore, ecc., Allora vai con tomcat + spring.

Inoltre, dall'esperienza ho scoperto che i progetti che richiedono molta integrazione di servizi Web, pianificazione e code di messaggi vengono eseguiti al meglio utilizzando alcuni stack Java EE. La cosa buona è che usando la primavera puoi ancora integrare con i moduli Java EE in esecuzione in un server delle applicazioni.

Java EE 6 è molto diverso dalle versioni precedenti e rende davvero tutto molto più semplice. Java EE 6 combina le migliori idee della variegata comunità Java - ad esempio Rod Johnson del framework Spring è stato attivamente coinvolto nella realizzazione del JSR Dependency Injection in Java EE 6. Un vantaggio dell'utilizzo di Java EE 6 è che stai codificando secondo uno standard, che potrebbe essere importante in alcune organizzazioni per il supporto dei fornitori, ecc.

GlassFish v3 supporta Java EE 6 ed è abbastanza leggero e si avvia molto velocemente. Ho usato glassfish v3 per i miei sviluppi ed è davvero facile da configurare. Viene fornito con una console di amministrazione molto intuitiva che ti consente di amministrare graficamente il tuo server.

Se stai utilizzando Glassfish V3 e JSF 2, puoi sfruttare le funzionalità CDI di Java EE 6, che ti consentono di creare facilmente conversazioni (ad esempio pagine simili a procedure guidate) in JSF.

Detto questo, l'utilizzo di Java EE 6 richiede anche l'apprendimento di una nuova API. A seconda del periodo di tempo disponibile, potrebbe non essere la scelta migliore per te. Tomcat è in circolazione da anni e la combinazione tomcat + spring è stata adottata da molti progetti web, il che significa che c'è molta documentazione / forum in giro.

Ho lavorato sia in Spring che in Java EE 6. Quello che posso dire dalla mia esperienza è che se stai optando per il vecchio JSP o Flex proprietario, allora sei al sicuro se rimani con Spring.

Ma se vuoi andare avanti con JSF, allora è il momento di passare a Java EE 6. Con Java EE 6 stai passando a Facelets e alle librerie di script standardizzate e alle librerie dei componenti. Niente più incompatibilità di script e matrici di librerie di componenti.

Per quanto riguarda Spring MVC, va bene finché il tuo progetto non diventa troppo grande. Se si tratta di un'enorme applicazione aziendale, attenersi a Java EE 6. Perché è l'unico modo per mantenere le proprie librerie di componenti e bundle di risorse in modo ordinato.

Se hai bisogno dello stack completo di Java EE ti consiglio GlassFish 3.1. Si avvia molto rapidamente rispetto ad altri contenitori Java EE che implementano parte o tutto Java EE 6 (JBoss 6, WebLogic 10.3.4), la ridistribuzione richiede pochi secondi e quasi tutto può essere fatto per convenzione sulla configurazione, è molto amichevole.

Se vuoi qualcosa di "leggero" puoi personalizzare un Apache Tomcat 7.x con le caratteristiche desiderate. Ho usato molto con le seguenti librerie: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - solo transazioni locali di risorse JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Sono stato uno sviluppatore Java EE negli ultimi 10 anni (soffro delle prime tecnologie EJB, JSF e web), Java EE 6 è molto semplice, ben accoppiato e l'hardware attuale funziona senza intoppi, quindi le ragioni originali che motivano la primavera non sono più valide.

Preferirei comunque la primavera.

E trasmetterei JSF. Penso che sia una tecnologia morta. Spring MVC sarebbe un'alternativa migliore. Così sarebbe Flex. Pensa in termini di contratto prima dei servizi XML e puoi scollegare completamente il back-end dall'interfaccia utente.

Consiglierei Spring + Tomcat a meno che non si possa aspettare il tempo che glassfish v3 e Weld diventino più maturi. Attualmente ci sono alcuni problemi con il consumo di memoria / carico della CPU durante l'esecuzione di glassfish con applicazioni abilitate CDI.

Non ho letto tutto ma solo per dirti che ora puoi usare EJB3 all'interno di una guerra su Java EE 6 in modo da poter usare EJB3 su Tomcat (credo).

Ti ho consigliato Tomcat con Spring perché:

1. La primavera può creare fagioli di sostegno per JSP
2. Utilizzerai Spring per rendere persistente l'oggetto tramite JPA

È una buona scelta scegliere Tomcat perché non è necessaria alcuna elaborazione pesante