© Copyright International Business Machines Corporation 2006. Wszelkie prawa zastrzeżone. Ograniczone prawa na rzecz rządu Stanów Zjednoczonych - używanie produktów, tworzenie ich duplikatów oraz ujawnianie informacji o nich podlega zastrzeżeniom zawartym w umowie GSA ADP Schedule zawartej z firmą IBM® Corp.
Podczas importowania przykładowego projektu portalu lub tworzenia projektu portalu za pomocą kreatora "Nowy projekt portalu" z galerii przykładów w widoku Problemy pojawia się komunikat ostrzeżenia o niepoprawnym odsyłaczu.
W tej wersji produktu Rational® Developer Projektant portalu obsługuje tylko wyświetlanie w językach HTML, cHTML i WML. Jeśli dla strony lub etykiety w importowanym projekcie zostały określone inne obsługiwane języki znaczników, ich wyświetlanie jest obsługiwane przez produkt Rational Developer, ale nie mogą być one edytowane. Te języki znaczników nie będą wyświetlane w widoku Właściwości.
Dopóki użytkownik nie przypisze stronie palety kolorów, stosowana jest domyślna paleta kolorów produktu WebSphere® Portal 6. Jednak jeśli nie została określona paleta kolorów w Projektancie portalu, zamiast palety domyślnej wykorzystywana jest paleta kolorów strony będącej przodkiem.
Wybranie wersji serwera portalu w kreatorze Nowy projekt portalu nie powoduje automatycznej aktualizacji docelowego środowiska wykonawczego. Ustawienia wersji serwera portalu oraz docelowego środowiska wykonawczego muszą zostać zsynchronizowane ręcznie. Na przykład dla wersji 6.0.0.x serwera portalu należy wybrać środowisko wykonawcze WebSphere Portal w wersji 6.0 , a dla wersji 5.1.0.x serwera portalu należy wybrać środowisko wykonawcze WebSphere Portal w wersji 5.1. Jeśli wersja docelowego środowiska wykonawczego nie zostanie zsynchronizowana z wersją portalu, serwer portalu może zostać uszkodzony lub stać się bezużyteczny po wdrożeniu projektu portalu.
W przypadku produktu WebSphere Portal, wersja 6.0 edytowanie plików JSP typu treści CSS, takich jak styles.jsp lub styles_theme.jspf za pomocą okna dialogowego Style może spowodować wyświetlenie wyrażeń JSP w tym oknie. Wyrażeń JSP nie można modyfikować w oknie dialogowym. Należy je modyfikować w panelu źródłowym Projektanta CSS.
W przypadku portletu Faces JSR168, jeśli do generowania klienta usługi na stronie Faces JSP wykorzystywane są wymienione poniżej narzędzia, wygenerowany kod strony nie będzie działał poprawnie na serwerze WebSphere Portal 6.0 i 5.1. Dotyczy to następujących narzędzi:
- Widok Dane strony
- Komponent bean Java™ (z wywoływaniem metody)
- Usługa Web Service
- Komponent bean sesji EJB
- Widok Paleta
- Komponent bean Java (z wywoływaniem metody)
- Usługa Web Service
- Komponent bean sesji EJB
- Opcja Wstaw -> Dane z menu kontekstowego Projektanta stron lub menu okien
- Komponent bean Java (z wywoływaniem metody)
- Usługa Web Service
- Komponent bean sesji EJB
Jest to spowodowane nową implementacją środowiska wykonawczego portletu Faces JSR168 zawartą w pliku jsf-portletbridge.jar, która różni się od poprzedniej.
W nowej implementacji komponenty bean z kodem strony dla stron JSP Faces po zadeklarowaniu jako komponenty bean zarządzane zasięgiem żądania nie są zachowywane między fazą działania i renderowania portletu. W wygenerowanym kodzie klienta usług Web Services komponent bean z kodem strony jest wykorzystywany do buforowania wyniku usługi Web Service w fazie działania. Ponieważ jednak znajduje się on w zasięgu żądania, podczas fazy renderowania tworzona jest nowa instancja. Z tego względu buforowane wyniki są tracone.
Istnieją dwa rozwiązania:
- Komponent bean należy umieścić w zasięgu sesji (można to skonfigurować w pliku faces-config.xml). Jest to bardzo proste i polega na zmianie pojedynczego wiersza w pliku konfiguracyjnym.
- Drugi sposób nie jest tak prosty, ale jest zalecanym sposobem implementowania klienta usług w portletach JSR168. Jest zgodny ze sprawdzonymi procedurami programowania portletów JSR168 i umożliwia znacznie lepszą obsługę przycisku powrotu oraz tworzenia zakładek.
- Jeśli usługa Web Service musi zostać wywołana podczas fazy działania, na przykład gdy w zależności od wyniku działania usługi ma być wykonana nawigacja do różnych stron docelowych, wtedy należy zmienić sposób buforowania tego wyniku. Zamiast korzystać ze zmiennej lokalnej w komponencie bean z kodem strony, należy użyć parametru renderowania lub sesji portletu. Użycie parametrów renderowania jest lepszym sposobem na przekazanie informacji z fazy działania do fazy renderowania, chociaż obsługiwane są w ten sposób tylko wartości łańcuchowe. Jeśli wynik jest typu złożonego, należy wówczas użyć sesji portletu.
- Poniżej przedstawiono przykładowy fragment kodu służący do ustawiania wartości parametrów renderowania w ramach metody akcji JSF w komponencie bean z kodem strony:
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("resultValue", resultValue);
- Poniżej przedstawiono przykładowy fragment kodu służący do ustawiania wartości sesji portletu w ramach metody akcji JSF w komponencie bean z kodem strony:
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
request.getPortletSession().put("resultValue", resultValue);
- W przypadku gdy wywoływanie usługi w fazie działania nie jest wymagane można odroczyć wywołanie usługi do metody pobierającej dla komponentu bean wyniku usługi Web Service. W metodzie akcji JSF wartość wejściową należy wstawić do parametru żądania renderowania, jeśli jest to łańcuch, lub do sesji portletu, jeśli wartość wejściowa jest typu złożonego. Następnie należy pobrać ją z metody pobierającej dla komponentu bean wyniku usługi Web Service, tak aby mogła zostać użyta do wywołania usługi.
- Poniżej przedstawiono przykładowy fragment kodu służący do ustawiania wartości wejściowej w parametrze renderowania w ramach metody akcji JSF w komponencie bean z kodem strony:
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("inputValue", inputValue);
- Poniżej przedstawiono przykładowy fragment kodu służący do pobrania wartości wejściowej w metodzie pobierającej jako wyniku:
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
String inputValue = request.getParameter("inputValue");
- Należy zauważyć, że wykorzystanie parametru renderowania do przekazania informacji do fazy renderowania przynosi dodatkowe korzyści w postaci lepszej obsługi przycisku Wstecz przeglądarki oraz procesu tworzenia zakładek.
Podczas importowania projektu portalu może zostać wyświetlony komunikat z pytaniem: "Następujące pliki obszaru roboczego są niespójne z edytorem. Czy zaktualizować edytor treścią pochodzącą z obszaru roboczego?". Należy wtedy kliknąć przycisk Tak.
Identyfikator aplikacji portletowej jest opcjonalny zgodnie ze specyfikacją JSR 168, ale produkt Rational® Developer nie publikuje poprawnie portletów bez identyfikatorów. Produkt Rational Developer nie generuje portletów bez tych identyfikatorów. Możliwe jest jednak, że portlet został utworzony w wyniku zaimportowania portletu z innego źródła. Aby obejść ten problem, należy otworzyć deskryptor wdrażania portletu dla projektu i na karcie źródła dodać identyfikator aplikacji portletowej. Na przykład:
<portlet-app xmlns=... version=... xmlns:xsi=... xsi:schemaLocation=... id="TU_WPISZ_IDENTYFIKATOR">
...
</portlet-app>
Jeśli stan serwera wykrywany jest jako Zatrzymany, gdy serwer jest uruchomiony, najpierw należy upewnić się, czy porty konektora SOAP/RMI są poprawne, a w edytorze serwera należy sprawdzić, czy poprawne są wykorzystywane referencje zabezpieczeń serwera WebSphere. Jeśli nie są poprawne, stan serwera nigdy nie zostanie wykryty jako Uruchomiony. Jeśli są poprawne, a stan serwera nadal wykrywany jest jako Zatrzymany, problem może być związany ze współistnieniem serwera WebSphere Application Server 6.1 i WebSphere Portal 6.0.
Najczęstszy scenariusz polega na tym, że serwer WebSphere Application Server 6.1 jest zainstalowany na komputerze lokalnym, a użytkownik uruchamia nowy obszar roboczy. W nowym obszarze roboczym automatycznie zostanie utworzona i zainicjowana nowa instancja serwera WebSphere Application Server 6.1, co spowoduje niepoprawne działanie wykrywania stanu serwera Portal 6.0. Może się to zdarzyć także, gdy właśnie został utworzony serwer WebSphere Application Server 6.1, a następnie serwer Portal 6.0.
Rozwiązaniem jest ponowne uruchomienie produktu Rational z tym samym obszarem roboczym. Instancja serwera Portal 6.0 powinna wówczas działać prawidłowo, dopóki nie zostanie zainicjowany serwer WebSphere Application Server 6.1, tzn. jego status pozostaje pusty i nie zawiera określenia Zatrzymany lub Uruchomiony.
Portlety nie są wyświetlane na stronach po uruchomieniu lub wdrożeniu projektu portalu użytkownika na serwerze Portal 6.0. Aby zminimalizować efekt tego problemu, za każdym razem, gdy pełne wdrożenie nie jest konieczne, należy korzystać z wdrażania samej konfiguracji.
Jeśli ten problem wystąpi, należy spróbować uruchomić wdrożenie samej konfiguracji projektu portalu bez wdrażania portletów. Zazwyczaj umożliwia to ponowne poprawne wyświetlenie portletów przez portal.
W przypadku tworzenia nowego komunikatu procesu biznesowego z wykorzystaniem pliku WSDL ze stylem literału dokumentu nazwy komunikatów wejściowych i wyjściowych mogą nie być wyświetlane na drugiej stronie kreatora. Użytkownik nadal może je wybierać i przeglądać szczegóły komunikatów po prawej stronie kreatora. Wygenerowany kod będzie prawidłowy, niezależnie do faktu, że nazwy komunikatów nie są widoczne w kreatorze.
W przypadku korzystania z kreatorów kooperatywnych w celu utworzenia portletów źródłowych lub docelowych i gdy projekt portletu JSR 168 zawiera wiele typów portletów, na przykład jeden portlet podstawowy i jeden portlet Struts, domyślny parametr akcji w kreatorze może być niepoprawny.
W przypadku portletów podstawowych i portletów Faces domyślnym parametrem akcji powinien być parametr ACTION_NAME_PARAM, ale użytkownik może wybrać inną wartość.
W przypadku portletów Struts parametrem akcji musi być spf_strutsAction.
Poniżej przedstawiono domyślne wartości nazwy unikalnej w kontenerach strony zadania:
WebSphere Portal 6.0: ibm.portal.MyTasks
WebSphere Portal 5.1: wps.MyTasksJeśli w Projektancie portalu używana jest kolejna strona z inną nazwą unikalną niż wymienione powyżej, po wdrożeniu na serwerze WebSphere Portal strona ta nie zostanie rozpoznana jako strona kontenera strony zadania.
Obejście: Po wdrożeniu należy zmienić wartość parametru TaskPageContainerUniqueName w portlecie Moje zadania, wykonując następujące czynności:
1. Wybierz opcje Administrowanie > Zarządzanie portletami > Portlety.
2. Dla portletu Moje zadania kliknij przycisk Konfiguruj portlet.
3. Kliknij przycisk Edytuj dla parametru TaskPageContainerUniqueName.
4. Zmień wartość w Projektancie portalu na nową nazwę unikalną, korzystając z następujących wartości:WebSphere Portal 6.0: ibm.portal.MyTasks
WebSphere Portal 5.1: wps.MyTasks
5. Kliknij przycisk OK.
Jeśli projekt portalu był migrowany z produktu Rational Developer 6.x do obszaru roboczego produktu Rational Developer 7.0, może powodować niepowodzenie wdrażania i wyjątek NoModuleFileException. Gdy wystąpi taka sytuacja, należy wykonać poniższą procedurę.
- W tej procedurze przyjęto, że projekt EAR "wps" został już wygenerowany w błędnej operacji wdrażania projektu portalu.
- Otwórz plik application.xml nowo wygenerowanego projektu EAR wps.
- Upewnij się, że treść pliku application.xml wygląda następująco:
<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>
- Szczególnie treść powinna
- Zawierać definicję modułu WWW dla pliku wps.war z wartością content-root ustawioną na "wps".
- Nie zawierać więcej niż jednej definicji modułu WWW z wartością content-root ustawioną na "wps".
- Zawierać definicję modułu WWW dla pliku wps_facade.war z wartością content-root ustawioną na "/wsrp.
- Zawierać definicję modułu ejb dla pliku wp.scheduler.ejb.jar.
- Zawierać definicje ról zabezpieczeń dla pozycji "Everyone Role", "All Role" i "No Role".
- Zapisz i opublikuj projekt ponownie.
Z powodu nieaktualnej wersji pliku jsf-ibm.jar, która była dostarczana z produktem WebSphere Portal 6.0, niektóre komponenty JSF nie są poprawnie wyświetlane w portletach, jeśli tryb programu ładującego klasy jest ustawiony w module WWW portletu na PARENT_FIRST. Dzieje się tak, ponieważ przy trybie programu ładującego klasy ustawionym na PARENT_FIRST zamiast kopii pliku jsf-ibm.jar zawartej w module WWW portletu użyta zostanie kopia serwera WebSphere Portal 6.0.
Ma to wpływ tylko na komponenty w pliku jsf-ibm.jar, które odpowiadają adresowi URI http://www.ibm.com/jsf/html_extended. Ma to wpływ zarówno na portlety Faces IBM oraz Faces JSR168.
Tryb programu ładującego klasy modułu WWW portletu będzie ustawiony na PARENT_FIRST w następujących sytuacjach, w których będzie wymagana jego zmiana:
Aby obejść ten problem, należy otworzyć plik application.xml w projekcie EAR zawierającym projekt portletu, a następnie otworzyć kartę "Wdrażanie". W sekcji "Aplikacja" należy znaleźć drzewo wyświetlające projekt EAR oraz projekt portletu. Następnie należy wybrać projekt portletu i zmienić wartość "Tryb programu ładującego klasy" z "PARENT_FIRST" na "PARENT_LAST". Aby zmiany zostały zastosowane na serwerze docelowym, konieczne może być ponowne opublikowanie aplikacji.
- Gdy portlet jest wdrażany przez produkt Rational Developer wersja 7.
- Gdy portlet najpierw jest instalowany na serwerze WebSphere Application Server za pomocą pliku EAR, a następnie konfigurowany na serwerze WebSphere Portal za pomocą komendy xmlAccess.
Jeśli portlet został zainstalowany bezpośrednio na serwerze WebSphere Portal za pomocą pliku WAR, na stronie administrowania serwera WebSphere Portal lub za pomocą komendy xmlAccess, wtedy tryb programu ładującego klasy jest już ustawiony na PARENT_LAST. W tym przypadku portlet będzie działał poprawnie bez konieczności stosowania obejścia.
Gdy projekt portalu w wersji 5.1.0.1 utworzony za pomocą produktu Rational Developer 6.x jest importowany z wykorzystaniem opcji wymiany projektów do obszaru roboczego Rational Developer 7.0, działanie opcji "Uruchom w środowisku testowym WebSphere Portal 5.1" może się nie powieść.
Obejście: Należy zmodyfikować zawartość pliku .portalsettings, wykonując następujące czynności:
1. Wybierz opcje Okno > Otwórz perspektywę > Inne....
2. Wybierz opcję Zasób i kliknij przycisk OK w oknie dialogowym Otwórz perspektywę.
3. W widoku Nawigator rozwiń projekt portalu.
4. Wybierz plik .portalsettings i otwórz go w edytorze tekstu.
5. Wstaw następującą treść:
<?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>
Możliwość "Projektant WWW (zaawansowany) musi być włączona, aby widoczny był kreator importowania portalu oraz przykłady portalu i portletów (z galerii przykładów). Aby włączyć tę możliwość, należy wybrać opcje Pomoc > Witamy i w oknie Witamy kliknąć przycisk "Włącz role" znajdujący się w rogu ekranu. Następnie należy wybrać rolę "Projektant WWW (zaawansowany)", aby ją włączyć. Aby zmiany zostały zastosowane, należy zrestartować kreatora lub galerię przykładów.