Newsgroup: it.comp.java
Titolo: Struts 2 o Spring?

Salve a tutti
ho finalmente la possibiltà di sganciarmi dal vecchio Struts 1 (non che non
mi piacesse , però gli mancano delle cose)
A cosa mi consigliate di passare per fare webapp?
Il nome + famoso che sento attualmente è Spring (con SringMVC + Hibernate)
però Struts già un po lo conosco (anche se ho visto che il 2 cambia molto)
Voi cosa consigliate?
Mi sono letto "Spring in action" e "Hibernate in action" e devo dire che mi
hanno un po spaventato (sopratutto il primo; hibernate invece mi sa che è
bene impararselo in ogni caso)
Vorrei sapere a questo punto (oltre la vostra semplice preferenza), con cosa
sviluppate, ovvero:
- che IDE? (Eclipse, Netbeans, JBuilder....)
- ci sono plugin aggiuntivi (o tool extra in generale) ma cmq free che
usate? (tipo Spring IDE... qualcuno lo usa? a che serve?) Quali sono questi
plugin?
- per la presentazione cosa usate? (ho provato a guardare anche JSF ma non
mi è molto chiaro) Usate JSP, template su Velocity (vorrei conoscerne uno lo
usa...), JSF... ??
Insomma vi sto chiedendo come mettere in piedi un completo (e moderno)
ambiente di sviluppo (nel senso più ampio)
per sviluppare applicazione web (di medie/grandi dimensioni)
ciao e grazie

 - che IDE? (Eclipse, Netbeans, JBuilder....)
Eclipse + WTP e nessun plugin. Anzi per le JSP preferisco JEdit o
Notepad++ (su Win) oppure Kate (su Linux).
Per la presentazione utilizzo JSP, ultimamente ho scoperto SiteMesh
per i template: molto molto buono :) lo consiglio a tutti
Ciao, Dimitri
P.S.
Sul mio blog sto cominciando a postare roba su Spring, se vuoi dagli
un'occhiata:
http://blog.megadix.it/2007/09/20/spring-mvc-riflessioni-e-qualche-trucco/
oppure
http://tinyurl.com/yvocsy
--
www.megadix.it

 per sviluppare applicazione web (di medie/grandi dimensioni)
?????????
Perche' spring ?
Usa JBoss Seam che e' 10 mila anni avanti
ciao
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Usa JBoss Seam che e' 10 mila anni avanti
emh... ma io non voglio viaggiare nel tempo  ;-)
a parte gli scherzi... cosa c'ha di bello Seam per essere cosě avanti
(l'avevo sentito nominare solo raramente)
ciao


Cosi' lo spingi in un baratro.
Perche' non aggiungi che gli serve un EJB3 container, e perche' non aggiungi 
che e' molto meglio se usa JBoss, altrimenti con Seam non si sa dove si va a 
finire?
Perche' non aggiungi che deve consocere a menadito JPA, Hibernate, EJB3, 
JSF, Facelets per poterlo padroneggiare?
Ti sembra che sono cose che conosce? A me no, visto che sembra, ad esempio, 
non aver compreso neppure cosa sia JSF. 


Ciao, sarei interessato anch'io a Seam.
Che cos'ha in più (ed eventualmente in meno) Seam rispetto a Spring?
Grazie,
D. 


Innanzitutto non conosco Spring.
Seam in piu' di Spring certamente ha il fatto che e' JEE5 mentre Spring e'
J2EE cioe' usa il java vecchio.
Dovrebbe bastare.
Per quanto riguarda il "terrorismo" di cicap, che saluto gentilmente,
l'unica cosa che e' limitante e' che oggi gira solo sotto JBOSS.
Perche' gli altri appserver stanno ancora adeguandosi a JEE5. Questo puo'
essere un motivo li limitazione oggi, che sparira'.
Comuqneu non sono manco esclusivi, infatti e' possibile integrare Seam e
spring, feature che e' stata introdotta piu' per compatibilita' col passato
e per evitare guerre di religione con i vecchi springisti.
Certo iniziare oggi un progetto con spring non mi pare una grande idea.
Poiche' dalla domanda del mittente si deduce che la persona in questione sta
iniziando un progetto nuovo e pare intenzionato acneh a stuidiare nuovi
framwork e non ha vincoli non vedo perche' non usare la tecnologia piu'
nuova e avanzata, senza contare che una volta padroneggiata semplifica
moltissimo la programmaziione e le applicazioni , a differenza di J2EE e
tutti i framwork che per anni ci hanno incasinato la vita con pattern
rigidissimi e sovraingegnerizzati.
se volete informazioni piu' dettaglioate fatemi domande piu' specifiche o
date un occhio al forum di JBoss Seam
ciao a tutti



Te l'ho chiesto proprio perchč dopo una pessima esperienza con jsf e con 
Hibernate (che IMHO sono troppo sovraingegnerizzati, soprattutto Hibernate) 
ora mi trovo benissimo con Spring, jsp e iBatis.
L'unica critica che posso muovere a Spring č forse nella parte MVC che č 
perfetta per applicazioni web classiche, ma un po' poco integrata con i 
framework Ajax piů recenti (sarebbe fantastica amio avviso un'integrazione 
con GWT).
Per il resto sono contento di spring, ho il pieno controllo 
dell'applicazione senza troppi strati difficili da controllare (Hibernate) e 
pesanti (JSF) e con l'autowiring e le annotation la configurazione xml non č 
piů un problema.
D. 

 non aver compreso neppure cosa sia JSF.
Be' non e' mica da meyttere in galera se non conosce JSF :-))
io nn le conoscevo fino a un anno fa e proprio perche' le ho trovate in seam
ho iniziato ad usarle studiarle e apprezzarle
ciauz a tutti


 D.


 Vorrei sottolineare che non volevo aprire una guerra seam spring.
Tranquillo, nemmeno io, solo che usando Spring e trovandomi bene mi chiedevo 
che cosa gudagnerei usando Seam.
Per quanto riguarda Hibernate ovviamene sono solo punti di vista. A mio 
avviso è uno strato troppo pesante sul DB e soprattutto richiede una grossa 
conoscenza del framework stesso prima di usarlo. Per il tipo di applicazioni 
che sviluppo in azienda va più che bene iBatis dove ho il controllo diretto 
dell'SQL.
Ciao,
D. 


A me di Seam interessa spratutto lo scope di conversazione, pero' al momento 
non sento l'esigenza di tutto il resto.
Per fortuna MyFaces sta sviluppando Orchestra che dovrebbe fornire questa 
feature assieme ad un entitymanger gestito nello stesso scope, offrendo lo 
stesso benificio di Seam.
Poi Seam ha molto altro per carita'.
Comunque dimostra anche che le sfuriate di King Gavin contro Spring erano 
completamete fuori luogo: a sentir lui sembra che la lazy loading exception 
era tutta colpa del modello di programmazione proposto da Spring. Invece 
ecco che basta un framework di collegamento tra JSF e Spring (come Seam lo 
e' tra EJB e JSF) e il problema e' risolto. 

 Certo iniziare oggi un progetto con spring non mi pare una grande idea.
Ragazzi, Spring non sta facendo e non fara' la fine di Struts .
Spring 2 e' assolutamente moderno e all'avanguardia.
Gli EJB hanno recuperato terreno con la versione 3, ma non e' affatto chiaro 
quale delle 2 tecnologie sia la migliore.
Tu invece vuoi far sembrare che EJB3 sia nettamente migliore, che so come 
JSF lo e' di Struts. Non e' cosi'. 

 l'enetity manager attaccato ai bean di convresation.
Ecco, un'alta cosa di cui sento la mancanza in Spring è proprio lo scope 
conversation.
D. 

 JSF lo e' di Struts. Non e' cosi'.
Sono d'accordo. Con gli EJB2 era tutto più "burocratico", mentre con
gli EJB3 è tutto "magico": in ambito *enterprise* secondo me spesso è
meglio essere *sicuri* di una cosa anche se è pallosa, piuttosto che
passare le nottate a capire cosa caspita e magari non sono stati
configurati correttamente, che so, i pointcut AOP, qualche annotazione
o chissà quale altra "magia"...
--
www.megadix.it

intanto ringrazio tutti per la bella discussione che è scaturita...
poi mi interesserebbe anche sapere le vostre "configurazioni di sviluppo"
(vedi le domande "che IDE" e successive)
grazie mille a tutti


 
www.megadix.it
ciao Dimitri


 riguarda il mittente che se capisco bene parte da 0.
Tu queste cose le pensi, ma non si sa perche' e in base a quali 
informazioni.
Non sono insomma minimamente motivate. 

 Non sono insomma minimamente motivate.
Ma si stai tranquillo, e' chiaro che in un compare ognuno avra' simpatir
diverse Pero' il compare lo devi tenere obiettivo
Dimitri ha motivato bene le motivazione che possono portare alla scelta di
un framwork piu' vecchio e non JEE5 semplicemente dicendo che per molte cose
JEE5 ed EJB3 non gli garbano perche' sono troppo di alto livello e quindi
invasivi.
E' innegabile pero' che Spring e' un framwork JEE2 o addirittura quasi java
standard e Seam un framwork JEE5 completo qindi la scelta non e' tanto per
il nome dell'autore ma su che tipo di Specifiche Java si vogliono
utilizzare.
ciao Nicola


 ha  
scritto:


 utilizzare.
mah, mi pare di leggere un bel po' di confusione. e onestamente quando 
scrivi che spring è un framework j2ee dire che fai confusione è un 
eufemismo :) a parte che uso spring anche su applicazioni swing-based e 
pare la morte sua, ma il punto è un'altro: la forza di spring è che 
introduce l'inversion of control insieme alla dependency injection 
(scusate se ripeto ciò che ha già scritto corrado, ma è importante) e 
ciò implica alcuni aspetti importanti:
- sviluppi esclusivamente pojo
- quando scrivi il programma spring *non* lo vedi nemmeno
- le dipendenze sono tutte dichiarative
se ci ragioni sopra questo è il nirvana della programmazione ad oggetti 
per come è concepita in java.
il confronto con ejb poi lo capisco fino ad un certo punto. ma se ci si 
limita al contesto comune, quello in cui ejb e spring si sovrappongono, 
è decisamente spring ad essere avanti anni luce.

 uno lo usa...), JSF... ??
JSP.
Ciao
  Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it

 e come vuoi, come logica, come dati, come record, come tutto.
Hanno gia' detto Corrado e rootkit con molta piu' chiarezza di quanto potrei 
fare io.
Aggiungo solo che quella che tu vedi come grande novita' da programmaotore 
EJB, e' presente in Spring da sempre. I bean di Spring sono sempre stati dei 
normali POJO sui quali il framework ci inietta le dipendenze e non solo, in 
maniera ultra trasparente e soprattutto testabile.
Per fare un unit integration test con il database con Spring non ho bisogno 
di chissa' quali framework, come tu invece hai bisogno con EJB.
Altra nota: Seam utilizza i session bean per fare tutto: fungono da logica e 
da managed-bean volendo.
Ma questa non e' affatto una pecularieta' EJB, infatti questo progetto 
raggiunge la stessa identica cosa con Spring:
http://myfaces.apache.org/orchestra/index.html
 

 è decisamente spring ad essere avanti anni luce.
Non capisco perche' vi incazzate con me e mi dite che ho confusione se dico
che Spring non e' EJB e quindi non e' un framwork full JEE5.
Poi tutti e 3 andate a speigarmi che Spring non usa EJB perche' usa dei pojo
avanzati, confermando tutti e 3 che quello che dico e' verissimo.
Allora facciamo ordine e semplifichiamo all'osso :
A )
Vuoi un framwork full JEE5, che utilizza in modo massivo gli EJB3 e quindi
gli EJB sotto jndi, con le loro annnotation, con gli enity 3 ceh sono
hibernate embedded, che crea applicazioni per Application Server con EJB
COntainer ( oggi in pratica solo JBOSS ) e quindi con tutti i i
vantaggi/svantaggi dell'utilizzo degli stessi ?
Che inoltre utilizza sul fron end JSF che e' oggi inegrato direttamente
nella libreria Java ufficiale SUn ?
B)
Vuoi un framwork che non utilizza EJB, che utilizza invece oggetti pojo
propri ottimamente pensati e realizzati ma pure sempre semplici oggetti java
standard ?
Sul front-end offre un MVC proprietario
La risposta e'
A) = seam
B) = Spring
Spreo ora siano contenti tutti e il primo che ricomincia a dire che ho
confusione solo perche' dico che A=A e che l'acqua e' bagnata rischia anche
che gli rispondo male.
Stimao confrontando 2 framwork per 2 specifiche java diverse, con uno che e'
stato scritto incontemporanea alla stesura JEE5 con King che lavorava
contemporaneamente in Sun e in JBOSS e che produce applicazioni per EJB
COntainer che utilizzano ovunque EJB3 sotto jndi e che utilizzano il
formalismo delle amnnotations
L'altro e' un framwork pensato e realizzato molto prima dell'avvento del
JEE5 attuale e produce applicazioni Standard.
Se poi uno non vuole imbarcarsi su JSF EJB3 EJB enity con dentro hibernate
eccetera mi sta benissimo e puo' usare spring, o Struts 2, o Tapesty, o
quello che vuole , ma se desidera imbarcarsi su queste tecnologie
sostanzialmente e' OBBLIGATO a usare seam visto che e' l'UNICO framwork a
oggi che le integra,
In pratica io dico che uso Seam perche' e' l'unico JEE5 ch eintegra gli EJB3
in modo completo e voi mi rispondete che dico cazzate perche' Spring fa le
stesse cose senza usare EJB 3 e mi sviolinate la bellezza di sti pojo DI che
NON SONO EJB
Io dico esattamente come stanno le cose. Se a voi non piace il JEE5
dell'ultima versione e in particolare hibernate/jsf/EJB3 benissimo , fate
benissimo a usare spring.
Ma sostanzialemtne stiamo parlando quasi di 2 linguaggi diversi che girano
addirittura in container diversi.
Scusate ma siete voi che avete confusione :-)


 Nicola
Peace&Love
Corrado

 Scusate ma siete voi che avete confusione :-)
Ma se parli male di Spring da 2 giorni, e tu stesso hai ammesso che non ci 
ha neppure dato un'occhiata..secondo te chi puo' fare confuzione? 


La confusione la avra' chi legge fra un po' :-)
Il post di Corrado qua sopra dice che in Spting normalmente si lavora senza
EJB, pur usando tante altre feature di JEE5 e alla fine pioano piano la
confusione sta sparendo
Ora tu vai in giro a consigliare spirng per integrare gli EJB 3, e credo sia
una pessima proposta.
Io non ho mai parlato male di spring, che come detto non conosco.
Semplicemtne ho detto che chi vuole salire sull'ultimo treno del JEE5 e in
particolare sull'uso pesante di EJB3 non lo farei visto che spring e' stato
scritto prima che uscissero
buon lavoro a tutti
peace and love lol



Il tuo unico cavallo di battaglia e' questo, ma non ha alcun senso: Spring 2 
e' uscito dopo EJB 3.
Ora non si capisce perche' EJB1, EJB2 non debbano contare (sono molto 
antecedenti a spring 1).
Quindi semmai l'ultimo treno e Spring 2.
Questo ovviamente seguendo il tuo insensato ragionamento. 

 Scusate ma siete voi che avete confusione :-)
permettimi di dubitare, non tanto che io sia o meno in confusione (per 
carità ci può anche stare) ma che non lo sia tu più di noialtri.
argomenti sciorinando termini e tecnologie con un flusso quasi casuale, 
ti lasci andare a diverse imprecisioni e ti riscaldi pure senza motivo.
questo, sia chiaro, è ciò che ho constatato in questi due messaggi e non 
è certo un giudizio sulla persona.

 è una domanda seria, mi piacerebbe saperlo davvero.
Provo a spiegare meglio la mia visione su Sullo stato dell'arte di Java.
COsi' magari si chiarisce meglio Seam e poi ognuno fara' tutti i confronti e
le riflessioni che vuole.
Partiamo un po' da lontano.
Un lontano giorno , intorno agli anni 2000, forse anche un po' prima venne
splittato il linguaggio hava in JSE e JEE. Nel JEE, che comprende anche SE
comparvero i famigerati odiati dibattuti e anche derisi ( soprattutto da i
non javisti ) EJB
Gli EJB sono classi piu' complesse di una classe pura. Si inseriscono nel
Jndi raggiungibili via Corba, via RMI, via JNDI. Per funzionare non basta
piu' una VM classica ma ci vuole un container particolare che supporta
appunto tutte le tecnologie citate. E che poi potra' favorire il balancing
il fault tolerance, oltre a integrare i servizi.
COntemporaneamente la SUn vuole offrire con gli EJB entity un framowork di
persistenza dati.
Gli EJB 1 sono un massacro. Gli Entity 1 sono infelici. Tutto l'ambaradam
per usare i session risulta iper macchinoso. I Session sono logica pura
quindi parte della logica sta nella servlet , parte nei session, poi i
session chiameranno gli entity.
La comunnity inzia a non usarli e in breve si ritorna alle servlet.
La Sun ci riprova e pensa che i Session sono abbastanza validi, soprattutto
per la transaction, e scarica tutte le colpe sugli entity
Esce quindi con entity 2, che di fatto sono tali e quali agli 1 e finiscono
piu' meno al dimenticatoio
Intanto si era affermato e diffuso struts sul front-end. Che pero' pur
essendo di buona visione non e' particolarmente felice per la programmazione
che e' un sostanzialmente poco semplice e leggibile.
A questo punto , e dovremmo essere intorno al 2003, finalmente escono 3
grossi framework che faranno storia. Hibernate , Spring, JSF.
Spring vuole dare un ambiente completo per sviluppare web applicazioni e
integra fra l'altro hibernate e da un MVC proprietario per il front end ( e
qua puntualizzate se c'e' da puntualizzare )
JSF vuole portare i "component" cioe' classi e logica nelle pagine
direttamente e quindi offre un front-end molto migliore di struts, pur
mantenendo la logica MVC
hibernate e' finalmente un framwork di persistenza valido, che inoltre
riesce nel semi miracolo di trasformare un db relazionale e farlo vedere a
oggetti al programma.
QUesti 3 framework finalmente soddisfano chi li usa e si diffondono nella
comunity :-)
Che fa mamma Sun nel frattempo ? Decide che non c'e' 2 senza 3 e vuole
tentare ancora col JEE. Non vuole abbandonare l'idea originale degli EJB e
inizia a scrivere gli ejb 3.
Per gli entity, visto il successo di hibernate decide che anziche' farne un
concorrente la cosa migliore e chiamare il suo creatore e inglobarlo negli
entity nuovo. E cosi' e' stato fatto
Poi attribuisce molte sfortune dei precedenti ejb alle menate portate dal
JNDI e cosi' cerca di semplificarlo all'osso fino al punto che un ejb 3 si
invoca oggi nel 99% dei casi direttamente dal suo nome, pur essendo sotto
jndi
Decide inoltre di introdurre le annotation, che stravolgono parecchio la
programmazione alzando il livello applicativo non di poco, scatenando spesso
le ire dei nerd ceh vogliono il controllo totale.
E ad esempio passa la validation sotto annotation e anceh le acl mi pare (
devo studiarmele appena ho tempo )
Poi fa una campagna di comunicazione, prende il J2EE, decide di chiamarlo
JEE5 ci mette dentro sti EJB3 che gireranno comuqnue sotto EJB container, e
poi ci mette dentro le JSF direttamente nella libreria java.
A questo punto King decide di fare un framwork che congiunga ( to seam se
non erro e seam = giuntura mi pare) le JSF con gli EJB3. DI fatto uno puo'
ovviamente chiamare gli EJB 3 da una jsf anche senza seam.
Pero' decidono in JBOSS di sscrivere un framework che amalgami un po' il
tutto in modo armonioso.
Inoltre King ha la "fissa" che programmare solo con request e' session e'
una rottura di palle. SI continua a scrivere codice "bollito alla piastra" (
cit. ) eccetera. Del resto lui e' il profeta della persistenza, quello che
persistentizza anche la figa :-) e quindi decide che nelle web application
bisogna dare lustro ai bean stateful. Srive quindi un context ( o
environment ) manager a 3 livelli ( saranno poi di + ma logicamente saono 3
) : request, session, conversation
dentro questi scope ci mette direttamente gli ejb3, che saranno fruibili sia
1. da jsf direttamente,
2. tramite bi-injection potranno rintracciarsi l'un l'altro ( tramite aop mi
pare ma e' trasparente )
3. nel lifecicle di Jsf sono rintracciabili di nuovo e quindi volendo
ragionare anche in modalita' MVC nel model e nel view vai a ritrovarti
sempre sti ejb3
La bi-injection ora non so dirvi se e' farrina del sacco suo, se e' aggiunta
da seam o c'e' anche in EJB3 standard, e se voi mi dite che in spring
esistevano da prima gia' i "pojo di" probabilmente e' stata scopiazzata
proprio da la
QUindi per chiarire come funzia un po' il tutto , alla fine in una pagina
jsf possiamo "attaccare" direttamente un ejb3 entity, che corrisponde in
tutto e per tutto a un pojo hibernate, attaccarlo in pratica agli input
html. Poi usiamo liberamente gli ejb stateful mandando a puttane mvc,
pattern vari e ogni rigidita'
Il risultato e' sorprendente perche' si destruttura ogni vecchio tier, tutti
quei layer di separazione dati,logica, presentation, validation, tutto.
Diventa un "minestrone". All'inizio facevo fatica e quasi iniziavo a pensare
che fosse uno schifo peggio di visual basic. Mi permisi di porre i miei
dubbi a King stesso, lui rispose che destrutturando di fatto a nessuno era
vietato di crearsi i suoi layer come una volta. Ma che semplicemente era a
scelta del programmatore, ed era consentito fare i "ribelli" diciamo. Anzi
esagero' e disse a me e altri che un po' eravamo tutti della stessa scuola,
ci disse di smetterla di ragionare sovreaingegnerizzati, di "smollarci" di
pensare ai problemi dei nostri clienti e non ai problemi del nostro
programma. insomma sul forum, sui libri, alle interviste continua a dire
cose del genere, un po' probabilmente per mania di dare spettacolo, e un po'
perche' e' andato in fissa con sti concetti.
Per chiudere una nota sugli altri servizi offerti da Seam , dal Remoting (
per ajax spinto ), a a4jsf ( ajax bello) a jbpm ( per processi ), aop (non
so bene dove lo usano a parte per gestire gli stati pagina ad esempio ),
esportazione su portlet , che mi sembrano ottimi ........... , ma immagino
che acneh gli altri framwork li abbiano , chi piu' chi meno, o li
metteranno.
La vera grande differenza con tutto quello che ho visto prima sta proprio
nel nuovo modo di programmare, nel uso totale di ejb3, nel ritrovarmi
hibernate "embedded" e direttamente configurabile via annotation anziche
xml.
Spero di avere spiegato qualcosina in piu' di Seam, visto che in effetti
fino a ora avevo sciorinato solo qualche slogan, probabilmente comprensibile
da uno che conosce Seam stesso, ma magari non comprensibile da uno che non
lo conosce.
Finirei l'infelice guerriglia spring-seam, che non porta anulla. Ognuno
utilizzera' quello che piu' gli piace, se puo' scegliere lui o quello che
gli viene imposto dal capo/cliente/decisore di turno :-)
Ciao a tutti e buon aperitivo che e' pure venerdi.


 lo conosce.
mah, non vorrei apparire presuntuoso ma sono abbastanza convinto che le 
argomentazioni su java e jboss mi siano perfettamente comprensibili. 
così come sono in grado di comprendere che a domanda puntuale l'hai 
presa laaaaaarga sperando non mi accorgessi che non hai risposto :P

 n.n ha scritto:
--
mi risulta (correggimi se sbaglio) che jboss fornisca hibernate come
servizio pubblicato su jndi. al che mi sorge spontanea la domanda:
perchč seam sarebbe l'unico framework che lo integra con ejb e cosa ci
sarebbe di cosě speciale in questa integrazione, dato che per qualsiasi
servizio di jboss č necessario e sufficiente accedere al jndi?
č una domanda seria, mi piacerebbe saperlo davvero.
--
come ho scritto nel lungo post, hibernate e' finito dentro gli ejb 3 enity.
Dentro significa che quando li utilizzi viene utilizzato il motore ( le
classi ) di hibernate.
Non ho mai affermato che seam e' l'unico framework che integra hibernate ed
ejb3, se lo ho fatto e' stato un malinteso.
CHiunque usa ejb3 entity , e li collega al db tramite le annotation si
trovera' a usare hibernate di fatto anche se non lo ha mai sentito nominare.
La tua domanda perde di significato nel momento che usi ejb3. Perche' se e
mai adeguerrano tutti gli Application Server alle specifiche JEE5 in
qualsiasi container ejb verra' utilizzato hibernate perche' fa parte delle
specifiche del container.
Se pigli un vecchio JBOSS col container vecchio. E utilizzi hibernate da ejb
vecchi hai un risultato molto simile. se e quello che ti interessa, ma non
capisco se vuole essere un invito a non passare a ejb3 entity perche' si
puo' fare con ejb vecchi + hibernate mi pare un dibattito un pochino
curioso.
E' avvenuto un "Upgrade" della tecnologia ejb complessivo e fra qualche
anno, salvo imprevisti, nessuno usera' piu' ejb vecchi se non per
compatibilita' passata.
Io ho detto e ripeto che lo scopo finale di seam e' di integrare jsf e ejb3.
SI puo' integrarli anche senza seam ovviamente. Se si vuole utilizzare un
framwork piu' o meno completo anziche fare tutto a mano ecco seam
Questo e' quanto, e ho fatto la storiella per fare capire perche' integrarli
e perche' si puo' scegliere queste tecnologie per basarci l'applicazione.
Insomma se uno vuole un front-end nelle jsf e la logica e i dati negli ejb3.
Seam e' nato per quello, a mio avviso e' l'unico ( se non e' l'unico dico il
migliore ) nato e progettato alla nascita per quello. Ovvio che se vuoi ti
chiamo un ejb3 pure da struts, o da una applet, oppure uso le jsf senza ejb3
o uso spring che offe un front end propietario e altri strumenti per logica.


 e perche' si puo' scegliere queste tecnologie per basarci l'applicazione.
Si ma credo che tu non stia spiegando cosa c'e' che non va nell'usare nel 
tradizionale utilizzo di EJB3 da un normale managed-bean. E soprattutto cosa 
offre in piu' Seam in questo contesto. 

 cosa offre in piu' Seam in questo contesto.
Mi sono incaartato ;)
volevo dire:
Si ma credo che tu non stia spiegando cosa c'e' che non va nel
tradizionale utilizzo di EJB3 all'interno di un normale managed-bean. E 


 offre in piu' Seam in questo contesto.
Ciao,
Un architetto valuta tutte le tecnologie e sceglie quelle che ritiene
migliori e piu' potenti enll'ambito dei propri obiettivi, in questo caso
l'obiettivo e' fare una web application
IO ho accennato un po' di feature di Seam. Se vuoi saperne di piu' ti
rimando ai testi ufficiali, agli articoli dei forum e blog specialistici. Al
Forum stesso di Seam. Di sicuro non le impari da me, visto anche che pare ne
sai molto di piu' ;-)
Fra l'altro non ho capito cosa suggerisci tu per fare web application, visto
che hai tutta questa chiarezza e visto che il thread e' molto mirato e
chiede consigli su un framework che sostituisca struts
Ciao e buon lavoro


 Fra l'altro non ho capito cosa suggerisci tu per fare web application
Guarda che io non sono affatto contro Seam, che assieme a te (ma tu 
sicuramente con piu' cognizione di causa perche' lo utilizzi) considero il 
piu' potente framework in circolazione.
Il punto e' che questo non significa che Spring e' superato o che Spring sia 
il treno sbagliato: il team di Seam ha scelto EJB3 per ragioni sue (forse 
anche di JBoss che sembra antagonista a Spring, Gavin soprattutto), ma un 
framework altrettanto potente potrebbe essere costruito al di sopra di 
Spring. Vedremo in futuro...c'e' gia' questo Orchestra di MyFaces che sembra 
promettente.