Newsgroup: it.comp.java
Titolo: Re: JBOSS 5.1.0 e JBOSS 4.2.3 e dubbi vari

 rimasta per imparare seam?"
parere personale: se vuoi lavorare con jsf si, altrimenti quel po' di 
ragione rimasta la perdi dietro a loro. però ad esempio io jsf le detesto 
di cuore e se posso le evito :-)
ps: sposto su it.comp.java

 ps: sposto su it.comp.java
(...cercavo te, apposta postai "dillà" :)..)
Se posso chiederti ancora qualche informazione, poi per il resto mi
arrangio con Google.
Con Netbeans utilizzo GlassFish, mentre con Eclipse (per ora) ho due
versioni di JBOSS (e questo mi ha fatto scontrare con i problemi
legati alle versioni della JDK, ultimamente ho installato due
versioni, la 1.6.0_03 che va bene con JBOSS 4.2.3 e la 1.6.0_19 che va
perfettamente con JBOSS 5.1.0... tutto molto interessante dal punto di
vista didattico).
Ho appena provato ad utilizzare WebSphere ma mi sono spaventato
parecchio (Application Server v.6.... questo avevo...) per via della
JDK proprietaria eccetera eccetera.
Domanda 1: credi che la conoscenza di due Application Server come
JBOSS (varie versioni) e GlassFish sia sufficiente per arrivare
all'agognato traguardo di "so fare qualcosa con JEE" o è necessario
conoscere (almeno un po') altri Application Server come WebLogic e
WebSphere, appunto? (o altri di cui ignoro l'esistenza)
Domanda 2: hai visto l'ultima release JBOSS 6.0.0? Vale la pena
corrergli dietro, o JBOSS 5.1.0 basta e avanza e, per ora, ci si può
fermare a questa versione?
Domanda 3. XDoclet è qualcosa di vetusto ed è caduto in disuso? Mi ci
stavo avventurabdo, ma mi ha spaventato leggere che l'ultimo
aggiornamento è del 2005!!!
Ciao!!!

 Domanda 3. XDoclet è qualcosa di vetusto ed è caduto in disuso?
Si'. Aveva guadagnato popolarita' perche' aiutava a districarsi nel
orrida bolgia delle prime versioni di EJB ma adesso per fortuna non
serve piu'.

 della propria libreria interna al progetto)
E non ti sei chiesto se non ci sia una ragione per quei thread chilometrici?
Se le versioni delle librerie fornite dall'AS non sono quelle che 
servono alla tua applicazione, che fai? (ad esempio sono troppo vecchie)
La soluzione è di solito proprio quella di sostituire le librerie 
dell'AS con quelle della tua applicazione (sperando che non facciano 
casino).
...in generale è il classloader si JBoss che fa schifo.
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org

 serve piu'.
Grazie!
:)
Domanda: da dove mi conviene scaricare Maven? PErchè ho utilizzato il
seguente:
http://m2eclipse.sonatype.org/sites/m2e
e fatto quello che dovevo da Help --> install new software
ma ad un certo punto mi ha chiesto "se fossi sicuro di voler
continuare con l'installazione, perchè non si era sicuri della
provenienza"
Ho cancellato!
Dovevo continuare o esiste un sito sicuro da far lavorare con l'update
di Eclipse Galileo?
Ciao!

 ...in generale il classloader si JBoss che fa schifo.
Ok, adesso ho capito dove far l'aggiornamento delle .jar (se va storto
qualcosa poi rimetto a posto). Il problema è proprio quello che dici;
"versione delle librerie"
Ciao
Domanda che faccio anche a te:
Questo sito funziona per fare l'upload di Maven su Eclipse dal tool
che è in Help --> Install New Software, però dopo mi compare un
messaggio di quelli che fanno paura, tipo "se continui è a tuo rischio
e pericolo, perchè non si capisce da dove arriva questo software!"
Io ho cancellato l'installazione. Dovevo continuare?
C'è un sito preferito per installare il modulo su Ecliopse senza
troppi problemi?
Ciao!
http://m2eclipse.sonatype.org/sites/m2e

 servono alla tua applicazione, che fai? (ad esempio sono troppo vecchie)
si ma lui a quanto leggo sta facendo i tutorial :-)
e comunque la giudico una extrema ratio: *tendenzialmente* preferisco 
che sia l'applicativo ad adattarsi all'application server e non 
viceversa, sia perché potrebbe non essere solo in quella istanza (e 
generalmente non lo č, come minimo ci sono i servizi di jboss) sia 
perché in produzione potresti non poter intervenire a quel livello. io 
ad esempio ho dei clienti che hanno la 4.3.0 supportata a pagamento da 
redhat e, giustamente, le librerie comuni non si toccano.

 troppi problemi?
Mi spiace, non uso Eclipse, mi fa schifo, specialmente l'integrazione 
con Maven. Molto meglio NetBeans per me.
Ciao
   Lucio


 redhat e, giustamente, le librerie comuni non si toccano.
Ovvio, se ci sono vincoli simili, e il cliente me lo ha detto per tempo...
In generale una applicazione Java scritta seguendo gli standard non 
dovrebbe avere grossi problemi ad essere deployata su un qualunque 
application server decente...peccato che JBoss non lo sia.
Fra parentesi, visto che c'è hai il supporto di redhat, loro come 
risolverebbero il problema di un'applicazione (magari acquistata a caro 
prezzo da terze parti) che usa librerie più recenti delle loro? 
Ovviamente non modificando l'applicazione, dato che essa segue tutti gli 
standard che loro dicono di supportare.


 standard che loro dicono di supportare.
se fa riferimento esplicito a implementazioni vuol dire che lo standard 
così tanto non lo segue. lo standard è jpa, non hibernate. se trovi un 
bug nell'implementazione del jpa allora magari sì interviene il supporto 
con la patch, ma se vuoi una specifica versione di hibernate diversa da 
quella "certificata" è chiaro che non te la supportano. anche perché 
l'ultima versione di hibernate implementa uno standard persistence 
diverso da quello che è su quella versione di jboss.

 aggiornamento è del 2005!!!
sicuramente vetusto, era un surrogato delle attuali annotation. non mi 
risulta che nessuna tecnologia ancora lo utilizzi.

 troppi problemi?
scarica eclipse da qui, dopo essertelo configurato a piacimento:
http://eclipsesource.com/en/yoxos/yoxos-ondemand/

 diverso da quello che è su quella versione di jboss.
Sarà supportata in JBoss6, che attualmente è in mileston1.
-- 
Il CGI secondo Radicale: una specie di linguaggio per fare query su 
siti,internet.

 aderenza agli standard non si è distinta, recentemente, per stabilità.
Ho usato di recente JBoss 5.x. A parte problemi fastidiosi di lentezza 
esorbitante in deploy e startup, e bug con il redeploy piuttosto 
ridicoli, non ho riscontrato inadempienze allo standard Jee5. Almeno per 
quanto riguarda EJB3, JPA, JSF, JAX-WS.
Che problemi hai avuto?

 diverso da quello che č su quella versione di jboss.
Appunto...se lo standard č JPA, come mai JBoss ingloba una specifica 
versione di Hibernate, e costringe le applicazioni ad usare quella?
A parte JPA comunque io mi riferivo allo standard delle applicazioni Web 
Java: io dovrei poter prendere un qualunque WAR e farne il deploy senza 
problemi. Con JBoss invece questo raramente avviene.


 Che problemi hai avuto?
no, problemi assolutamente no. mi riferivo a come hanno gestito il 
passaggio al jee5, con il ritardo notevole di uscita di jboss 5 (che 
doveva essere la versione ufficialmente conforme) che ha costretto alla 
versione "intermedia" 4.2.x e addirittura alla patch sulla 4.0.5 per 
supportare gli ejb3. ma mi viene in mente anche jms con la diatriba 
jbossmq vs jboss messaging che anche quella doveva essere risolta con la 
5 ma che hanno costretto gli utenti della 4.2.x ad avventurosi 
aggiornamenti (perché jbossmq era veramente inusabile se non per qualche 
balocco).

 problemi. Con JBoss invece questo raramente avviene.
mah guarda... di migrazioni verso jboss ne ho fatte diverse e la 
procedura era costituita sostanzialmente da due passi:
- togliere il lo4j (sennò oggettivamente il logging fa del casino)
- aggiungere il deployment descriptor jboss-web.xml, che però non è 
manco obbligatorio
per il resto problemi non ne ho avuti.

 problemi. Con JBoss invece questo raramente avviene.
Io ho fatto una migrazione recente da JBoss a Glassfish. I WAR 
praticamente non ho dovuto toccarli. L'EAR è un'altra storia :)

 doveva essere la versione ufficialmente conforme)
Hai ragione, e per di pi� se ne sono usciti con un pachiderma di cui non 
se ne sentiva bisogno. Ad esempio  mi � andato in crisi l'ambiente per 
la continuous integration, perch� il pachiderma dopo 3 deploy mi va in 
permgen space (si tratta di EAR grossi). Prima mica era cos�.
Hanno fatto una enfasi pazzesca sulla nuova architettura modulare di 
JBoss5, ma io di benefici mica ne ho visti, anzi.

 Tanto vale usare Tomcat a quel punto. Che specifiche implementa la minimal?
mi pare che addirittura faccia partire solo il microkernel, manco il 
catalina.

 catalina.
Allora forse intendeva il profilo web, che comunque mi pare essere un 
semplice servlet container o poco pi�.



Grazie Rootkit, cerco di capire come funziona e me lo scarico.
Su Eclipse Galileo comunque sono riuscito a scaricarlo: se vado su un
progetto nella finestra a sinistra "Project Explorer", vedo l'iconcina
rossa m2 e la scritta Maven, da cui compare "Enable Dependancy
Management". Ora devo cercare un buon Tutorial!
:)
Ciao!


Il tuo approccio, Rootkit, è quello (a mio modesto parere), più
logico. Il "Server Container" non andrebbe toccato: sapendo a PRIORI
che la propria applicazione andrà ad essere installata su QUEL tipo di
server, è necessario premunirsi prima.
E' per questo che non mi convinceva l'idea di manipolare le classi
dell'application server, a meno che il server sia quello di casa
nostra, o all'interno della nostra azienda.
Infatti mi chiedevo: "quante volte capita, durante il proprio lavoro,
di dover "CONSEGNARE IL FILE WAR O JAR A TERZE PARTI"... come dicono
quelli che scrivono bene, nei libri :) ???
Credo che sia il "top" riuscire a manipolare i propri file di
deployment per far adattare l'applicazione a qualsiasi contesto.
...magari sto dicendo un sacco di fesserie, ma è la conclusione a cui
sono arrivato è questa (sbagliata? Boh!) :)
Luca

 praticamente non ho dovuto toccarli. L'EAR è un'altra storia :)
Le "migrazioni"... una cosa che mi fa tanta tanta paura! Sarà che sono
rimasto scioccato dal passaggio JBOSS 4.2.3 a JBOSS 5.1.0
:)
Luca

 risulta che nessuna tecnologia ancora lo utilizzi.
Meno male! Una cosa in meno nel mare JEE
:)
Luca
Una curiosità: ha senso utilizzare EJB e relegare la persistenza ad
Hibernate? Ho visto qualche esempio e tutoriala riguardo (che poi,
alla fine, sono quelli che creano più problemi...)



 alla fine, sono quelli che creano pi� problemi...)
Si e' la stessa cosa, metti le regole in xml anziche' in annotations.
Lo vedo meglio per un porting pero' che per un progetto nuovo poiche' ejb3
entity sono comodissimi
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 entity sono comodissimi
Ciao n.n!
Quindi, se io, ad esempio, conoscessi "perfettamente" tecnologia Ejb3
(ovviamente sottindendo la conoscenza anche di jsp, Servlet e qualche
libreria particolare, tipo jstl) potrei dire che questa è
"alternativa" alla conoscenza di Hibernate e Spring (o Struts)? Oppure
è più corretto dire: "in funzione del progetto JEE e della sua
complessità, conviene l'una oppure l'altra"?
Voglio dire: sono conoscenze alternative o, comunque, un vero esperto
deve conoscerle tutte?
Mi è sembrato di capire (e forse non ci ho capito una mazza) che i
framework Struts e/o Spring ti "guidano" nella realizzazione dei
progetti, mentre Hibernate ti aiuta nella gestione della persistenza e
Ejb3, conoscendolo a menadito, ti permette di essere autonomo da tutte
le cose sopracitate (gestione della persistenza compresa)?
Ho detto minchiate? :) Ciao!
Luca
(dico queste fesserie perché, leggendo qualche libro su Ejb3, negli
esempi svolti ho notato che non si sente la mancanza di
Hibernate...spero di non aver "notato male"!)

 rimasto scioccato dal passaggio JBOSS 4.2.3 a JBOSS 5.1.0
Paura non direi, richiedono qualche giorno di smanettamenti. Io poi ho 
una mia tecnica per i casi complicati: si parte con un EAR semplice che 
non centra nulla con l'applicazione di cui devi fare il porting, testi 
un po' di tecnologia che ti serve (JAX-WS, EJB, JPA eccetera), poi 
comincia a portare dentro le classi e i file di configurazione. Un po' 
alla volta arrivi.
Se cerchi invece di fare tutto in blocco, allora si che sono problemi.

 complessità, conviene l'una oppure l'altra"?
Sostanzialmente quello che puoi fare in EJB lo puoi fare anche con 
Spring. Spring è dichiaratamente concorrente, sebbene integri comunque 
alcuni standard del mondo EJB (ad esempio JPA).
Io personalmente preferisco aderire ad uno standard (quindi scelgo lo 
standard JEE), perché uno standard offre discreti vantaggi (e qualche 
svantaggio).
Altri preferiscono la snellezza e la flessibilità di Spring, dove però 
devi arrangiarti nel configurare e distribuire le librerie a cui si 
integra (all'opposto del mondo EE, dove spesso sono già presenti nel 
Application Server di riferimento).

 Hibernate...spero di non aver "notato male"!)
Ejb3 Entity e hibernate sono piu' o meno la stessa cosa quindi non so se dirti
se hai capito male o bene.
In pratica ejb3 puo' sostituire in apparenza hibernate ma di fatto stai usando
hibernate ( JPA ).
Per spiegarmi e non essere troppo vago ti dico come vanno le cose :
Tu studi gli EJB3 e gli EJB3 entity sui libri Sun , poi quando lavori coi db con
gli EJB3Entity comunque finirai a studiare sui libri Hibernate per
HQL, Lazy strategy, Join Startegy, Relazioni e altro
Ciao
Nicola 
-- 
Nicola


Grazie infinite cicap!
:)
Luca


Grazie davvero!
:)

 alone
Bene :)

Grazie delle informazioni preziosissime: sei stato estremamente chiaro
e completo!
Ciao Nicola!
:)
Luca Paolucci