4 komentáře “Jednoduché logování ve Springu

  1. Ano, myslím, že tohle bude to správné vysvětlení. Osobně se Cglib proxy nestraním – v případě, že nemá interface opodstatnění (vždy bude jen jediná implementace), bych jej kvůli potřebě použití JDK proxy nezakládal.

  2. Jo tenhle článek jsem četl a nic podezřelého jsem nenašel (final třída apod.). Po kratším zamyšlení ale myslím, že problém je v tom, že už samotné beany vyzvedávané z kontejneru (bez AOP logování) jsou instance proxy tříd, protože jejich metody jsou anotované jako @Transactional a vzniká tak potřeba proxy přístupu. Pokud jsem správně pochopil dokumentaci, Spring upřednostňuje JDK dynamic proxy pokud je to možné (zde je to díky použití interfaces možné), výsledná proxy třída je pak final a CGLIB proxy pro potřeby logování k ní už vytvořit nejde. Pravděpodobně by se dalo nakonfigurovat vytváření CGLIB proxy i pro transaction management a pak by to fungovalo s CGLIB pro logování a s JDK dynamic proxy už zase ne…
    Každopádně JDK dynamic proxy je mi tak nějak bližší, protože podobným způsobem (přes interface) bych to dělal, kdybych měl podobné logování dodělat „ručně“ – rozhodně bych nepoužil dědění. Samozřejmě předpokladem je, že ty potřebné interfaces existují.

  3. Zajimavý článek o Cglib2AopProxy: http://insufficientinformation.blogspot.com/2007/12/spring-dynamic-proxies-vs-cglib-proxies.html

    Tahle vyjímka nastává, pokud se člověk snaží vybudovat proxy nad finální třídou, nebo třídou bez bezparametrického konstruktoru. Možná také maskuje vyjímky, které se vyhodí při volání konstruktoru třídy.

    Každopádně já Cglib proxy používám poměrně rutinně a taky fungují bez problémů.

  4. Začínám si s tím hrát a narazil jsem na problém s CGLIB proxy „Could not generate CGLIB subclass of class“. Po pravdě jsem nepřišel na přesný důvod, ale vzhledem k tomu, že mám všechno striktně řešené přes interfaces, zdálo se mi nakonec i jako vhodnější použít JDK dynamic proxy a funguje to bez problémů. Zde to znamená změnit v ukázkovém konfiguračním souboru proxyTargetClass na false. Tak to jen kdyby měl třeba někdo podobný problém.

  5. Myslim ze na produkci by melo by standardne vse na info, nejen chyby te zajimaji, ale i co se delo pred, protoze ne vzdy je monze pouzit postup co jsi popsal, tj. po chybe zmenime logovani a pak zjistime vic.

  6. Ad Lubor) ano, to je obecně známá vlastnost „proxy based AOP“ – nicméně myslím, že už na základě mezivrstvového volání metod mezi objekty se dá lecos o problematické situaci odvodit

  7. Malou nevyhodou tohto riesenia je ze „proxy based AOP“ nieje mozne aplikovat na vnutorne volania metod vramci danej spring beany, ale iba v pripade ak je metoda volana zvonka inou beanou (teda ak volanie prechadza cez AOP proxy). Takze prakticka pouzitelnost je do znacnej miery zavisla na strukture vasho kodu (v akej miere pouziva vnutorne volania metod).

  8. Vycházeli jsme z této úvahy – na produkčním prostředí je logování typicky nastavené na level WARN nebo ERROR. Tato advice loguje volání metod na úrovni TRACE. Tzn. na produkčním prostředí se do logu typicky nic nedostane.

    V případě, že narazíme na chybu, kterou nedokážeme odhalit podle chybového stacktrace, požádáme administrátory zákazníka, aby nám upravili odpovídajícím způsobem log4j konfiguraci (respektive jim pošleme celý konfigurační soubor) a na patřičných místech si zvýšíme loglevel na hodnotu TRACE.

    V tu dobu je tedy možné že by se mohly zalogovat i citlivá data. Nicméně počítáme s tím, že po odstranění chyby se vrátí zpět původní nastavení hladin logu a vyrobené logy s TRACE levelem se odstraní.

    Navíc máme tedy ještě tu výhodu, že nás systém nepracuje s výrazně citlivými daty, takže je tato politika akceptovatelná. Nicméně ano – v případě požadavku na zabezpečení citlivých dat je určitě legitimní mít vlastní custom advice.

    O tomto řešení jsem psal hlavně z toho důvodu, že většinou tak super zabezpečení není třeba a pro tyto účely máme již připravené řešení ve Springu out of the box.

  9. Zajímavé. Dosud jsme pro stejný účel používali námi napsaný aspect.
    Zajímalo by mě, jestli v produkčním prostředí logujete opravu všechny public metody *Manager a *Storage tříd, nebo jestli rozlišujete nějakou sadu metod / argumentů, které logovat nechcete (např. citlivá data jako hesla nebo rodná čísla klientů). A pokud ano, jak se toho docílí (na úrovni definice dynamické proxy nebo nějak jinak?).

  10. To si musím někam uložit velmi zajímavá informace 🙂 A o třídě org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator jsem taky nevěděl, ale vypadá to velmi užiečně když chcu všechny bean obalit stejném Interceptor.