JSF (MyFaces) et TimeZone

Les spécifications JSF font que le fuseau horaire (timezone) par défaut d'une conversion Date -> String est le GMT.
Celui du serveur n'est pas pris en compte.
Pour MyFaces, ces spécifications sont respectées depuis les versions supérieures à 1.1.0

package javax.faces.convert;
...
public class DateTimeConverter implements Converter, StateHolder {
...
  private static final TimeZone TIMEZONE_DEFAULT = TimeZone.getTimeZone("GMT");
...
}

Ainsi, il faudrait préciser le fuseau horaire dans toutes les pages affichant des dates si on souhaite en utiliser un autre.

<h:outputText value="#{bean.date}">
 <f:convertDateTime timeZone="Europe/Paris"/>
</h:outputText

Fastidieux!
Le plus simple est d'écrire son propre DateTimeConverter :

import java.util.TimeZone;
import javax.faces.convert.DateTimeConverter;
public class MyDateTimeConverter extends DateTimeConverter {
  public MyDateTimeConverter() {
    super();
    setTimeZone(TimeZone.getDefault());
  }
}

et de faire en sorte qu'il devienne le converter par défaut :

<converter>
<converter-for-class>java.util.Date</converter-for-class>
<converter-class>MyDateTimeConverter</converter-class>
</converter>

Utilisation avancée du plugin Maven Hibernate 3

Le plugin Maven Hibernate 3 permet d'intégrer facilement Hibernate 3 au sein d'un projet géré par maven. Ce plugin est régulièrement maintenu et sa communauté réactive mais on peu cependant déplorer une documentation succincte.
On y trouve en effet des exemples que pour des cas simples d'utilisation.
Par exemple, on y trouve comment générer un schéma pour une base de donnée avec un seul fichier de configuration mais comment faire pour générer des schémas pour plusieurs bases de données, chacune possédant son propre fichier de configuration .hbm.
Pour cela, il faut appeler plusieurs fois hbm2ddl :

 org.codehaus.mojo
 hibernate3-maven-plugin
 2.2-SNAPSHOT
 
  
   generate-database-1
   process-test-resources
   
    hbm2ddl
   
   
    
     target/classes/hibernate1.cfg.xml
     target/classes/jdbc1.properties
    
   
  
  
   generate-database-2
   process-test-resources
   
    hbm2ddl
   
   
    
     target/classes/hibernate2.cfg.xml
     target/classes/jdbc2.properties
    
   
  
 
 
  
   ${jdbc1.groupId}
   ${jdbc1.artifactId}
   ${jdbc1.version}
  
  
   ${jdbc2.groupId}
   ${jdbc2.artifactId}
   ${jdbc2.version}
  
 

Cette logique reste vraie avec les autres "goals".

Problème de validation XML avec JAXP

L'api JAXP permet l'analyse et la transformation de documents XML. Une implémentation de JAXP est disponible dans JAVASE 5.0 mais il est aussi possible d'utiliser l'implémentation fournie par Apache Xerces.
Pour analyser le fichier data.xml avec un parser SAX :

SAXParserFactory spfactory = SAXParserFactory.newInstance();
spfactory.setNamespaceAware(true);
SAXParser saxparser = spfactory.newSAXParser();
saxparser.parse(new File("data.xml"));

Et avec un parser DOM :

DocumentBuilderFactory dbfactory = DocumentBuilderFactory.newInstance();
dbfactory.setNamespaceAware(true);
DocumentBuilder domparser = dbfactory.newDocumentBuilder();
domparser.parse(new File("data.xml"));

La fonctionnalité qui nous intéresse ici est la validation d'un document par rapport à un schéma.

DocumentBuilderFactory dbfactory = DocumentBuilderFactory.newInstance();
dbfactory.setNamespaceAware(true);
dbfactory.setXIncludeAware(true);

DocumentBuilder parser = dbfactory.newDocumentBuilder();
Document doc = parser.parse(new File("data.xml"));

DOMSource xmlsource = new DOMSource(doc);

SchemaFactory wxsfactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);

//load a W3C XML Schema
Schema schema = wxsfactory.newSchema(new File("myschema.xsd"));

// create a validator from the loaded schema
Validator validator = schema.newValidator();

//validate the XML instance
validator.validate(xmlsource);

Si cet exemple fonctionne avec l'implémentation fournie avec JAVASE 5.0, une exception est toujours levée avec Xerces :

Exception in thread "main" org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'root'.

En effet, l'implémentation Xerces de Validator#validate ne semble pas supporter un objet de classe DOMSource en paramètre.
Pour contourner ce problème, il faut utiliser la fonctionnalité de transformation de JAXP et transformer notre document DOM(DOMSource) en Stream(StreamSource).

DOMSource xmlsource = new DOMSource(doc);
StringWriter writer = new StringWriter();
StreamResult result = new StreamResult(writer);
TransformerFactory tf = TransformerFactory.newInstance();
Transformer transformer = tf.newTransformer();
transformer.transform(xmlsource , result);
validator.validate(new StreamSource(new StringReader(result.toString())));

Pour aller plus loin : http://issues.apache.org/jira/browse/XERCESJ-1163

Sticky sessions

Dans un environnement multi-serveurs (cluster), le mécanisme de sticky session (affinité de session) assure qu'un client qui a ouvert une session sur un serveur sera toujours aiguillé vers ce même serveur durant sa session.
Par opposition, la réplication de session permet de garder sa session quelque soit le serveur sur lequel l'utilisateur est aiguillé.

Oracle rachète BEA

Ca se tramait depuis un certain temps mais c'est maintenant officiel :

Oracle to Acquire BEA Systems

L'un des 2 serveurs d'application OC4J ou Weblogic Server devrait passer à la trappe.

De même, on peut se demander comment va se positionner la nouvelle entité par rapport à Workshop concurent direct de JDevelopper.

En tout cas, ce rachat sucite de nombreuses réactions dont celles de Rod Johnson et Gigaspace qui nous encouragent à s'affranchir de l'architecture j2ee dont les 2 seuls concurrents directs sont maintenant Oracle et IBM.

Niveau d'isolement des transactions avec les EJB

C'est souvent trop tard qu'on commence à se pencher sérieusement sur certains concepts. Celui-ci est souvent occulté quand on développe un module EJB mais cet oubli peut conduire à des incompréhensions. L'abstraction de l'architecture J2EE peut alors se montrer trompeuse ...

L'isolement des transactions (le "I" dans les propriétés ACID), représente un concept et des mécanismes permettant d'assurer l'intégrité d'une base de données pouvant être accedée et(ou) mise à jour par un ensemble de clients simultanément.

En vue d'un déploiement au sein d'un conteneur d'EJB, la bonne pratique veut que ces transactions soient déclarées "déclarativement" dans les différents descripteurs de déploiement.
Dans cette optique, le niveau d'isolement peut être défini pour l'EJB ou pour une méthode en particulier.
Les différents niveaux d'isolement et leurs caractéristiques sont résumés ici.


TRANSACTION_SERIALIZABLE

La transaction obtient les privilèges exclusifs de lecture et d'écriture sur les données. Aucune autre transaction ne peut lire ou écrire les même données. Les "dirty reads", "nonrepeatable reads" et "phantom reads" sont donc exclues. Ce niveau d'isolation est le plus restrictif.

TRANSACTION_REPEATABLE_READ

La transaction ne peut modifier les données en cours de lecture par une autre transaction.Les "dirty reads" et "nonrepeatable reads" sont exclues. Les "phantom reads" peuvent subvenir. Les EJB ou méthodes utilisant ce niveau d'isolation ont les mêmes restrictions que le niveau TRANSACTION_READ_COMMITED et auront des données identiques pendant toute la transaction.

TRANSACTION_READ_COMMITTED

La transaction ne peut lire des données non commitées. Des données en cours de modification par une autre transaction ne peuvent pas être lues. Les "dirty reads" sont exclues mais les "nonrepeatable reads" et "phantom reads" peuvent subvenir.

TRANSACTION_READ_UNCOMMITTED

La transaction peut lire des données pas encore commitées par une autre transaction en cours.Les "dirty reads", "nonrepeatable reads" et "phantom reads" peuvent subvenir.

dirty reads
Séquence :
– A écrit un tuple
– B lit ce tuple
– A fait un rollback (restaurant l'ancienne valeur)
Conséquence :
– B a effectué un dirty read
– B possède une mauvaise valeur

nonrepeatable reads
Séquence :
– B lit un tuple
– A modifie ce tuple
– A fait un commit, rendant le changement permanent
Conséquence :
– B a effectué un non repeatable read
– B ne possède pas la bonne valeur du tuple
Si B refait une lecture de ce tuple, il aura une autre valeur

phantom reads
Séquence :
– A lit un ensemble de tuples
– B écrit un tuple qui aurait dû se trouver dans l'ensemble de A si B avait été plus rapide
Conséquence :
– A ne possède pas toute l'information qu'il cherchait
– Si A exécute la même requête à nouveau, les phantoms (nouveaux tuples) apparaissent