Outils de portail et de portlet - Notes sur l'édition

© Copyright International Business Machines Corporation 2006. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Notes sur l'édition

1.0 Limitations
   1.1 Des messages d'avertissement signalant des liens rompus sont affichés dans la vue Erreurs
   1.2 Support de marquage dans Portal Designer
   1.3 La palette de couleurs par défaut n'est pas utilisée correctement
2.0 Problèmes connus et leurs solutions
   2.1 L'environnement d'exécution cible et la version du serveur de portail doivent être synchronisés manuellement dans l'assistant Nouveau projet de portail
   2.2 Edition des JSP de type de contenu CSS dans la boîte de dialogue Styles
   2.3 Le code généré pour un client de services ne fonctionne pas dans les portlets Faces JSR 168
   2.4 Message signalant l'incompatibilité des fichiers lors de l'importation d'un projet de portail
   2.5 Impossible d'exécuter un portlet JSR 168 dépourvu d'ID d'application ou impossible d'exécuter un projet de portail contenant un tel portlet
   2.6 Le statut du serveur WebSphere Portal 6.0 est détecté comme Arrêté, bien que le serveur soit en cours d'exécution
   2.7 Les portlets ne s'affichent pas sur les pages après l'exécution ou le déploiement du projet Mon portail sur WebSphere Portal 6.0
   2.8 Lorsque vous créez un message de processus métier avec un fichier WSDL utilisant le style document/littéral, les noms des messages ne s'affichent pas dans l'assistant
   2.9 Dans l'assistant de création de portlets coopératifs, le paramètre d'action par défaut peut être incorrect si le projet de portlets JSR 168 contient des portlets de types différents
   2.10 Le conteneur de page de tâche ne fonctionne pas en cas de changement de la valeur par défaut du nom unique
   2.11 Certains projets de portail que vous faites migrer à partir de Rational Application Developer 6.x peuvent provoquer une exception NoModuleFileException durant leur déploiement
   2.12 Définition du mode de chargeur de classes PARENT_LAST pour les portlets Faces
   2.13 L'exécution dans l'environnement de test WebSphere Portal v5.1 peut échouer pour les projets de portail créés à l'aide de Rational Application Developer 6.x
   2.14 Les exemples de portails et de portlets disponibles dans la galerie d'exemples et l'assistant d'importation de portail sont filtrés par capacité

1.0 Limitations

1.1 Des messages d'avertissement signalant des liens rompus sont affichés dans la vue Erreurs

Lors de l'importation d'un exemple de projet de portail à partir de la galerie d'exemples, ou lorsque vous utilisez l'assistant "Nouveau projet de portail", un message d'avertissement signalant la rupture de liens apparaît dans la vue Erreurs.

1.2 Support de marquage dans Portal Designer

Dans cette version de Rational® Application Developer, Portal Designer admet uniquement les langages de marquage HTML, cHTML et WML. Si vous avez spécifié d'autres langages supportés pour une page ou un libellé dans un projet importé, leur affichage est pris en charge par Rational Application Developer, mais ils ne peuvent pas être édités. Ils ne sont pas non plus visibles dans la vue Propriétés.

1.3 La palette de couleurs par défaut n'est pas utilisée correctement

Sauf si vous associez spécifiquement une palette de couleurs à une page, c'est la palette de couleurs par défaut de WebSphere® Portal 6 qui est utilisée. Cependant, dans Portal Designer, lorsque la palette de couleurs n'est pas spécifiée, c'est celle de la page ancêtre qui est utilisée, et non la palette par défaut.

2.0 Problèmes connus et leurs solutions

2.1 L'environnement d'exécution cible et la version du serveur de portail doivent être synchronisés manuellement dans l'assistant Nouveau projet de portail

Dans l'assistant Nouveau projet de portail, la sélection d'une version spécifique du serveur de portail ne met pas à jour automatiquement la sélection de l'environnement d'exécution cible.Ces deux sélections doivent être synchronisées manuellement.Par exemple, l'environnement d'exécution WebSphere Portal v6.0 doit être sélectionné pour un serveur de portail version 6.0.0.x, et l'environnement d'exécution WebSphere Portal v5.1 doit être sélectionné pour un serveur de portail version 5.1.0.x. Si ces deux paramètres ne sont pas en accord, le serveur de portail peut être altéré et devenir inutilisable au déploiement du projet de portail.

2.2 Edition des JSP de type de contenu CSS dans la boîte de dialogue Styles

Dans WebSphere Portal v6.0, lorsque vous éditez les fichiers JSP du type de contenu CSS tels que styles.jsp ou styles_theme.jspf  dans la boîte de dialogue Styles, cette dernière peut afficher des expressions JSP. Cependant, elles ne peuvent pas être modifiées dans cette boîte de dialogue. Vous devez les modifier dans le volet Source de CSS Designer.

2.3 Le code généré pour un client de services ne fonctionne pas dans les portlets Faces JSR 168

Pour un portlet Faces JSR 168, si vous utilisez l'un des outils suivants pour générer un client de services sur une page JSP Faces, le code de page généré ne fonctionnera pas correctement sur WebSphere Portal 6.0 ou 5.1. Les outils concernés sont les suivants :

Ce problème est dû à la nouvelle implémentation de l'environnement d'exécution des portlets Faces JSR 168 dans jsf-portletbridge.jar, qui est différente de ce qu'elle était auparavant.

Dans la nouvelle implémentation, les beans pagecode des JSP Faces, lorsqu'ils sont déclarés comme beans gérés avec une portée demande (requestScope), ne persistent pas entre les phases Action et Render (rendu) du portlet. Dans le code généré pour le client de services Web, le bean pagecode est utilisé pour mettre en cache le résultat du service Web durant la phase Action. Mais comme il est confiné dans la portée demande, une nouvelle instance de ce bean est créée durant la phase Render. Par conséquent, le résultat mis en cache est perdu en cours de route.

Il existe deux solutions possibles :

  1. Placez le bean dans la portée session (modification à apporter dans le fichier faces-config.xml). Vous avez simplement à changer une ligne dans le fichier de configuration.
  2. La deuxième solution est moins simple que la première, mais elle est à privilégier lorsque vous implémentez des clients de services dans les portlets JSR 168. Elle obéit aux pratiques recommandées en matière de programmation des portlets JSR 168 et offre un support bien meilleur du bouton Précédent et des marque-page (signets ou favoris).
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("resultValue", resultValue);
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
request.getPortletSession().put("resultValue", resultValue);
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("inputValue", inputValue);
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
String inputValue = request.getParameter("inputValue");

2.4 Message signalant l'incompatibilité des fichiers lors de l'importation d'un projet de portail

Lorsque vous importez un projet de portail, il est possible que vous receviez le message suivant : "Les fichiers suivants de l'espace de travail ne sont pas compatibles avec l'éditeur. Mettre à jour l'éditeur avec le contenu de l'espace de travail ?". Cliquez sur Oui.  

2.5 Impossible d'exécuter un portlet JSR 168 dépourvu d'ID d'application ou impossible d'exécuter un projet de portail contenant un tel portlet

Selon la spécification JSR 168, l'indication de l'ID d'application d'un portlet est optionnelle. Cependant, Rational® Application Developer ne publie pas correctement les portlets s'ils sont dépourvus d'un ID. Les portlets qu'il génère lui-même sont systématiquement assortis d'un ID. Or, vous pouvez très bien créer un portlet en l'important d'une autre source et il se peut alors qu'il ne comporte pas d'ID. Pour remédier à cette situation, ouvrez le descripteur de déploiement de portlet du projet et ajoutez un ID d'application de portlet sous l'onglet Source de l'éditeur. Par exemple :
<portlet-app xmlns=... version=... xmlns:xsi=... xsi:schemaLocation=... id="ENTREZ_VOTRE_ID_ICI">
...
</portlet-app>

2.6 Le statut du serveur WebSphere Portal 6.0 est détecté comme Arrêté, bien que le serveur soit en cours d'exécution

Si le statut du serveur est détecté comme Arrêté alors que le serveur est en cours d'exécution, vérifiez d'abord, dans l'éditeur de serveur, que les ports des connecteurs SOAP/RMI sont corrects et que les justificatifs de sécurité WebSphere utilisés sont également corrects. S'ils ne le sont pas, le statut du serveur ne sera jamais détecté comme Démarré. S'ils sont corrects et que le statut Arrêté demeure affiché pour le serveur, il peut y avoir un problème de coexistence entre WebSphere Application Server v6.1 et WebSphere Portal v6.0.

Le scénario le plus courant est celui où vous démarrez le produit avec un nouvel espace de travail tandis que le serveur WebSphere Application Server 6.1 est installé sur votre machine locale. Une instance de serveur WebSphere Application Server 6.1 est alors automatiquement créée et initialisée dans ce nouvel espace de travail, empêchant la détection correcte du statut de WebSphere Portal 6.0. Cela peut arriver aussi si vous créez une instance de serveur WebSphere Application Server v6.1 et, immédiatement après, une instance de WebSphere Portal 6.0.

La solution est de redémarrer votre produit Rational avec le même espace de travail. L'instance de serveur Portal 6.0 devrait alors fonctionner correctement, tant que le serveur WebSphere Application Server 6.1 n'est pas initialisé (c'est-à-dire aussi longtemps que la colonne Statut reste vide pour ce serveur et ne contient pas de mention Démarré ou Arrêté).

2.7 Les portlets ne s'affichent pas sur les pages après l'exécution ou le déploiement du projet Mon portail sur WebSphere Portal 6.0

Les portlets ne s'affichent pas sur les pages après l'exécution ou le déploiement du projet Mon portail sur WebSphere Portal 6.0. Pour éviter cette situation, limitez le déploiement à la configuration du portail chaque fois que le déploiement complet n'est pas nécessaire.

Si vous rencontrez ce problème, essayez d'exécuter un déploiement de la configuration seule, sans inclure aucun portlet du projet de portail. Cela permet généralement de rétablir le rendu correct des portlets.

2.8 Lorsque vous créez un message de processus métier avec un fichier WSDL utilisant le style document/littéral, les noms des messages ne s'affichent pas dans l'assistant

Si vous créez un nouveau message de processus métier et que votre fichier WSDL utilise le style document/littéral, les noms des messages d'entrée et de sortie risquent de ne pas être affichés sur la seconde page de l'assistant. Vous êtes quand même en mesure de sélectionner ces messages et de visualiser leurs détails dans la partie droite de l'assistant. Même si les noms des messages ne sont pas affichés dans l'assistant, le code généré sera correct. 

2.9 Dans l'assistant de création de portlets coopératifs, le paramètre d'action par défaut peut être incorrect si le projet de portlets JSR 168 contient des portlets de types différents

Si vous utilisez l'assistant de création de portlets coopératifs pour créer des portlets source et cible et que votre projet de portlets JSR 168 contient plusieurs types de portlet (par exemple, un portlet de base et un portlet Struts), le paramètre d'action par défaut spécifié dans l'assistant peut être incorrect.

Dans les portlets de base et Faces, le paramètre d'action par défaut devrait être ACTION_NAME_PARAM, mais l'utilisateur a la possibilité de sélectionner une valeur différente.
Dans un portlet Struts, le paramètre d'action doit obligatoirement être spf_strutsAction.

2.10 Le conteneur de page de tâche ne fonctionne pas en cas de changement de la valeur par défaut du nom unique

Voici la valeur par défaut du nom unique dans les conteneurs de page de tâche :  
 WebSphere Portal v6.0 :   ibm.portal.MyTasks
 WebSphere Portal v5.1 :   wps.MyTasks

Dans Portal Designer, lorsque vous utilisez une autre page avec un nom unique différent de ceux indiqués plus haut, après le déploiement, cette page n'est pas reconnue comme conteneur de page de tâche dans WebSphere Portal. 

Solution : Après le déploiement, changez la valeur du paramètre TaskPageContainerUniqueName dans le portlet Mes tâches en procédant comme suit :
 1.  Ouvrez Administration > Gestion de portlets > Portlets
 2.  Pour le portlet Mes tâches, cliquez sur le bouton Configurer le portlet. 
 3.  Pour le paramètre TaskPageContainerUniqueName, cliquez sur Edition.
 4.  Remplacez la valeur du paramètre par le nom unique utilisé dans Portal Designer, à savoir :

  WebSphere Portal v6.0 :   ibm.portal.MyTasks
  WebSphere Portal v5.1 :   wps.MyTasks
 5.  Cliquez sur OK. 

2.11 Certains projets de portail que vous faites migrer à partir de Rational Application Developer 6.x peuvent provoquer une exception NoModuleFileException durant leur déploiement

Si vous faites migrer un projet de portail créé avec Rational Application Developer 6.x  dans votre espace de travail Rational Application Developer 7.0, il est possible que son déploiement échoue avec une exception NoModuleFileException.Dans ce cas, suivez la procédure décrite ci-après pour corriger le problème.

      <module id="WebModule_1163447032109">
          <web>
              <web-uri>wps.war</web-uri>
              <context-root>wps</context-root>
          </web>
      </module>
      <module id="WebModule_WSRP">
         <web>
            <web-uri>wps_facade.war</web-uri>
            <context-root>/wsrp</context-root>
         </web>
      </module>
      <module id="EjbModule_1">
          <ejb>wp.scheduler.ejb.jar</ejb>
      </module>
      <security-role id="SecurityRole_1">
         <description>Everyone in the enterprise.</description>
         <role-name>Everyone Role</role-name>
      </security-role>
      <security-role id="SecurityRole_2">
         <description>All Authenticated users in the enterprise.</description>
         <role-name>All Role</role-name>
      </security-role>
      <security-role id="SecurityRole_3">
         <description>No users in the enterprise.</description>
         <role-name>No Role</role-name>
      </security-role>

2.12 Définition du mode de chargeur de classes PARENT_LAST pour les portlets Faces

Une version obsolète de jsf-ibm.jar a été livrée avec WebSphere Portal 6.0. Pour cette raison, certains composants JSF ne sont pas rendus correctement dans les portlets si le mode du chargeur de classes est PARENT_FIRST dans le module Web de ces portlets.En effet, lorsque le mode du chargeur de classes est réglé sur PARENT_FIRST, le fichier jsf-ibm.jar de WebSphere Portal 6.0 est utilisé à la place de la copie contenue dans le module Web du portlet.

Seuls sont affectés les composants qui, dans jsf-ibm.jar, correspondent à l'URI http://www.ibm.com/jsf/html_extended.Les deux catégories de portlets Faces (IBM et JSR 168) sont affectées.

Le mode du chargeur de classes du module Web du portlet est réglé sur PARENT_FIRST dans les situations suivantes et doit, par conséquent, être changé :

Pour remédier à ce problème, ouvrez le fichier application.xml du projet EAR qui contient le projet de portlet et cliquez sur l'onglet "Déploiement".Dans la section "Application", localisez l'arborescence dans laquelle figurent le projet EAR et le projet de portlet.Sélectionnez le projet de portlet et, dans la liste "Mode du chargeur de classes", choisissez "PARENT_LAST" à la place de "PARENT_FIRST".Il est possible que vous deviez publier à nouveau l'application pour que le changement soit pris en compte sur le serveur cible.
Si vous installez le portlet sous forme de fichier WAR directement dans WebSphere Portal en utilisant la page d'administration ou la commande xmlAccess, le mode du chargeur de classes est déjà réglé sur PARENT_LAST.Dans ce cas, vous n'avez rien à changer pour que le portlet fonctionne correctement.

2.13 L'exécution dans l'environnement de test WebSphere Portal v5.1 peut échouer pour les projets de portail créés à l'aide de Rational Application Developer 6.x

Lorsque vous importez dans votre espace de travail Rational Application Developer 7.0 un projet de portail 5.1.0.1 ayant été créé avec Rational Application Developer 6.x et que vous utilisez pour cela le format d'échange de projets, il est possible que son exécution dans l'environnement de test WebSphere Portal v5.1 échoue.

Solution : Modifiez le contenu du fichier .portalsettings en procédant comme suit :
 1. Sur la barre de menus, sélectionnez Fenêtre > Ouvrir la perspective > Autre...
 2. Sélectionnez Ressource et cliquez sur OK.
 3. Développez la branche du projet de portail dans la vue Navigateur.
 4. Sélectionnez le fichier .portalsettings et ouvrez-le avec l'éditeur de texte.
 5. Insérez le code suivant.
    <?xml version="1.0" encoding="UTF-8"?>
    <portalSettings>
         <portal-version version="5.1.0.1"/>
         <portlets-ear-project portlets-ear-project-name=""/>
         <process-integration mytaskspage-uniquename="wps.MyTasks"/>
     </portalSettings>

2.14 Les exemples de portails et de portlets disponibles dans la galerie d'exemples et l'assistant d'importation de portail sont filtrés par capacité

Pour accéder à l'assistant d'importation de portail et aux exemples de portails et de portlets disponibles dans la galerie d'exemples, vous devez activer la capacité "Web Developer (avancé)".Pour cela, sélectionnez Aide > Bienvenue sur la barre de menus. Cliquez ensuite sur le bouton "Rôles valides", dans l'angle inférieur droit de la fenêtre Bienvenue.Sélectionnez le rôle "Web Developer (avancé)" pour l'activer.Pour que ce changement soit pris en compte, relancez l'assistant ou rouvrez la galerie d'exemples.