sobota, 31 stycznia 2015

JRebel, ADF i nieprzeładowane strony.

Chwała!
Po długiej, chyb nawet zbyt, przerwie czas wysilić swoje pozostałe szare komórki, póki fałdy na korze jakieś zostały. Okazja się akurat trafiła sama, bo w ramach obowiązków zawodowych mam okazję sprawdzić w boju produkt firmy ZeroTurnaround - JRebel.
Właśnie w trakcie tego sprawdzania napotkałem na początkowo dość zagadkowy problem, który poniżej postaram się naświetlić. Otóż, mam ci ja aplikację zewnętrzną, podbudowę czy też rdzeń systemu, w technologii Oracle ADF. Natomiast sam dopisuję do niej moduły biblioteki rozszerzeń dostosowującej tenże rdzeń do zachcianek i zapotrzebowań klienta. No więc dopisuję sobie nowy tzw. fragment strony, wszystko ładnie mi JRebel przeładowuje, jest fajnie. Biorę się za następny i... i nic, tak jakby JRebel zmian nie widział. Co ciekawe, przepływ odświeża, ziarna też, tylko sama strona jak wyglądała tak wygląda. Ki czort? Hmmm... Po restarcie zmiany widać, ale nowych znów niet. Hmmm... Rzut oka w logi, i co? I wszystko wygląda na to, że... działa.
2015-01-29 08:26:23.947 TRACE [IntelliJFSNotify] >> path\to\my\changed\PageFragment.jsff
2015-01-29 08:26:23.947 INFO  [IntelliJFSNotify] Event 'CHANGE' on: 'path\to\my\changed\PageFragment.jsff'
2015-01-29 08:26:23.955 TRACE [IntelliJFSNotify] >> CHANGE
2015-01-29 08:26:31.733 INFO  [ADF-Core] ADF metadata resource modified: file:/path\to\my\changed\PageFragment.jsff
2015-01-29 08:26:31.767 DEBUG [ADF-Core] ResourceMonitor instance named 'BindingRequestHandler' returns new positive result
2015-01-29 08:26:31.767 INFO  [ADF-Core] Purging page and view definition cache
2015-01-29 08:26:31.767 INFO  [ADF-Core] Reinserting juMom definition
2015-01-29 08:26:31.767 DEBUG [Mojarra] FacesConfigReloader.reload invoked
2015-01-29 08:26:31.767 DEBUG [Mojarra] Capturing NavigationHandler state.
2015-01-29 08:26:31.767 TRACE [Mojarra] NavigationDiff: null
2015-01-29 08:26:31.767 INFO  [Mojarra] Reloading configuration
2015-01-29 08:26:31.767 INFO  [Mojarra] Application does not allow to unsubscribe listeners
2015-01-29 08:26:31.767 INFO  [Mojarra] Application class: com.sun.faces.application.ApplicationImpl
2015-01-29 08:26:31.767 TRACE [Mojarra] Reload on oracle.adfinternal.view.faces.lifecycle.LifecycleImpl@75aec8d1 and org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit@5b5cca6 with sc weblogic.servlet.internal.WebAppServletContext@79606145 and cm com.sun.faces.config.ConfigManager@613b3643
2015-01-29 08:26:31.767 TRACE [Mojarra] Clear done
Zagwozdka coraz większa. O! Przelogowanie też powoduje „odświeżenie” zmian. Zastanówmy się poważnie...
Bingo! Tak jest! Cóż to więc okazuje się naszym winowajcą? Ano, aplikacja ma skonfigurowane dostosowywanie (customization) na poziomie użytkownika (UserCC). To powoduje, że każda zmiana na stronie stanu np. zwinięcia segmentu akordeonu czy też widoczności kolumn w tabeli jest zapamiętywane w MDS i nakładane w każdej sesji użytkownika. Fajny mechanizm, dzięki któremu korzystający z aplikacji ma taki układ stron w aplikacji jaki mu wygodnie. Problem w tym, że zmiany te nie są przez mechanizmy WebLogica nakładane na „oryginał” w momencie wchodzenia na stronę, tylko przy logowaniu się użytkownika. Przez co zmiany „przeładowywane” przez JRebel nie znajdowały odzwierciedlenia w treści serwowanej do przeglądarki. Wyjście? Skasowanie plików *.jsff.xml z odpowiedniego podkatalogu lokalnego MDS. No i teraz furczy aż miło. Można wrócić do generowania kolejnych błędów w oprogramowaniu ;)

P.S. Przy okazji jest to setna notka na blogu. Sam nie wiem, czy to dużo, czy mało, ale pękła i już!