Comments on: Jednoduché logování ve Springu

By: Otec Fura

Otec Fura — Mon, 25 Jan 2010 20:06:57 +0000

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.

By: niko

niko — Mon, 25 Jan 2010 15:25:59 +0000

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í.

By: Otec Fura

Otec Fura — Mon, 25 Jan 2010 05:17:08 +0000

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ů.

By: niko

niko — Fri, 22 Jan 2010 17:00:51 +0000

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.

By: Michal Franc

Michal Franc — Thu, 07 May 2009 14:01:58 +0000

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.

By: Otec Fura

Otec Fura — Thu, 07 May 2009 12:18:12 +0000

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

By: Lubor Gajda

Lubor Gajda — Thu, 07 May 2009 11:53:44 +0000

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).

By: Otec Fura

Otec Fura — Thu, 07 May 2009 11:35:31 +0000

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.

By: Tomáš Piňos

Tomáš Piňos — Thu, 07 May 2009 11:26:25 +0000

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?).

By: Tomáš Homola

Tomáš Homola — Thu, 07 May 2009 09:30:14 +0000

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.