Lorsque vous tentez une opération de glisser-déposer de la vue Données de page vers une page contenant une table à agencement libre, le curseur NOT est affiché et l'opération n'est pas possible.
Pour effectuer une opération de glisser-déposer à partir de la vue Données de page, sélectionnez d'abord Cellule de texte dans la palette, puis ajoutez une cellule de texte dans la table à agencement libre. Vous pouvez alors effectuer l'opération de glisser-déposer de la vue Données de page vers la cellule de texte.
Lors de la tentative de déploiement d'une application Web (avec fonction SDO) accédant à une base de données relationnelle à l'aide d'une connexion à un gestionnaire de pilotes, les fichiers Jar du pilote ne sont pas automatiquement ajoutés au chemin d'accès aux classes du serveur. Cela provoque des erreurs ClassNotFound.
Actuellement, une connexion à une source de données est créée par défaut chaque fois que l'application accède aux bases de données relationnelles suivantes : Cloudscape, DB2, SQL Server & Oracle. Toutefois, pour toute autre base de données et notamment Informix et Sybase, une connexion à un gestionnaire de pilotes est créée et l'incident décrit ci-avant se produit.
Pour que la connexion au gestionnaire de pilotes fonctionne, l'utilisateur doit ajouter manuellement les chemins des fichiers Jar des pilotes au chemin d'accès aux classes du serveur. Pour ce faire, exécutez la console Admin du serveur et ajoutez des entrées de chemin d'accès aux classes sousServeurs->Serveurs d'applications-><nomServeur>->Gestion des processus et Java->Définition du processus->Machine virtuelle Java->Chemin d'accès aux classes
Actuellement, le produit ne génère pas de méthode de mise à jour avec chaque liste de données relationnelles. Voici le code que vous pouvez placer dans votre action pour mettre à jour le contenu de la liste de données myList
try { getMyListMediator().applyChanges((DataObject)((ECoreEList)getMyList()).getEObject()); } catch (Throwable e) { logException(e); }
Si votre serveur JDBC fonctionne sur autre chose que les valeurs par défaut du fournisseur, vous devez modifier la connexion à l'environnement SDO lors de sa création.
Lorsqu'un projet Web est migré d'un serveur WAS V5 vers un serveur WAS V6, le fichier WEB-INF/lib/wdo_web.jar n'est parfois pas supprimé. Il n'est pas valide sur un serveur WAS V6 et peut entraîner des incidents lors de la régénération des objets côté client de votre projet (si vous avez suivi la procédure de la rubrique "Migration de ressources JavaServer Faces avec des composants Faces Client" du guide de migration).
Pour éviter ces incidents, supprimez ce fichier JAR du dossier lib. Une fois que vous l'avez supprimé, ouvrez le fichier web.xml de votre projet Web et supprimez la balise taglib qui fait référence à ce fichier JAR. Vous pouvez la supprimer à partir de la page Variables ou Source de l'éditeur de descripteur de déploiement Web. L'URI de cette balise taglib est http://www.ibm.com/websphere/wdo/core. Enfin, sélectionnez le projet Web dans la vue Explorateur de projets, puis cliquez sur Propriétés dans son menu contextuel. Sélectionnez Chemin de compilation Java puis, à partir de la page Bibliothèques, supprimez toutes les entrées WDO_EMF_JARS_PATH/* du chemin d'accès aux classes.
Lorsque vous créez une page JSP avec un enregistrement relationnel qui utilise la génération automatique de clés destinée à un serveur v5.1, vous risquez de recevoir l'erreur ci-après:
2 cvc-complex-type.2.4.d : Contenu non valide commençant par l'élément "tables". Pas d'élément enfant requis ici.
Ce message d'erreur n'est pas valide et peut être ignoré.
Si vous exécutez WebSphere Application Server comme service avec l'authentification par défaut (exécuté comme utilisateur ayant ouvert une session) et que vous essayez de vous connecter à DB2 dans une application Web sans fournir de nom d'utilisateur et de mot de passe, vous risquez de recevoir l'erreur suivante :
java.sql.SQLException: [IBM][CLI Driver] SQL0567N "SYSTEM" n'est pas un ID d'autorisation correct. SQLSTATE=42602 DSRA0010E: Etat SQL = 42602, Code d'erreur = -567
Pour éviter cela, fournissez un ID utilisateur et un mot de passe à l'application ou configurez WAS de sorte qu'il soit exécuté de manière explicite (entrez un ID utilisateur et un mot de passe) comme compte utilisateur ayant accès à votre installation DB2.
Si vous fermez une page JSP dont les modifications n'ont pas été validées et que vous êtes invité à sauvegarder cette page JSP, le fait de répondre oui risque de ne pas sauvegarder les modifications non validées dans vos fichiers de configuration WDO/SDO.
Pour éviter cela, après avoir configuré un enregistrement relationnel ou une liste d'enregistrements, veillez à bien enregistrer le JSP en appuyant sur Ctrl+S ou en cliquant sur Fichier-->Enregistrer.
Ce problème se produit dans les applications WDO, créées pour s'exécuter sur le serveur Websphere v51, qui migrent sur le serveur Websphere v60. Dans ce scénario, une page Faces contenant un enregistrement ou une liste d'enregistrements comportant plusieurs clauses de filtres risque de lever l'exception suivante lorsqu'elle s'exécute sur le serveur :
java.lang.ArrayIndexOutOfBoundsException: 1 at org.eclipse.emf.ecore.impl.DynamicEObjectImpl.dynamicGet(DynamicEObjectImpl.java:192) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet(EStructuralFeatureImpl.java:1758) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicGet(BasicEObjectImpl.java:485) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:476)e at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java(Compiled Code)) at com.ibm.etools.webtools.sdo.runtime.internal.MapDataObjectImpl.getValue(MapDataObjectImpl.java:197) at com.ibm.etools.webtools.sdo.runtime.internal.MapDataObjectImpl.put(MapDataObjectImpl.java:162) at pagecode.PageCodeBase.resolveParams(PageCodeBase.java:189)
Le problème se trouve dans l'objet Parameter du médiateur.
Pour corriger le problème, vous devez définir correctement cet objet Parameter. Pour ce faire, modifiez votre méthode getList ou getRecord
avant :
public DataListAccessBean getList1() { if (list1 == null) { try { resolveParams(getList1Mediator().getParams(), list1ArgNames, list1ArgValues, "list1_params_cache"); DataGraphAccessBean graph = getList1Mediator().fetchGraph(); list1 = graph.getDataListAccessBean(); } catch (Throwable e) { logException(e); } } return list1; }
après :public DataListAccessBean getList1() { if (list1 == null) { try { getList1Mediator().setParams( new MapDataObjectImpl(((EObject) new MediatorImpl( (Metadata) getList1Mediator().getMetadata(), new NullConnectionWrapper()) .getParameterDataObject()).eClass())); resolveParams(getList1Mediator().getParams(), list1ArgNames, list1ArgValues, "list1_params_cache"); DataGraphAccessBean graph = getList1Mediator().fetchGraph(); list1 = graph.getDataListAccessBean(); } catch (Throwable e) { logException(e); } } return list1; }
Notez le bout de code qui définit l'objet Parameter.
Les sources de données ne seront pas configurées correctement sur le serveur lors d'une exécution sur le serveur si c'est un serveur par défaut qui a été sélectionné. Pour être sûr que votre source de données est correctement configurée, ne sélectionnez pas de serveur par défaut. Une fois que la publication de vos applications a abouti de manière satisfaisante, vous pouvez sélectionner un serveur par défaut dès lors que vous n'apportez aucune modification à vos sources de données.
L'affectation d'un nouveau nom à un schéma dans le cas d'un enregistrement relationnel/liste n'actualise pas le nom du schéma de la table à clé unique
Pour pallier le problème, modifiez le nom du schéma de la table à clé unique dans le fichier xml qui stocke la requête pour l'enregistrement ou la liste.
Retour au fichier Readme principal