वसंत में cglib निर्भरता नहीं है, दोनों cglib और spring cglib में Enhancer वर्ग है, एक net.sf.cglib.proxy.Enhancer है जबकि दूसरा org.springframework.cglib.proxy है, उनके बीच क्या अंतर है?वसंत CGLIB और CGLIB के बीच क्या अंतर है?
यह पैकेजिंग कहा जाता है: के बजाय एक निर्भरता के रूप में कुछ पुस्तकालय का उपयोग कर के, एक परियोजना के लिए अपने स्वयं परियोजना का हिस्सा है और यह स्थानों में के रूप में निर्भरता की एक प्रतिलिपि बनाता एक अलग पैकेज
ऐसा करने का कारण यह है कि स्प्रिंग का उपयोग करने वाली एक परियोजना स्वयं को cglib का उपयोग करना चाहती है। यदि स्प्रिंग के पास निर्भरता के रूप में cglib का एक विशेष संस्करण था, तो स्प्रिंग का उपयोग एक अलग संस्करण चुनने के लिए प्रोजेक्ट के लिए असंभव होगा। लेकिन यदि वसंत एक अलग पैकेज में है जो repackaged cglib का उपयोग करता है, तो कोई संस्करण संघर्ष नहीं होता है और यदि परियोजना पसंद है तो परियोजना cglib के किसी भी संस्करण का उपयोग कर सकती है।
कुछ परियोजनाएं गुवा, नेटटी या अन्य लोकप्रिय पुस्तकालयों को उसी तरह से पुनर्स्थापित करती हैं।
वसंत पुन: संग्रहित cglib के साथ भेज दिया। आप ग्रैडल buildfile में वास्तविक cglib संस्करण देख सकते हैं। शब्द "cglib" के लिए खोज और आप पाते हैं यह:
// As of Spring 4.0.3, spring-core includes asm 5.x and repackages cglib 3.2, inlining
// both into the spring-core jar. cglib 3.2 itself depends on asm 5.x and is therefore
// further transformed by the JarJar task to depend on org.springframework.asm; this
// avoids including two different copies of asm unnecessarily.
def cglibVersion = "3.2.4"
Cglib संस्करण 3.2.0 के रूप में वसंत में inlined गया था के रूप में यह release notes of this version में बताया गया है:
पहले के संस्करण में, वसंत के उपवर्ग आधारित AOP प्रॉक्सी (जैसे के उपयोगकर्ताओं को प्रॉक्सी-लक्ष्य श्रेणी के माध्यम से = "सत्य") और @ कॉन्फ़िगरेशन क्लास समर्थन को CGLIB 2.2 पर स्पष्ट निर्भरता घोषित करने के लिए आवश्यक था। वसंत फ्रेमवर्क 3.2 के रूप में, अब हम नए रिलीज किए गए CGLIB 3.0 को पुन: पैकेज और इनलाइन करते हैं।
यह जावा 7 उपयोगकर्ताओं जो प्रकार है कि invokedynamic बाईटकोड निर्देश के उपवर्ग प्रॉक्सी बना रहे हैं उपयोगकर्ताओं के लिए अधिक से अधिक सुविधा है, साथ ही सही कार्यप्रणाली। पुन: पैकेजिंग CGLIB आंतरिक रूप से अन्य तृतीय पक्ष फ्रेमवर्क के साथ कोई क्लासपाथ विवाद सुनिश्चित नहीं करता है जो CGLIB के अन्य संस्करणों पर निर्भर हो सकता है।
यह स्वचालित अद्यतन प्रदान करने के लिए किया गया था जो सीजीएलआईबी से संबंधित है और संस्करण संघर्षों से परहेज करता है क्योंकि सीजीएलआईबी कभी-कभी अपने एपीआई को तोड़ देता है।