Newsgroup: it.comp.java
Titolo: EJB3

 - www: 
http://csvtosql.sf.net
"E' una delle superstizioni dello spirito umano aver immaginato che la
verginita' potesse essere una virtu'." -- Voltaire, "Le sottisier"

 ha scritto nel messaggio 
news:eal3c1$ac3$3...@newsreader.mailgate.org...


 - www: 
http://csvtosql.sf.net
Prima Legge di Jay sul Comando: Cambiare le cose e' l'essenza del comando;
cambiarle prima di chiunque altro e' creativita'.

 webapp ma nada ...
Io, invece, ho dannato non poco con l'injection dei reference...
Scorpio.

 - www: 
http://csvtosql.sf.net
"Rosebud!" -- Orson Welles, da "Quarto potere"

 ha scritto nel messaggio 
news:eao1r9$giu$1...@newsreader.mailgate.org...

Credo sia dovuto ad un problema relativo a come il container risolve 
l'injection del persistence manager....
io ho avuto un po' di noie con i session bean....


 - www: 
http://csvtosql.sf.net
Mar, l'e' fioo d'una baltroca: o piof, o tira vent, o fioca. -- Antico
proverbio della Brianza

 ai session perň ci dovresti accedere con jndi .. giusto ?
Certo, JNDI č supportato e funziona perfettamente, ma ho preferito 
giocherellare con la injection.....
E non č stato cosě semplice: in pratica, ho dovuto specificare qualche campo 
nelle annotations relative
agli ejb perchč la lookup "automatica" andasse a buon fine.
Peraltro, posso farti una domanda "architetturale" ?
Ciao,
    Scorpio. 

 - www: 
http://csvtosql.sf.net
L'uomo e' nato per soffrire, e ci riesce benissimo. -- Roberto Gervaso

 se sono in grado di risponderti ... spara :)
Secondo me, sì :-)
Dunque, senza volerti tediare troppo: al lavoro, stiamo sviluppando una
soluzione gestionale basata su Java. A dire il vero, il requisito principale
era che fosse Web-based, ma dal momento che non mi andava di limitare un
progetto di reingegnerizzazione ad una questione di interfacce, ho con un
po' di fatica convinto i capi della convenienza di utilizzare EJB. In
primis, perchè sono lo standard J2EE per architetture distribuite, ma,
soprattutto, perchè l'idea di base era utilizzare tanti EJB stateless come
servizi riusabili in diversi progetti. Il tutto funziona, perchè nei
"progetti secondari" abbiamo potuto tranquillamente riusare i servizi EJB,
come peraltro dovrebbe essere prassi normale.
Tuttavia, qualche dubbio è emerso circa la distribuzione degli stessi EJB.
Poichè l'appserver che utilizziamo non consente di deployare moduli ejb o
web stand-alone, ma richiede espressamente che i moduli EJB siano contenuti
in un EAR, anzichè duplicare gli EJB nei vari EAR, abbiamo creato un unico
EAR contenente gli EJB, a cui gli altri progetti (a loro volta EAR)
accedono. Ribadisco che il sistema funziona, e ci consente di applicare
aggiornamenti ad un unico progetto EJB, anzichè updatare tutti i progetti
dipendenti da questi. Però, sembra che la prassi migliore sia realizzare
degli EAR autocontenuti, ossia con tutti gli EJB e classi di utilità al loro
interno. A me questa prassi non sembra tanto coerente con l'idea EJB =
componente distribuito.... vorrei avere un tuo parere in merito.
Grazie,
    Scorpio.

 - www: 
http://csvtosql.sf.net
"Doppo ch'Adamo comincio' co Eva tutte le donne se so' fatte fotte'." --
Belli, "Chi risica rosica" dai "Sonetti"


WebSphere 5.0
In procinto di passare alla versione 7.0 (o qualunque numero di versione 
abbia, purche sia full J2EE5 compliant).