2009-06-04 11 views
7

Uderzyłem się tym paskudnym zachowaniem na JBoss 4.2 w QA, a ja chcę go zdusić w zarodku, zanim przejdziemy do produkcji i znajdziemy inny przypadek.Jak wymusić ponowną kompilację jsp w JBoss 4.2?

JSP calles metoda, która miała następujący podpis:

public void methodName(String arg) 

ta została zmieniona na:

public void methodName(String arg, Object... args) 

Wcześniej istniejące JSP nazywa tę metodę poprzez:

methodName("param"); 

Po wdrożeniu zmodyfikowanego kodu JBoss nie rekompilował strony JSP, co spowodowało awarię w kontroli jakości. Dodanie głupiego komentarza do jsp rozwiązało problem (JBoss uznał, że JSP zmienił i zrekompilował go).

Czy istnieje ustawienie JBoss wymuszające ponowną kompilację stron JSP po ponownym uruchomieniu?

EDYCJA: Aby wyjaśnić niektóre punkty odpowiedzi, konfiguracja jest taka, że ​​strony JSP są częścią wojny, która jest częścią ucha. W uchu znajdują się wszystkie klasy w słoiku.

Odnośnie do chęci wstępnej kompilacji, jeśli system nie uważa, że ​​kompilacja jsp wymaga kompilacji, wstępnie skompiluje wymuszoną rekompilację? Nie wydaje się tak. Błąd tutaj nie jest błędem kompliacji, jest to błąd wywołania metody z powodu "zmienionego" (na poziomie kodu bajtu, a nie na poziomie kodu) sygnatury metody.

Dodatek: Należy zauważyć, że ostatnio doświadczyliśmy w produkcji, że nawet przy ustawieniu flagi akceptowanej odpowiedzi strony JSP nie rekompilowały się, mimo że w rzeczywistości strona JSP uległa zmianie. Poważny błąd, ale niezależnie, JBoss był normalnie wyłączony. W tym momencie staje się starą wersją JBoss, ale jeśli wciąż go używasz, usuwanie zawartości katalogu roboczego i tmp jest jedynym sposobem, aby się upewnić.

Nie zmieniam zaakceptowanej odpowiedzi tylko dlatego, że naprawdę dociera do tego, czego szukało. Błędy JBoss to osobny problem.

Odpowiedz

11

Jeśli JSP są częścią wojny, która jest częścią EAR, który jest wdrożony w słoiku, to nie jestem jasne, dlaczego JSP nie są rekompilacji. Czy pliki stron JSP w pliku wojny nie mają nowszych znaczników czasu niż pliki klas skompilowane przez JBoss z ostatniego wdrożenia? Jeśli nie, nie możesz dotknąć stron JSP w ramach budowania WAR/EAR przed wdrożeniem. [Mam tu na myśli użycie uniksowego polecenia "touch", a nie ręczne dotykanie każdego pliku JSP.]

Alternatywnie, ustawienie DeleteWorkDirOnContextDestroy w $ JBOSS/server/default/deploy/jboss-web.deployer/META-INF /jboss-service.xml może być tym, czego szukasz. Domyślnie jest to wartość false, ale ustawienie jej na wartość true może być tym, czego potrzebujesz. Myślę, że powinno to usunąć pliki klas JSPs podczas redeploy, aby odtworzyć je po pierwszym dostępie do każdej strony JSP.

Aby uzyskać więcej informacji, patrz https://jira.jboss.org/jira/browse/JBAS-3358.

+1

Świetnie! Sprawdzę, czy to działa, i czy akceptuje odpowiedź. – Yishai

+5

+1 Dzięki! Wystarczy zauważyć w JBoss 5.1.0GA równoważny plik to $ JBOSS/server/default/deplyers/jbossweb.deployer/META-INF/war-deployers-jboss-bean.xml –

+1

Dzięki temu rozwiązałem problem, który miałem ze zmianami w JSP nie zostały odzwierciedlone po wdrożeniu. –

1

Nie znam ustawienia, ale usunięcie wygenerowanego pliku klasy Java w katalogu roboczym instancji JBoss spowoduje, że strona JSP zostanie ponownie skompilowana przy następnym wywołaniu.

+1

Dzięki, ale byłoby to trudne do wykonania praktycznie podczas wdrożenia produkcyjnego. – Yishai

1

Możesz zmienić skrypty startowe JBoss, aby jawnie usunąć katalogi "tmp" i/lub "pracy", w których przechowywane są skompilowane strony JSP. JBoss nie miałby wówczas innego wyboru, jak tylko przekompilować je wszystkie.

Nie subtelna, ale wykonałaby zadanie.

0

Jedną z opcji jest wstępne skompilowanie wszystkich plików JSP w czasie kompilacji. To szybko oznaczałoby błędy kompilacji.

Możesz również zrobić to podczas produkcji - przyśpieszyć pierwszy dostęp, ale mam wrażenie, że chcesz tego bardziej dla etapu kontroli jakości niż cokolwiek innego. Jeśli tak, możesz dodać etap prekompilacji do fazy testowania w wybranym narzędziu do budowania - a tym samym do środowiska CI. Zapewniłoby to pewność, że pliki jsp, które nie zostaną skompilowane, nie sprawią, że nie zostaną przetestowane.

Zobacz ten Szczegółowe informacje na temat prowadzenia prekompilacji zadanie:

Jboss Jasper configuration

nadzieję, że to pomaga.

+0

Dzięki, robimy to właściwie. Problem polega na tym, że skrypt kompilacji jest czysty, a w czystej kompilacji przykład jest w porządku. Problem polega na tym, że podstawowa JSP musiała zostać przekompilowana do działania, nawet jeśli się nie zmieniła, a rekompilacja zadziała, ale JSP nie będzie działać bez rekompilacji. – Yishai

+0

Wystarczająco fair, nie znajdzie tego błędu podczas kompilacji. Czy rozważałeś wstępne skompilowanie produkcji? – Pablojim

+0

W jaki sposób prekompilujesz na produkcji (jakiego ustawienia używasz)?Czy przekompiluje wszystko? – Yishai

0

Niektóre pojemniki JSP (zgodnie z sekcją 8.4.2 specyfikacji JSP 1.2) obsługują funkcję prekompilowania strony JSP.

Aby precompile stronę JSP, dostęp do strony z ciąg kwerendy? Jsp_precompile

http://hostname.com/mywebapp/mypage.jsp?jsp_precompile 

strona JSP nie zostanie wykonany. Jeśli kontener obsługuje prekompilację, strona JSP zostanie skompilowana w razie potrzeby.

Zobacz także http://www.rgagnon.com/javadetails/java-0414.html

0

Pablojim jest na dobrej drodze. Potrzebujesz więcej informacji, aby uzyskać pełny obraz tego, co się dzieje. Oto, jak to rozumiem.

W prod, zmieniłeś jsp, który wymaga ponownej kompilacji innych jsp. Aby je skompilować, musi się zdarzyć jedna z dwóch rzeczy:

  1. Skompilowana wersja jsp musi zostać usunięta.
  2. Sam JSP musi być zmodyfikowany (lub nawet jeśli jest to „dotknął” - data modyfikacji jest aktualizowana)

Jeśli trzeba jeszcze sprawdzić, czy wszystkie strony JSP pracować, będą one wszystkie muszą być precompiled using an ant task. to również pozwala na wdrożenie pliku wojny z prekompilowanymi jsps w pliku wojny. To powinno rozwiązać twój problem.

Jeśli twoje pliki nie są rozmieszczone w pliku wojennym, ale w formacie rozłożonym, powinieneś seriously consider packaging your web app w pliku wojennym do rozmieszczenia. To sprawia, że ​​jest to miły pakiet do wdrażania między środowiskami.

+0

Jest on wdrażany na wojnie, a ja dokonuję weryfikacji z prekompilacją, ale wyniki prekompilacji są po prostu wyrzucane, więc JBoss podejmuje własne decyzje dotyczące rekompilacji, a w tym przypadku nie jest wystarczająco agresywny. – Yishai