refpack

Quelques points importants de l'intégration de JBoss 5.1.0 sont présentés ici. Cette liste n'est pas exhaustive mais permet une première approche du sujet.

Description du package
JBoss5 & Web Services
Séparation technique et applicative
Démarrage et options de la JVM
Gestion des ports
Sécurité de JBoss
Slimming de JBoss
Tuning de JBoss
Supervision de JBoss

Description du package

La version JBoss 5.1.0 nécessite le JRE 1.6 pour son exécution.

1. Répertoire <JBOSS_HOME>/

Le répertoire root JBoss contient les répertoires suivant :

bin	Contient les scripts d'arrêt et de lancement des instances JBoss.
lib	Contient les librairies techniques utilisées par JBoss.
server	Contient l'environnement des instances JBoss.
client	Contient les librairies pour les parties clientes (consommation EJB / web service / ...).

2. Répertoire <JBOSS_HOME>/server/

Le répertoire de chaque instance JBoss (server/<INSTANCE>/) contient les répertoires suivant :

conf	Contient la configuration technique de l'instance JBoss.
lib	Contient les librairies techniques utilisées par l'instance JBoss.
data	Contient des fichiers stockées par les composants applicatifs (WSDL, ...).
deploy	Contient les composants techniques utilisés dans l'instance JBoss.
deployers	Contient les composants techniques utilisés pour les déployeurs personnalisés.
work	Contient les objets compilés de l'instance JBoss (JSP, ...).
tmp	Contient les composants techniques des applications installés. Chaque fois que le serveur est demarré, chaque archive dans le répertoire deploy est déployée dans tmp.

3. Répertoire <JBOSS_HOME>/server/<INSTANCE>/conf/

jboss-service.xml	Contient la configuration des services intégrés au coeur de JBoss.
jndi.properties	Spécifie le JNDI Initial Context.
jboss-log4j.xml	Configuration log4j pour l'instance Jboss (couche de gestion des logs).
login-config.xml	Gestion des droits pour le module JAAS.
standardjboss.xml	Configuration du container EJB.
props	Répertoire contenant les comptes / groupes de gestion des droits pour le module JAAS.
xmdesc	Répertoire contenant les descripteurs XMBean pour les services configurés dans le fichier jboss-service.xml.

4. Répertoire <JBOSS_HOME>/lib/

JAR	Version	But
concurrent.jar	5.1.0.GA	Concurrent Programming in Java - concurrency library
dom4j.jar	1.6.1	dom4j : XML framework for Java
getopt.jar	5.1.0.GA
javassist.jar	3.9.0.GA	Modification du bytecode Java
jaxb-impl.jar	2.1.9	Java Architecture for XML Binding
jaxb-xjc.jar	2.1.9	Java Architecture for XML Binding
jboss-aop-asintegration-core.jar	2.1.1.GA	JBoss AOP AS Integration Core
jboss-aop-asintegration-jmx.jar	2.1.1.GA	JBoss AOP AS Integration JMX
jboss-aop-asintegration-mc.jar	2.1.1.GA	JBoss AOP AS Integration MC
jboss-aop-deployers.jar	2.1.1.GA	JBoss AOP Deployers
jboss-aop.jar	2.1.1.GA	JBoss AOP Framework
jboss-aop-jboss5.jar	1.3	JBoss AOP Aspect Library
jboss-aop-mc-int.jar	2.0.6.GA	JBoss Microcontainer AOP MC INT
jboss-bootstrap.jar	1.0.0-Beta-3	JBossAS Bootstrap
jboss-classloader.jar	2.0.6.GA	JBoss ClassLoader
jboss-classloading.jar	2.0.6.GA	JBoss ClassLoading
jboss-classloading-spi.jar	5.1.0.GA	JBoss ClassLoading 5.1.0 SPI
jboss-classloading-vfs.jar	2.0.6.GA	JBoss ClassLoading VFS
jboss-common-core.jar	2.2.14.GA	JBoss Common Classes
jboss-dependency.jar	2.0.6.GA	JBoss Microcontainer Dependency
jboss-deployers-client.jar	2.0.7.GA	JBoss Deployers Client
jboss-deployers-client-spi.jar	2.0.7.GA	JBoss Deployers Client SPI
jboss-deployers-core.jar	2.0.7.GA	JBoss Deployers Core
jboss-deployers-core-spi.jar	2.0.7.GA	JBoss Deployers Core SPI
jboss-deployers-impl.jar	2.0.7.GA	JBoss Deployers Impl
jboss-deployers-spi.jar	2.0.7.GA	JBoss Deployers SPI
jboss-deployers-structure-spi.jar	2.0.7.GA	JBoss Deployers Structure SPI
jboss-deployers-vfs.jar	2.0.7.GA	JBoss Deployers VFS
jboss-deployers-vfs-spi.jar	2.0.7.GA	JBoss Deployers VFS SPI
jboss-j2se.jar	5.1.0.GA	JBoss
jboss-jmx.jar	5.1.0.GA	JBoss
jboss-kernel.jar	2.0.6.GA	JBoss Microcontainer Kernel
jboss-logbridge.jar	5.1.0.GA	JBoss
jboss-logging-jdk.jar	2.1.0.GA	JBoss Logging JDK
jboss-logging-log4j.jar	2.1.0.GA	JBoss Logging Log4j
jboss-logging-spi.jar	2.1.0.GA	JBoss Logging Programming Interface
jboss-logmanager.jar	5.1.0.GA	JBoss
jboss-main.jar	5.1.0.GA	JBoss
jboss-managed.jar	2.1.0.SP1	JBoss Managed
jboss-mbeans.jar	5.1.0.GA	JBoss
jboss-mdr.jar	2.0.1.GA	JBoss MetaData Repository
jboss-metatype.jar	2.1.0.GA	JBoss Metatype
jboss-profileservice-spi.jar	5.1.0 SP1	JBoss ProfileService
jboss-reflect.jar	2.0.2.GA	JBoss Reflection
jboss-system.jar	5.1.0.GA	JBoss
jboss-system-jmx.jar	5.1.0.GA	JBoss
jboss-vfs.jar	2.1.2.GA	JBoss VFS
jboss-xml-binding.jar	2.0.1.GA	JBoss XML Binding
log4j-boot.jar	5.1.0.GA	JBoss
osgi.core.jar	5.1.0.GA	JBoss
trove.jar	1.0.2	GNU Trove for Java
wstx.jar	3.2.6	WoodSToX XML Processor (STAX)

5. Répertoire <JBOSS_HOME>/common/lib/

Jar	Version	But
antlr.jar	5.1.0.GA	un framework de construction de compilateurs
autonumber-plugin.jar	5.1.0.GA	Scheduler Varia
bcel.jar	5.1.0.GA	Apache Byte Code Engineering Library
bsf.jar	5.1.0.GA	Beans Scripting Framework
bsh.jar	5.1.0.GA	Beanshell Console
commons-collections.jar	3.1	Apache Commons Collections
commons-logging.jar	1.1.0	Apache Commons Logging
dtdparser121.jar	5.1.0.GA	DTD Parser
ejb3-persistence.jar	3.0	Enterprise JavaBeans
el-api.jar	5.1.0.GA	Unified Expression Language
hibernate-annotations.jar	3.4.0.GA	Hibernate
hibernate-commons-annotations.jar	3.1.0.GA	Hibernate
hibernate-core.jar	3.3.1.GA	Hibernate
hibernate-entitymanager.jar	3.4.0.GA	Hibernate
hibernate-jmx.jar	3.3.1.GA	Hibernate
hibernate-validator.jar	3.1.0.GA	Hibernate
hsqldb.jar
hsqldb-plugin.jar
jaxen.jar	1.1	Universal Java XPath Engine
jaxws-api.jar
jbossas-remoting.jar	5.1.0.GA	JBoss Remoting
jboss-common-jdbc-wrapper.jar	5.1.0.GA	JBoss
jboss-current-invocation-aspects.jar	1.0.0.GA	JBoss Current Invocation Aspects
jboss-ejb3-cache.jar	1.0.0	JBoss EJB 3.0 Cache
jboss-ejb3-common.jar	1.0.0	JBoss EJB 3.0 Common Utilities
jboss-ejb3-core.jar	1.1.5	JBoss EJB 3.0 Core
jboss-ejb3-deployers.jar	1.0.0	JBoss EJB3 Deployers
jboss-ejb3-endpoint.jar	0.1.0	JBoss EJB 3.x Endpoint SPI
jboss-ejb3-ext-api-impl.jar	1.0.0	JBoss EJB 3.0 Implementation Classes
jboss-ejb3-ext-api.jar	1.0.0	JBoss EJB 3.0 External API
jboss-ejb3-interceptors.jar	1.0.2	JBoss EJB 3.0 Interceptors
jboss-ejb3-mc-int.jar	1.0.1	JBoss EJB 3.x MicroContainer Integration
jboss-ejb3-metadata.jar	1.0.0	JBoss EJB 3.0 Meta Data bridge
jboss-ejb3-proxy-clustered.jar	1.0.1	JBoss EJB 3.0 Clustered Proxy
jboss-ejb3-proxy-impl.jar	1.0.2	JBoss EJB 3.x Proxy Implementation (Internals)
jboss-ejb3-proxy-spi.jar	1.0.0	JBoss EJB 3.x Proxy SPI
jboss-ejb3-security.jar	1.0.0	JBoss EJB 3.0 Security
jboss-ejb3-timerservice-spi.jar	1.0.0	JBoss EJB 3.x TimerService SPI
jboss-ejb3-transactions.jar	1.0.0	JBoss EJB 3.0 Transactions
jboss-ha-client.jar	1.1.1.GA	JBoss Cluster HA Client Classes
jbossha.jar	5.1.0.GA	JBoss High Availability (clustering)
jboss-ha-server-api.jar	1.1.1.GA	JBoss Cluster HA Server API Classes
jboss-ha-server-cache-jbc.jar	2.0.0.GA	JBoss Cache Integration Implementation
jboss-ha-server-cache-spi.jar	2.0.0.GA	JBoss Cache Integration SPI
jboss-hibernate.jar	5.1.0.GA
jboss-iiop.jar	5.1.0.GA
jboss-integration.jar	5.1.0.GA
jboss.jar	5.1.0.GA	JBoss
jboss-jaspi-api.jar	1.0.0.GA	JBoss Java Authentication SPI for Containers
jboss-javaee.jar	5.1.0.GA	JBoss
jboss-jca.jar		JBoss JCQ
jboss-jmx-remoting.jar	5.1.0.GA	JBoss Remoting
jboss-jpa-deployers.jar	1.0.0	JBoss Container Managed JPA Deployers
jboss-jsr77.jar	5.1.0.GA	JBoss (J2EE Management)
jboss-jsr88.jar	5.1.0.GA	JBoss (Java EE Application Deployment)
jbossjts-integration.jar
jbossjts-jacorb.jar
jbossjts.jar
jboss-management.jar	5.1.0.GA	JBoss
jboss-messaging-int.jar	5.1.0.GA	JBoss
jboss-messaging.jar	1.4.3.GA	JBoss Messaging
jboss-metadata.jar	1.0.1.GA	JBoss Metadata
jboss-monitoring.jar
jboss-negotiation.jar		JBoss Security, security for JEMS projects
jboss-profileservice.jar
jboss-remoting-aspects.jar	1.0.1.GA	JBoss Remoting Aspects
jboss-remoting.jar	2.5.1	JbossRemoting
jboss-security-aspects.jar	1.0.0.GA	JBoss Security Aspects
jboss-security-spi.jar	2.0.3.SP1	JBoss Security SPI
jboss-serialization.jar
jboss-srp.jar
jbosssx.jar	2.0.3.SP1	JBoss Security Extension Framework
jbosssx-server.jar		JBoss Security Extension Framework
jboss-threads.jar
jboss-transaction-aspects.jar	1.0.0.GA	JBoss Transaction Aspects
jbossts-common.jar
jbossws-common.jar	1.1.0.SP1	JBoss Web Services
jbossws-framework.jar	3.1.2.SP1	JBoss Web Services - Framework Parent
jbossws-spi.jar	1.1.2.GA
jbossxacml.jar	2.0.3	JBoss XACML
jmx-adaptor-plugin.jar
jnpserver.jar	5.0.3.GA	JBoss Naming Server
joesnmp.jar	0.3.4	joeSNMP
jsp-api.jar	5.1.0.GA	JBoss JSP API
jsr181-api.jar		Web Services MetaData
log4j.jar	1.2.14	Log4J
log4j-snmp-appender.jar
mail.jar	1.4	javax.mail
mail-plugin.jar
properties-plugin.jar	5.1.0.GA	JBoss Varia
quartz.jar	1.5.2	Quartz Enterprise Job Scheduler
saaj-api.jar
scheduler-plugin-example.jar
scheduler-plugin.jar
servlet-api.jar
slf4j-api.jar	1.5.6	Simple Logging Facade for Java
slf4j-jboss-logging.jar	1.0.2.GA	Simple Logging Facade for Java
stax-api.jar
xnio-api.jar	1.2.1.GA	XNIO API

6. Répertoire <JBOSS_HOME>/server/<INSTANCE>/deploy/

admin-console.war	Application web fournissant une console d'administration.
cache-invalidation-service.xml	Configuration du service permettant l'invalidation de cache via notifications JMS.
ejb2-container-jboss-beans.xml	Bean qui gère l'integration des UserTransaction pour EJB2.
ejb2-timer-service.xml	Beans qui gèrent le EJB Timer Service.
ejb3-connectors-jboss-beans.xml	Beans de transport pour EJB3 remoting.
ejb3-container-jboss-beans.xml	Bean qui gère l'integration des UserTransaction pour EJB3.
ejb3-interceptors-aop.xml	Configurations de pile d'intercepteur AOP pour les types bean EJB3.
ejb3-timerservice-jboss-beans.xml	Timer Service base sur Quartz.
hdscanner-jboss-beans.xml	Bean qui scanne le dossier de deploiement pour les deploiements à chaud.
hsqldb-ds.xml	Configuration du composant Hypersonic intégré à JBoss (base de données interne).
http-invoker.sar	Invoker RMI over HTTP. De plus, permet la consommation du JBoss JNDI en HTTP.
jboss-local-jdbc.rar	JCA resource adaptor pour les drivers JDBC ne supportant pas JCA mais supportant DataSource interface.
jbossweb.sar	JavaEE application container Tomcat.
jossws.sar	Web Service support.
jboss-xa-jdbc.rar	JCA resource adapter pour les drivers JDBC ne supportant pas JCA mais supportant XADataSource interface.
jca-jboss-beans.xml	JCA pour le serveur. Gestion des connections pour intégrer les Resource Adapter au serveur.
jms-ra.rar	jms-ra.rar est un adaptateur de ressources JCA pour les fabriques de connexions JMS.
jmx-console.war	Application web fournissant une console d'interaction avec le JMX Mbean Server (coeur JBoss).
jmx-invoker-service.xml	MBean pour permettre les acces RMI au fonctions du coeur JMX.
jmx-remoting.sar	Connecteur permettant l'interaction avec le JMX Mbean Server indépendamment du protocole.
jsr88-service.xml	Fournit le service de déploiement distant JSR 88.
juddi-service.sar	Services de recherche UDDI.
legacy-invokers-service.xml	Anciens services de remoting JMX.
mail-ra.rar	Java Mail Connecteur.
mail-service.xml	Configuration du bean fournissant le Java Mail Connecteur.
management	Contient les consoles d'administration web (admin console et web console).
messaging	Contient les composants de gestion des messages.
monitoring-service.xml	Configuration du monitoring pour les alertes JMX.
profileservice-jboss-beans.xml	Permet la gestion des ProfileService.
profileservice-secured.jar	Façon d'accéder au ProfileService avec une façade EJB sécurisée.
properties-service.xml	Descripteur de service MBean qui permet la personnalisation des PropertyEditors, des JavaBeans, de même que la définition des propriétés système.
quartz-ra.rar	Resource Adapter recevant les événements Quartz.
remoting-jboss-beans.xml	Les Unified Invoker de JBoss Remoting.
ROOT.war	L'application web '/'.
schedule-manager-service.xml, scheduler-service.xml	Configuration des services de scheduling.
security	Configuration de la sécurité des beans.
sqlexception-service.xml	Configuration du composant permettant la gestion des exceptions java.sql.SQLExceptions spécifiques aux vendeurs.
transaction-jboss-beans.xml	Beans associé avec JTA transaction manager.
transaction-service.xml	Configuration du service proxy ClientUserTransaction.
uuid-key-generator.sar	Composant de génération de clefs basé sur UUID.
vfs-jboss-beans.xml	Permet de verifier les statistiques de la cache VFS.
xnio-provider.jar	XNIO est une couche simplifiée pour Java NIO.

7. Répertoire <JBOSS_HOME>/server/<INSTANCE>/deploy/messaging/

connection-factories-service.xml	Configuration du connection factories.
destinations-service.xml	Configuration des destinations JMS DLQ et ExpiryQueue.
hsqldb-persistence-service.xml	Configuration de la base de données pour messaging. Par defaut HSQLDB.
jms-ds.xml	Configuration du JMSProviderLoader et JmsXA (inflow resource adapter).
legacy-service.xml	Configuration des anciens services JMS.
messaging-jboss-beans.xml	Configuration des beans Messaging de sécurité et management.
messaging-service.xml	Configuration du coeur du service JBoss Messaging.
remoting-bisocket-service.xml	Configuration de la couche du service Messaging remoting.

8. Répertoire <JBOSS_HOME>/server/<INSTANCE>/deploy/security/

security-jboss-beans.xml	Beans associé avec le domaine sécurité.
security-policies-jboss-beans.xml	Beans associé aux autorisations pour les accès web et EJB.

9. Répertoire <JBOSS_HOME>/server/<INSTANCE>/deployers/

alias-deployers-jboss-beans.xml
bsh.deployer	Composant Bean shell qui déploie des scripts en tant que services de JBoss.
clustering-deployer-jboss-beans.xml	Configuration des services permettant les déploiements des EJB en grappe.
dependency-deployers-jboss-beans.xml	Deployers pour aliases.txt et jboss-dependency.xml
directory-deployer-jboss-beans.xml	Permet le déploiement des répertoires. Désactivé par défaut.
ear-deployer-jboss-beans.xml	Configuration du service permettant les déploiements EAR.
ejb3.deployer	Composant permettant les déploiements EJB.
ejb-deployer-jboss-beans.xml	Configuration du service permettant les déploiements EJB (JAR).
jboss-aop-jboss5.deployer	Composant JBoss AOP applications.
hibernate-deployer-jboss-beans.xml	Permet le déploiement des fichiers *-hibernate.xml.
jboss-aop-jboss5.deployer	JbossAspectLibrary et Aspects de base.
jboss-ejb3-endpoint-deployer.jar	Permet le déploiement d'un Endpoint pour chaque conteneur session.
jboss-jca.deployer	Composant JCA permettant la gestion des connexions BD.
jboss-threads.deployer	Déploiement des services qui utilisent des Thread Pool.
jbossweb.deployer	Permet le déploiement des JavaEE 5 JSP, JSF et servlet.
jbossws.deployer	Permet le déploiement des Endpoint des services web.
jsr77-deployers-jboss-beans.xml	Permet le déploiement des composants JavaEE tant que JSR77 Mbean.
logbridge-jboss-beans.xml	Bean qui synchronise le niveau de log Java Logging avec Log4J chaque fois que le fichier <JBOSS_HOME>/conf/jboss-log4j.xml est modifié.
messaging-definitions-jboss-beans.xml	Permet la création des QueueService et des TopicService (QueueServiceMO et TopicServiceMO).
metadata-deployer-jboss-beans.xml	Deployers qui traitent des meta-données JavaEE de XML et des annotations.
seam.deployer	Permet le déploiement des applications Seam.
security-deployer-jboss-beans.xml	Permet le configuration des couches de sécurité des composants JavaEE.
webbeans.deployer	Composant permettant le déploiement des POJOs.
xnio.deployer	Permet le déploiement des applications qui utilisent XNIO directement.

JBoss5 et les Web Services

Il existe 3 implémentation de la stack Web Service pour JBoss 5.1.0 :
- JBossWS - Native (la stack par défaut),
- JBossWS - CXF,
- JBossWS - Metro.

Ces trois stack améliore la qualité et la performance de la consommation et de l'exposition des Web Services.

Séparation technique et applicative

La séparation des fichiers techniques et applicatifs dans JBoss peut simplifier la répartition des rôles en entreprise.
La séparation s'applique à :
- les applications (ear / war) déployées par défaut dans le répertoire /deploy,
- les librairies (jar) déployées par défaut dans le répertoire /lib,
- la déclaration des datasources (xml),
- la configuration applicative (xml) déployées en général dans le répertoire /conf,
- la configuration des logs applicatives (jboss-log4j.xml).

1. Séparation des applications et des datasources

Pour que jboss prenne en compte un répertoire applicatif spécifique, il faut ajouter le répertoire dans le chemin de déploiement du moteur. Il faut donc ajouter la ligne en gras dans le fichier /conf/bootstrap/profile.xml :

<bean name="BootstrapProfileFactory" class="org.jboss.system.server.profileservice.repository.StaticProfileFactory">
    <property name="bindingsURI">${jboss.server.home.url}conf/bindingservice.beans</property>
    <property name="bootstrapURI">${jboss.server.home.url}conf/jboss-service.xml</property>
    <property name="deployersURI">${jboss.server.home.url}deployers</property>
    <property name="applicationURIs">
        <list elementClass="java.net.URI">
            <value>${jboss.server.home.url}deploy</value>
            <value>${jboss.server.home.url}deployappli</value>
        </list>
    </property>
    <property name="attachmentStoreRoot">${jboss.server.data.dir}/attachments</property>
    <property name="profileFactory"><inject bean="ProfileFactory"/></property>
</bean>

Il est alors possible de créer un répertoire deployappli dans <JBoss Home>/server/<instance>/ et d'y déposer les applications et datasources.

2. Séparation des librairies

Pour que JBoss prenne en compte un répertoire de librairies spécifique, il faut ajouter le répertoire dans le classpath de la JVM. Il faut donc ajouter la ligne en gras dans le fichier /conf/jboss-service.xml :

<classpath codebase="libappli" archives="*"/>

Il est alors possible de créer un répertoire libappli dans <JBoss Home>/server/<instance>/ et d'y déposer les jar applicatifs.

3. Séparation des configurations applicatives

Le chargement des fichiers de configuration applicative se fait directement dans le code de l'application.
Il suffit que le répertoire de configuration spécifique appartienne au classpath de la JVM. Il faut donc ajouter la ligne en gras dans le fichier /conf/jboss-service.xml :

<classpath codebase="confappli" archives="*"/>

Il est alors possible de créer un répertoire confappli dans <JBoss Home>/server/<instance>/ et d'y déposer fichiers de configuration applicatifs.

4. Séparation des configurations de logs

Le chargement de la configuration log4j se fait dans le code de l'application. Il suffit que le répertoire contenant la configuration log4j (confappli dans notre exemple) soit dans le classpath (comme décrit ci dessus).

<classpath codebase="logappli" archives="*"/>

Démarrage et options de la JVM

1. Chargement spécifique de configuration

Le chargement d'options spécifiques pour la JVM peut se faire par le biais du script de démarrage et de fichiers de configuration dans le répertoire <JBoss_Home>/bin.
La commande de démarrage de JBoss peut ainsi contenir l'option -c <fichier de configuration spécifique à l'instance>.
Ex :

JBOSSSH=${JBOSSSH:-"export RUN_CONF=${JBOSS_HOME}/bin/run_${JBOSS_SRV}.conf; $JBOSS_HOME/bin/$RUNSH -c $JBOSS_CONF -b $JBOSS_HOST"}

Les fichiers de configuration peuvent ainsi être stockés dans le répertoire bin de jboss qui contient déjà des fichiers de configuration de la JVM (ex : run.conf).
Il est possible de dupliquer le fichier run.conf et de le configurer spécifiquement pour l'instance JBoss.

2. Options "classiques" de la JVM

Mémoire globale de la JVM : Xms et Xmx

La mémoire globale de la JVM est configurée avec les options Xms et Xmx.
L'option Xms indique à la JVM (et donc à JBoss) la quantité de mémoire à réserver dès le démarrage.
L'option Xmx indique à la JVM (et donc à JBoss) la quantité de mémoire à maximum qu'elle peut utiliser.
Il faut noter que la JVM ne libère jamais au système de la mémoire réservée. a quantité de mémoire réservée est donc une valeur qui ne peut décroitre.

Mémoire de chargement : XX:PermSize et XX:MaxPermSize

Le processus de chargement / déchargement d'application et de librairies utilise une zone mémoire spécifique de la JVM. Cette zone mémoire est définie au démarrage du serveur d'application à l'aide des paramètres -XX:PermSize et -XX:MaxPermSize.
La version de l'environnement java (JRE) est la 1.6.0 en production. La mémoire par défaut allouée pour ce processus de chargement (pour cette version de JRE) est de 16MB pour le PermSize et 64MB pour le MaxPermSize.
Suivant les technologies utilisées pour le développement des applications et leur cycle de vie, il peut être nécessaire d'augmenter ces valeurs.
Cette zone de la mémoire permanente (PermGen) peut facilement se remplir. Il y a deux causes à cela :
1. Les mécanismes d'interception impliquent généralement la génération de classes (.class) par des bibliothèques particulières (ex: Hibernate utilise sont propre Class Loader). Ces classes sont instanciées dans la mémoire permanente. Par défaut, ces classes ne sont pas "vidées". La JVM peut effectuer des déchargements et du nettoyage des objets créés par les mécanismes d'interception si l'option suivante est passée : -XX:+CMSClassUnloadingEnabled
2. Les références fortes (Strong Reference) vers des classes chargées peuvent causer l'impossibilité de nettoyage de celle ci. Ce genre de référence apparaissent dans le cas d'erreur de développement. Par exemple, le déploiement à chaud provoque l'instanciation d'un nouveau ClassLoader et le chargement de nouvelles classes dans la mémoire permanente. Si du code applicatif fait référence vers une classe chargée par le ClassLoader du serveur, le ClassLoader de l'application ne peut pas être ramassé par le ramasse miettes (référence forte entre le ClassLoader du serveur et le ClassLoader de l'application). Un autre exemple est le non nettoyage applicatif de références vers des méthodes ou des variables statiques. Il faut alors revoir le code.

Garbage Collector

La JVM inclut trois ramasse miettes, chacun avec des caractéristiques de performance différentes.

Le serial collector utilise un thread unique pour faire son travail, ce qui le rend relativement efficace puisqu'il n'y a pas de communication entre threads. Il est le mieux adapté aux machines à processeur unique (puisqu'un GC multi thread ne pourrait pas profiter de plusieurs coeurs) et à des applications avec des ensembles de données de petite taille (jusqu'à environ 100 Mo).
Le collecteur en série est sélectionnée par défaut sur certains matériels et certaines configurations du système d'exploitation. Il peut être explicitement activé avec l'option -XX:+UseSerialGC

Le parallel collector (également appelé throughput collector) effectue certaines collectes en parallèle. Il est destiné aux applications avec des ensembles de données de moyenne à grande taille qui sont exécutées sur plusieurs processeurs ou sur du hardware multi-thread.
Le compactage parallèle est une fonctionnalité introduite dans J2SE 5.0 Update 6 et renforcée dans Java SE 6. Il permet au parallel collector d'exercer d'importantes collections en parallèle. Sans ce compactage parallèle, les importantes collectes sont réalisées en utilisant un seul thread. Le compactage parallèle est activé en ajoutant l'option -XX:+UseParallelOldGC
Le parallel collector est sélectionné par défaut sur certains matériels et certaines configurations du système d'exploitation. Il peut être explicitement activé avec l'option -XX:+UseParallelGC

Le concurrent collector effectue la plupart de ses travaux en même temps (par exemple, pendant que la demande est encore en cours d'exécution) de facon à minimiser les temps de pause pour les collectes. Il est destiné aux applications avec des ensembles de données de moyenne à grande taille pour lesquels le temps de réponse est plus important que le débit global, puisque les techniques utilisées pour minimiser les pauses peuvent réduire les performances des applications.
Le concurrent collector est activé avec l'option -XX:+UseConcMarkSweepGC

Répertoire temporaire :

Par défaut, le répertoire temporaire de la JVM est le répertoire bin de JBoss. Il est donc préférable de modifier cette configuration au niveau des paramètres de la JVM :
-Djava.io.tmpdir=<JBOSS_HOME>/server/<INSTANCE>/tmp

Mode debug :

Les options suivantes permettent d'ouvrir un connecteur JBoss permettant le debug à distance (notamment dans Eclipse) :
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=<port>

Gestion des ports

1. Description des ports par défaut

1099	JNDI standard
1098	JNDI / RMI
1090	Remoting JMX (utilisé par le Unified Invoker)
4444	JRMPInvoker (invoker standard)
4445	PooledInvoker
4446	Unified Invoker
3873	EJB3 Invoker
8080	Connecteur HTTP Tomcat
8009	Connecteur AJP Tomcat
8083	Chargement de classes à distance via http (WebService)
8093	Connecteur JMS

2. Gestion du binding multi instances

La version JBoss 5.1.0 apporte une nouvelle méthodologie de gestion de la gestion des ports.
Plutôt que de définir l'ensemble des ports pour chaque instance, il est possible de définir un incrément pour chaque instance, incrément qui s'applique à l'ensemble des ports par défaut.
Cette configuration se met en place dans le fichier de configuration <JBOSS_HOME>/server/<INSTANCE>/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml :

...
<constructor>

<parameter>${jboss.service.binding.set:jbossports}</parameter>

<parameter>
<set>
<inject bean="PortsBindings"/>
</set>
</parameter>

<parameter><inject bean="StandardBindings"/></parameter>
</constructor>
</bean>

<bean name="PortsBindings" class="org.jboss.services.binding.impl.ServiceBindingSet">
<constructor>

<parameter>ports-default</parameter>

<parameter>${jboss.bind.address}</parameter>

<parameter>100</parameter>

<parameter><null/></parameter>
</constructor>
</bean>
...

A la génération de l'instance, il faut venir remplir la valeur de l'attribut parameter (100 dans l'exemple).

Sécurité de JBoss

1. Sécurisation des consoles

Rappel sur les services techniques JBoss

L'architecture d'un serveur JBoss est structurée en couches :
- les Mbeans qui sont des objets représentant les ressources, chaque Mbean proposant des méthodes permettant de contrôler la ressource associée,
- le Mbean Server qui fournit aux interfaces d'administration les méthodes des différents Mbeans disponibles. Toute interaction avec un MBean passe par le MBean Server. Il permet de gérer toutes les ressources (MBeans) disponibles.

Il existe notamment des MBeans permettant de gérer les mécanismes d'authentification des applications hébergées. D'autres permettent le déploiement d'application au format .war, .jar ou .sar par exemple.

Pour communiquer avec le MBean Server, JBoss propose plusieurs interfaces d'administration. JBoss dénombre 4 interfaces d'administration :
- l'ADMIN console, disponible depuis JBoss 5, qui réunit les fonctionnalités principales de la JMX console et la web console; elle est très utile notamment pour le déploiement d'applications à distance sur le serveur,
- la JMX console, la plus connue et la cible privilégiée des pirates puisqu'elle permet d'interagir graphiquement avec le Mbean Server et donc l'ensemble des Mbeans,
- la WEB console qui permet, théoriquement, de n'obtenir que des informations concernant la configuration du serveur,
- la console TOMCAT-STATUS qui permet de voir le status du serveur d'application Tomcat,
- le JMX-INVOKER (JRMP - Java Remote Method Protocol - sur le port 4444) qui permet d'interagir par RMI avec le MBean Server,
- la JBOSSWS console qui permet de visualiser les web services déployés.

Les différentes consoles JBoss sont accessibles par défaut sur l'URL http://<serveur>:<port http>/ :
Console management JBoss

L'outil twiddle permettant l'interaction avec le JMX-INVOKER est présent dans le répertoire <JBOSS_HOME>/server/bin/twiddle.sh.

Sécuriser la console d'administration

La console d'administration de JBoss est sécurisée par défaut. La sécurisation est faite dans le fichier :
<JBOSS_HOME>/server/<INSTANCE>/deploy/admin-console.war/WEB-INF/jboss-web.xml

Sécuriser la console JMX

Pour se connecter à la console JMX (http://<serveur>:<port http>/jmx-console/), il est possible d'imposer la fourniture d'un compte d'administration.

L'activation de cette authentification se fait en dé-commentant les sections des fichiers suivants :
<JBOSS_HOME>/server/<INSTANCE>/deploy/jmx-console.war/WEB-INF/jboss-web.xml

<!DOCTYPE jboss-web PUBLIC
"-//JBoss//DTD Web Application 5.0//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">

<jboss-web>
<security-domain>java:/jaas/jmx-console</security-domain>
</jboss-web>

<JBOSS_HOME>/server/<INSTANCE>/deploy/jmx-console.war/WEB-INF/web.xml

...
<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML JMX console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>

Sécuriser la Web Console JBoss

Pour se connecter à la WEB console JBoss (http://<serveur>:<port http>/web-console/), il est possible d'imposer la fourniture d'un compte d'administration.

L'activation de cette authentification se fait en dé-commentant la section du fichier suivant :
<JBOSS_HOME>/server/<INSTANCE>/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml

<!DOCTYPE jboss-web
PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd">

<jboss-web>
<security-domain>java:/jaas/jmx-console</security-domain>

<depends>jboss.admin:service=PluginManager</depends>
</jboss-web>

On notera que pour centraliser la gestion des comptes d'administration, on a remplacer le security-domain pour indiquer la valeur jmx-console (à la place de web-console).

Puis il faut décommenter la section suivante :
<JBOSS_HOME>/server/<INSTANCE>/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml

<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML JMX console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>

Sécuriser l'accès au Tomcat status

Pour se connecter à la console Tomcat (http://<serveur>:<port http>/status/), il est possible d'imposer la fourniture d'un compte d'administration.

L'activation de cette authentification se fait en créant le fichier :
<JBOSS_HOME>/server/<INSTANCE>/deploy/ROOT.war/WEB-INF/jboss-web.xml

Et en ajoutant les lignes suivantes à la fin du fichier (dans le tag <web-app>) :
<JBOSS_HOME>/server/<INSTANCE>/deploy/ROOT.war/WEB-INF/web.xml

... <security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the status application
</description>
<url-pattern>/status</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>JBoss Status</realm-name>
</login-config>

<security-role>
<role-name>JBossAdmin</role-name>
</security-role>
<web-app>

Sécuriser la JBOSSWS console

Pour se connecter à la JBoss web service console (http://<serveur>:<port http>/jbossws/), il est possible d'imposer la fourniture d'un compte d'administration.

L'activation de cette authentification se fait en décommentant et en corrigeant la section du fichier (on passe sur le security domain global):
<JBOSS_HOME>/server/<INSTANCE>/deploy/jbossws.sar/jbossws-management.war/WEB-INF/jboss-web.xml

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE jboss-web
PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd">

<jboss-web>

<security-domain>java:/jaas/jmx-console</security-domain>
<context-root>jbossws</context-root>

</jboss-web>

Et en ajoutant les lignes suivantes à la fin du fichier (dans le tag <web-app>) :
<JBOSS_HOME>/server/<INSTANCE>/deploy/jbossws.sar/jbossws-management.war/WEB-INF/web.xml

...
<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JbossAdmin to access the status application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>

<login-config>
<auth-method>BASIC</auth-method>
<realm-name>JBoss Status</realm-name>
</login-config>

<security-role>
<role-name>JBossAdmin</role-name>
</security-role>
<web-app>

Sécuriser le jmx-invoker

Les accès via RMI et twiddle passent par le jmx-invoker. Pour le sécuriser, il est possible d'imposer la fourniture d'un compte d'administration.

L'activation de cette authentification se fait en dé-commentant la section du fichier suivant :
<JBOSS_HOME>/server/<INSTANCE>/deploy/jmx-invoker-service.xml

<descriptors>
<interceptors>
<interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
securityDomain="java:/jaas/jmx-console"/>
</interceptors>
</descriptors>

Une fois cette partie activée, les accès par script (twiddle ou shutdown) nécessitent de renseigner les arguments -u et -p.

Définition des comptes d'accès

L'ensemble des AuthenticationInterceptor ayant étaient configurés sur le securityDomain Java:/jaas/jmx-console, les comptes d'accès sont configurés pour l'ensemble des interfaces de JBoss :
- console d'administration,
- console JMX,
- web console,
- Tomcat status,
- web services console.

Pour se connecter à la console JMX (http://<serveur>:<port http>/jmx-console/) et à la console d'administration JBoss (http://<serveur>:<port http>/admin-console/), il est possible de définir des comptes d'accès.

La modification du mot de passe se fait dans le fichier suivant :
<JBOSS_HOME>/server/<INSTANCE>/conf/props/jmx-console-users.properties

# A sample users.properties file for use with the UsersRolesLoginModule
<user>=<password>

Pour information, le lien entre le secutiryDomain et le fichier de configuration se fait dans la section suivante :
<JBOSS_HOME>/server/<INSTANCE>/conf/login-config.xml

<application-policy name="jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>

2. Sécurisation du Detached Invoker

Choix du Detached Invoker

Il existe plusieurs Detached Invoker embarqués dans JBoss permettant l'inter action avec le Mbean server :
- le JRMP Invoker (RMI over JRMP),
- le Pooled Invoker (RMI over socket layer),
- le HTTP Invoker (RMI over HTTP),
- le Unified Invoker (RMI over socket / sslsocket / bisocket / sslbisocket / http / https / jrmp / ssljrmp / servlet / sslservlet). Validé en EJB3.

Ces invokers sont utilisés dans JBoss pour :
- l'invoker JMX,
- la console de management JBoss - JOPR,
- les exe twiddle.sh et shutdown.sh,
- la gestion des EJB2 (naming et invocation).

Ces invokers permettent d'interagir avec le Mbean Server et sont accessibles en dehors du moteur JBoss sur les ports sur lesquels ils sont bindés. Il faut donc sécuriser l'accès à ces invokers.

Pour sécuriser la partie Remote Invoker, il a été décidé de garder uniquement le Unified Invoker.

Une autre solution aurait été de n'utiliser que le HTTP Invoker. Celle ci est décrite dans l'annexe 3.
Une dernière solution aurait été de n'utiliser que le Pooled Invoker (socket multi threadé). Celle ci est décrite dans l'annexe 4.

La configuration du Unified Invoker est décrite ci dessous. La suppression des autres Detached Invoker est décrite dans le chapitre Tuning JBoss.

Configuration du Unified Invoker

Pour améliorer la sécurité du service JBoss, il est possible de binder le Detached Unified Invoker en localhost, de manière à ce que les actions d'administration sur le serveur par le biais des commandes twiddle.sh et shutdown.sh ne puissent être réalisée que depuis le serveur.

Pour ce faire, il faut modifier la section suivante dans le fichier :
<JBOSS_HOME>/server/<INSTANCE>/deploy/remoting-jboss-beans.xml

<bean name="UnifiedInvokerConnector" class="org.jboss.remoting.transport.Connector">
<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX (name="jboss.remoting:service=Connector,transport=socket", exposedInterface=org.jboss.remoting.transport.ConnectorMBean.class,registerDirectly=true)</annotation>
<property name="serverConfiguration"><inject bean="UnifiedInvokerConfiguration"/></property>
</bean>


<bean name="UnifiedInvokerConfiguration" class="org.jboss.remoting.ServerConfiguration">
<constructor>

<parameter>socket</parameter>
</constructor>


<property name="invokerLocatorParameters">
<map keyClass="java.lang.String" valueClass="java.lang.String">
<entry>
<key>serverBindAddress</key>
<value>
<value-factory bean="ServiceBindingManager" method="getStringBinding">
<parameter>UnifiedInvokerConnector</parameter>
<parameter>localhost</parameter>

</value-factory>
</value>
</entry>

De plus, il faut configurer le JMX Invoker pour qu'il utilise le Unified Invoker.
Pour ce faire, il faut modifier la section du fichier suivant :
<JBOSS_HOME>/server/<INSTANCE>/deploy/jmx-invoker-service.xml

<mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory"
name="jboss.jmx:type=adaptor,name=Invoker,protocol=jrmp,service=proxyFactory">

<depends optional-attribute-name="InvokerName">jboss:service=invoker,type=unified</depends>

<depends optional-attribute-name="TargetName">jboss.jmx:type=adaptor,name=Invoker</depends>

<attribute name="JndiName">jmx/invoker/RMIAdaptor</attribute>

<attribute name="ExportedInterfaces">org.jboss.jmx.adaptor.rmi.RMIAdaptor,
org.jboss.jmx.adaptor.rmi.RMIAdaptorExt
</attribute>
<attribute name="ClientInterceptors">
<interceptors>
<interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor>
<interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
<interceptor>org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor</interceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
</interceptors>
</attribute>
<depends>jboss:service=Naming</depends>
</mbean>

Slimming de JBoss

1. HTTP Class Loader

Le service http class loader permet de charger à distance des classes via HTTP.

Pour supprimer ce service, il faut supprimer la section dans le fichier :
<JBOSS_HOME>/server/<INSTANCE>/conf/jboss-service.xml

<mbean code="org.jboss.web.WebService"
name="jboss:service=WebService">

<attribute name="BindAddress">

<value-factory bean="ServiceBindingManager" method="getStringBinding" parameter="jboss:service=WebService"/>
</attribute>
<attribute name="Port">

<value-factory bean="ServiceBindingManager" method="getIntBinding" parameter="jboss:service=WebService"/>
</attribute>

<attribute name="Host">${java.rmi.server.hostname}</attribute>

<attribute name="DownloadServerClasses">true</attribute>

<attribute name="DownloadResources">false</attribute>


<depends optional-attribute-name="ThreadPool"
proxy-type="attribute">jboss.system:service=ThreadPool</depends>
</mbean>

De plus, il faut supprimer les dépendances :
<JBOSS_HOME>/server/<INSTANCE>/deployers/ejb-deployer-jboss-beans.xml

<property name="webServiceName">jboss:service=WebService</property>

<JBOSS_HOME>/server/<INSTANCE>/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml

<bean class="org.jboss.services.binding.ServiceBindingMetadata">
<property name="serviceName">jboss:service=WebService</property>
<property name="port">8083</property>
<property name="description">Socket for dynamic class and resource loading</property>
</bean>

2. Suppression des Invoker

Les Invokers sont un façon d'appeler des méthodes des autres MBean, indépendamment d'un protocole spécifique. Il est donc pertinent de supprimer les Invoker qui donnent acces aux Mbean sur les protocoles non-utilisés.

Suppression du JRMP Invoker

La suppression de cet Invoker se fait en supprimant le MBean associée du fichier :
<JBOSS_HOME>/server/<INSTANCE>/deploy/legacy-invokers-service.xml

<mbean code="org.jboss.invocation.jrmp.server.JRMPInvoker"
name="jboss:service=invoker,type=jrmp,host=localhost">
<attribute name="RMIObjectPort">
<value-factory bean="ServiceBindingManager" method="getIntBinding" parameter="jboss:service=invoker,type=jrmp"/>
</attribute>
<attribute name="ServerAddress">
<value-factory bean="ServiceBindingManager" method="getStringBinding" parameter="jboss:service=invoker,type=jrmp"/>
</attribute>

<depends>jboss:service=TransactionManager</depends>
</mbean>

Suppression du Pooled Invoker

La suppression de cet Invoker se fait en supprimant le mbean associée du fichier :
<JBOSS_HOME>/server/<INSTANCE>/deploy/legacy-invokers-service.xml

<mbean code="org.jboss.invocation.pooled.server.PooledInvoker"
name="jboss:service=invoker,type=pooled">
<attribute name="NumAcceptThreads">1</attribute>
<attribute name="MaxPoolSize">300</attribute>
<attribute name="ClientMaxPoolSize">300</attribute>
<attribute name="SocketTimeout">300000</attribute>
<attribute name="ServerBindAddress">
<value-factory bean="ServiceBindingManager" method="getStringBinding" parameter="jboss:service=invoker,type=pooled"/>
</attribute>
<attribute name="ServerBindPort">
<value-factory bean="ServiceBindingManager" method="getIntBinding" parameter="jboss:service=invoker,type=pooled"/>
</attribute>
<attribute name="ClientConnectAddress">
<value-factory bean="ServiceBindingManager" method="getStringBinding" parameter="jboss:service=invoker,type=pooled"/>
</attribute>
<attribute name="ClientConnectPort">0</attribute>
<attribute name="ClientRetryCount">1</attribute>
<attribute name="EnableTcpNoDelay">false</attribute>


<depends optional-attribute-name="TransactionManagerService">jboss:service=TransactionManager</depends>
</mbean>

Suppression du HTTP Invoker

Le httpd invoker permet de passer des ordres au Mbean Server sur le protocole HTTP. Il permet d'inter-agir avec les Beans JMX, JNDI, EJB2 et JMS.

cd <JBOSS_HOME>/server/<INSTANCE>/deploy/
rm -Rf http-invoker.sar

3. ClientUserTransaction

Le service ClientUserTransaction fournisse les transactions JBoss aux clients autonomes par JNDI.

cd <JBOSS_HOME>/server/<INSTANCE>/deploy/
rm transaction-service.xml

4. Suppression du BSH Deployer

Le BSH Deployer permet d'utiliser les scriptes BSH comme des services JBoss. Pour le supprimer, il faut :

cd <JBOSS_HOME>/server/<INSTANCE>/deployers/
rm -Rf bsh.deployer

5. Suppression du XNIO

XNIO est une couche de JBoss qui simplifie la couche Java NIO.

cd <JBOSS_HOME>/server/<INSTANCE>/deployers/
rm -Rf xnio.deployer
cd ../deploy/
rm -Rf xnio-provider.jar

6. Suppression du jUDDI

L'annuaire UDDI (Universal Description Discovery and Integration) est un façon de chercher les services web, fondé sur XML.

cd <JBOSS_HOME>/server/<INSTANCE>/deploy/
rm -Rf juddi-service.sar

7. Suppression du Key Generator

Si le génération des clés unique n'est pas utilisé, le Key Generator peut être supprimé.

cd <JBOSS_HOME>/server/<INSTANCE>/deploy/
rm -Rf uuid-key-generator.sar

8. Suppression des services EJB2

Si il n'est pas utilisé, le conteneur EJB2 peut être supprimé.

cd <JBOSS_HOME>/server/<INSTANCE>/deploy/
rm ejb2-container-jboss-beans.xml

9. Suppression de SQL Exception Service

Suppression du gestion des exceptions SQL spécifiques au fournisseur :

cd <JBOSS_HOME>/server/<INSTANCE>/deploy/
rm sqlexception-service.xml

10. Remote JMX Connector

L'accès à distance à JMX n'est pas toujours utilisé dans les systèmes. Il peut être supprimé :

deploy/jmx-remoting.sar/META-INF/jboss-service.xml
deploy/jmx-remoting.sar

11. JBoss Web Server

JBoss Web Server (une version de Tomcat modifié) utilise les Connectors pour AJP et HTTP. Pour production, il faut faire les modifications suivantes :
<JBOSS_HOME>/server/<INSTANCE>/deploy/jbossweb.sar/server.xml

Les modifications sont descrites ci-dessous:

Option	Nouvelle valeur	Description
redirectPort	supprimiée	Supprime la rédirection de demandes sécurisés
enableLookups	false	Supprime le lookup de chaque hôte quand request.getRemoteHost() est appellé
request.registerRequests	false	Supprime le monitoring JMX du Connector
emptySessionPath	true	Tous chemins pour les session cookies seront mis à /
maxThreads	250	Limite de threads pour traiter les demandes
maxHttpHeaderSize	8192	Taille maximale des request et reponses de l'en-tête HTTP
connectionTimeout	20000	Nombre de milliseconds le Connector attendra pour le request URI

12. Autres possibilités pour slimming

Les jar suivants peuvent probablement être supprimé du répertoire common/lib :

bsf.jar
bsh.jar
jboss-ha-server-cache-jbc.jar
jboss-jmx-remoting.jar
jboss-remoting-aspects.jar
jbossas-remoting.jar
mail-plugin.jar & mail-service.xml et mail-ra.xml de deploy
mail.jar
scheduler-plugin-example.jar

Le fichier deploy/schedule-manager-service.xml est completement commenté.

Tuning de JBoss

1. Turn Off JCA Debugging

Le CachedConnectionManager vérifie par défaut que des connections JCA sont fermés après usage. Pour l'éteindre, il faut modifier la section suivante dans le fichier :
<JBOSS_HOME>/server/<INSTANCE>/deploy/jca-jboss-beans.xml

<bean name="CachedConnectionManager" class="org.jboss.resource.connectionmanager.CachedConnectionManager">


<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.jca:service=CachedConnectionManager", exposedInterface=org.jboss.resource.connectionmanager.CachedConnectionManagerMBean.class)</annotation>


<property name="debug">false</property>


<property name="error">false</property>


<property name="transactionManager"><inject bean="TransactionManager" property="transactionManager"/></property>

</bean>

2. Configuration de JBoss Web Server

Jasper Compiler

Il y a plusieurs options pour modifier le fonctionnement du compilateur des JSP. La modification de ces options se fait dans le fichier suivant (dans le tag <servlet> pour le servlet "jsp" de classe org.apache.jasper.servlet.JspServlet):
<JBOSS_HOME>/server/<INSTANCE>/deployers/jbossweb.deployer/web.xml

Pour chaque valeur, soit modifier le paramètre existant, soit ajouter une nouvelle entrée dans le style suivant :

<init-param>
<param-name><paramètre></param-name>
<param-value><valeur></param-value>
</init-param>

Paramètre	Nouvelle valeur	Description
development	false	Désactive le rechargement automatique des pages JSP
suppressSmap	true	Suppression de la génération d'un "source map", qui associe les numéros de ligne avec le code JSP
genStrAsCharArray	true	Les String sont déclarés sous forme de static char[] : static char[] char_array_1 = "string".toCharArray(); Ils sont utilisés : out.write(char_array_1); qui évite un appel implicite à toCharArray() chaque fois que le String est utilisé : out.write(someString);
classdebuginfo	false	Suppression de la génération des informations supplémentaires pour le débogage. Ca rend plus rapide la compilation des pages JSP.

Configuration du pool de threads HTTP & AJP

Modifier le fichier <JBOSS_HOME>/server/<INSTANCE>/deploy/jbossweb.sar/server.xml.
Pour les Connectors HTTP/1.1 et AJP/1.3 ajouter ou modifier le paramètre maxThreads - une limite 250 * le nombre de CPU dans le serveur est souvent correcte, mais il faut faire des essais pour trouver une bonne limite.

3. Configuration du pool de threads JNDI : System Thread Pool

Ce pool de threads est utilisé pour le traitement des requêtes JNDI.
La configuration se fait dans le fichier de configuration :
<JBOSS_HOME>/server/<INSTANCE>/conf/jboss-service.xml

4. Configuration du pool de threads JMX : Unified Invoker Thread Pool

Ce pool de threads est utilisé pour le traitement des requêtes JMX.
La configuration du pool de threads du JMX Unified Invoker se fait dans le fichier de configuration :
<JBOSS_HOME>/server/<INSTANCE>/deploy/remoting-jboss-beans.xml

5. Configuration du pool de threads JCA : WorkManager Thread Pool

Ce pool de threads est utilisé pour le traitement des interfaces externes (Message Driver Bean / JMS / Hibernate).
La configuration du pool de threads du WorkManager se fait dans le fichier de configuration :
<JBOSS_HOME>/server/<INSTANCE>/deploy/jca-jboss-beans.xml

6. Configuration du pool de threads JMS : Messaging Thread Pool

Ce pool de threads est utilisé pour le traitement des messages JMS.
La configuration du pool de threads Messaging se fait dans le fichier de configuration :
<JBOSS_HOME>/server/<INSTANCE>/deploy/messaging/remoting-bisocket-service.xml

7. Configuration du pool de threads EJB3

Ce pool de threads est utilisé pour le traitement des requêtes EJB3.
La configuration du pool de threads se fait dans le fichier de configuration :
<JBOSS_HOME>/server/<INSTANCE>/deploy/ejb3-interceptors-aop.xml

8. Configuration de la mémoire

La configuration de la mémoire allouée à JBoss se fait dans les options de la JVM.
Elle est décrite dans le chapitre Démarrage et options de la JVM.

9. Remplacement de HsqlBD (base de données intégrée à JBoss) par Oracle

HsqlDB est une base de données qui n'est pas conseillé pour la production; il est donc nécessaire de supprimer HsqlDB du système et d'utiliser une autre base de données. Parce que plusieurs composants du serveur JBoss s'appuyer sur HsqlDB, il faut s'assurer que ces composants peuvent toujours fonctionner.

1. Supprimer les fichiers suivants :
a. <JBOSS_HOME>/common/lib/hsqldb.jar
b. <JBOSS_HOME>/common/lib/hsqldb-plugin.jar
2. Copier les jar nécessaires pour la base de données souhaité dans <JBOSS_HOME>/server/<INSTANCE>/lib/
3. Créer un nouveau schéma et donner les droits aux utilisateurs nécessaires
4. Modifier le fichier suivant (en modifiant le tag appelé "<application-policy name= "HsqlDbRealm"> ") :
<JBOSS_HOME>/server/<INSTANCE>/conf/login-config.xml

<application-policy name="OracleDbRealm">
<authentication>
<login-module code="org.jboss.resource.security.ConfiguredIdentityLoginModule" flag="required">
<module-option name="principal"><principal></module-option>
<module-option name="userName"><utilisateur></module-option>
<module-option name="password"><mot-de-passe></module-option>
<module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>
</login-module>
</authentication>
</application-policy>

5. Supprimer le fichier <JBOSS_HOME>/server/<INSTANCE>/deploy/hsqldb-ds.xml
6. Créer un nouveau fichier dans <JBOSS_HOME>/server/<INSTANCE>/deploy/ en utilisant les examples en <JBOSS_HOME>/docs/examples/jca. Le nouveau fichier doit être nommé *-ds.xml
7. Modifier ce nouveau fichier en ajoutant (dans le tag <local-tx-datasource>). Le valeur de <security-domain> doit être le pareil que dans <JBOSS_HOME>/server/<INSTANCE>/conf/login-config.xml :

<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<security-domain>OracleDbRealm</security-domain>

8. Modifier le fichier suivant. Dé-commenter le tag <datasource-mapping/> et changer le valeur du tag au valeur correcte. De plus, changer le valeur de <fk-constraint/> à true.
<JBOSS_HOME>/server/<INSTANCE>>conf/standardjbosscmp-jdbc.xml

<defaults>
<datasource>java:/DefaultDS</datasource>
<datasource-mapping>Oracle9i</datasource-mapping>

<create-table>true</create-table>
<remove-table>false</remove-table>
<read-only>false</read-only>
<read-time-out><00000</read-time-out>
<row-locking>false</row-locking>
<pk-constraint>true</pk-constraint>
<fk-constraint>true</fk-constraint>
... </defaults>

9. Supprimer <JBOSS_HOME>/server/<INSTANCE>/deploy/messaging/hsqldb-persistence-service.xml
10. Créer un nouveau fichier dans <JBOSS_HOME>/server/<INSTANCE>/deploy/messaging/ en utilisant les examples en <JBOSS_HOME>/docs/examples/jms. Le nouveau fichier doit être nommé *-persistence-service.xml
11. Modifier ce nouveau fichier, en supprimant le tag <depends/> identifié en dessous et ajoutant le tag <attribute/> :

<server>
...
<mbean code="org.jboss.messaging.core.jmx.MessagingPostOfficeService"
name="jboss.messaging:service=PostOffice"
xmbean-dd="xmdesc/MessagingPostOffice-xmbean.xml">
...
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends>
<attribute name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</attribute>
...
</mbean>
...
</server>

supervision de JBoss

La ligne de commande suivante permet de récupérer des informations sur le fonctionnement de JBoss au sein de la JVM :
<JBOSS_HOME>/bin/twiddle.sh -s <host>:<jndi port> -u -p get "<argument JMX>"

La commande twiddle.sh est incluse dans le package JBoss. Elle permet de passer des requêtes JMX directement à la JVM.

Dans le cas où le connecteur JMX est protétégée par compte d'accès, il faut passer le user / password avec les options -u et -p.

1. Supervision du pool de threads HTTP / AJP

La supervision du pool de threads AJP se fait avec la requête JMX :
jboss.web:name=ajp-<host>-<port>,type=ThreadPool

La supervision du pool de threads HTTP se fait avec la requête JMX :
jboss.web:name=http-<host>-<port>,type=ThreadPool

2. Supervision du pool de threads JMX

La supervision du pool de threads JMX se fait avec la requête JMX :
jboss.remoting:service=invoker,transport=socket,host=localhost,port=<port>,dataType=invocation,enableTcpNoDelay=true, marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller,unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller

3. Supervision du pool de threads JNDI

La supervision du pool de threads JNDI se fait avec la requête JMX :
jboss.system:service=ThreadPool

4. Supervision du pool de threads JCA

La supervision du pool de threads JCA se fait avec la requête JMX :
jboss.jca:service=WorkManagerThreadPool

5. Supervision du pool de threads JMS

La supervision du pool de threads JMS se fait avec la requête JMX :
jboss.remoting:service=invoker,transport=bisocket,host=<host>,port=<port>,JBM_clientMaxPoolSize=200,clientLeasePeriod=10000, clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper,connectionWait=10,dataType=jms, marshaller=org.jboss.jms.wireformat.JMSWireFormat,numberOfCallRetries=1,pingFrequency=214748364,pingWindowFactor=10, socket.check_connection=false,stopLeaseOnFailure=true,timeout=0,unmarshaller=org.jboss.jms.wireformat.JMSWireFormat, validatorPingPeriod=10000,validatorPingTimeout=5000

6. Supervision du pool de threads EJB3

La supervision du pool de threads EJB3 se fait avec la requête JMX :
jboss.j2ee:ear=<application>.ear,jar=<librairie>.jar,name=<ejb>,service=EJB3

7. Supervision de la mémoire

La supervision de la mémoire se fait avec la requête JMX :
jboss.system:type=ServerInfo