Tomcat, Spring, JNDI & Oracle

Step 1:

Ajouter le JAR du driver Oracle dans le répertoire common/lib de Tomcat. S'assurer que dans le catalina.properties, la variable common.loader contient bien ${catalina.base}/common/lib/*.jar


Step 2:

Dans le fichier context.xml du répertoire conf de Tomcat, ajouter la ressource suivante :


<resource 
auth="Container" 
driverclassname="oracle.jdbc.driver.OracleDriver"
factory="oracle.jdbc.pool.OracleDataSourceFactory" 
maxactive="40" maxidle="3" 
maxopenpreparedstatements="100" maxwait="10000"
name="jdbc/oracleDataSource" password="password"
poolpreparedstatements="true" 
type="oracle.jdbc.pool.OracleDataSource"
url="jdbc:oracle:thin:@oracle_host:oracle_port:oracle_sid"
username="username" validationquery="SELECT SYSDATE FROM DUAL">
</resource>




Step 3:

Dans le fichier web.xml


<resource-ref>
<description>Connection Pool</description>
<res-ref-name>jdbc/oracleDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>




Step 4:

Déclaration du data source dans le fichier de context Spring


<bean class="org.springframework.jndi.JndiObjectFactoryBean" id="dataSource">
<property name="jndiName" value="java:comp/env/jdbc/oracleDataSource"></property>
<property name="resourceRef" value="true"> </property>
<property name="proxyInterface" value="javax.sql.DataSource"></property>
<property name="lookupOnStartup" value="true"></property>
</bean>




Step 5:

Modifier les valeur maxActive, maxWait... pour qu'ils correspondent aux besoins.


...avec Maven et Cargo plugin

Ajouter la dépendance vers la librairie Oracle dans votre POM :


<dependency>
<groupid>com.oracle</groupid>
<artifactid>ojdbc5</artifactid>
<version>${oracle.version}</version>
<type>jar</type>
</dependency>



Dans la configuration du plugin cargo, dans la section 'container', ajouter la dépendance vers la librairie Oracle:


<pluginmanagement>
<plugins>
...
<plugin>
<groupid>org.codehaus.cargo</groupid>
<artifactid>cargo-maven2-plugin</artifactid>
<version>1.1.3</version>
<configuration>
<container>
<containerid>tomcat6x</containerid>
...
<dependencies>
<dependency>
<groupid>com.oracle</groupid>
<artifactid>ojdbc5</artifactid>
<classpath>extra</classpath>
</dependency>
</dependencies>
</container>
</configuration>
</plugin>
</plugins>
</pluginmanagement>


Réaliser un fichier tomcat-context.xml dans un répertoire de resource (par exemple, resource/conf/) avec pour contenu :


<context>
<resource 
auth="Container" 
driverclassname="oracle.jdbc.driver.OracleDriver"
factory="oracle.jdbc.pool.OracleDataSourceFactory" 
maxactive="40" maxidle="3" maxopenpreparedstatements="100"
maxwait="10000" name="jdbc/oracleDataSource" password="password"
poolpreparedstatements="true" type="oracle.jdbc.pool.OracleDataSource"
url="jdbc:oracle:thin:@oracle_host:oracle_port:oracle_sid"
username="username" validationquery="SELECT SYSDATE FROM DUAL">
</resource>



Finalement, modifier la configuration du plugin cargo :


<plugins>
<plugin>
<groupid>org.codehaus.cargo</groupid>
<artifactid>cargo-maven2-plugin</artifactid>
<executions>
<execution>
<id>start-cargo</id>
<phase>pre-integration-test</phase>
<goals>
<goal>${cargo.goal}</goal>
</goals>
<configuration>
<container>
<timeout>200</timeout>
</container>

<configuration>
<properties>
<cargo .servlet.port=".servlet.port">${servlet.port}</cargo>
</properties>
<deployables>
<deployable>
<groupid>application.group.id</groupid>
<artifactid>myapp</artifactid>
<type>war</type>
</deployable>
...
</deployables>
<configfiles>
<configfile>
<file>${project.build.directory}/test-classes/tomcat-context.xml</file>
<todir>conf/</todir>
<tofile>context.xml</tofile>
</configfile>
...
</configfiles></configuration></configuration></execution></executions></plugin>
</plugins>

Maven, attacher un artefact supplémentaire

Le projet génère plusieurs fichiers que j'aimerai rendre disponible sur notre Nexus (des WSDL).

Pour ajouter les fichiers supplémentaires, j'ai utilisé le plugin build-helper-maven-plugin


<plugin>
 <groupid>org.codehaus.mojo</groupid>
 <artifactid>build-helper-maven-plugin</artifactid>
 <version>1.7</version>
 <executions>
  <execution>
   <id>attach-artifacts</id>
   <phase>package</phase>
   <goals>
    <goal>attach-artifact</goal>
   </goals>
   <configuration>
    <artifacts>
     <artifact>
      <file>${project.build.directory}/generated/wsdl/Service1.wsdl</file>
      <type>wsdl</type>
      <classifier>Service1</classifier>
     </artifact>
     <artifact>
      
      <file>${project.build.directory}/generated/wsdl/Service2.wsdl</file>
      <type>wsdl</type>
      <classifier>Service2</classifier>
     </artifact>
     <artifact>
      
      <file>${project.build.directory}/generated/wsdl/Service3.wsdl</file>
      <type>wsdl</type>
      <classifier>Service3</classifier>
     </artifact>
    </artifacts>
   </configuration>
  </execution>
 </executions>
</plugin>




Ensuite, le module qui aurait besoin de ces fichiers n'aura plus qu'à ajouter les dépendances dans son POM.

Java, SLF4J, Logback & Maven

Petite recette pour une utilisation de SLF4J avec Logback dans un context Maven


Créez un projet maven avec l'arborescence classique. Le package de base que j'utilise dans le projet exemple est "fr.gunduz.logback".

Ajoutez dans le POM les dépendances suivantes :


<dependency>
   <groupid>org.slf4j</groupid>
   <artifactid>slf4j-api</artifactid>
   <version>1.6.4</version>
  </dependency>
  <dependency>
   <groupid>ch.qos.logback</groupid>
   <artifactid>logback-classic</artifactid>
   <scope>runtime</scope>
   <version>1.0.0</version>
</dependency>





Dans le répertoire 'resources', ajouter le fichier logback.xml avec le contenu suivant :


<configuration>
 <appender class="ch.qos.logback.core.ConsoleAppender" name="STDOUT">
  <layout class="ch.qos.logback.classic.PatternLayout">
   <pattern>
    %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
   </pattern>
  </layout>
 </appender>

 <logger level="DEBUG" name="fr.gunduz" />
 <root level="debug">
  <appender-ref ref="STDOUT" />
 </root>
</configuration>


On peut faire une classe pour tester logback :

package fr.gunduz.logback;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;


public class App 
{
  private static final Logger logger = LoggerFactory.getLogger(App.class);

  public static void main( String[] args )
  {
    String test = "with SLF4J and Logback";

    logger.debug("Hello wolrd, {}", test);
  }
}

On peut lancer l'execution :

mvn clean compile exec:java -Dexec.mainClass=fr.gunduz.logback.App

Et vous aurez le 'Hello world'!



Les sources sont disponible sur Google Code

Maven, versions plugin

Assigner un nouveau numéro de version a un projet Maven et ses sous projets :
mvn versions:set -DnewVersion=<nouveau numéro de version>

Par exemple:
mvn versions:set -DnewVersion=1.12.1-SNAPSHOT

Il est possible de revenir en arrière si vous rencontrez un problème :

mvn versions:revert

Si tout est bon, on peut faire :

mvn versions:commit 

PS : les sous modules concernés sont uniquement ceux indiqués dans le POM parent. Si vous avez un répertoire de module dans votre projet mais qu'il n'apparait pas dans le POM parent pour diverses raisons, il ne sera pas touché par ces commandes.

Ubuntu 11.10, Unity reste en arrière plan

De temps en temps Unity reste en arrière plan chez moi.

Une des solutions est de taper la commande suivante dans une console : unity& disown

src : http://askubuntu.com/questions/60698/how-do-i-stop-the-unity-launcher-from-hiding-behind-other-windows

Getters et Setters avec Java

Vous aussi vous en avez assez de tout ce code généré automatiquement par votre Eclipse ou Netbeans ? Lombok peut peut-être vous aidez.

Au passage, je n'utilise pas encore ce projet dans des cas professionnels mais plutôt sur certains projets personnels.

Je vais montrer ici son utilisation dans un projet Maven. Dans un premier temps, il faut ajouter la dépendance Lombok dans votre POM :

<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>0.10.0</version>
</dependency>




Classe de test : Book.class
Ensuite créons une classe (Book) pour la démonstration : 

@Data
Lombok nous propose une annotation @Data qui permet d'avoir les getters, setters, equals, toString... :

un petit test pour voir le résultat :

Lombok propose bien d'autres annotations. Si vous ne voulez que des getters, il suffit de préfixer les variables concernées avec l'annotation @Getter.


Les annotations disponibles :

• @Log,
• @Getter,
• @Setter,
• @Log,
• @ToString,
• ...

La liste complète est disponible ici : http://projectlombok.org/features/index.html


J’espère que ce genre de mécanisme sera intégré dans les prochaines versions de Java.


PS : petite boulette au niveau du nom du package. Pas encore fini de prendre en main le Netbeans on dirait!

Hibernate : WrappedMaterializedBlobType overrides final method

Après migration de Hibernate 3.5.3-Final vers 3.6.6.Final, je me suis retrouvé dans l'impossibilité de lancer notre projet avec pour erreur :

Error creating bean with name 'org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor#0': Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [META-INF/......xml]: Invocation of init method failed; nested exception is java.lang.VerifyError: class org.hibernate.type.WrappedMaterializedBlobType overrides final method

Après quelques recherches, le coupable est Hibernate annotation 3.5.6-Final. Une des librairies de notre projet avait cette dépendance dans son fichier POM or annotation semble maintenant inclus dans les version 3.6.X

Solution dans mon cas : enlever Hibernate annotation des dépendances et tout semble rouler pour le moment.


English version :
After upgrading Hibernate 3.5.3-Final to 3.6.6.Final, i encoutered this error. I was unable to launch our project.

After few research in the code, my problem was related to my dependency with Hibernate annotation 3.5.6-Final. This dependecy was listed in one of our child module. It seems that annotation has been included into the main Hibernate jar (3.6.6.Final). So, in my case, the solution was to remove the dependency to Hibernate annotation 3.5.6-Final and now, our project seems to go back on track.