Co sprawia, że ​​portlet JSR-286 jest zgodny?

Question

Czy ktoś ma link do zwięzłego podsumowania tego, co sprawia, że ​​portlet "zgodny z JSR-286" jest tylko "zgodny z JSR-168". Mam kopię specyfikacji i nic nie jest zwięzłe, więc połączenie specyfikacji nie jest przydatną odpowiedzią. Przeszukałem internet już od godziny i nie znalazłem nic, co byłoby jasne (poza specyfikacją, która oczywiście wymaga przeczytania poprzedniej specyfikacji), a następnie wyeliminować "nowe funkcje" z "wymaganych Zgodność ".

Szczególnie zauważyłem, że istnieje sporo zamieszania związanego z koniecznością web.xml, która wydaje się pochodzić od osób używających Liferay i nie zdając sobie sprawy, że Liferay spada w web.xml dla . im

Do JSR-286 portlets require a web.xml file in their WAR files?

Co naprawdę chciałbym coś który zawiera jeden lub więcej z następujących list:

• rzeczy trzeba zrobić, aby JSR-168, aby stać się JSR-286 zgodny
• rzeczy nie musi tego zrobić, spowodowałaby inaczej portlet JSR-286 zgodny uznać jedynie JSR-168.

Możesz opuścić "use portlet-app_2_0.xsd" z listy, ponieważ uważam tę część za oczywistą.

Jestem otwarty na odpowiedź, że obie listy są puste poza DTD/xsd dla portlet.xml, a różnica dotyczy tylko tego, co obsługuje portal, ale proszę o zwrot tego potwierdzenia za pomocą linku lub innego odnośnika .

Uważam, że widzę posty o portletach Vaadin w Liferay, co oznacza, że ​​niektóre funkcje nie są dostępne dla portletów JSR-168 ... Może się również zdarzyć, że niektóre logiki w przełącznikach Liferay będą oparte na wersji portletu. xml widzi, ale nie potwierdziłem, że również dlatego, że również będą interesujące informacje, ale nie odpowiedź na moje pytanie.

Answer 1

Według this doc, ale również wspomniano w jsr286:

JSR 286 Widmo (portletu 2,0) nie pęka kompatybilność binarnych JSR168 (portletĂłw 1,0). Oznacza to, że wszystkie portlety napisane zgodnie ze specyfikacją Portletu 1.0 mogą działać niezmienione. Jedynymi wyjątkami od tej reguły są:

renderResponse.setContentType nie jest już wymagane przed wywołaniem getWriter lub getOutputstream. W JSR168 wywoływanie getWriter lub getOutputstream bez uprzedniego ustawienia typu zawartości spowodowało wyjątek IllegalStateException.

getProtocol dla dołączonych serwletów/JSP zwraca "HTTP/1.1", w JSR168 zwrócono wartość null.

Więc tak długo, jak jsr168 portlet nie zależy od wartości zwracanej przez getProtocol() jesteś bezpieczny (tj każdy jsr168 portlet jest portlet jsr286).

Posty, które widzisz, wydają się być logiczne, ponieważ jsr286 to nowsza specyfikacja, a niektóre funkcje sprawiają, że portlet jsr268 nie jest portletem jsr168.

Answer 2

OK, ponieważ nie znalazłem nic nowego, co odróżniałoby portlet 2.0 od portletu 1.0 (oprócz korzystania z dodatkowych usług) i zacznę od list dla mojej odpowiedzi tutaj.

Must Do:

1. zgodne z XSD 2.0 dla portlet.xml (xmlns = "http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd")

Musi nie:

1. Polegaj na getWriter rzuca wyjątek, jeśli renderResponse.setContentType nie została jeszcze wywołana. (Wydaje się mało prawdopodobne, w każdym razie)
2. Polegaj na getProtocol() powracającego zerowy

Skutek jest taki, jeśli po prostu zamienić portlet.xml, jesteś teraz „286 zgodny” chyba, że ​​oparła się na dwóch elementów w druga lista dla twojego przepływu programu. Nie mogę znaleźć nic innego, ale jeśli ktoś znajdzie inny przedmiot dla tych list, edytuj.