Mi chiedevo se qualcuno ha esperienza con l'implementazione JPA2.0 di uno di questi framework? Soprattutto insieme a Spring3.x che viene fornito con il supporto di EclipseLink.Hibernate o EclipseLink per JPA?
Utilizzate uno di questi framework e JPA2.0 per la produzione? Qualche problema grave?
IMHO È sempre preferibile utilizzare una API standard ove possibile. Il tuo esempio lo dimostra perfettamente. Sei riuscito a provare il tuo codice identico su due provider quando uno non ha funzionato come previsto. Passare a qualsiasi API nativa ti impedisce di farlo.
Se si utilizza EclipseLink come il proprio provider JPA 2.0 funziona correttamente, quindi utilizzarlo. Se ti capita di imbatterti in un problema, presenta un bug di EclipseLink e ottieni aiuto su questo forum, sui forum e sui newsgroup di EclipseLink.
EclipseLink è più conforme agli standard, poiché è l'implementazione di riferimento per JPA 2, Hibernate presenta alcuni problemi di conformità, ma è più maturo.
Uno dei principali vantaggi di EclipseLink è che è possibile chiamare le funzioni native SQL direttamente nelle query JPQL. In Hibernate questo non è direttamente possibile.
Ma Hibernate ha una community più ampia, una documentazione migliore e anche messaggi di errore migliori.
Dalla mia esperienza, con Perf Profiling Java. Le mie app create con Eclipselink sembrano funzionare molto meglio che con Ibernazione sia in Inserimento dati che in recupero. Hibernate tuttavia è più ampiamente utilizzato e fornisce un forum più grande per il supporto.
In produzione, prenderò semplicemente Hibernate per questo motivo.
Basta prendere e attaccare con uno. Gli standard sono solo nelle linee guida finali e ogni implementatore può implementare o non riuscire a implementare gli standard di conseguenza.
ad es.
EclipseLink ha problemi con qualcosa di base come ad esempio JPA @Converter s anche se apparentemente di recente fissato tramite IBM http://www-01.ibm.com/support/docview.wss?uid=swg1PI73277
implementazione JPQL di Hibernate non capisce valori booleani che si distinguono per conto proprio più specificamente ho dovuto cambiare la mia JPQL dire
from Participant p where not p.cancelled
a
0.123.from Participant p where p.cancelled = false
L'altra cosa è che si sta costruendo le cose in primavera e si sta probabilmente andando a fare l'approccio improprio ma comune di cambiare il caricatore di classe a PARENT_LAST ordine in modo che le classi sono utilizzate piuttosto che il server delle applicazioni.
Se si prevede di fare il modo corretto e utilizzare il JPA fornito con il server delle applicazioni, fare attenzione a quanto l'implementazione del server delle applicazioni potrebbe essere problematica.
Per quanto riguarda la tua applicazione, in particolare Spring deve gestire le cose per te.
Non sono d'accordo. Essere il RI non ti rende più compliant e ho affrontato problemi con entrambe le implementazioni anche se dovrebbero essere compatibili con JPA 2.0, vedi [questa domanda per esempio] (http://stackoverflow.com/questions/3014313/jpa -2-criteri-api-perché-è-isnull-essere-ignorato, quando-in-congiunzione-con-uguale). Il TCK non è esaustivo. –
@ pascal-thivent, l'implementazione JPQL di EclipseLink è in effetti più conforme agli standard di quella di Hibernate. Ed essendo il RI ti mette in una sorta di posizione di riferimento. –
Poiché ho riscontrato problemi di conformità con entrambi, il mio riferimento è la specifica, ho imparato che non posso usare EclipseLink come "riferimento". –