© 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.
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.
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.
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.
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.
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.
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 :
- Vue Données de page
- Bean Java™ (avec invocation des méthodes)
- Service Web
- Bean session EJB
- Vue Palette
- Bean Java (avec invocation des méthodes)
- Service Web
- Bean session EJB
- Insérer -> Données (dans le menu contextuel de Page Designer ou sur la barre de menus du plan de travail)
- Bean Java (avec invocation des méthodes)
- Service Web
- Bean session EJB
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 :
- 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.
- 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).
- S'il y a besoin d'invoquer le service Web durant la phase Action (par exemple, pour naviguer vers différentes pages cible en fonction du résultat du service), vous devez changer la manière dont le résultat est mis en cache.Au lieu d'utiliser une variable locale dans le bean pagecode, utilisez soit le paramètre render, soit la session du portlet.L'utilisation du paramètre render est la technique préférée pour faire passer des informations de la phase Action à la phase Render. Cependant, seules les chaînes (String) sont acceptées pour la valeur de ce paramètre.Par conséquent, si le résultat du service est un type complexe, vous devez nécessairement utiliser la session du portlet à la place.
- Voici un fragment de code permettant d'écrire la valeur du paramètre render depuis la méthode d'action JSF dans le bean pagecode :
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("resultValue", resultValue);
- Voici un fragment de code permettant d'écrire une valeur dans la session du portlet depuis la méthode d'action JSF dans le bean pagecode :
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
request.getPortletSession().put("resultValue", resultValue);
- Ou alors, si l'invocation du service durant la phase Action n'est pas nécessaire, vous pouvez la reporter dans la méthode get du bean de résultat du service Web. Dans la méthode d'action JSF, placez la valeur d'entrée dans un paramètre render s'il s'agit d'une chaîne (String) ou dans la session du portlet s'il s'agit d'un type complexe.Récupérez-la ensuite dans la méthode get du bean de résultat du service Web afin qu'elle puisse être utilisée pour invoquer le service.
- Voici un fragment de code permettant d'écrire la valeur d'entrée dans un paramètre render depuis la méthode d'action JSF dans le bean pagecode :
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("inputValue", inputValue);
- Voici un fragment de code permettant de récupérer la valeur d'entrée à partir de la méthode get du bean de résultat :
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
String inputValue = request.getParameter("inputValue");
- Notez que l'utilisation du paramètre render pour passer des données à la phase Render a pour avantage supplémentaire un meilleur support du bouton Précédent et des marque-page (signets ou favoris).
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.
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>
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é).
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.
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.
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.
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.MyTasksDans 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.
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.
- Dans cette procédure, on suppose qu'un projet EAR "wps" a déjà été généré par l'opération de déploiement qui a échoué.
- Ouvrez le fichier application.xml du projet EAR wps qui vient d'être créé.
- Assurez-vous que le contenu du fichier application.xml ressemble à ceci :
<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>
- Plus spécifiquement, le fichier doit avoir les caractéristiques suivantes :
- Il doit contenir une définition de module Web pour wps.war dont la valeur de context-root est "wps".
- Il ne doit pas contenir plus d'une définition de module Web dont la valeur de context-root est "wps".
- Il doit contenir une définition de module Web pour wps_facade.war dont la valeur de context-root est "/wsrp".
- Il doit contenir une définition de modèle EJB pour wp.scheduler.ejb.jar.
- Il doit contenir des définitions de rôle de sécurité pour "Everyone Role", "All Role" et "No Role".
- Apportez les modifications nécessaires au fichier, enregistrez-le et publiez à nouveau l'application.
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.
- Lorsque le portlet est déployé par Rational Application Developer v7.
- Lorsque le portlet est d'abord installé dans WebSphere Application Server via le fichier EAR qui le contient, puis configuré dans WebSphere Portal à l'aide de la commande xmlAccess.
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.
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>
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.