Java Maven & AngularJs

L'ho letto un po' velocemente, ma forse c'è la possibilità di integrare un po' più strettamente il ciclo di sviluppo di applicazioni AngularJs con JavaEE.
Qui i dettagli

Come migrare da Weblogic o Websphere a Tomcat

Questo articolo è interessante, più che per i tips di migrazione, per il confronto tra i vari Application Server ( e perché ho scoperto OpenEJB non si finisce mai di imparare)

Hibernate e la cache di secondo livello

Hibernate ha la possibilità di configurare una cluster cache. Questo sia per le singole classi che per le collection di dati (class-by-class basis or collection-by-collection basis). E' anche possibile configurare una cache clutered. E' evidente che questo meccanismo da alcuni vantaggi, ma anche alcuni svantaggi.


Vantaggi

• Il database non sarà gravato da continue richieste, perchè molte di queste verranno già risolte a livello di cache.
• Il workload per rappresentare un dato tabulare come oggetto si riduce.
• La cache, che di solito è in memoria, è molto più veloce nel reperire i dati che non l'accesso al database.
• La cache può essere clusterizzata, aumentando la scalabilità ed affidabilità del sistema.

Svantaggi

• I dati, se possono essere variati anche da altre applicazioni, potrebbero non essere sempre aggiornati: è quindi necessario configurare adeguate policies di refresh dei dati.

Per questo tipo si caching, dette cache di secondo livello, Hibernate si affida a librerie esterne, che possono essere pluggate.

Per fare questo è sufficiente fare 2 operazioni.

1. Nella configurazione di hibernate (hibernate.hbm.xml) basta settare la proprietà hibernate.cache.provider_class
2. Per ogni classe di cui si vuole fare caching si deve aggiungere il tag al file di mapping (o l'equivalente annotation sulla classe, ma io preferisco lavorare con i files di mapping) oppure, a livello di configurazione hibernate (hibernate.hbm.xml) specificare gli elementi e

Hibernate supporta alcuni cache providers, da una semplice Hashtable, creata per ragioni di test (e assolutamente da NON usare in produzione) a EHCache che supporta la replicazione e il clustering, a a JBossCache 2 che supporta anche la Query Cache.

Da mettere in evidenza che Hibernate, fino alla versione 3.0, veniva impacchettato con EHCache di default, e su questa Cache enterò più in dettaglio in futuro.

Da Spring a JavaEE: una guida alla migrazione

http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/

Mule rilascia la milestone 3 di Mule 3

Mule ha rilasciato la milestone 3 della nuova release Mule.

Appena posso vedo di convertire un progettino che già è fatto con Mule 2 e vedo come si comporta.

Spring 3 e lo Unit Testing

Ho fatto qualche piccolo passo nello Unit Testing di Spring3
L'ho fatto con JUnit4, in modo da poter sfruttare le annotations.
Uno potrebbe dire: JUnit ha i "classici" eventi di SetUp e TearDown, si usano quelli per istanziare Spring e poi si fanno i test normalmente.
Non è una cattiva idea, peccato che i due eventi vengono lanciati prima e dopo ogni test, quindi per fare 5 test si istanzia e distrugge 5 volte il framework Spring.
E allora come si fa?
Si usa l'annotation @RunWith di JUnit4. Questa annotation permette di invocare, invece del runner standard, il runner specificato. Spring4, nel pacchetto di test, ha il runner SpringJUnit4ClassRunner, quindi l'annotation diventa

@RunWith(SpringJUnit4ClassRunner.class)

OK, e ora come si fa a caricare la configurazione?
Semplice, sempre con l'annotation, questa volta specifica del package Spring Test, @ContextConfiguration
Questa annotation permette di specificare, sia con path relativo che assoluto, quali files usare per i test.
A questo punto basta scrivere i nostri test e, prima che vengano lanciati, verrà lanciato il framework spring con la configurazione specificata.

Context and Dependency Injection in JavaEE

Perchè Java va bene per lo sviluppo on line "di base"

L'autore,
che è italiano e vive a Firenze come me, mi perdonerà questa traduzione all'impronta del titolo del suo post.
Mi piace il suo punto di vista: è vero, si possono anche fare le cose molto complicate in Java, ma si può anche iniziare in maniera molto semplice. Poi a complicar le cose c'è sempre tempo, come per aggiungere Unit Testing e quant'altro. E poi la cosa + importante: Java è VERAMENTE una V.M. multipiattaforma, stabile ed affidabile, e questo fa ben la differenza...

Spring 3 e i Web Services

Leggendo la documentazione di Spring 3 si dichiara che Spring supporta 2+1 modi di esporre i Web Services:

• via JAX-RPC
• via JAX-WS
• via Spring Web Services

Ora, io escludo Spring Web Services perchè ha un approccio "Contract-First" alla creazione del webService: cioè prima si crea il wsdl e poi lo si implementa con le classi. Questo è un metodo splendido perchè molto flessibile, ma anche un po' lento nell'implementazione.
Rimangono quindi le altre due strade e fra le due scelgo volentieri quella JAX-WS, una specifica più recente di JAX-RPC, che permette di esporre come Web Services dei semplici POJO.

Per esporli al mondo esterno basta creare una Web Application ed esporre come servlet il POJO.

Vediamo quindi come è la classe che rappresente il Web Service.

@WebService(serviceName="TestService")
public class TestServiceEndpoint {
   
    @WebMethod
    public String sayHello() {
        return "Hello";
    }
}

Questa classe è un banalissimo POJO con 2 annotation una che dichiara che è un webservice, dal nome "TestService" e l'altra che dice che il metodo sayHello è un WebMethod. Ovviamente queste 2 annotations hanno molti altri parametri che permettono una configurazione minuziosa di tutto il Webservice, ma per l'esempio a noi va bene così.

Esponiamo ora il WebService al mondo. Basta creare una WebApplication e nel web.xml, dichiarare il POJO come servlet.

Questo basta per avere un bel WebService. Deploiando ad esempio su JBoss (purtroppo ci vuole un container j2EE per deploiare, ma ormai sono all'ordine del giorno) il gioco è fatto.

Bene, e fin qui abbiamo usato solo J2EE, neanche una traccia di Spring.
Come possiamo fare ad integrare Spring con JAX-WS?

Basta far si che il nostro POJO (o la nostra servlet, se così vogliamo pensarla) estenda SpringBeanAutowiringSupport. Facendo così si può accedere ai bean gestiti da Spring. L'unica limitazione è che queste due "parti" (il POJO e lo Spring context) devono girare nella stessa webApplication.

La classe diventa quindi


@WebService(serviceName="TestService")
public class TestServiceEndpoint extends SpringBeanAutowiringSupport {

   @Autowired
   private HelloService biz;

    @WebMethod
    public String sayHello() {
        return biz.sayHello();
    }
}



L'interfaccia HelloService viene, grazie all'annotation @Autowired, gestita da Spring: questo è il punto di unione tra le due tecnologie.


Per far funzionare il tutto dobbiamo fare una modifica anche al web.xml, aggiungendo la gestione dello SpringContext.


Quindi in fondo al web.xml si aggiunge

Per la parte Spring, basta creare l'xml ApplicationContext.xml (anche qui, si usano i default per velocità)

Qui si dice appunto che la classe che implementa helloService (notare la consonanza di nome tra l'interfaccia e l'id del bean, è uno dei modi in cui Spring ricerca i bean per il metodo @Autowired) è it.ws.test.HelloServiceImpl, che ovviamente implementerà l'interfaccia HelloService.


Tutto qua, nulla di più. Facile vero?

Mule iBeans

Mule ha appena rilasciato iBeans, che sta per Integration Beans.
E' un nuovo framework di integrazione che permette alle webapps Java esistenti di interagire con altre webapps e servizi.

Ovviamente non vuole essere un rimpiazzo per MuleEsb, ma un semplice mezzo per il routing dei messaggi, e magari un modo veloce per girare i messaggi verso Mule e da Mule verso l'esterno.

JPA con database multipli

Mi sono fatto una domanda: supponiamo di avere MOLTI dati da trattare, suddivisi in più di un database. Come si può fare con JPA?

Infatti JPA, di default, punta ad un solo database.

l'EntityManager, cioè il gestore delle Entity, si ottiene attraverso EntityManagerFactory. Ora, usualmente si invoca il metodo EntityManagerFactory.createEntityManager(), senza parametri nè altro, e quindi si ottiene l'EntityManager predefinito.

Si può però usare anche il metodo EntityManagerFactory.createEntityManager(Map map) dove nella map sono specificate le proprietà con cui si vuol creare l'EntityManager.

Un esempio di tutto questo si può trovare qui http://www.nabble.com/Creating-EntityManager-with-a-specific-username-and-password--td21207265.html

Viene fatto con Hibernate, ma il concetto è lo stesso.

Questo mi permette di ottenere il risultato voluto, e di implementare una logica custom per la scelta del database.