Codage du service pour la réception des propriétés de configuration

Les propriétés de configuration sont disponibles par l'intermédiaire de l'objet org.osgi.service.component.ComponentContext qui est fourni en argument à la méthode d'activation (activate).

Avant de commencer

Vous devez effectuer la tâche décrite dans Association d'un service à une identité persistante.

Pourquoi et quand exécuter cette tâche

Si des propriétés sont mises à jour après l'activation, la méthode utilisée pour les injecter dépend du contexte que le service fournit dans sa déclaration auprès des services déclaratifs (DS) OSGi.

Généralement, mieux vaut déclarer une méthode à utiliser spécifiquement pour injecter les propriétés mises à jour. A cet effet, on utilise l'attribut modified dans la déclaration du service. Si aucune méthode 'modified' n'est disponible, DS désactive le service, puis le réactive avec les nouvelles propriétés.

La désactivation et la réactivation d'un service peut également entraîner le recyclage de services dépendants et doivent être évitées sauf en cas de besoin explicite. Il est recommandé d'utiliser l'attribut modified pour recevoir les mises à jour de configuration.

Exemple

Dans la tâche précédente, Association d'un service à une identité persistante, vous avez défini un serveur dans les services déclaratifs. L'exemple suivant illustre la méthode activate et la méthode modified à coder d'après la déclaration DS décrite dans la présente tâche.
private static Dictionary<String, Object> _props = null;

    protected void activate(ComponentContext cc) {
        _props = cc.getProperties();
    }

    protected void modified(Map<?, ?> newProperties) {
        if (newProperties instanceof Dictionary) {
            _props = (Dictionary<String, Object>) newProperties;
        } else {
            _props = new Hashtable(newProperties);
        }
    }
Lorsque vous obtenez ou lisez les valeurs des propriétés de configuration, servez-vous des mécanismes suivants, qui autorisent une certaine souplesse :
  • Codez les méthodes de sorte qu'elles s'attendent, au minimum, à recevoir les propriétés par défaut incluses dans le même bundle tout en laissant la place aux dérogations de l'utilisateur, le but étant d'éviter la migration de la configuration personnalisée.
  • Ignorez les propriétés redondantes ou non reconnues.
Le service doit être capable de fonctionner avec la configuration par défaut seule. Pour que le niveau de fonctionnalité soit raisonnable, les substitutions de l'utilisateur ne doivent pas être obligatoires.

Icône indiquant le type de rubrique Rubrique Tâche



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_setup_service_getprops
Nom du fichier : twlp_setup_service_getprops.html