Top Dix des Astuces de Configuration de Tomcat
Note des auteurs : Maintenant que l’écriture d’applications Web en Java est devenue une manière répandue de créer et de déployer de nouveaux contenus sur le Web, les gens de part le monde sont séduits par l’utilité du conteneur JSP et servlet de Jakarta Tomcat. C’est une solution gratuite, multiplate-forme, riche en fonctionnalités, en évolution et amélioration constante et n’a jamais été aussi populaire.
Le seul souci semble être : comment peut on configurer Tomcat pour qu’il fasse ce qu’on souhaite qu’il fasse ? Tomcat est capable, tant que vous pouvez le configurer pour qu’il réponde à vos besoins. Voici donc ma liste de dix astuces de configuration de Tomcat, tirées de “Tomcat: The Definitive Guide”, pour vous aider à y arriver. — Jason Brittain
1. Configurer l’Application Web Admin
La plupart des serveurs J2EE commerciaux fournissent une interface d’administration pleinement fonctionnelle, et la plupart sont accessibles en tant qu’applications Web. L’application Tomcat Admin est sur le point de devenir un outil d’envergure d’administration de Tomcat rivalisant avec ces offres commerciales. Tout d’abord inclus dans Tomcat 4.1, Admin permet déjà le contrôle des contextes, des sources de données, des utilisateurs et des groupes. Vous pouvez aussi contrôler les ressources telles que les paramètres d’initialisation tout comme les utilisateurs, les groupes et les rôles de nombreuses bases de données utilisateur. La liste des possibilités sera étendue dans les prochaines versions, mais l’implémentation actuelle s’est déjà affirmée par son utilité.
L’application web Admin est définie dans le fichier d’auto-déploiement CATALINA_BASE/webapps/admin.xml.
Vous devez éditer ce fichier pour vérifier que le chemin d’accès spécifié dans l’attribut docBase de l’élément Context est absolu ; c’est à dire, le chemin d’accès absolu CATALINA_HOME/server/webapps/admin. Autrement, vous pourriez retirer le fichier d’auto-déploiement et spécifier le contexte Admin manuellement dans votre fichier server.xml. Sur les machines qui ne seront pas gérées par cette application, vous devrez probablement les désactiver toutes les deux en supprimant simplement CATALINA_BASE/webapps/admin.xml.
Si vous utilisez un UserDatabaseRealm (par défaut), vous devrez ajouter un utilisateur et un rôle au fichier CATALINA_BASE/conf/tomcat-users.xml. Pour le moment, éditez juste ce fichier et ajoutez un rôle appelé “admin” à votre base de données utilisateurs :
<role name="admin"/>
Vous devez aussi ajouter un utilisateur assigné au rôle “admin”. Ajoutez une ligne utilisateur comme celle la après la ligne utilisateur existante (en mettant un mot de passe un peu plus sécurisé) :
<user name="admin" password="deep_dark_secret" roles="admin"/>
Une fois que vous avez passé ces étapes et redémarré Tomcat, visitez l’URL http://localhost:8080/admin, et vous devriez voir apparaître un écran d’accueil. L’application Admin est bâtie en utilisant la sécurité gérée par conteneur et le framework Jakarta Struts. Une fois que vous êtes connecté sous l’utilisateur assigné au rôle Admin, vous pouvez utiliser l’application Admin pour configurer Tomcat.
2. Configurer l’Application Web Manager
L’application web Manager vous permet d’effectuer des tâches simple de gestion sur vos applications web au travers d’une interface utilisateur plus simple que celle de l’application web Admin.
L’application web Manager est définie dans le fichier d’auto-déploiement CATALINA_BASE/webapps/manager.xml.
Vous devez éditer ce fichier pour vérifier que le chemin d’accès spécifié dans l’élément Context est absolu ; c’est à dire, le chemin d’accès absolu CATALINA_HOME/server/webapps/manager.
Si vous utilisez un UserDatabaseRealm (par défaut), vous devrez ajouter un utilisateur et un rôle au fichier CATALINA_BASE/conf/tomcat-users.xml. Pour le moment, éditez juste ce fichier et ajoutez un rôle appelé “manager” à votre base de données utilisateurs :
<role name="manager"/>
Vous devez aussi ajouter un utilisateur assigné au rôle “manager”. Ajoutez une ligne utilisateur comme celle la après les lignes utilisateur existantes (en mettant un mot de passe un peu plus sécurisé) :
<user name="manager" password="deep_dark_secret" roles="manager"/>
Puis remancez Tomcat et allez à l’URL http://localhost/manager/list pour voir apparaître l’interface manager en mode texte, ou http://localhost/manager/html/list pour l’interface manager en mode HTML. Dans les deux cas, votre application Manager devrait maintenant fonctionner.
L’application Manager vous permet d’installer des applications web de manière temporelle, juste pour les tester. Si vous avons une application dans /Users/username/hello et que nous souhaitons la tester en l’installant sous l’URI /hello, nous plaçons “/hello” dans le premier champ de saisie texte (pour le chemin d’accès) et “file:///Users/username/hello” dans le second (pour l’URL Config).
Le Manager permet aussi d’arrêter, de recharger, de retirer ou d’annuler le déploiement d’une application web. L’arrêt d’une application la rend indisponible jusqu’à notification ultérieure mais elle peut bien sûr être relancée. Les utilisateurs essayant d’accéder à une application arrêtée recevront un message d’erreur, tel que 503 - This application is not currently available.
Le fait de retirer une application ne la retire que de la copie de Tomcat en cours d’exécution—si elle avait été lancée à partir des fichiers de configuration, elle réapparaîtra la prochaine fois que Tomcat sera relancé (en d’autres termes, cela ne supprime pas l’application sur le disque dur).
3. Déployer une Application Web
Il y a deux façons de déployer une application web sur le système de fichier :
1. Copiez votre fichier WAR ou le répertoire de votre application web (y compris tout son contenu) vers le répertoire $CATALINA_BASE/webapps.
2. Créez un fichier fragment XML avec juste l’élément Context pour votre application web et placez ce fichier XML dans $CATALINA_BASE/webapps. L’application web elle-même peut être stockée n’importe où sur le système de fichier.
Si vous avez un fichier WAR, vous pouvez le déployer en le copiant simplement dans le répertoire CATALINA_BASE/webapps. Le nom de fichier doit se terminer avec une extension “.war“. Une fois que Tomcat remarque ce fichier, il le dépactera (par défaut) dans un sous-répertoire portant le nom du fichier WAR. Il créera alors un contexte en mémoire, de la même façon que quand vous en aviez créé un en éditant le fichier server.xml de Tomcat. Cependant, tout paramétrage par défaut sera obtenu à partir de l’élément DefaultContext du fichier server.xml de Tomcat.
Une autre façon de déployer une application web consiste à écrire un fichier XML fragment de Contexte et à le déployer dans le répertoire CATALINA_BASE/webapps. Un fragment de contexte n’est pas un document XML complet mais juste un élément Context avec les sous-élements appropriés pour votre application web. Ces fichiers sont comme des éléments Context retirés du fichier server.xml, d’où le nom “fragment de context”.
Par exemple, si nous souhaitions déployer le fichier WAR MyWebApp.war avec un domaine permettant d’accéder à des parties de cette application web, nous pourrions utiliser ce fragment :
<!--
Fragment de contexte pour déployer MyWebApp.war
-->
<Context path="/demo" docBase="webapps/MyWebApp.war"
debug="0" privileged="true">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Context>
Placez ceci dans un fichier appelé “MyWebApp.xml” et copiez le dans le répertoire CATALINA_BASE/webapps.
Ces fragments de contexte apporte une méthode commode pour déployer des applications web ; vous n’avez pas à éditer le fichier server.xml et, à moins que vous ayez désactivé la fonction liveDeploy activée par défaut, vous n’avez pas à relancer Tomcat pour installer une application web.
4. Configurer les Hôtes Virtuels
L’élément Host n’a normalement besoin d’une modification que si vous configurez des hôtes virtuels. Les hôtes virtuels sont un mécanisme par lequel un processus de serveur web peut servir plusieurs nom de domaine, donnant à chaque domaine l’impression d’avoir son propre serveur. En fait, la majorité des sites web de petites entreprises sont implémentés sous forme d’hôte virtuel, de part le coût de connexion d’un ordinateur directement à Internet avec suffisamment de bande passante pour fournir des temps de réponse raisonnables et la stabilité d’une adresse IP permanente.
La gestion d’hôtes viruels basée sur le nom est effectuée sur tout serveur web en établissant un alias d’adresse IP dans les données du Domain Name Service (DNS) et en indiquant au serveur web de rediriger toute requête destinée à cet alias d’adresse vers un répertoire particulier de pages web. Puisque cet article est sur Tomcat, nous n’allons pas monter toutes les manières de positionner des données DNS sur différents systèmes d’exploitation. Si vous avez besoin d’aide là-dessus, veuillez vous référer à DNS and Bind, de Paul Albitz et Cricket Liu (O’Reilly). Dans un but de démonstration, j’utiliserai un fichier statique d’hôtes, puisque c’est la façon la plus simple de configurer des alias en vue de tests.
Pour utiliser les hôtes virtuels avec Tomcat, vous n’avez qu’à configurer les données du DNS ou des hôtes pour l’hôte. Pour tester, le fait de faire un alias pour localhost est suffisant. Vous avez alors besoin d’ajouter quelques lignes au fichier de configuration server.xml :
<Server port="8005" shutdown="SHUTDOWN" debug="0">
<Service name="Tomcat-Standalone">
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"/>
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8443" minProcessors="5" maxProcessors="75"
acceptCount="10" debug="0" scheme="https" secure="true"/>
<Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
clientAuth="false" protocol="TLS" />
</Connector>
<Engine name="Standalone" defaultHost="localhost" debug="0">
<!-- Cet hôte est celui par défaut -->
<Host name="localhost" debug="0" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<Context path="" docBase="ROOT" debug="0"/>
<Context path="/orders" docBase="/home/ian/orders" debug="0"
reloadable="true" crossContext="true">
</Context>
</Host>
<!-- Cet hôte est le premier "Hôte Virtuel" : www.example.com -->
<Host name="www.example.com" appBase="/home/example/webapp">
<Context path="" docBase="."/>
</Host>
</Engine>
</Service>
</Server>
Le fichier server.xml de Tomcat, tel qu’il est distribué, ne contient qu’un seul hôte virtuel mais il est facile d’ajouter le support d’hôtes virtuels supplémentaire. La version simplifiée du fichier server.xml de l’exemple précédent montre en gras la structure complète supplémentaire requises pour ajouter un hôte virtuel. Chaque élément Host doit contenir un ou plusieurs éléments Context ; un d’entre eux doit être le Context par défaut de cet hôte spécifié par le fait d’avoir une chaîne de caractère vide dans le chemin relatif (par exemple, path="").
5. Configurer l’Authentification de Base
Les méthodes d’authentification gérées par des conteneurs contrôlent la manière dont sont vérifiées les lettres de créance d’un utilisateur lorsque la ressource d’une application Web est accédée. Quand une application web utilise une authentification de base (BASIC dans l’élément auth-method du fichier web.xml), Tomcat utilise une authentification HTTP basique pour demander au navigateur un nom d’utilisateur et un mot de passe au moment où le navigateur fait la demande d’une ressource de cette application web protégée. Avec cette méthode d’authentification, tous les mots de passe sont envoyés sur le réseau au format texte encodé en base64.
Note : L’utilisation d’une authentification de base est généralement considérée peu sûre car elle ne crypte pas fortement les mots de passe, à moins que le site n’utilise HTTPS ou d’autres formes de cryptage entre le client et le serveur (par exemple, un réseau privé virtuel—VPN). Sans ce cryptage, des surveilleurs de réseau peuvent intercepter les mots de passe (et en abuser). Mais, si vous commencez à peine à utiliser Tomcat, ou si vous ne souhaitez que tester la sécurité gérée par conteneur avec votre application web, une authentification basique est simple à mettre en oeuvre et à tester. Ajoutez seulement les éléments <security-constraint> et <login-config> au fichier web.xml de votre application web et les éléments appropriés <role> et <user> à votre fichier CATALINA_BASE/conf/tomcat-users.xml, relancez Tomcat et Tomcat s’occupera du reste.
L’exemple ci-dessous montre un extrait de fichier web.xml tiré d’un site web gérant un club de membres contenant seulement un sous-répertoire protégé par authentification basique destiné aux membres. Notez que cela remplace efficacement les fichiers .htaccess du serveur Apache.
<!--
Définit la zone réservée aux Membres, en définissant une "Security Constraint"
sur cette Application, et en la redirigeant vers le sous-répertoire (URL) que
nous souhaitons protéger.
-->
<security-constraint>
<web-resource-collection>
<web-resource-name>
Entire Application
</web-resource-name>
<url-pattern>/members/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>member</role-name>
</auth-constraint>
</security-constraint>
<!-- Définit la Configuration de Connexion pour cette Application -->
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>My Club Members-only Area</realm-name>
</login-config>
6. Eviter les Demandes d’Authentification à Répétition
Une fois que vous aurez mis sur pied votre méthode d’authentification, vous devrez traiter véritablement processus de connexion de l’utilisateur. Plus souvent qu’on ne le croit, la connexion à une application est ennuyante pour l’utilisateur final et vous devrez minimiser le nombre de fois qu’il devra s’identifier. Par défaut, chaque application web demandera à l’utilisateur de s’identifier la première fois qu’il demandera l’accès à une ressource protégée. Cela peut vite devenir très génant si vous avez plusieurs applications web et que chaque application nécessite une identification. Les utilisateurs ne peuvent déterminer combien il y a d’applications web se cachent derrière un seul site web, ils ne pourront donc pas se rendre compte que leur requête sort des frontières d’un contexte et ils se demanderont pourquoi on leur demande de s’identifier de manière répétitive.
La fonction “une seule identification” de Tomcat 4 permet à un utilisateur de s’identifier qu’une fois pour accéder toutes les applications web chargées sous un hôte virtuel. Pour utiliser cette fonction, vous n’avez qu’à ajouter un élément SingleSignOn Valve au niveau de l’hôte. Cela ressemble à ceci :
<Valve className="org.apache.catalina.authenticator.SingleSignOn" debug="0"/>
Le fichier server.xml par défaut de la distribution de Tomcat contient un exemple de configuration de la Valve d’identification mis en commentaire que vous pouvez activer. Alors, tout utilisateur qui sera réputé valide dans un contexte situé au sein d’un hôte virtuel configuré sera considéré valide dans tous les autres contextes de ce même hôte.
Il y a plusieurs restrictions importantes dans l’utilisation de la valve d’identification unique :
- La valve doit être configurée et emboîtée dans le même élément
Hostque celui dans lequel les applications web (représentées par des élémentsContext) sont placés. - Le
Realmqui contient l’information utilisateur partagée doit être configuré soit au niveau du même hôte, soit dans un emboîtement externe. - Le
Realmne peut être surpassé au niveauContext. - Les applications webs qui utilisent une identification unique doivent utiliser un des authentificateurs internes de Tomcat (dans l’élément
<auth-method>du fichier web.xml), plutôt qu’un authentificateur personnel. Les méthodes internes sont les authentificationsbasic,digest,formetclient-cert. - Si vous utilisez une identification unique et souhaitez intégrer une autre application web de tierce partie dans votre site web et que cette application utilise son propre code d’identification sans utiliser de sécurité gérée par conteneur, vous êtes fondamentalement coincé. Vos utilisateurs devront s’identifier une fois pour toutes les applications qui utilisent l’identification unique, puis une fois encore s’ils formulent une requête en direction de la nouvelle application de tierce partie. Bien sûr, si vous pouvez vous procurer le source et que vous êtes développeur, vous pouvez corriger cela, mais cela ce ne sera probablement pas si facile à faire.
- La valve d’identification unique nécessite d’utiliser les cookies HTTP.
7. Configurer des Répertoires Utilisateur Personnalisés
Certains sites aiment bien permettre à des utilisateurs individuels de publier des pages web dans un répertoire du serveur. Par exemple, un département universitaire pourrait souhaiter donner à chaque étudiant une aire publique, ou un provider pourrait rendre disponible un peu d’espace sur un de ses serveurs pour les clients n’ayant pas de serveur web virtuellement hébégé. Dans de tels cas, il est fréquent d’utiliser le caractère tilde (~) suivi du nom de l’utilisateur comme chemin d’accès virtuel au site web de cet utilisateur :
http://www.cs.myuniversity.edu/~username http://members.mybigisp.com/~username
Tomcat vous apporte deux manières de rediriger ceci hôte par hôte en utilisant une paire d’éléments Listener spéciaux. L’attribut className de Listener devrait être org.apache.catalina.startup.UserConfig, avec l’attribut userClass spécifiant une des nombreuses classes de redirection. Si votre système est sous Unix, qu’il est doté d’un fichier standard /etc/passwd lisible par le compte exécutant Tomcat et que ce fichier spécifie les répertoires “home” de l’utilisateur, utilisez alors la classe de redirection PasswdUserDatabase :
<Listener className="org.apache.catalina.startup.UserConfig" directoryName="public_html" userClass="org.apache.catalina.startup.PasswdUserDatabase"/>
Les fichiers web necéssiteront d’être dans des répertoires tels que /home/users/ian/public_html ou /users/jbrittain/public_html. Bien sûr, vous pouvez changer public_html en n’importe quel répertoire dans lequel vos utilisateurs placent leurs pages web personnelles.
En fait, les répertoires n’ont pas du tout besoin d’être à l’intérieur du répertoire Home d’un utilisateur. Si vous n’avez pas de fichier password mais souhaitez effectuer une redirection à partir d’un nom d’utilisateur vers le sous-répertoire d’un répertoire parent commun tel que /users, utilisez la classe HomesUserDatabase :
<Listener className="org.apache.catalina.startup.UserConfig" directoryName="public_html" homeBase="/users" userClass="org.apache.catalina.startup.HomesUserDatabase"/>
Dans ce cas, les fichiers web seront dans des répertoires tels que /users/ian/public_html ou /users/jasonb/public_html. Ce format est plus utile sous Windows, de part l’utilisation de répertoire sous la forme C:\home.
Ces éléments Listener, s’ils sont presents, doivent être à l’intérieur d’un élément Host, mais pas à l’intérieur d’un élément Context, du fait qu’ils s’appliquent à l’hôte en tant que tel.
8. Utiliser des Scripts CGI avec Tomcat
Tomcat est essentiellement indiqué pour être un conteneur de servlet/JSP, mais il est doté de beaucoup de possibilités lui permettant de rivaliser avec des serveurs web traditionnels. Une de ces possibilités est le support des Common Gateway Interface (CGI) qui apportent le moyen de lancer un programme externe en réponse à une requête de navigateur, habituellement pour traiter un formulaire web. CGI est appelé “commun” parce qu’il peut invoquer des programmes dans presque tous les langages de programmation ou de scripting : Perl, Python, awk, scripting de shell Unix et même Java sont tous des options supportées. Cependant, vous ne souhaiterez probablement pas lancer une application Java par ce biais à cause du temps système de démarrage ; l’élimination de ce temps système représente ce qui a mené à l’élaboration originale des spécifications des servlets. Les servlets sont presque toujours plus efficaces que les CGI parce que vous ne démarrez pas de nouveau processus au niveau système d’exploitation chaque fois que quelqu’un clique sur un lien ou un bouton.
Tomcat comprend une servlet CGI optionnelle qui vous permet de lancer d’anciens scripts CGI ; en supposant que les tout nouveaux traitements back-end seront faits par des servelts et des JSP utilisateurs.
Pour activer la servlet CGI de Tomcat, vous devez faire les choses suivantes :
- Renommer le fichier servlets-cgi.renametojar (situé dans CATALINA_HOME/server/lib/) en servlets-cgi.jar, de façon à ce que la servlet qui traitera les scripts CGI soit dans le
CLASSPATHde Tomcat. - Dans le fichier CATALINA_BASE/conf/web.xml de Tomcat, enlever les commentaires sur la définition de la servlet nommée
cgi(c’est aux allentours de la ligne 241 dans la distribution). - Toujours dans le fichier web.xml, décommentez la redirection de servlet pour la servelet
cgi(près de la ligne 299 du fichier de la distribution). Souvenez-vous, cela spécifie les liens HTML vers le script CGI. - Placez les scripts CGI soit dans le répertoire WEB-INF/cgi directory (rappelez vous que WEB-INF est un endroit sûre pour cacher les choses que vous ne voulez pas que les utilisateurs voyent, pour des raisons de sécurité), soit dans un autre répertoiore de votre contexte et ajustez le paramètre d’initialisation
cgiPathPrefixduCGIServletde façon à identifier le répertoire contenant les fichiers. Cela spécifie l’emplacement réel des scripts CGI qui en général ne sera pas le même que celui de l’URL de l’étape précédente. - Relancez Tomcat, et votre processus CGI devrait être maintenant opérationnel.
Le répertoire par défaut utilisé par la servlet pour localiser les scripts est WEB-INF/cgi. Comme il a été dit, le répertoire WEB-INF est protégé contre les intrusions fortuites des navigateurs, c’est donc un bon endroit pour y placer les scripts CGI qui pourraient contenir des mots de passe ou d’autres informations sensibles. Pour assurer cependant la compatibilité avec d’autres serveurs, vous souhaiterez peut-être garder les scripts dans le répertoire traditionnel, /cgi-bin, mais soyez averti que les fichiers de ce répertoire pourront être vues par les surfeurs curieux. Aussi, sous Unix, assurez vous que les fichiers de script CGI soient exécutables par l’utilisateur sous lequel vous avez lancé Tomcat.
9. Changer le Compilateur JSP de Tomcat
Dans Tomcat 4.1 (et sûrement après), la compilation de JSP est effectuée en utilisant le contrôleur de programme Ant directement dans Tomcat. Cela semble un peu étrange, mais cela fait partie de ce à quoi Ant a été destiné ; il y a une API documentée qui permet aux développeurs d’utiliser Ant sans avoir à lancer une nouvelle Machine Virtuelle Java (JVM). C’est un des avantages de l’écriture de Ant en Java. En plus, cela signifie que vous pouvez maintenant utiliser tout autre compilateur supporté par la tâche javac dans Ant ; ils sont listés sur la page javac du manuel Ant d’Apache. Il est facile à utiliser parce que vous n’avez seulement besoin que d’un <init-param> avec le nom “compiler” et une valeur avec un des noms de compilateur supporté :
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>
org.apache.jasper.servlet.JspServlet
</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>WARNING</param-value>
</init-param>
<init-param>
<param-name>compiler</param-name>
<param-value>jikes</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
Bien sûr, le compilateur doit être installé sur votre système, et le CLASSPATH doit être réglé en fonction du compilateur choisi.
10. Restreindre les Accès à des Hôtes Spécifiques
Quelque fois, vous souhaitez seulement restreindre les accès aux applications web de Tomcat à des noms d’hôte ou à des adresses IP spécifiques. De cette façon, seuls les clients de ces sites spécifiés pourront être servis en contenu. Tomcat est accompagné de deux Valves que vous pouvez configurez et utilisez dans ce but : RemoteHostValve et RemoteAddrValve.
Ces Valves vous permettent de filtrer les requêtes sur le nom d’hôte ou l’adresse IP, et d’accepter ou refuser les hôtes correspondants, de manière similaire à la directive Autoriser/Refuser par répertoire dans le fichier httpd d’Apache. Si vous lancez l’application Admin, vous souhaiterez peut-être en autoriser l’accès qu’à partir de l’hôte localhost, de cette manière :
<Context path="/path/to/secret_files" ...>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127.0.0.1" deny=""/>
</Context>
Si aucun modèle d’autorisation est donné alors les modèles qui correspondront aux modèles de l’attribut de refus seront rejetés et tous les autres seront autorisés. De la même manière, si aucun modèle de refus n’est donné, les modèles qui correspondront à l’attribut allow seront autorisés et tous les autres refusés.
Jason Brittain est Ingénieur Développement Sénior pour CollabNet Inc., où il travaille sur des logiciels d’infrastructure d’hébergement de projets logiciel collaboratifs. Il a contribué à plusieurs projets Jakarta d’Apache, et il est un développeur actif de logiciels open source depuis de nombreuses années.
Ian F. Darwin travaille dans l’industrie informatique depuis trois décades : sur Unix depuis 1980, Java depuis 1995 et OpenBSD depuis 1998. Il est l’auteur de deux livres chez O’Reilly, Checking C Programs with lint et Java Cookbook.
Textes originaux en anglais sur O’Reilly : Top Ten Tomcat Configuration Tips par by Jason Brittain et Ian F. Darwin, auteurs de Tomcat: The Definitive Guide
Chargement
Commentaires récents