Off the record

Aller au contenu | Aller au menu | Aller à la recherche

samedi 2 juillet 2011

Who is occupying *my* port?

Annoying bind exception...
If it looks like :

java.net.BindException: Address already in use

Then you might start your inquiry with the following command :

Windows : netstat -nab

OSX / Unix : lsof -i :9000

And...

WTF, Firefox (might be Windows though) is responsible for the port occupation. Shut down Firefox, kill the annoying issue !

-> lsof == list open files -> man lsof

mardi 27 mai 2008

Spring, listener et ApplicationContext.

Dans le fichier de configuration web.xml de notre application, il est possible de déclarer des éléments "listener". Que font-ils? Comment Spring s'initialise grâce à eux?

Une classe listener implémenter l'une des deux super classe suivantes :

  • ServletContextListener
  • HttpSessionListener

Dans le premier cas, il faudra obligatoirement implémenter la méthode suivante : public void contextInitialized(ServletContextEvent ce)

Dans le second cas, il faudra implémenter entre autres : ublic void sessionCreated(HttpSessionEvent se)

A quoi tout cela peut il bien servir?
Oui exact, c'est ça, on obtient tout simplement ce qu'on appelle un hook sur les événements suivants (respectivement) :

  • création d'un ServletContext
  • création d'une session

Revenons en à Spring. Dés que l'application est démarrée, il nous faut le fameux "ApplicationContext Spring".
Très simplement, on va choisir de démarrer ce dernier par le biais d'une classe listener, qui sera déclarée dans le fichier web.xml comme suit :

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

Et bien sûr il existe une configuration par défaut pour le nom de fichier. S'il est déclaré comme suit, le listener le trouvera sans plus de configuration :
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/classes/applicationContext.xml, /WEB-INF/classes/resources.xml</param-value>
</context-param>

Voila voila...(A noter qu'en fait, petit malin, j'ai passé deux fichiers de config).

mardi 4 décembre 2007

Tomcat, JNDI et resources factories.

Configuration(s) de JNDI

Tomcat offre un service de nommage JNDI, par webapp depuis la version 5.5. Comment le configurer et y accéder?
Il faut, si l'on veut insérer une information dans le context général, commun à toutes les applications tournant sur le serveur, ajouter les lignes suivantes dans $TOMCAT_HOME/conf/context.xml : (exmple pour une datasource)

  <Resource name="jdbc/TestDB" auth="Container" type="javax.sql.DataSource"
        username="sa"
        password=""
        driverClassName="org.hsqldb.jdbcDriver"
        url="jdbc:hsqldb:hsql://localhost/data"/>

Si l'on veut restreindre l'acessibilité du contexte à une application web, il suffit de créer un fichier context.xml contenant les lignes ci-dessus (dans un tag <context></context>) dans le répertoire META-INF de la webapp et de déployer sous forme d'archive web (war).

On accédera ensuite à l'objet avec un code de type

Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");

if (envCtx == null)
   throw new Exception("Boom - No Context");
 
   DataSource ds = (DataSource) envCtx.lookup("jdbc/TestDB");
   if (ds != null) {
      Connection conn = ds.getConnection();
      // etc etc...

A noter que le registre JNDI de Tomcat est readonly, il n'est donc pas modifiable par programmation. On ne peut le configurer qu'au démarrage du serveur ou lors du déploiement d'une application...

Les "resources factories" proposées par Tomcat

Donc non seulement le service JNDI de Tomcat nous a permis de référencer une source de données, nous permettant ainsi de nous affranchir d'un nommage (et d'un paramétrage) dans l'application elle même, mais en plus, comme on le voit dans le code ci-dessus, Tomcat nous simplifie encore une étape en construisant pour nous l'objet Java Datasource directement, sur la base des infos JNDI.
Tomcat dispose en effet de "ressources factories", dans le cas ci-dessus, nous avons utilisé la "datasource factory". Ok quelles sont les autres?
De base, Tomcat fournit les factories suivante :

  • JDBC datasource factory
  • Javamail session factory
  • Javabean factory (similaire à Spring, en un sens)

On peut ensuite intégrer sa propre factory d'objet à Tomcat si l'on en ressent le besoin, une custom factory en fait...
Plus ici.

vendredi 16 février 2007

Tuning the logging level in Tomcat

Little tip in case ou want to have HIGHER level of logging from tomcat (version 5.5 or higher), because he fails to do something but just says failure ;-)
Tomcat, out of the box, does not include any logging library. However, if you want to make some fine-tuning on the logging, he is ready to achieve your configuration.
At startup (my guess...) Tomcat checks if some special configuration has to be applied, via the "bridge" interface commons logging . This library can be described as a logging implementation abstraction layer. If so, he applies it. Commons logging interface hides the actual implementation, that is, you can use either log4j or any alternative behind the scenes.
Anyway, drop the commons logging and log4j jar files in the common/lib directory, write a log4j.properties file in the common/classes directory, and you should be fine.

Log4j.properties example :

log4j.rootLogger=ERROR, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout

# Print the date in ISO 8601 format
log4j.appender.A1.layout.ConversionPattern=%d %t %-5p %c - %m%n

log4j.logger.org.apache=DEBUG



Pour tester tout ça, rapatriez ce petit projet JSF dans eclipse, ant compile et deploy...