Stack Java EE 6 e Spring 3 [chiuso]


90

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?


8
Vorrei andare su primefaces.org invece di IceFaces se vuoi la luce. È molto più veloce e un'API più snella.
Shervin Asgari

1
Al momento ci sono solo Glassfish che forniscono JEE6. Resin sta implementando lentamente il profilo web JEE6 , che potrebbe essere sufficiente per te a seconda di ciò di cui hai bisogno.
Thorbjørn Ravn Andersen

3
@ Thorbjørn Puoi usare GlassFish v3 Web Profile se desideri solo il profilo web.
Pascal Thivent

@Pascal, era in dettaglio che presto ci sarà un'alternativa a Glassfish per ottenere JEE6 se puoi vivere con il profilo web (posso), per non dire che Glassfish non può.
Thorbjørn Ravn Andersen

@ Thorbjørn Ho dimenticato di rimuovere il @ Thorbjørn :) Il commento era destinato all'OP che sembra presumere che l'utilizzo del GFv3 "full-stack" sia l'unica opzione.
Pascal Thivent

Risposte:


101

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.


2
Sto solo cercando un grande progetto sviluppato con EJB3.0 + Seam su JBoss con Drools, GraniteDS e altri ancora. Sono d'accordo Seam rocks! Ma ho speso il 50% dello sviluppo su ridistribuzione, riavvio di server, errori di distribuzione, pulizia di directory temporanee ecc. D'altra parte le prestazioni di JBoss Tools erano davvero scarse (intendo davvero - ctrl + spazio e 10 secondi di blocco) Questo mi scoraggia davvero a usare JEE6 che sembra preso in prestito dal framework Seam. Per quanto riguarda il server non voglio pensare a conecion pool, jndi, jms, jmx, ear deplyment. Ho bisogno di qualcosa su cui mettere WAR e funzionare in pochi secondi.
Piotr Gwiazda

6
@peperg Gaving King è il responsabile delle specifiche di CDI (Weld è l'IR), quindi troverai somiglianze tra Seam e CDI. Ma CDI! = Seam, Java EE 6! = Seam, la tua percezione è sbagliata. Magari prova GlassFish v3 Web Profile, rimarrai sorpreso (e una volta definito il pool di connessioni, non c'è molto di cui preoccuparsi).
Pascal Thivent

8
Cosa c'è con le persone che dicono che gli EJB sono pesanti? Sto usando EJB v3.1 e sono semplicemente pojo annotati. Quando dicono pesante intendono in termini di prestazioni o cosa?
arg20

13
@ arg20 - Questa è davvero la grande domanda e Pascal chiede giustamente di spiegare cosa significa il termine "pesante" (o "leggero") in questo contesto. Molto probabilmente è un resto della vecchia faida tra Spring e EJB. All'inizio, EJB1 e 2 erano concettualmente pesanti. Un'enfasi eccessiva sul remoting e sui bean stateful, un descrittore di distribuzione XML ridicolmente dettagliato e una quantità assolutamente folle di interfacce richieste da implementare hanno dato loro una pessima reputazione. Con EJB3 (2006) questo è completamente cambiato, ma le persone che hanno lasciato EJB nel 2004 per la primavera a volte pensano ancora che sia il 2004 e EJB2 sia l'ultimo.
Arjan Tijms

7
Notare che nella pagina about di Spring c'è scritto "Crediamo che: J2EE dovrebbe essere più facile da usare". Nota che usano il termine "J2EE" e non "Java EE", che è stato il nome corretto sin dal rilascio di Java EE 5 (credo). Questo la dice lunga su di loro ...
Vítor E. Silva Souza

32

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).


1
Esatto, questo è un ottimo ragionamento.
Palesz

1
Sono d'accordo con questo ragionamento, molti problemi che ho dovuto affrontare sono stati le dipendenze dall'implementazione di una specifica da parte di un container. Significativamente meno dolore dalle librerie incorporate. Difficile da discutere, al di fuori della preferenza filosofica di una specifica.
Peter Porter

Ragionamento meraviglioso. Tuttavia è questa la tua esperienza anche dopo JEE 6? Capisco che le implementazioni delle specifiche di App Server possano ancora essere un problema, quindi le stesse specifiche implementate da App Server 1 potrebbero essere semplici ed efficienti mentre non per App Server 2
Soumya

1
+1. inoltre, il server delle applicazioni cambia in base alla pianificazione delle operazioni, dove la primavera / ibernazione è sotto il controllo degli sviluppatori. in un ambiente aziendale di grandi dimensioni l'aggiornamento del server delle applicazioni è un affare molto più grande.
Nathan Hughes

Non ho davvero capito il punto su Dot-Net. È tanto proprio quanto Spring ed è sviluppato da un unico fornitore che è Microsoft. Potrebbe essere spiegato per favore?
user1339260

23

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).


1
Quindi la domanda è: "Ha senso utilizzare Glassfish Application Server full-stack anche solo con il profilo web"?
Piotr Gwiazda

1
@peperg Usa il profilo Web GlassFish v3 se vuoi solo il profilo web, vedi la mia risposta.
Pascal Thivent

Ho postato alcuni argomenti qui stackoverflow.com/questions/2822812/spring-3-0-vs-j2ee-6-0/… , piuttosto presi dal punto di vista "come portarlo in produzione". Quindi forse questo riempie un po 'la tua riserva di argomenti.
Oliver Drotbohm

@peperq, JBoss 6 è stato rilasciato durante le vacanze.
Thorbjørn Ravn Andersen

17

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.


Java EE 6 è semplicemente dannatamente lento, il profilo web glassfish e glassfish è solo molto lento per iniziare a confrontarli con jetty / tomcat / qualunque cosa. Anche il test, il contenitore incorporabile è molto lento.
Palesz

15

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à)

21
Non vedo come la tua risposta sia collegata alla domanda ...
Pere Villega

1
-1 Sembra molto inappropriato accettare questa risposta, dal momento che non menziona nemmeno Java EE 6. Inoltre, non affronta nessuno dei punti sollevati nel ben ponderato (e molto più votato) di @Pascal Thievent risposta.
user359996

1
In realtà la domanda non è più valida. JEE 6 è ora molto maturo, non era nel marzo 2010 quando è stata posta la domanda.
Piotr Gwiazda

@PiotrGwiazda in che modo è cambiato JEE 6 da allora? La gente allora ne aveva più paura, ma fondamentalmente era lo stesso JEE 6.
ymajoros

1
Volevo dire che le implementazioni JEE6 sono più mature e disponibili. JBoss 7 è ora stabile e sono disponibili più implementazioni. Anche la comunità ora è più ampia. Altri strumenti e librerie ora supportano lo stack JEE 6.
Piotr Gwiazda

8

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 '


6
Siamo quasi esattamente un anno dopo e JBoss AS 6, che supporta Java EE 6, è attualmente utilizzato in produzione.
Arjan Tijms

8

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.


Si è scoperto che Java ServerFaces 2 in Java EE 6 poteva fare da solo ciò per cui avevamo bisogno di Tomahawk con JSF 1. È un framework abbastanza capace (ma un po 'XML pesante)
Thorbjørn Ravn Andersen

Ottimo punto, sfortunatamente le persone tendono a dimenticare che il software è fatto per vivere per decenni e che il supporto a lungo termine è una chiave cruciale.
timmz

6

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.


5

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.


4

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.


Non sono d'accordo con la tua prima frase, la scelta non riguarda l'utilizzo o meno di JMS. E non penso che JSR-330 sia così importante in Java EE 6 (è più presente per ragioni politiche), la parte importante è JSR-299 (CDI). Almeno, questa è la mia opinione.
Pascal Thivent

D'accordo che c'erano alcune politiche che coinvolgevano JSR330, tuttavia è abbastanza importante in quanto fornisce una base comune per l'iniezione di dipendenze in Java (SE o EE) piuttosto che rendere DI una tecnologia solo JEE. Inoltre, è supportato dal framework Spring e da Google Guice, il che significa che renderà il codice Spring / Guice facile da trasferire su JEE6 o viceversa. JSR299 è stato progettato anche per estendere le funzionalità di JSR330. Hai ragione in quanto per le applicazioni web in JEE6, JSR299 è assolutamente cruciale. Grazie a questi due JSR, JEE6 e Spring hanno entrambi un modello di programmazione molto simile. Grazie per il tuo commento!
Raz

3

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.


1
Grazie per il tuo commento. La mia scelta è stata Spring + Vaadin.
Piotr Gwiazda

3

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.


1
Mi piace la tua risposta. Molto ragionevole. Quando ho postato la domanda, JEE6 era molto giovane e Tomcat 7 non era ancora finito. "le ragioni originali che hanno motivato la primavera non sono più valide" - è vero, ma JEE6 con CDI ha bisogno di un po 'di tempo per adattarsi. Ad esempio: il monitoraggio Javamelody è disponibile per Spring e Guice (non riesco a immaginare di provare applicazioni senza di esso). EHcache è disponibile per Spring (intendo i risultati dei metodi di memorizzazione nella cache). Molte cose come la programmazione degli aspetti sono ancora più facili in Spring, perché molte librerie e framework di terze parti si integrano facilmente con Spring ma non ancora con JEE6.
Piotr Gwiazda

1

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.


1
Ho creato alcune applicazioni con Java + Flex e PHP + Flex e sono d'accordo che sia la soluzione migliore per interfacce ricche. Ma in questa applicazione non posso usare Flex :( Ho bisogno di un'interfaccia di alto livello, quindi Spring MVC non è una soluzione. Voglio pensare a una possibilità di datazione ordinabile che a <tr> <td> in un ciclo.
Piotr Gwiazda

1
@duffymo - Posso sostenere se il flex sia una buona scelta. JSF non è sicuramente morto, soprattutto con librerie come richfaces, primefaces, icefaces, ecc. In giro.
Bozho

1
In IceFaces creo menu, alberi, datagrid usano azioni, eventi e non penso se la pagina si ricarica o è una richiesta ajax. Un datagrid ordinabile o un albero caricato ajax è un componente integrato. In Spring MVC opero su HTML - tabelle, elenchi, ecc. Ho bisogno di utilizzare un framework javascript di terze parti e creare AJAX magic a mano. Mi piacerebbe farlo in Flex ma è una decisione politica / commerciale, non mia.
Piotr Gwiazda

1
I miei attuali due progetti JSF non sono definitivamente morti;) E sono molto più soddisfatto del modo in cui JSF costruisce RIA ("ricco" in "richfaces" è per questo), che usare Flex. Uno diventerà pubblico la prossima settimana.
Bozho

2
Mi piacerebbe davvero sapere perché preferiresti ancora la primavera, Java EE 6 è dannatamente buono. Non pensi che funzionare su una piattaforma aperta sia importante per il futuro di Java?
Pascal Thivent

0

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.


0

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).


Sì, puoi impacchettare EJB in una WAR in Java EE 6 ma questo non significa che puoi distribuire una tale WAR su Tomcat. È necessario un contenitore che implementa il profilo Web e Tomcat no e in realtà non esiste alcun piano nella comunità Tomcat per implementarlo (vedere old.nabble.com/Java-EE-6-Web-Profile-td27715793.html ). Ma c'è GlassFish v3 Web Profile, ci sarà Resin ...
Pascal Thivent

2
aggiornamento: dai un'occhiata al progetto TomEE
gpilotino

-3

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


1
"Lavorazione pesante"? Potresti elaborare? Sono curioso.
Pascal Thivent
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.