1.0 Introduzione
2.0 Problemi noti
2.1 Aggiunta di file dei moduli a un progetto Enterprise Application
2.2 Elementi alt-dd (alternate deployment descriptor) nelle applicazioni aziendali
2.3
Impostazioni del percorso di generazione Java per i progetti client EJB/Web/Application
2.4 Spazi non supportati negli URI JAR all'interno di un EAR
2.5
I nomi dei progetti Enterprise Application non devono contenere caratteri DBCS
2.6 I progetto binari sono di sola lettura
2.7 Rimozione automatica di binding WebSphere con eliminazione
2.8 Blocco delle risorse dovuto alla convalida JSP
Nella prospettiva J2EE sono contenute le viste solitamente utilizzate quando si sviluppano risorse per progetti Enterprise Application, EJB, Web e client di applicazione. In questo file Readme vengono descritti problemi noti, limitazioni e soluzioni associati agli strumenti di sviluppo J2EE in WebSphere Studio. Inoltre, nel file readme relativo agli strumenti Web, è possibile trovare ulteriori informazioni relative alle viste J2EE e ai progetti Web J2EE.
Quando si importa uno dei tipi di file dei moduli (file JAR EJB, WAR, RAR e file JAR del client di applicazioni), è necessario utilizzare la procedura guidata per l'importazione e importare il modulo nel tipo di progetto appropriato. Non importare il file in un progetto Enterprise Application. Se il file del modulo viene importato nel progetto Enterprise Application, non sarà possibile aggiungere il modulo all'applicazione mediante l'editor del descrittore di distribuzione dell'applicazione.
L'utilizzo di alt-dd non è attualmente supportato in WebSphere Studio. La soluzione a questo problema consiste nel modificare i descrittori di distribuzione dei moduli contenuti.
Laddove è possibile, si consiglia di accettare le impostazioni predefinite del percorso di generazione Java per i tipi di progetti J2EE. Per impostare le dipendenze tra i progetti contenuti in una applicazione Enterprise, utilizzare invece l'editor Dipendenze JAR o la pagina delle proprietà di Dipendenze JAR di Java. L'attributo Class-Path del file MANIFEST.MF (utilizzato per il runtime del server) verrà sincronizzato con il percorso di generazione Java del progetto (utilizzato per la compilazione Java).
In generale, le librerie richieste da un modulo devono essere contenute nell'applicazione Enterprise oppure devono essere visibili al server. Di conseguenza, fare attenzione quando si aggiungono librerie esterne al percorso di generazione del progetto, perché il progetto potrebbe non avviare il server. Ad esempio, si supponga di disporre di una libreria off_the_shelf.jar da utilizzare come riferimento in un modulo WEB. È possibile:
- Aggiungere la libreria off_the_shelf.jar all'applicazione Enterprise utilizzando la procedura guidata dell'importazione del file system, utilizzare quindi l'editor Dipendenze JAR per rendere il modulo WEB dipendente dal file JAR, oppure
- Utilizzare le proprietà del percorso di generazione Java del progetto WEB per aggiungere il file JAR al percorso di generazione; il file JAR deve essere visibile al server.
Per realizzare questa operazione per la verifica dell'unità, modificare la configurazione server e aggiungere il file JAR al percorso classi.
Gli spazi negli URI per i moduli o nei JAR di utilità nelle applicazioni Enterprise non sono supportati. L'attributo "Class-Path:" del file MANIFEST.MF in un JAR o in un modulo, è un elenco dei percorsi relativi in un EAR delimitato da spazi. Un JAR non può fare riferimento ad un altro JAR in EAR, se l'URI dello JAR specificato contiene degli spazi.
Se si crea un progetto Enterprise Application, è preferibile non assegnargli un nome contenente caratteri DBCS.
I progetti binari creati dall'importazione EAR (disponibile come opzione della procedura guidata) sono di sola lettura. Non modificare il contenuto dei progetti binari. È possibile, invece, eliminare il progetto binario e sostituirlo con una versione di origine di un repository. La maggior parte delle azioni dovrebbero essere disabilitate per i progetti binari. Se si utilizzano progetti binari, non eseguire alcuna azione che possa modificare il contenuto del progetto o del file JAR.
Quando si elimina un oggetto contenente binding WebSphere, l'oggetto di binding viene eliminato automaticamente. Ad esempio, se si elimina un ruolo di protezione con binding nella pagina Protezione dell'editor del descrittore di distribuzione dell'applicazione, vengono eliminati anche i binding del ruolo di protezione. Se si aggiunge nuovamente un ruolo di protezione con lo stesso nome, ricordarsi di eseguire nuovamente il binding.
Se un progetto Web è stato convalidato di recente dal validator JSP, è possibile che sia ancora utilizzato un file JAR di libreria o di classe cui il progetto fa riferimento. In questo caso, potrebbe risultare difficile eliminare o spostare i singoli file JAR o di classe (ad esempio, se si sceglie di eliminare la directory /WEB-INF/lib). Se in un progetto Web esiste un riferimento a un file JAR di un progetto EAR come dipendenza JAR Java, potrebbe divenire impossibile la cancellazione del progetto EAR o del JAR al suo interno. Per "rilasciare" queste risorse per le attività di gestione dei file, chiudere il progetto Web e riaprirlo.
Visualizza il file Readme principale
(C) Copyright IBM Corporation 2000, 2003. Tutti i diritti riservati.