Le schéma Solaris de l'annexe A du nouveau Solaris WBEM Developer's Guide fait référence à des fichiers de référence MOF mis à jour depuis les fichiers MOF mentionnés précédemment dans le Solaris WBEM SDK Developer's Guide. Le nouveau Solaris WBEM Developer's Guide ne doit pas contenir de références au nouveau fichier Solaris_DMGT1.0.mof ou Solaris_VM2.0.mof. qui n'étaient pas inclus à cette version et ne devraient donc pas y figurer.
La description du nouveau Solaris WBEM Developer's Guide mentionne le fait que des références de fichiers MOF ont été mises à jour dans l'annexe de ce nouveau manuel, depuis les fichiers MOF mentionnés précédemment dans le Solaris WBEM SDK Developer's Guide. Cependant, le nouveau WBEM Developer's Guide et le What's New ne doivent pas faire partie du nouveau fichier Solaris_DMGT1.0.mof ou le fichier Solaris_VM2.0.mof. car ils n'étaient pas inclus dans cette version.
Dans le schéma CIM de Solaris, les classes et propriétés suivantes sont marquées du qualificatif Deprecated (désapprouvé).
Classe Solaris_LogRecord
Classe Solaris_LogService
Classe Solaris_LogServiceSetting
Classe Solaris_LogServiceSetting
Propriété OptionsEnabled dans la classe Solaris_IPProtocolEndpoint
Utilisez les alternatives appropriées de ces classes et propriétés désapprouvées. Reportez-vous aux qualificatifs de description de la classe pour déterminer les alternatives de classe et de propriété correctes.
Le chapitre “Writing a Client Program” fournit des informations sur la création de clients WBEM qui utilisent le protocole RMI avec l'API javax.com.sun.client . Si vous souhaitez vous connecter à un serveur sur lequel tourne l'environnement d'exploitation Solaris 8, vous devez inclure le fichier /usr/sadm/lib/wbem/cimapi.jar au CLASSPATH du client. Le fichier cimapi.jar inclut les classes com.sun.wbem requises pour communiquer avec un serveur de ce type.
cette documentation est liée à l'utilisation de répertoires de déploiement indexés.
La partie schéma de numérotation d'un nom de répertoire d'application déployée a été mise en oeuvre en tant que mécanisme d'indexation. Ce mécanisme, qui permet aux développeurs de modifier un fichier JAR ou un fichier de classe associé à l'application déployée, est important pour la plate-forme Windows, car toute tentative d'écrasement de fichier partagé entraîne une erreur de violation de partage et Windows verrouille le fichier chargé. Le fichier est chargé dans l'instance de serveur ou l'IDE lors du démarrage de la session. En cas d'erreur de violation de partage, vous avez le choix entre les deux possibilités suivantes :
Compilez le fichier de classe mis à jour (qui, à l'origine, faisait partie de ce fichier JAR), placez-le en premier dans CLASSPATH afin qu'il soit chargé avant les classes plus anciennes et autorisez Sun ONE Application Server à recharger cette application (à condition que le rechargement soit actif).
Procédez à la mise à jour du fichier JAR, créez un nouveau fichier EAR et redéployez l'application.
le redéploiement de l'application sur la plate-forme Solaris n'est pas nécessaire, car il n'existe aucune contrainte de verrouillage de fichier.
Lorsqu'une application déjà déployée sur la plate-forme Windows fait l'objet de changements en vue d'une configuration IDE, d'une copie de fichier ANT, d'une compilation ou de toute autre opération, tenez compte du fait qu'un nouveau répertoire avec un numéro d'index incrémenté est créé pour pallier la contrainte de verrouillage du fichier. Exemple : sur la plate-forme Solaris, l'application J2EE Helloworld est déployée sur le serveur d'applications Sun ONE. Son arborescence de répertoires se présente de la manière suivante :
appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_1
Il est nécessaire de modifier le servlet faisant partie de cette application déployée (ex. : HelloServlet.java). L'environnement de développement intégré de Sun ONE Studio est lancé et le fichier source de ce servlet est modifié puis compilé à l'aide de la cible javac attribuée au répertoire mentionné ci-dessus. Si la source a été compilée à l'emplacement approprié, il existe un fichier de rechargement pour cette application. L'indicateur de rechargement du fichier server.xml est défini sur True et, si l'instance du serveur tourne, les modifications prennent effet sans qu'il soit nécessaire de réassembler l'application, ni de la redéployer.
Sur la plate-forme Windows, il est impossible de modifier ou de mettre à jour le fichier JAR ou le fichier de classe en raison du verrouillage du fichier. Vous disposez de deux solutions pour résoudre ce problème sous Windows :
Compilez le fichier source modifié et ajoutez le fichier de classe ou le fichier JAR au début du chemin d'accès de la classe, de manière à ce que les modifications de la source prennent effet.
Effectuez les modifications dans la source de l'applet Helloworld, assemblez-le, puis redéployez-le sans en annuler le déploiement précédent.
La deuxième option est préférable, car elle débouche sur l'utilisation du numéro d'index incrémenté ajouté au nom de répertoire de l'application déployée. Après un deuxième déploiement, l'arborescence des répertoires de Helloworld revêt l'apparence suivante :
appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_1
appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_2
Le deuxième déploiement de Helloworld s'effectue alors sous helloworld_2.