Comments on: Skrytý drahokam Springu

By: Petr Juza

Petr Juza — Tue, 27 Jan 2009 12:59:14 +0000

Kromě @Configurable je ještě možné k podobným účelům použít ProxyFactory, ale to není vůbec tak hezké a hlavně to neřeší inicializaci objektů, kterou nemáme pod kontrolou, např. vytváření objektů Hibernatem. Něco málo jsem o tom napsal zde.

By: Lukáš Křečan

Lukáš Křečan — Mon, 26 Jan 2009 21:35:13 +0000

Dík za zkušenosti z praxe.

By: Lukas

Lukas — Mon, 26 Jan 2009 13:00:17 +0000

Dagi, presne. Par dni jsem si s tim hral v prostredi, kde se pouziva maven.

Compile time weaving bylo nemozne nastavit v Eclipse rucne. Natoz donutit maven, aby pro kazde IDE generoval spravny konfigurak, ktery to zapne.

I Runtime weaving se musi nastavovat v IDE rucne, ale zaroven ho neni mozne mit v produkci, takze se musi delat 2 ruzne buldy.

By: Dagi

Dagi — Mon, 26 Jan 2009 09:14:06 +0000

Bohuzel ten drahokam je tak skryty, ze z toho muze jednoho bolet hlava . Problem je v tom, ze pokud tam ten weaving neni, tak se uzivatel hrozne divi, ze se DI neprovede. Mozna vam to neprijde podstatne, ale nam se stalo, pri pouziti tehle techniky a lidi celkem matlo. Pustili si v IDE testy a hrozne se divili, ze to nefakci. No samozrejme by to fakcilo, kdyby vedeli, ze pro tu magii je potreba. Nerikam ze je to chyba technologie, ale...

By: Honza Novotný

Honza Novotný — Sat, 24 Jan 2009 12:25:12 +0000

O jej, kdybych jen četl dokumentaci do konce .... :

"6.8.1.2. Working with multiple application contexts

The AnnotationBeanConfigurerAspect used to implement the @Configurable support is an AspectJ singleton aspect. The scope of a singleton aspect is the same as the scope of static members, that is to say there is one aspect instance per classloader that defines the type. This means that if you define multiple application contexts within the same classloader hierarchy you need to consider where to define the bean and where to place spring-aspects.jar on the classpath.

Consider a typical Spring web-app configuration with a shared parent application context defining common business services and everything needed to support them, and one child application context per servlet containing definitions particular to that servlet. All of these contexts will co-exist within the same classloader hierarchy, and so the AnnotationBeanConfigurerAspect can only hold a reference to one of them. In this case we recommend defining the bean in the shared (parent) application context: this defines the services that you are likely to want to inject into domain objects. A consequence is that you cannot configure domain objects with references to beans defined in the child (servlet-specific) contexts using the @Configurable mechanism (probably not something you want to do anyway!).

When deploying multiple web-apps within the same container, ensure that each web-application loads the types in spring-aspects.jar using its own classloader (for example, by placing spring-aspects.jar in 'WEB-INF/lib'). If spring-aspects.jar is only added to the container wide classpath (and hence loaded by the shared parent classloader), all web applications will share the same aspect instance which is probably not what you want."

By: Honza Novotný

Honza Novotný — Sat, 24 Jan 2009 12:21:25 +0000

Zdá se mi, že tahle technika asi nebude použitelná v případě, že v aplikaci běží víc aplikačních kontextů. Protože z ukázek není patrné, jak by bylo možné zvolit ten správný kontext, který mě například zajímá pro autowiring. Nebo je tu něco co jsem nepostřehl?

Na první pohled se mi tohle zdá jako fakt už velká magie. Kdybych studoval cizí kód který by něco takového používal a já o této možnosti nevěděl, tak jsem asi v koncích.

By: Lukáš Křečan

Lukáš Křečan — Sat, 24 Jan 2009 06:42:48 +0000

Ještě jsem o tom přemýšlel a napadly mě dvě věci.
1) @palo Máš pravdu, ono to ani jinak než staticky vyřešit nejde. Prostě je tam natvrdo vazba mezi třídou a konfigurací, ne mezi instancí a konfigurací. Varianta s AspectJ je jen mnohem lépe testovatelná než přímé volání statických metod.
2) Asi jsem špatně zvolil příklad, místo User.remove() tam mělo být User.leave() nebo User.die(), prostě něco co má smysl z obchodního hlediska, ne databázového.

By: Lukáš Křečan

Lukáš Křečan — Fri, 23 Jan 2009 17:10:28 +0000

Co se týče rychlosti při startu, předpokládám, že by to mohlo vyřešit přesunutí úprav bytecode do kompilace, popřípadě nějaký filtr, který omezí množství prohledávaných tříd.

By: palo

palo — Fri, 23 Jan 2009 12:13:38 +0000

@vlasta:
zkus si precist Domain Driven Design od Erica Evanse (je opravdu vyborna - http://domaindrivendesign.org/books/index.html#DDD) a/nebo dalsi zdroje na webu, napr. http://debasishg.blogspot.com/search/label/ddd a potom mozna zmenis nazor a nebude to fuj )

By: Vlasta

Vlasta — Fri, 23 Jan 2009 10:33:44 +0000

Naucit objekty fukcionalitu napr persistovat je?

S tim nemohu souhlasit. To si pak kazdy muze volatu User.save() kdy a kde se mu to libi. Vedlo by to k rozdrobeni business logiky. Kdo nam zaruci, ze kdyz ma User ve svem ifacu metodu save(), ze bude vzdy spravne nasetovane DAO (nebo EntityManager).

Kdyz se tento pristup dovede ad absurdum tak by zadne servisni metody nebyly potreba...Fuj