Spring \u00e7er\u00e7evesinde AOP (Aspect-Oriented Programming – Y\u00f6nelimli Programlama) ve di\u011fer bir\u00e7ok \u00f6zellik, proxy mekanizmalar\u0131 arac\u0131l\u0131\u011f\u0131yla hayata ge\u00e7irilir. Bu makalede, Spring’in kulland\u0131\u011f\u0131 iki temel proxy olu\u015fturma tekni\u011fini, JDK Dinamik Proxy ve CGLIB’i derinlemesine inceleyece\u011fiz. Hangi durumda hangisinin tercih edilmesi gerekti\u011fini ve performans farklar\u0131n\u0131 ke\u015ffederken, ger\u00e7ek d\u00fcnya senaryolar\u0131yla konuyu somutla\u015ft\u0131raca\u011f\u0131z.<\/p>\n
Modern yaz\u0131l\u0131m geli\u015ftirmede, bir uygulaman\u0131n temel i\u015f mant\u0131\u011f\u0131na odaklan\u0131rken, enine kesen (cross-cutting) endi\u015feleri y\u00f6netmek b\u00fcy\u00fck bir zorluktur. G\u00fcvenlik kontrolleri, i\u015flem (transaction) y\u00f6netimi, \u00f6nbellekleme (caching), loglama veya performans \u00f6l\u00e7\u00fcmleri gibi g\u00f6revler, uygulaman\u0131n bir\u00e7ok farkl\u0131 yerinde tekrar tekrar kar\u015f\u0131m\u0131za \u00e7\u0131kar. Kodunuzu her yeni \u00f6zellik i\u00e7in ba\u015ftan yazmak yerine, mevcut i\u015flevselli\u011fe nas\u0131l yeni yetenekler ekleyebilirsiniz? \u0130\u015fte tam bu noktada, Spring’in proxy mekanizmalar\u0131 devreye girer ve geli\u015ftiricilere e\u015fsiz bir esneklik sunar. Proxy’ler, mevcut kodu de\u011fi\u015ftirmeden veya kirletmeden, bir nesnenin davran\u0131\u015f\u0131n\u0131 geni\u015fletmek veya de\u011fi\u015ftirmek i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r.<\/p>\n
Spring, \u00f6zellikle AOP (Aspect-Oriented Programming) uygulamalar\u0131nda bu vekil (proxy) mekanizmalar\u0131n\u0131 yo\u011fun bir \u015fekilde kullan\u0131r. AOP, i\u015f mant\u0131\u011f\u0131n\u0131 kesen (cross-cutting concerns) bu t\u00fcr endi\u015feleri mod\u00fcler bir \u015fekilde y\u00f6netmeyi ama\u00e7lar. \u00d6rne\u011fin, bir metodun \u00e7a\u011fr\u0131lmas\u0131ndan \u00f6nce g\u00fcvenlik kontrol\u00fc yapmak, metodun \u00e7al\u0131\u015fma s\u00fcresini \u00f6l\u00e7mek veya bir istisna (exception) durumunda belirli bir i\u015flemi tetiklemek isteyebilirsiniz. Spring, bu “y\u00f6nleri” (aspects) uygulaman\u0131z\u0131n belirli “kat\u0131lma noktalar\u0131na” (join points) dinamik olarak “dokumak” (weave) i\u00e7in proxy’leri kullan\u0131r. Bu sayede, temel i\u015f mant\u0131\u011f\u0131n\u0131z temiz kal\u0131r ve yan endi\u015feler ayr\u0131 mod\u00fcllerde y\u00f6netilir. Bu yakla\u015f\u0131m, kod tekrar\u0131n\u0131 azalt\u0131r, mod\u00fclerli\u011fi art\u0131r\u0131r ve uygulaman\u0131n bak\u0131m\u0131n\u0131 kolayla\u015ft\u0131r\u0131r. Spring’in sa\u011flad\u0131\u011f\u0131 bu soyutlama, geli\u015ftiricilerin proxy’lerin karma\u015f\u0131k detaylar\u0131na inmeden AOP’nin avantajlar\u0131ndan faydalanmas\u0131n\u0131 sa\u011flar, ancak bu mekanizmalar\u0131n nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak, daha derinlemesine sorun giderme ve optimizasyon i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n
Proxy mekanizmalar\u0131n\u0131 anlamak i\u00e7in \u00f6ncelikle temel kavramlar\u0131 netle\u015ftirmek gerekir. Bir proxy (vekil)<\/strong>, ger\u00e7ek bir nesne i\u00e7in bir yer tutucu veya sarmalay\u0131c\u0131 (wrapper) g\u00f6revi g\u00f6ren bir nesnedir. \u0130stemci, do\u011frudan ger\u00e7ek nesneyle etkile\u015fime girmek yerine, vekil arac\u0131l\u0131\u011f\u0131yla ger\u00e7ek nesneye eri\u015fir. Bu sayede vekil, ger\u00e7ek nesneye yap\u0131lan \u00e7a\u011fr\u0131lar\u0131 kesebilir (intercept) ve \u00e7a\u011fr\u0131 \u00f6ncesi veya sonras\u0131nda ek davran\u0131\u015flar ekleyebilir. Bu, \u00f6zellikle g\u00fcvenlik, loglama, \u00f6nbellekleme veya i\u015flem y\u00f6netimi gibi enine kesen i\u015flevsellikleri temel i\u015f mant\u0131\u011f\u0131ndan ay\u0131rmak istedi\u011fimizde \u00e7ok kullan\u0131\u015fl\u0131d\u0131r.<\/p>\n Metot vekil (method interception)<\/strong>, bir metot \u00e7a\u011fr\u0131s\u0131n\u0131n hedef nesneye ula\u015fmadan \u00f6nce veya ula\u015ft\u0131ktan sonra araya girme s\u00fcrecidir. Proxy, bir metot \u00e7a\u011fr\u0131s\u0131 ald\u0131\u011f\u0131nda, bu \u00e7a\u011fr\u0131y\u0131 do\u011frudan hedef nesneye iletmek yerine, \u00f6nce kendi vekil mant\u0131\u011f\u0131n\u0131 \u00e7al\u0131\u015ft\u0131r\u0131r. Bu mant\u0131k, \u00e7a\u011fr\u0131y\u0131 loglamak, g\u00fcvenlik kontrol\u00fc yapmak veya bir \u00f6nbellekten veri d\u00f6nd\u00fcrmek gibi \u00e7e\u015fitli eylemler olabilir. Ard\u0131ndan, vekil isterse \u00e7a\u011fr\u0131y\u0131 ger\u00e7ek nesneye iletir ve ger\u00e7ek nesnenin d\u00f6n\u00fc\u015f de\u011ferini veya istisnas\u0131n\u0131 da vekilleyebilir. Bu dinamik davran\u0131\u015f ekleme yetene\u011fi, AOP’nin temelini olu\u015fturur ve Spring gibi \u00e7er\u00e7evelerin g\u00fcc\u00fcn\u00fc art\u0131r\u0131r.<\/p>\n Aspect-Oriented Programming (AOP – Y\u00f6nelimli Programlama)<\/strong>, bir uygulaman\u0131n bir\u00e7ok farkl\u0131 b\u00f6l\u00fcm\u00fcn\u00fc etkileyen enine kesen endi\u015feleri mod\u00fcler hale getirmeyi ama\u00e7layan bir programlama paradigmas\u0131d\u0131r. Geleneksel nesne y\u00f6nelimli programlamada, bu t\u00fcr endi\u015feler genellikle kod tekrar\u0131na veya kodun da\u011f\u0131lmas\u0131na neden olabilir. AOP, bu endi\u015feleri “y\u00f6nler” (aspects) olarak adland\u0131r\u0131lan ayr\u0131 mod\u00fcllerde kaps\u00fclleyerek bu sorunu \u00e7\u00f6zer. Bir y\u00f6n, belirli “kat\u0131lma noktalar\u0131nda” (join points – \u00f6rne\u011fin metot \u00e7a\u011fr\u0131lar\u0131, istisna f\u0131rlatmalar\u0131) \u00e7al\u0131\u015facak “tavsiyeler” (advices) i\u00e7erir. Spring AOP, bu tavsiyeleri \u00e7al\u0131\u015fma zaman\u0131nda (run-time) proxy’ler arac\u0131l\u0131\u011f\u0131yla uygulayarak “dokuma” (weaving) i\u015flemini ger\u00e7ekle\u015ftirir. Bu, kodun derleme zaman\u0131nda veya y\u00fckleme zaman\u0131nda de\u011fi\u015ftirilmesine gerek kalmadan, uygulaman\u0131n davran\u0131\u015f\u0131n\u0131 dinamik olarak de\u011fi\u015ftirmemizi sa\u011flar.<\/p>\n Proxy mekanizmalar\u0131nda, aray\u00fcz (interface)<\/strong> ve s\u0131n\u0131f (class)<\/strong> aras\u0131ndaki fark kritik \u00f6neme sahiptir. Baz\u0131 proxy olu\u015fturma teknikleri sadece aray\u00fczleri vekilleyebilirken, di\u011ferleri somut s\u0131n\u0131flar\u0131 vekilleyebilir. Aray\u00fcz tabanl\u0131 vekilleme, bir nesnenin uygulad\u0131\u011f\u0131 aray\u00fczleri temel alarak bir proxy olu\u015fturur. Bu, istemcinin sadece aray\u00fcz s\u00f6zle\u015fmesi \u00fczerinden etkile\u015fim kurdu\u011fu durumlarda iyi \u00e7al\u0131\u015f\u0131r. S\u0131n\u0131f tabanl\u0131 vekilleme ise, do\u011frudan bir s\u0131n\u0131f\u0131n alt s\u0131n\u0131f\u0131n\u0131 (subclass) olu\u015fturarak ve metotlar\u0131n\u0131 ge\u00e7ersiz k\u0131larak (override) proxy olu\u015fturur. Bu yakla\u015f\u0131m, hedef nesnenin bir aray\u00fcz uygulamad\u0131\u011f\u0131 veya geli\u015ftiricinin s\u0131n\u0131f\u0131n somut metotlar\u0131n\u0131 vekillemek istedi\u011fi durumlarda gereklidir. Spring, hem JDK Dinamik Proxy ile aray\u00fcz tabanl\u0131 vekillemeyi hem de CGLIB ile s\u0131n\u0131f tabanl\u0131 vekillemeyi destekleyerek geli\u015ftiricilere esneklik sunar.<\/p>\n JDK Dinamik Proxy, Java’n\u0131n kendi standart k\u00fct\u00fcphanesinde yer alan ve dinamik olarak proxy nesneleri olu\u015fturmak i\u00e7in kullan\u0131lan bir mekanizmad\u0131r. Bu mekanizma, \u00f6zellikle Java 5 ve sonras\u0131nda AOP ve benzeri yakla\u015f\u0131mlar i\u00e7in pop\u00fcler hale gelmi\u015ftir. Temel olarak, JDK Dinamik Proxy’ler sadece aray\u00fczleri (interfaces) vekilleyebilir<\/strong>. Yani, vekilini olu\u015fturmak istedi\u011finiz nesnenin mutlaka bir veya daha fazla aray\u00fcz\u00fc uygulamas\u0131 gerekir. Bu, Java’n\u0131n temel prensiplerinden biri olan “implementasyona de\u011fil, aray\u00fcze programla” (program to an interface, not an implementation) felsefesiyle uyumludur.<\/p>\n JDK Dinamik Proxy’nin \u00e7al\u0131\u015fma prensibi olduk\u00e7a zarif ve basittir. Proxy olu\u015fturma s\u00fcreci iki ana bile\u015fen etraf\u0131nda d\u00f6ner: JDK Dinamik Proxy’nin ba\u015fl\u0131ca avantajlar\u0131 \u015funlard\u0131r:<\/p>\n Dezavantajlar\u0131 ise \u015funlard\u0131r:<\/p>\n \u015eimdi basit bir kod \u00f6rne\u011fi ile JDK Dinamik Proxy’nin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 g\u00f6relim:<\/p>\n Bu \u00f6rnekte, CGLIB (Code Generation Library), Java’da \u00e7al\u0131\u015fma zaman\u0131nda (runtime) byte kodu \u00fcreterek proxy nesneleri olu\u015fturmay\u0131 sa\u011flayan g\u00fc\u00e7l\u00fc, \u00fc\u00e7\u00fcnc\u00fc taraf bir k\u00fct\u00fcphanedir. JDK Dinamik Proxy’nin aksine, CGLIB aray\u00fcz uygulamayan s\u0131n\u0131flar\u0131 da vekilleyebilir<\/strong>. Bu, CGLIB’i \u00f6zellikle Spring gibi \u00e7er\u00e7eveler i\u00e7in vazge\u00e7ilmez k\u0131lar, \u00e7\u00fcnk\u00fc \u00e7o\u011fu zaman vekillemek istedi\u011fimiz s\u0131n\u0131flar belirli bir aray\u00fcz\u00fc uygulamayabilir veya sadece somut s\u0131n\u0131f metotlar\u0131n\u0131 vekillemek isteyebiliriz. CGLIB, ASM (Adaptive S\u0131n\u0131f Y\u00f6netimi) adl\u0131 bir ba\u015fka byte kodu manip\u00fclasyon k\u00fct\u00fcphanesini temel alarak \u00e7al\u0131\u015f\u0131r.<\/p>\n CGLIB’in \u00e7al\u0131\u015fma prensibi, hedef s\u0131n\u0131f\u0131n bir alt s\u0131n\u0131f\u0131n\u0131 (subclass) dinamik olarak olu\u015fturmaya dayan\u0131r. Bu alt s\u0131n\u0131f, hedef s\u0131n\u0131f\u0131n final (son) olmayan t\u00fcm metotlar\u0131n\u0131 ge\u00e7ersiz k\u0131lar (override eder). Ge\u00e7ersiz k\u0131l\u0131nan metotlar, \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda, sizin sa\u011flad\u0131\u011f\u0131n\u0131z bir CGLIB’in ba\u015fl\u0131ca avantajlar\u0131 \u015funlard\u0131r:<\/p>\n Dezavantajlar\u0131 ise \u015funlard\u0131r:<\/p>\n \u015eimdi basit bir kod \u00f6rne\u011fi ile CGLIB’in nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 g\u00f6relim:<\/p>\n Bu \u00f6rnekte, Spring Framework, AOP yeteneklerini ve di\u011fer bir\u00e7ok dinamik \u00f6zelli\u011fi sa\u011flamak i\u00e7in hem JDK Dinamik Proxy’yi hem de CGLIB’i ustaca kullan\u0131r. Ancak, geli\u015ftiricinin a\u00e7\u0131k\u00e7a belirtmedi\u011fi durumlarda, hangi proxy mekanizmas\u0131n\u0131n kullan\u0131laca\u011f\u0131na Spring kendisi karar verir. Bu otomatik se\u00e7im s\u00fcreci, genellikle hedef nesnenin bir aray\u00fcz uygulay\u0131p uygulamad\u0131\u011f\u0131na ve Spring konfig\u00fcrasyonundaki belirli ayarlara ba\u011fl\u0131d\u0131r. Spring’in bu konudaki varsay\u0131lan davran\u0131\u015f\u0131, \u00e7o\u011fu senaryo i\u00e7in uygun bir denge sa\u011flar.<\/p>\n Spring’in varsay\u0131lan proxy se\u00e7im mant\u0131\u011f\u0131 \u015fu \u015fekildedir:<\/p>\n Bu se\u00e7imin temel nedenleri \u015funlard\u0131r:<\/p>\n Spring’in bu otomatik se\u00e7imi, g\u00fcnl\u00fck geli\u015ftirme prati\u011finde \u00f6nemli sonu\u00e7lar do\u011furur:<\/p>\n Spring’in proxy se\u00e7imini manuel olarak kontrol etmek i\u00e7in \u00e7e\u015fitli konfig\u00fcrasyon se\u00e7enekleri mevcuttur:<\/p>\n Bu ayar, t\u00fcm AOP proxy’lerinin CGLIB kullan\u0131larak olu\u015fturulmas\u0131n\u0131 sa\u011flar.<\/li>\n Do\u011fru proxy mekanizmas\u0131n\u0131 se\u00e7mek, uygulaman\u0131z\u0131n performans\u0131n\u0131, esnekli\u011fini ve bak\u0131m kolayl\u0131\u011f\u0131n\u0131 etkileyebilir. \u00c7o\u011fu durumda Spring’in varsay\u0131lan se\u00e7imi yeterli olsa da, \u00f6zellikle performans veya belirli k\u0131s\u0131tlamalarla kar\u015f\u0131la\u015f\u0131ld\u0131\u011f\u0131nda bu mekanizmalar\u0131n nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak, do\u011fru karar\u0131 vermenize yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n JDK Dinamik Proxy ve CGLIB aras\u0131ndaki performans farklar\u0131, genellikle geli\u015ftiricilerin merak etti\u011fi \u00f6nemli bir konudur. Genel kan\u0131, CGLIB’in ba\u015flang\u0131\u00e7ta proxy olu\u015fturma maliyetinin (byte kodu \u00fcretme ve y\u00fckleme) daha y\u00fcksek oldu\u011fu, ancak sonras\u0131nda metot \u00e7a\u011fr\u0131lar\u0131nda JDK Dinamik Proxy’den daha h\u0131zl\u0131 olabilece\u011fidir. Bu durum, CGLIB’in do\u011frudan alt s\u0131n\u0131f metot \u00e7a\u011fr\u0131lar\u0131 yapmas\u0131na kar\u015f\u0131n, JDK Dinamik Proxy’nin reflection (yans\u0131ma) API’sini kullanmas\u0131ndan kaynaklan\u0131r.<\/p>\n As\u0131l \u00f6nemli olan, proxy’lerin do\u011fru \u015fekilde kullan\u0131lmas\u0131 ve mimariye uygun se\u00e7imin yap\u0131lmas\u0131d\u0131r. Mikro-benchmark testlerinde k\u00fc\u00e7\u00fck farklar g\u00f6zlemlense de, ger\u00e7ek d\u00fcnya uygulamalar\u0131nda bu farklar genellikle di\u011fer fakt\u00f6rlerin (veritaban\u0131 eri\u015fimi, a\u011f gecikmesi vb.) yan\u0131nda \u00f6nemsiz kal\u0131r. Performans endi\u015fesiyle birini di\u011ferine tercih etmek yerine, mimari gereksinimler ve kullan\u0131m senaryolar\u0131 daha belirleyici olmal\u0131d\u0131r.<\/p>\n Dikkat edilmesi gereken di\u011fer \u00f6nemli noktalar:<\/p>\n \u00d6zetle, Spring’in otomatik proxy se\u00e7imi \u00e7o\u011fu zaman do\u011fru karar\u0131 verir. Ancak, \u00f6zellikle performans kritik uygulamalarda veya yukar\u0131da bahsedilen k\u0131s\u0131tlamalarla kar\u015f\u0131la\u015f\u0131ld\u0131\u011f\u0131nda, hangi proxy mekanizmas\u0131n\u0131n kullan\u0131ld\u0131\u011f\u0131n\u0131 bilmek ve gerekirse manuel olarak yap\u0131land\u0131rmak, olas\u0131 sorunlar\u0131 \u00f6nlemek ve uygulaman\u0131n sa\u011flaml\u0131\u011f\u0131n\u0131 art\u0131rmak i\u00e7in faydal\u0131d\u0131r.<\/p>\n Spring proxy’leri, basit AOP uygulamalar\u0131n\u0131n \u00f6tesinde, daha karma\u015f\u0131k senaryolarda da kar\u015f\u0131m\u0131za \u00e7\u0131kar. Bu b\u00f6l\u00fcmde, proxy’lerin ileri d\u00fczey kullan\u0131m\u0131na dair baz\u0131 ipu\u00e7lar\u0131 ve s\u0131k kar\u015f\u0131la\u015f\u0131lan sorunlara \u00e7\u00f6z\u00fcmler sunaca\u011f\u0131z.<\/p>\n Spring AOP’nin en s\u0131k kar\u015f\u0131la\u015f\u0131lan tuzaklar\u0131ndan biri, bir vekil nesnesinin i\u00e7inden ba\u015fka bir vekil metodu \u00e7a\u011f\u0131rmaya \u00e7al\u0131\u015f\u0131ld\u0131\u011f\u0131nda ortaya \u00e7\u0131kan “self-invocation” (kendi kendini \u00e7a\u011f\u0131rma) problemidir. \u00d6rne\u011fin, bir servis s\u0131n\u0131f\u0131n\u0131n i\u00e7indeki bir metot, ayn\u0131 s\u0131n\u0131f\u0131n ba\u015fka bir Bu sorunu \u00e7\u00f6zmek i\u00e7in birka\u00e7 yakla\u015f\u0131m vard\u0131r:<\/p>\n Veya Bu yakla\u015f\u0131m biraz daha az tercih edilir \u00e7\u00fcnk\u00fc kodunuzu Spring AOP’ye daha s\u0131k\u0131 ba\u011flar ve Spring bile\u015fenlerini test ederken, bazen ger\u00e7ek nesneyi (proxy’siz) test etmek, bazen de proxy’nin kendisini (AOP mant\u0131\u011f\u0131yla birlikte) test etmek isteyebilirsiniz. Proxy’nin kendisini test etmek, AOP y\u00f6nlerinin (transaction, caching vb.) do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olmak i\u00e7in \u00f6nemlidir. Spring’in test ba\u011flam\u0131, genellikle proxy’leri otomatik olarak olu\u015fturur, bu nedenle normalde Spring Boot, proxy konfig\u00fcrasyonunu b\u00fcy\u00fck \u00f6l\u00e7\u00fcde basitle\u015ftirir. Bazen bir proxy’nin bekledi\u011finiz gibi \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 fark edebilirsiniz. Bu durumda, hata ay\u0131klama (debugging) s\u00fcrecinde proxy’nin nas\u0131l olu\u015fturuldu\u011funu ve hangi metotlar\u0131 vekilledi\u011fini anlamak \u00f6nemlidir. CGLIB, dinamik olarak olu\u015fturdu\u011fu s\u0131n\u0131flar\u0131 diske yazma se\u00e7ene\u011fi sunar. Bunu Bu ileri d\u00fczey ipu\u00e7lar\u0131, Spring proxy’leri ile \u00e7al\u0131\u015f\u0131rken kar\u015f\u0131la\u015fabilece\u011finiz yayg\u0131n sorunlar\u0131 \u00e7\u00f6zmenize ve daha sa\u011flam, \u00f6ng\u00f6r\u00fclebilir uygulamalar geli\u015ftirmenize yard\u0131mc\u0131 olacakt\u0131r. Proxy mekanizmalar\u0131n\u0131n derinlemesine anla\u015f\u0131lmas\u0131, \u00f6zellikle karma\u015f\u0131k AOP senaryolar\u0131nda hata ay\u0131klama ve performans optimizasyonu i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n Spring Framework’\u00fcn kalbinde yer alan proxy mekanizmalar\u0131, modern Java uygulamalar\u0131nda AOP’nin ve bir\u00e7ok temel \u00f6zelli\u011fin (i\u015flem y\u00f6netimi, g\u00fcvenlik, \u00f6nbellekleme gibi) dinamik olarak uygulanmas\u0131n\u0131 sa\u011flar. Bu makalede, Spring’in kulland\u0131\u011f\u0131 iki ana proxy olu\u015fturma tekni\u011fini, JDK Dinamik Proxy ve CGLIB’i ayr\u0131nt\u0131l\u0131 bir \u015fekilde inceledik. Her iki mekanizman\u0131n da kendine \u00f6zg\u00fc g\u00fc\u00e7l\u00fc ve zay\u0131f y\u00f6nleri oldu\u011funu g\u00f6rd\u00fck.<\/p>\n \u00d6zetle:<\/p>\n Spring, hedef s\u0131n\u0131f\u0131n bir aray\u00fcz uygulay\u0131p uygulamad\u0131\u011f\u0131na ve konfig\u00fcrasyon ayarlar\u0131na g\u00f6re bu iki mekanizma aras\u0131nda otomatik olarak se\u00e7im yapar. Varsay\u0131lan olarak, aray\u00fcz varsa JDK Dinamik Proxy, yoksa CGLIB tercih edilir. Geli\u015ftiriciler, Proxy teknolojileri, Java ekosisteminde s\u00fcrekli geli\u015fmektedir. \u00d6zellikle GraalVM ve native image (yerel g\u00f6r\u00fcnt\u00fc) deste\u011fi gibi yeni trendler, proxy olu\u015fturma mekanizmalar\u0131n\u0131 etkileyebilir. Native image’ler, \u00e7al\u0131\u015fma zaman\u0131nda byte kodu \u00fcretme yetene\u011fini k\u0131s\u0131tlad\u0131\u011f\u0131 i\u00e7in, proxy’lerin derleme zaman\u0131nda (build time) veya \u00f6nceden olu\u015fturulmas\u0131 (ahead-of-time generation) gibi yakla\u015f\u0131mlar daha fazla \u00f6nem kazanmaktad\u0131r. Spring Framework de bu yeni teknolojilere uyum sa\u011flamak i\u00e7in s\u00fcrekli evrilmekte ve geli\u015ftiricilere en iyi deneyimi sunmaya devam etmektedir.<\/p>\n Sonu\u00e7 olarak, Spring proxy’leri, uygulaman\u0131z\u0131n esnekli\u011fini, mod\u00fclerli\u011fini ve bak\u0131m kolayl\u0131\u011f\u0131n\u0131 art\u0131ran g\u00fc\u00e7l\u00fc ara\u00e7lard\u0131r. Hangi mekanizman\u0131n ne zaman ve neden kullan\u0131ld\u0131\u011f\u0131n\u0131 anlamak, daha sa\u011flam, performansl\u0131 ve s\u00fcrd\u00fcr\u00fclebilir Java uygulamalar\u0131 geli\u015ftirmenize yard\u0131mc\u0131 olacakt\u0131r. Bu bilgiler \u0131\u015f\u0131\u011f\u0131nda, Spring tabanl\u0131 projelerinizde proxy’leri daha bilin\u00e7li bir \u015fekilde kullanabilirsiniz.<\/p>\n Spring, farkl\u0131 vekilleme (proxying) ihtiya\u00e7lar\u0131n\u0131 kar\u015f\u0131lamak i\u00e7in her iki mekanizmay\u0131 da kullan\u0131r. JDK Dinamik Proxy, sadece aray\u00fczleri vekilleyebilir ve Java’n\u0131n standart bir par\u00e7as\u0131d\u0131r. CGLIB ise aray\u00fcz uygulamayan somut s\u0131n\u0131flar\u0131 vekilleyebilir, bu da Spring’e daha fazla esneklik sa\u011flar. Hedef nesnenin aray\u00fcz uygulamas\u0131na veya geli\u015ftiricinin tercihine g\u00f6re Spring bu ikisinden birini otomatik olarak se\u00e7er.<\/p>\n<\/li>\n E\u011fer bir s\u0131n\u0131f Proxy’ler, metot \u00e7a\u011fr\u0131lar\u0131na ek bir katman ekledi\u011fi i\u00e7in teorik olarak k\u00fc\u00e7\u00fck bir performans maliyetine sahiptir. CGLIB’in ilk olu\u015fturma maliyeti daha y\u00fcksekken, sonraki metot \u00e7a\u011fr\u0131lar\u0131 genellikle JDK Dinamik Proxy’den daha h\u0131zl\u0131d\u0131r. Ancak, modern JVM’lerin optimizasyonlar\u0131 sayesinde, \u00e7o\u011fu ger\u00e7ek d\u00fcnya uygulamas\u0131nda bu farklar ihmal edilebilir d\u00fczeydedir. Uygulaman\u0131n genel performans\u0131 \u00fczerinde daha \u00e7ok veritaban\u0131 eri\u015fimi, a\u011f gecikmesi gibi fakt\u00f6rler etkili olur.<\/p>\n<\/li>\n Evet, Spring’in AOP API’si olduk\u00e7a esnektir. Kendi \u00f6zel #SpringFramework #Java #AOP #Proxy #JDKDynamicProxy #CGLIB<\/p>\nJDK Dinamik Proxy Nedir ve Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h2>\n
java.lang.reflect.Proxy<\/code> s\u0131n\u0131f\u0131 ve java.lang.reflect.InvocationHandler<\/code> aray\u00fcz\u00fc. Proxy<\/code> s\u0131n\u0131f\u0131, \u00e7al\u0131\u015fma zaman\u0131nda (runtime) yeni bir proxy s\u0131n\u0131f\u0131 olu\u015fturur ve bu s\u0131n\u0131f\u0131 belle\u011fe y\u00fckler. Bu yeni s\u0131n\u0131f, belirtilen aray\u00fczleri uygular ve t\u00fcm metot \u00e7a\u011fr\u0131lar\u0131n\u0131, sizin sa\u011flad\u0131\u011f\u0131n\u0131z InvocationHandler<\/code> uygulamas\u0131ndaki invoke<\/code> metoduna y\u00f6nlendirir. InvocationHandler<\/code> ise, ger\u00e7ek i\u015f mant\u0131\u011f\u0131n\u0131n nerede ve nas\u0131l y\u00fcr\u00fct\u00fclece\u011fine karar veren bile\u015fendir. invoke<\/code> metodu, \u00e7a\u011fr\u0131lan metot, metot parametreleri ve proxy \u00f6rne\u011fi hakk\u0131nda bilgi i\u00e7erir. Bu sayede, metot \u00e7a\u011fr\u0131s\u0131 \u00f6ncesi veya sonras\u0131nda \u00f6zel mant\u0131k ekleyebilir, \u00e7a\u011fr\u0131y\u0131 ger\u00e7ek nesneye iletebilir veya tamamen farkl\u0131 bir de\u011fer d\u00f6nd\u00fcrebilirsiniz.<\/p>\n\n
\n
\nimport java.lang.reflect.InvocationHandler;\nimport java.lang.reflect.Method;\nimport java.lang.reflect.Proxy;\n\n\/\/ 1. Bir Aray\u00fcz Tan\u0131mlayal\u0131m\ninterface MyService {\n void doSomething();\n String getData(String id);\n}\n\n\/\/ 2. Aray\u00fcz\u00fcn Ger\u00e7ek Uygulamas\u0131\nclass MyServiceImpl implements MyService {\n @Override\n public void doSomething() {\n System.out.println(\"MyServiceImpl: \u0130\u015flem yap\u0131l\u0131yor...\");\n }\n\n @Override\n public String getData(String id) {\n System.out.println(\"MyServiceImpl: ID \" + id + \" i\u00e7in veri al\u0131n\u0131yor.\");\n return \"Veri-\" + id;\n }\n}\n\n\/\/ 3. InvocationHandler Uygulamas\u0131\nclass MyInvocationHandler implements InvocationHandler {\n private final Object target; \/\/ Ger\u00e7ek nesne\n\n public MyInvocationHandler(Object target) {\n this.target = target;\n }\n\n @Override\n public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {\n \/\/ Metot \u00e7a\u011fr\u0131s\u0131 \u00f6ncesi mant\u0131k\n System.out.println(\"Proxy: Metot \u00e7a\u011fr\u0131l\u0131yor: \" + method.getName());\n if (args != null) {\n System.out.print(\"Proxy: Parametreler: \");\n for (Object arg : args) {\n System.out.print(arg + \" \");\n }\n System.out.println();\n }\n\n \/\/ Ger\u00e7ek metodu \u00e7a\u011f\u0131r\n Object result = method.invoke(target, args);\n\n \/\/ Metot \u00e7a\u011fr\u0131s\u0131 sonras\u0131 mant\u0131k\n System.out.println(\"Proxy: Metot \u00e7a\u011fr\u0131s\u0131 tamamland\u0131: \" + method.getName());\n if (result != null) {\n System.out.println(\"Proxy: D\u00f6n\u00fc\u015f de\u011feri: \" + result);\n }\n return result;\n }\n}\n\n\/\/ 4. Proxy Olu\u015fturma ve Kullanma\npublic class JdkDynamicProxyExample {\n public static void main(String[] args) {\n MyService realService = new MyServiceImpl();\n\n \/\/ Proxy olu\u015fturma\n MyService proxyService = (MyService) Proxy.newProxyInstance(\n realService.getClass().getClassLoader(), \/\/ S\u0131n\u0131f y\u00fckleyici\n realService.getClass().getInterfaces(), \/\/ Vekillenecek aray\u00fczler\n new MyInvocationHandler(realService) \/\/ InvocationHandler \u00f6rne\u011fi\n );\n\n \/\/ Proxy \u00fczerinden metotlar\u0131 \u00e7a\u011f\u0131r\n proxyService.doSomething();\n System.out.println(\"--------------------\");\n String data = proxyService.getData(\"123\");\n System.out.println(\"Ana Uygulama: Al\u0131nan veri: \" + data);\n }\n}\n<\/code><\/pre>\n<\/div>\nMyService<\/code> aray\u00fcz\u00fcn\u00fc uygulayan MyServiceImpl<\/code> s\u0131n\u0131f\u0131 i\u00e7in bir proxy olu\u015fturduk. MyInvocationHandler<\/code> sayesinde, doSomething()<\/code> ve getData()<\/code> metotlar\u0131 \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda ek loglama mesajlar\u0131 ekleyebildik. Bu, JDK Dinamik Proxy’nin \u00e7al\u0131\u015fma zaman\u0131nda nas\u0131l dinamik olarak davran\u0131\u015f ekleyebildi\u011fini a\u00e7\u0131k\u00e7a g\u00f6stermektedir.<\/p>\nCGLIB (Code Generation Library) Nedir ve Neden Kullan\u0131l\u0131r?<\/h2>\n
net.sf.cglib.proxy.MethodInterceptor<\/code> uygulamas\u0131na y\u00f6nlendirilir. MethodInterceptor<\/code> aray\u00fcz\u00fcndeki intercept<\/code> metodu, JDK Dinamik Proxy’deki InvocationHandler<\/code>‘\u0131n invoke<\/code> metoduna benzer \u015fekilde \u00e7al\u0131\u015f\u0131r. Bu metot, orijinal metot \u00e7a\u011fr\u0131s\u0131 hakk\u0131nda bilgi (proxy nesnesi, \u00e7a\u011fr\u0131lan metot, parametreler) i\u00e7erir ve vekilin \u00e7a\u011fr\u0131 \u00f6ncesi veya sonras\u0131nda ek mant\u0131k y\u00fcr\u00fctmesine olanak tan\u0131r. E\u011fer isterseniz, MethodProxy<\/code> nesnesini kullanarak orijinal metodu \u00e7a\u011f\u0131rabilir veya tamamen farkl\u0131 bir de\u011fer d\u00f6nd\u00fcrebilirsiniz. Bu alt s\u0131n\u0131f olu\u015fturma yakla\u015f\u0131m\u0131, CGLIB’in aray\u00fczs\u00fcz s\u0131n\u0131flar\u0131 vekilleme yetene\u011finin anahtar\u0131d\u0131r.<\/p>\n\n
\n
cglib<\/code>) eklemeniz gerekir.<\/li>\nfinal<\/code> olarak i\u015faretlenmi\u015fse, CGLIB o s\u0131n\u0131f\u0131n alt s\u0131n\u0131f\u0131n\u0131 olu\u015fturamaz veya o metodu ge\u00e7ersiz k\u0131lamaz. Bu, vekilleme i\u015flemini engeller.<\/li>\nprivate<\/code> Metotlar\u0131 Vekilleyemez:<\/strong> Sadece public, protected veya package-private metotlar\u0131 vekilleyebilir.<\/li>\n\nimport net.sf.cglib.proxy.Enhancer;\nimport net.sf.cglib.proxy.MethodInterceptor;\nimport net.sf.cglib.proxy.MethodProxy;\n\nimport java.lang.reflect.Method;\n\n\/\/ 1. Aray\u00fcz uygulamayan basit bir s\u0131n\u0131f tan\u0131mlayal\u0131m\nclass MyClass {\n public void performAction() {\n System.out.println(\"MyClass: Bir eylem ger\u00e7ekle\u015ftiriliyor.\");\n }\n\n public String greet(String name) {\n System.out.println(\"MyClass: \" + name + \" selamlan\u0131yor.\");\n return \"Merhaba, \" + name + \"!\";\n }\n\n \/\/ Final metotlar vekillenemez\n public final void finalMethod() {\n System.out.println(\"MyClass: Bu bir final metot.\");\n }\n}\n\n\/\/ 2. MethodInterceptor Uygulamas\u0131\nclass MyMethodInterceptor implements MethodInterceptor {\n private final Object target; \/\/ Ger\u00e7ek nesne\n\n public MyMethodInterceptor(Object target) {\n this.target = target;\n }\n\n @Override\n public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {\n \/\/ Final metotlar\u0131 vekilleyemedi\u011fimiz i\u00e7in kontrol edelim\n if (method.getName().equals(\"finalMethod\")) {\n System.out.println(\"CGLIB Proxy: Final metot vekillenemez, do\u011frudan \u00e7a\u011fr\u0131l\u0131yor.\");\n return method.invoke(target, args); \/\/ Orijinal metodu \u00e7a\u011f\u0131r\n }\n\n \/\/ Metot \u00e7a\u011fr\u0131s\u0131 \u00f6ncesi mant\u0131k\n System.out.println(\"CGLIB Proxy: Metot \u00e7a\u011fr\u0131l\u0131yor: \" + method.getName());\n if (args != null) {\n System.out.print(\"CGLIB Proxy: Parametreler: \");\n for (Object arg : args) {\n System.out.print(arg + \" \");\n }\n System.out.println();\n }\n\n \/\/ Ger\u00e7ek metodu \u00e7a\u011f\u0131r\n Object result = proxy.invoke(target, args); \/\/ veya proxy.invokeSuper(obj, args);\n\n \/\/ Metot \u00e7a\u011fr\u0131s\u0131 sonras\u0131 mant\u0131k\n System.out.println(\"CGLIB Proxy: Metot \u00e7a\u011fr\u0131s\u0131 tamamland\u0131: \" + method.getName());\n if (result != null) {\n System.out.println(\"CGLIB Proxy: D\u00f6n\u00fc\u015f de\u011feri: \" + result);\n }\n return result;\n }\n}\n\n\/\/ 3. Proxy Olu\u015fturma ve Kullanma\npublic class CglibProxyExample {\n public static void main(String[] args) {\n MyClass realClass = new MyClass();\n\n \/\/ Proxy olu\u015fturma\n Enhancer enhancer = new Enhancer();\n enhancer.setSuperclass(MyClass.class); \/\/ Hedef s\u0131n\u0131f\u0131 belirt\n enhancer.setCallback(new MyMethodInterceptor(realClass)); \/\/ MethodInterceptor \u00f6rne\u011fi\n\n MyClass proxyClass = (MyClass) enhancer.create(); \/\/ Proxy nesnesini olu\u015ftur\n\n \/\/ Proxy \u00fczerinden metotlar\u0131 \u00e7a\u011f\u0131r\n proxyClass.performAction();\n System.out.println(\"--------------------\");\n String greeting = proxyClass.greet(\"Ay\u015fe\");\n System.out.println(\"Ana Uygulama: Al\u0131nan selam: \" + greeting);\n System.out.println(\"--------------------\");\n proxyClass.finalMethod(); \/\/ Final metot \u00e7a\u011fr\u0131s\u0131\n }\n}\n<\/code><\/pre>\n<\/div>\nMyClass<\/code> adl\u0131 aray\u00fcz uygulamayan bir s\u0131n\u0131f i\u00e7in CGLIB kullanarak bir proxy olu\u015fturduk. MyMethodInterceptor<\/code> sayesinde, performAction()<\/code> ve greet()<\/code> metotlar\u0131 \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda ek loglama mesajlar\u0131 ekleyebildik. Ayr\u0131ca, finalMethod()<\/code> \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda CGLIB’in bu metodu vekilleyemedi\u011fini ve do\u011frudan orijinal metodu \u00e7a\u011f\u0131rd\u0131\u011f\u0131n\u0131 g\u00f6sterdik. Bu, CGLIB’in nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve k\u0131s\u0131tlamalar\u0131n\u0131 net bir \u015fekilde ortaya koymaktad\u0131r.<\/p>\nSpring Ne Zaman Hangi Proxy Mekanizmas\u0131n\u0131 Tercih Eder? Otomatik Se\u00e7im S\u00fcreci<\/h2>\n
\n
<aop:config proxy-target-class=\"true\"\/><\/code> veya Java Config (annotations) kullan\u0131rken @EnableAspectJAutoProxy(proxyTargetClass = true)<\/code> \u015feklinde yap\u0131l\u0131r. Bu ayar, hedef s\u0131n\u0131f bir aray\u00fcz uygulasa bile Spring’i CGLIB kullanmaya zorlar.<\/li>\n<\/ol>\n\n
Pratik Senaryolar ve Vaka Analizleri:<\/h3>\n
\n
@Transactional<\/code> anotasyonu ile i\u015faretlenmi\u015f metotlar genellikle bir servis aray\u00fcz\u00fc \u00fczerinden \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda JDK Dinamik Proxy kullan\u0131l\u0131r. \u00d6rne\u011fin, UserService<\/code> aray\u00fcz\u00fcn\u00fc uygulayan UserServiceImpl<\/code> s\u0131n\u0131f\u0131ndaki metotlar i\u00e7in proxy olu\u015fturulur. Bu, veritaban\u0131 i\u015flemlerinin do\u011fru bir \u015fekilde y\u00f6netilmesini sa\u011flar.<\/li>\n@Async<\/code>):<\/strong> @Async<\/code> anotasyonu ile i\u015faretlenmi\u015f metotlar, Spring’in kendi i\u015f par\u00e7ac\u0131\u011f\u0131 havuzunda (thread pool) ayr\u0131 bir i\u015f par\u00e7ac\u0131\u011f\u0131nda \u00e7al\u0131\u015f\u0131r. E\u011fer @Async<\/code> anotasyonunu uygulayan s\u0131n\u0131f bir aray\u00fcz uygulam\u0131yorsa veya proxyTargetClass = true<\/code> olarak ayarlanm\u0131\u015fsa, CGLIB kullan\u0131l\u0131r. \u00c7\u00fcnk\u00fc Spring’in bu metodu vekilleyebilmesi ve asenkron \u00e7a\u011fr\u0131y\u0131 ba\u015flatabilmesi i\u00e7in somut s\u0131n\u0131fa eri\u015fmesi gerekir.<\/li>\nproxyTargetClass = true<\/code> ayar\u0131n\u0131 kullanarak Spring’i CGLIB kullanmaya zorlayabilirler.<\/li>\n<\/ul>\nKonfig\u00fcrasyon Se\u00e7enekleri:<\/h3>\n
\n
\n<aop:config proxy-target-class=\"true\">\n <!-- AOP aspect tan\u0131mlamalar\u0131 -->\n<\/aop:config>\n<\/code><\/pre>\n<\/p><\/div>\n\n@Configuration\n@EnableAspectJAutoProxy(proxyTargetClass = true)\npublic class AppConfig {\n \/\/ Bean tan\u0131mlamalar\u0131\n}\n<\/code><\/pre>\n<\/p><\/div>\n@EnableAspectJAutoProxy<\/code> anotasyonunun proxyTargetClass<\/code> \u00f6zelli\u011fini true<\/code> olarak ayarlamak, Spring’i CGLIB kullanmaya y\u00f6nlendirir. Varsay\u0131lan de\u011feri false<\/code>‘tur, bu da Spring’in aray\u00fcz tabanl\u0131 vekillemeyi tercih etmesi anlam\u0131na gelir.<\/li>\n<\/ul>\nPerformans Kar\u015f\u0131la\u015ft\u0131rmas\u0131 ve Dikkat Edilmesi Gerekenler<\/h3>\n
\n
\n
final<\/code> olarak i\u015faretlenmi\u015f s\u0131n\u0131flar\u0131 ve metotlar\u0131 vekilleyemez. E\u011fer hedef s\u0131n\u0131f\u0131n\u0131z final<\/code> ise veya vekilini olu\u015fturmak istedi\u011finiz metotlar final<\/code> ise, CGLIB kullanamazs\u0131n\u0131z. Bu durumda JDK Dinamik Proxy (e\u011fer aray\u00fcz varsa) veya AspectJ gibi farkl\u0131 bir AOP yakla\u015f\u0131m\u0131 d\u00fc\u015f\u00fcn\u00fclmelidir.<\/li>\ncglib<\/code>) ekler. Bu, \u00f6zellikle k\u00fc\u00e7\u00fck projeler veya ba\u011f\u0131ml\u0131l\u0131k say\u0131s\u0131n\u0131 minimumda tutmak isteyen projeler i\u00e7in bir de\u011ferlendirme fakt\u00f6r\u00fc olabilir.<\/li>\n<\/ul>\nGeli\u015fmi\u015f Kullan\u0131m Senaryolar\u0131 ve \u0130pu\u00e7lar\u0131<\/h2>\n
AOP \u0130\u00e7erisinde
this<\/code> Referans\u0131na Eri\u015fim (Self-Invocation Problem)<\/h3>\n@Transactional<\/code> veya @Cacheable<\/code> anotasyonlu metodunu \u00e7a\u011f\u0131r\u0131rsa, bu \u00e7a\u011fr\u0131 proxy \u00fczerinden de\u011fil, do\u011frudan ger\u00e7ek nesne \u00fczerinden yap\u0131l\u0131r. Bu durumda, vekilin uygulad\u0131\u011f\u0131 AOP mant\u0131\u011f\u0131 (i\u015flem y\u00f6netimi, \u00f6nbellekleme vb.) \u00e7al\u0131\u015fmaz.<\/p>\n\n@Service\npublic class MyServiceImpl implements MyService {\n\n @Transactional\n public void methodA() {\n \/\/ ... baz\u0131 i\u015flemler ...\n methodB(); \/\/ Bu \u00e7a\u011fr\u0131 proxy \u00fczerinden de\u011fil, do\u011frudan ger\u00e7ek nesne \u00fczerinden yap\u0131l\u0131r.\n \/\/ methodB \u00fczerindeki @Transactional veya di\u011fer AOP vekilleri \u00e7al\u0131\u015fmaz.\n }\n\n @Transactional\n public void methodB() {\n \/\/ ... baz\u0131 i\u015flemler ...\n }\n}\n<\/code><\/pre>\n<\/div>\n\n
ApplicationContext<\/code> veya ObjectProvider<\/code> ile Kendi Proxy’sine Eri\u015fim:<\/strong> En yayg\u0131n ve \u00f6nerilen y\u00f6ntemlerden biri, s\u0131n\u0131f\u0131n kendi proxy \u00f6rne\u011fini Spring ba\u011flam\u0131ndan (context) almakt\u0131r.\n\n@Service\npublic class MyServiceImpl implements MyService {\n\n @Autowired\n private MyService self; \/\/ Kendi proxy'sini enjekte etme\n\n @Transactional\n public void methodA() {\n \/\/ ... baz\u0131 i\u015flemler ...\n self.methodB(); \/\/ \u015eimdi methodB proxy \u00fczerinden \u00e7a\u011fr\u0131l\u0131r ve AOP vekilleri \u00e7al\u0131\u015f\u0131r.\n }\n\n @Transactional\n public void methodB() {\n \/\/ ... baz\u0131 i\u015flemler ...\n }\n}\n<\/code><\/pre>\n<\/p><\/div>\nObjectProvider<\/code> kullanarak dairesel ba\u011f\u0131ml\u0131l\u0131klar\u0131 \u00f6nleyebilirsiniz:<\/p>\n\n@Service\npublic class MyServiceImpl implements MyService {\n\n @Autowired\n private ObjectProvider<MyService> selfProvider;\n\n @Transactional\n public void methodA() {\n \/\/ ... baz\u0131 i\u015flemler ...\n selfProvider.getObject().methodB(); \/\/ Proxy \u00fczerinden \u00e7a\u011fr\u0131\n }\n\n @Transactional\n public void methodB() {\n \/\/ ... baz\u0131 i\u015flemler ...\n }\n}\n<\/code><\/pre>\n<\/p><\/div>\n<\/li>\nAopContext.currentProxy()<\/code> Kullan\u0131m\u0131:<\/strong> Bu y\u00f6ntem, mevcut i\u015f par\u00e7ac\u0131\u011f\u0131n\u0131n (thread) proxy’sine eri\u015fmek i\u00e7in kullan\u0131l\u0131r. Ancak, bu y\u00f6ntemi kullanmadan \u00f6nce @EnableAspectJAutoProxy(exposeProxy = true)<\/code> ayar\u0131n\u0131 yapman\u0131z gerekir.\n\n@Configuration\n@EnableAspectJAutoProxy(exposeProxy = true)\npublic class AppConfig { \/* ... *\/ }\n\n@Service\npublic class MyServiceImpl implements MyService {\n\n @Transactional\n public void methodA() {\n \/\/ ... baz\u0131 i\u015flemler ...\n ((MyService) AopContext.currentProxy()).methodB(); \/\/ Proxy \u00fczerinden \u00e7a\u011fr\u0131\n }\n\n @Transactional\n public void methodB() {\n \/\/ ... baz\u0131 i\u015flemler ...\n }\n}\n<\/code><\/pre>\n<\/p><\/div>\nAopContext.currentProxy()<\/code> \u00e7a\u011fr\u0131s\u0131n\u0131n her zaman bir proxy ba\u011flam\u0131nda yap\u0131lmas\u0131 gerekir, aksi takdirde bir istisna f\u0131rlat\u0131l\u0131r.<\/li>\n<\/ol>\nProxy’lerin Test Edilmesi<\/h3>\n
@Autowired<\/code> ile enjekte etti\u011finiz servisler zaten vekil nesneler olacakt\u0131r.<\/p>\n\n@SpringBootTest\nclass MyServiceIntegrationTest {\n\n @Autowired\n private MyService myService; \/\/ Bu genellikle bir proxy nesnesidir\n\n @Test\n void testMethodAWithTransactionalBehavior() {\n \/\/ myService.methodA() \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda @Transactional'\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olun\n \/\/ \u00d6rne\u011fin, veritaban\u0131 de\u011fi\u015fikliklerinin geri al\u0131n\u0131p al\u0131nmad\u0131\u011f\u0131n\u0131 kontrol edin.\n }\n}\n<\/code><\/pre>\n<\/div>\nSpring Boot ile Otomatik Konfig\u00fcrasyonun Kolayl\u0131\u011f\u0131<\/h3>\n
@EnableAspectJAutoProxy<\/code> gibi anotasyonlar\u0131 manuel olarak eklemeye genellikle gerek kalmaz \u00e7\u00fcnk\u00fc Spring Boot, AOP ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 alg\u0131lad\u0131\u011f\u0131nda (\u00f6rne\u011fin spring-boot-starter-aop<\/code> ekledi\u011finizde) otomatik olarak AOP proxy’lerini etkinle\u015ftirir. proxyTargetClass<\/code> ayar\u0131n\u0131 de\u011fi\u015ftirmek isterseniz, bunu application.properties<\/code> veya application.yml<\/code> dosyas\u0131nda spring.aop.proxy-target-class=true<\/code> \u015feklinde yapabilirsiniz. Bu, Spring Boot’un “konfig\u00fcrasyon \u00fczerinde uzla\u015fma” (convention over configuration) prensibinin bir \u00f6rne\u011fidir.<\/p>\nProxy’lerin Debug Edilmesi<\/h3>\n
System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, \"cglib-debug\");<\/code> gibi bir JVM arg\u00fcman\u0131 ile yapabilirsiniz. Bu sayede, olu\u015fturulan .class<\/code> dosyalar\u0131n\u0131 inceleyerek proxy’nin i\u00e7 yap\u0131s\u0131n\u0131 g\u00f6rebilirsiniz. JDK Dinamik Proxy i\u00e7in de benzer \u015fekilde, System.setProperty(\"sun.misc.ProxyGenerator.saveGeneratedFiles\", \"true\");<\/code> ayar\u0131n\u0131 kullanarak olu\u015fturulan proxy s\u0131n\u0131flar\u0131n\u0131 diske kaydedebilirsiniz.<\/p>\nSonu\u00e7: Do\u011fru Proxy Se\u00e7imi ve Gelecek Trendler<\/h2>\n
\n
proxyTargetClass = true<\/code> ayar\u0131 ile Spring’i her zaman CGLIB kullanmaya zorlayabilirler. \u00c7o\u011fu durumda Spring’in otomatik se\u00e7imi yeterli olsa da, performans, k\u0131s\u0131tlamalar (final s\u0131n\u0131flar gibi) veya “self-invocation” sorunlar\u0131 gibi \u00f6zel senaryolarda bu mekanizmalar\u0131n derinlemesine anla\u015f\u0131lmas\u0131 kritik \u00f6neme sahiptir.<\/p>\nS\u0131k\u00e7a Sorulan Sorular<\/h3>\n
\n
final<\/code> olarak i\u015faretlenmi\u015fse, CGLIB bu s\u0131n\u0131f\u0131 vekilleyemez. \u00c7\u00fcnk\u00fc CGLIB, hedef s\u0131n\u0131f\u0131n bir alt s\u0131n\u0131f\u0131n\u0131 olu\u015fturma prensibiyle \u00e7al\u0131\u015f\u0131r ve final<\/code> s\u0131n\u0131flar\u0131n alt s\u0131n\u0131f\u0131 olu\u015fturulamaz. Bu durumda, e\u011fer s\u0131n\u0131f bir aray\u00fcz uyguluyorsa JDK Dinamik Proxy kullan\u0131labilir; aksi takdirde farkl\u0131 bir AOP yakla\u015f\u0131m\u0131 (\u00f6rne\u011fin AspectJ) d\u00fc\u015f\u00fcn\u00fclmelidir.<\/p>\n<\/li>\nproxyTargetClass = true<\/code> ne i\u015fe yarar ve ne zaman kullan\u0131lmal\u0131d\u0131r?<\/strong>\nproxyTargetClass = true<\/code> ayar\u0131, Spring’i, hedef nesne bir aray\u00fcz uygulasa bile her zaman CGLIB kullanarak proxy olu\u015fturmaya zorlar. Bu ayar, \u00f6zellikle s\u0131n\u0131f baz\u0131nda AOP uygulamak istedi\u011finizde (\u00f6rne\u011fin, private<\/code> veya protected<\/code> metotlar\u0131 vekilleyebilmek i\u00e7in – CGLIB sadece final olmayan public, protected, package-private metotlar\u0131 vekiller) veya bir aray\u00fcz \u00fczerinden eri\u015filemeyen somut s\u0131n\u0131f metotlar\u0131na AOP uygulamak istedi\u011finizde faydal\u0131d\u0131r. Ayr\u0131ca, “self-invocation” sorununu \u00e7\u00f6zmek i\u00e7in de bazen bu ayar tercih edilebilir.<\/p>\n<\/li>\nAdvisor<\/code>, Pointcut<\/code> ve Advice<\/code> uygulamalar\u0131n\u0131z\u0131 olu\u015fturarak Spring’in AOP altyap\u0131s\u0131n\u0131 geni\u015fletebilirsiniz. Ancak, bu genellikle \u00e7ok ileri d\u00fczey bir senaryodur ve \u00e7o\u011fu durumda Spring’in sa\u011flad\u0131\u011f\u0131 standart AOP yetenekleri yeterli olacakt\u0131r. Kendi proxy mekanizman\u0131z\u0131 entegre etmek yerine, mevcut AOP \u00f6zelliklerini do\u011fru bir \u015fekilde kullanmaya odaklanmak daha verimli olacakt\u0131r.<\/p>\n<\/li>\n<\/ol>\n