हाइबरनेट-एक्सटेंडर या हाइबरनेट, स्प्रिंग और ओएसजीआई

दुर्भाग्य से, फिलहाल, हाइबरनेट में ओएसजीआई वातावरण में काम करने के लिए आवश्यक एकीकरण तंत्र नहीं है, हालांकि इस दिशा में प्रगति ध्यान देने योग्य है (4 वीं शाखा में पैकेटों को विभाजित करके प्रारंभिक ओएसजी-फिक्शन)। यह अपने स्वयं के तंत्र के विकास को प्रोत्साहित करता है, जिसके लिए काफी अतिरिक्त प्रयास की आवश्यकता होती है।

यह लेख उन डेवलपर्स के लिए अभिप्रेत है जो इसमें रुचि रखते हैं: मैं स्प्रिंग + ओएसजीआई के एक गुच्छा के साथ हाइबरनेट का उपयोग कैसे कर सकता हूं; एक्सटेंडर पैटर्न क्या है; विशिष्ट व्यवहार के साथ ClassLoader को कैसे लागू किया जाए; वसंत फ्रेमवर्क में हाइबरनेट द्वारा समर्थित और इस कोड को विस्तारित करने के बारे में थोड़ा। बेशक, लेख को पढ़ने के लिए आपको स्प्रिंग, हाइबरनेट, ओएसजीआई की प्रौद्योगिकियों को समझने की आवश्यकता है, और एक बहु-थ्रेडेड वातावरण में कोड निष्पादन की मुख्य समस्याओं को भी समझना होगा। जो लोग OSGi परिवेश में स्प्रिंग फ्रेमवर्क का उपयोग करने से अपरिचित हैं, वे परिचय लेख "OSGi कंटेनर में स्प्रिंग का उपयोग करना" का उल्लेख कर सकते हैं।

प्रस्तुत सभी कोड प्रशिक्षण परियोजना का हिस्सा है, जो लिंक लेख के अंत में स्थित है। इसलिए, कृपया उपयोग किए जाने वाले टुकड़ों के बजाय एक प्रोटोटाइप के रूप में प्रस्तुत सभी उदाहरणों पर विचार करें।

एक्सटेंडर पैटर्न

OSGi कंटेनर में चलने वाले सॉफ़्टवेयर में अलग-अलग मॉड्यूल (बंडल) होते हैं, जिनमें से प्रत्येक अपने विशिष्ट कर्तव्यों का पालन करता है। जब एक मॉड्यूल को किसी अन्य मॉड्यूल में स्थित कुछ जटिल रनटाइम तंत्र का उपयोग करना चाहिए तो क्या करें? जवाब स्पष्ट है - OSGi सेवाओं का उपयोग करें। और क्या करना है जब इन तंत्रों की आवश्यकता होती है, उदाहरण के लिए, आरंभीकरण (एक सर्वलेट कंटेनर में एक सर्वलेट दर्ज करना या, हमारे मामले में, हाइबरनेट संस्थाओं के मैप किए गए वर्गों को पंजीकृत करना)। इस सवाल का जवाब पहले से ही कम स्पष्ट है। वास्तव में, केवल दो मुख्य विकल्प हैं: पहला - प्रत्येक मॉड्यूल जिसे इस इनिशियलाइज़ेशन की आवश्यकता होती है वह इसे अपने आप कहता है (उदाहरण के लिए, बंडलएक्टीवेटर से); दूसरा यह है कि इस तरह के इनिशियलाइज़ेशन के लिए एक मॉड्यूल की कुछ विशेषता मेटाडेटा होती है जिसके द्वारा एक अन्य मॉड्यूल सभी आवश्यक काम शुरू कर सकता है, क्योंकि OSGi में एक अच्छी तरह से विकसित इवेंट सिस्टम है। दूसरे विकल्प का एक निश्चित लाभ है - हम मॉड्यूल में समान कोड का एक गुच्छा वितरित नहीं करते हैं और अतिरिक्त काम के साथ उन पर बोझ नहीं डालते हैं, लेकिन हम इस जिम्मेदारी को एक अलग मॉड्यूल में स्थानांतरित करते हैं। दरअसल, स्प्रिंग डीएम इस सिद्धांत पर काम करता है। ऑपरेशन का यह सिद्धांत एक्सटेंडर पैटर्न है [http://www.aqute.biz/Snippets/Extender] और यह OSGi दुनिया में बहुत आम है।

हाइबरनेट-एक्सटेंडर के काम की समग्र तस्वीर का विवरण

हम हाइबरनेट-एक्सटेंडर के काम की सामान्य योजना पर चर्चा करना शुरू करते हैं। सबसे पहले, आपको मेटाडेटा धन्यवाद का चयन करने की आवश्यकता है जिसके लिए हमारे एक्सटेंडर उन मॉड्यूल को अलग कर देंगे जिन्हें गैर-विस्तार वाले लोगों से विस्तारित करने की आवश्यकता है। इसे मेटा-इन / MANIFEST.MF में एंटिटी-क्लास हेडिंग बनाते हैं जिसमें हाइबरनेट संस्थाओं की कक्षाएं होती हैं (एक्सएमएल-मैपिंग के प्रेमी अब के लिए काम से बाहर होंगे)। इसके बाद, आपको सक्रिय स्थिति में प्रवेश करने वाले मॉड्यूल से और इस राज्य को छोड़ने वाले मॉड्यूल से ईवेंट प्राप्त करने की आवश्यकता है। ऐसा करने के लिए, OSGi इवेंट तंत्र का उपयोग करें और SynchronousBundleListener इंटरफ़ेस को लागू करें। हम एसिंक्रोनस बंडल बंडलिस्ट को कॉल करने से पहले मॉड्यूल की स्थिति में तुरंत परिवर्तन का जवाब देने के लिए मॉड्यूल से एक सिंक्रोनस इवेंट हैंडलर का उपयोग करते हैं। उसी समय, हमें घटना को संसाधित करने के लिए सबसे कम संभव समय सुनिश्चित करना चाहिए ताकि हमारे हैंडलर के कारण थ्रेड को ब्लॉक न करें। यह निर्माता-उपभोक्ता पैटर्न को लागू करने से प्राप्त होता है, जहां हमारा ईवेंट हैंडलर निर्माता के रूप में कार्य करता है, जो उपभोक्ता को मॉड्यूल के बारे में जानकारी देता है, जो एक अलग थ्रेड में सभी लंबे ऑपरेशन करता है। हमारे मामले में, यह हाइबरनेट के रनटाइम संरचनाओं को फिर से संगठित करता है।

एक्सटेंडर तंत्र काफी सामान्यीकृत है, इसलिए कोड के पुन: उपयोग की सुविधा के लिए नीचे कार्यान्वयन डिपेंडेंसी इनवर्जन सिद्धांत (SOLID) का अनुसरण करता है।

public class Extender implements SynchronousBundleListener { private BundleContext bundleContext; private Executor executor; private BlockingQueue<ExtendedBundle> bundles = new LinkedBlockingQueue<ExtendedBundle>(); private BundleConsumer bundleConsumer; private ExtendedBundleFactory extendedBundleFactory; // getter's  setter's @Override public void bundleChanged(BundleEvent event) { Actions action = null; switch (event.getType()) { case BundleEvent.STARTED: action = Actions.ADDING; break; case BundleEvent.STOPPING: action = Actions.REMOVING; break; }; if (action == null) return; ExtendedBundle extendedBundle = extendedBundleFactory.newExtendedFactory( event.getBundle(), action ); try { bundles.put(extendedBundle); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } public void initialize() { getBundleConsumer().initialize(getBundles()); getExecutor().execute(bundleConsumer); getBundleContext().addBundleListener(this); for (Bundle bundle: getBundleContext().getBundles()) { if (Bundle.ACTIVE != bundle.getState()) continue; ExtendedBundle extendedBundle = extendedBundleFactory.newExtendedFactory( bundle, Actions.ADDING ); try { bundles.put(extendedBundle); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } } } 

एक्सटेंडर के कार्यान्वयन में शामिल हैं: बंडल कॉंटेक्स जिसमें एक्स्टेंडर खुद को मॉड्यूल से घटनाओं के लिए एक श्रोता के रूप में पंजीकृत है; निष्पादनकर्ता java.util.concurrent फ्रेमवर्क से निष्पादक का कार्यान्वयन है, जिसमें उपभोक्ता दीर्घकालिक संचालन को निष्पादित करता है; ब्लॉकिंग क्यू की अवरोधन कतार जिसके साथ निर्माता-उपभोक्ता निष्पादन थ्रेड सिंक्रनाइज़ होते हैं; बंडल मॉड्यूल मॉड्यूल के विशिष्ट उपभोक्ता कार्यान्वयन; ExtendedBundleFactory कारखाना "विस्तारित" मॉड्यूल।

सार्वजनिक शून्य इनिशियलाइज़ () विधि को ऑब्जेक्ट के निर्माण के तुरंत बाद कहा जाता है। इस पद्धति में, हम अपने एक्सटेंडर को एक हैंडलर के रूप में पंजीकृत करते हैं, उपभोक्ता निष्पादन शुरू करते हैं और उन मॉड्यूल को संसाधित करते हैं जो पहले से ही OSGi कंटेनर में हैं, यदि एक्सटेंडर एक्स्टेंसिबल मॉड्यूल के बाद शुरू होता है।

BundleConsumer

बंडलकॉन्समर एक इंटरफ़ेस है, एक प्रकार के साथ एक ऑब्जेक्ट जो इस इंटरफ़ेस को लागू करता है उसे एक्स्टेंडर द्वारा कतारबद्ध मॉड्यूल को संसाधित करना होगा।

 public interface BundleConsumer extends Runnable { void run(); void initialize( BlockingQueue<ExtendedBundle> newBundles ); } 

ऊपर दिए गए कोड से यह स्पष्ट है कि यह एक अतिरिक्त आरंभीकरण विधि के साथ सिर्फ Runnable है। शून्य रन () पद्धति के कार्यान्वयन में सब कुछ दिलचस्प होना चाहिए। आइए इस इंटरफ़ेस के एक विशिष्ट कार्यान्वयन को देखें जो हमारे हाइबरनेट-एक्सटेंडर के लिए काम करता है।

 public class SessionFactoryCreator implements BundleConsumer { private volatile Extendable extendable; private volatile ExtenderClassLoader extenderClassLoader; private volatile BlockingQueue<ExtendedBundle> newBundles; // getter's, setter's    @Override public void run() { ExtendedBundle bundle = null; while (!Thread.currentThread().isInterrupted()) { try { bundle = newBundles.take(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } if (!bundle.isValidForExtending()) continue; if (Actions.ADDING.equals(bundle.getAction())) { addBundle(bundle); } else if (Actions.REMOVING.equals(bundle.getAction())) { removeBundle(bundle); } } } private void addBundle(ExtendedBundle bundle) { bundle.extend(); extenderClassLoader.addBundle(bundle); extendable.addBundle(bundle); bundle.markAsCompleted(); } private void removeBundle(ExtendedBundle bundle) { bundle.extend(); extendable.removeBundle(bundle); extenderClassLoader.removeBundle(bundle); bundle.markAsCompleted(); } } 

शून्य रन () विधि में मुख्य लूप newBundles कतार को संभालता है। यदि कतार में कोई एक्स्टेंसिबल मॉड्यूल नहीं हैं, तो निष्पादन को कॉल में newBundles.take () विधि में अवरुद्ध कर दिया जाता है। जब विस्तार योग्य मॉड्यूल दिखाई देते हैं, तो वे एक बार में एक को स्थानांतरित करते हैं। इनमें से प्रत्येक मॉड्यूल पर, isValidForExtending () विधि को कहा जाता है, जिसे मॉड्यूल के विस्तार के लिए उपयुक्त होने पर सही मूल्य वापस करना चाहिए। पैकेजों के आंतरिक संसाधनों (उदाहरण के लिए, आई / ओ संचालन को कॉल करना) तक पहुंचते समय यह सत्यापन विधि काफी समय ले सकती है, इसलिए इसे यहां कहा जाता है, और एक्सटेंडर में नहीं। यदि मॉड्यूल विस्तार के लिए उपयुक्त है, तो मेटा-जानकारी को उस क्रिया के बारे में जांचा जाता है, जिस पर उसे कार्य करने की आवश्यकता होती है: Actions.ADDING या क्रियाएँ ।EMOVING। आवश्यक कार्रवाई के आधार पर, एक ऐड या रिमूव ऑपरेशन किया जाता है और मॉड्यूल को संसाधित के रूप में चिह्नित किया जाता है।

मैं मुख्य प्रसंस्करण लूप से बाहर निकलने के लिए परिस्थितियों पर पाठक का ध्यान आकर्षित करना चाहता हूं! थ्रेड.currentThread ()। Istertereded (), यह सुनिश्चित करता है कि थ्रेड फ़्लैग सेट होने पर थ्रेड सही ढंग से समाप्त हो जाए। एक अन्य स्थान जहां इस ध्वज का उपयोग किया जाता है, अवरोध विधि newBundles.take () की घटना से निपटने के लिए, जिसके प्रवाह को बाधित करने के लिए ध्वज को मुख्य लूप से बाहर सेट और बाहर किया जाता है।

बहु-थ्रेडेड वातावरण में दृश्यता की गारंटी प्रदान करने के लिए वर्ग विशेषताओं को अस्थिर के रूप में चिह्नित किया जाता है। एक वस्तु का निर्माण एक धागे में होता है, और दूसरे में आगे उपयोग होता है। BlockingQueue का कार्यान्वयन थ्रेड सुरक्षित है, इसलिए बहु-थ्रेडेड वातावरण में इसके उपयोग के लिए अतिरिक्त सिंक्रनाइज़ेशन की आवश्यकता नहीं होती है।

HibernateSessionFactoryBean

बड़ी संख्या में विभिन्न ढांचे आकस्मिक नहीं हैं। तृतीय-पक्ष का उपयोग करना, अच्छी तरह से परीक्षण किया गया, तैयार-से-उपयोग कोड विकास को बहुत सुविधाजनक बनाता है। इसलिए, हम बहुत अधिक आविष्कार न करने का प्रयास करेंगे। स्प्रिंग फ्रेमवर्क हाइबरनेट के साथ एकीकरण का समर्थन करता है। इस एकीकरण के मुख्य वर्गों में से एक है LocalSessionFactoryBean। यह एक सत्र का कारखाना शुरू करता है और बनाता है, जिसे तब हाइबरनेट एपीआई का उपयोग करके किसी भी कोड में उपयोग किया जाता है। इस वर्ग में एनोटेशन सेशनफैक्टरीबीन का वंशज है, जो एनोटेशन के समर्थन के साथ कुछ कार्यक्षमता जोड़ता है। उत्तरार्द्ध से, हम अपने कार्यान्वयन को विरासत में देंगे, जिसका कोड नीचे प्रस्तुत किया गया है।

 public class HibernateSessionFactoryBean extends AnnotationSessionFactoryBean { private SessionFactory sessionFactoryProxy; private Lock sessionFactoryAccessLock = new ReentrantLock(true); private ClassLoader classLoader; private Set<Class<?>> annotatedClasses = new CopyOnWriteArraySet<Class<?>>(); /** *   ClassLoader * @param classLoader */ public void setClassLoader(ClassLoader classLoader) { super.setBeanClassLoader(classLoader); this.classLoader = classLoader; } /** *   ClassLoader    BeanClassLoaderAware * @param beanClassLoader */ @Override public void setBeanClassLoader(ClassLoader beanClassLoader) { } @Override public void afterPropertiesSet() throws Exception { //  ClassLoader ProxyFactory.classLoaderProvider = new ClassLoaderProvider() { public ClassLoader get(ProxyFactory pf) { return HibernateSessionFactoryBean.this.classLoader; } }; super.afterPropertiesSet(); sessionFactoryProxy = createSessionFactoryProxy(); } @Override public SessionFactory getObject() { return sessionFactoryProxy; } /** *    Hibernate */ protected void recreateSessionFactory() throws Exception { sessionFactoryAccessLock .tryLock(3000, TimeUnit.MILLISECONDS); try { //  runtime-   Hibernate super.destroy(); //  runtime-   Hibernate super.afterPropertiesSet(); } finally { sessionFactoryAccessLock.unlock(); } } protected SessionFactory createSessionFactoryProxy() throws InstantiationException, IllegalAccessException, InterruptedException { //     //   SessionFactory  Extendable ProxyFactory sessionFactoryProxyFactory = new ProxyFactory(); sessionFactoryProxyFactory.setInterfaces( new Class[] {SessionFactory.class, Extendable.class} ); //    finalize sessionFactoryProxyFactory.setFilter(new MethodFilter() { public boolean isHandled(Method m) { return !m.getName().equals("finalize"); } }); Class<?> sessionFactoryProxyClass = sessionFactoryProxyFactory.createClass(); MethodHandler mi = new MethodHandler() { public Object invoke( Object self, Method thisMethod, Method proceed, Object[] args) throws Throwable { Object result = null; // TCCL ClassLoader defaultClassLoader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(classLoader); try { if (thisMethod.getName().contains("addBundle")) { addBundle((HibernateBundle) args[0]); } else if (thisMethod.getName().contains("removeBundle")) { removeBundle((HibernateBundle) args[0]); } else { sessionFactoryAccessLock .tryLock(3000, TimeUnit.MILLISECONDS); try { //   SessionFactory result = thisMethod .invoke(getSessionFactory(), args); } finally { sessionFactoryAccessLock.unlock(); } } } finally { // TCCL    Thread.currentThread() .setContextClassLoader(defaultClassLoader); } return result; } }; SessionFactory sessionFactory = (SessionFactory)sessionFactoryProxyClass.newInstance(); ((ProxyObject)sessionFactory).setHandler(mi); return sessionFactory; } private void addBundle(HibernateBundle bundle) throws Exception { for (String entityClassName: bundle.getEntityClassNames()) { annotatedClasses.add(classLoader.loadClass(entityClassName)); } setAnnotatedClasses( annotatedClasses.toArray( new Class[annotatedClasses.size()])); recreateSessionFactory(); } private void removeBundle(HibernateBundle bundle) throws Exception { for (Class<?> annotatedClass: annotatedClasses) { if (bundle.getEntityClassNames().contains( annotatedClass.getCanonicalName())) { annotatedClasses.remove(annotatedClass); } } setAnnotatedClasses( annotatedClasses.toArray( new Class[annotatedClasses.size()])); recreateSessionFactory(); } } 

इस कोड को निष्पादित करने की मुख्य योजना इस प्रकार है। AbstractSessionFactoryBean FactoryBean इंटरफ़ेस को लागू करता है, एक वर्ग ऑब्जेक्ट के निर्माण को संसाधित करता है जो स्प्रिंग कंटेनर में इस इंटरफ़ेस को लागू करता है। इस पर अधिक जानकारी के लिए स्प्रिंग फ्रेमवर्क प्रलेखन देखें। यह केवल उल्लेख के लायक है कि यह केवल सत्रफैक्टरी वस्तुओं का कारखाना है, न कि इसका ठोस कार्यान्वयन। LocalSessionFactoryBean में बनाए गए सत्रफैक्टरी ऑब्जेक्ट के बजाय, कोड एक प्रॉक्सी ऑब्जेक्ट देता है जो कि किसी वैश्विक कॉल के साथ किसी भी कॉल की रक्षा करते समय देशी SessionFactory तरीकों के लिए लगभग सभी कॉल करता है (इस आर्किटेक्चर को प्रदर्शन के संदर्भ में संसाधित किया जा सकता है, सत्र ऑब्जेक्ट्स का उपयोग करते समय SessionFactory फिर से बनाने की संभावना पर ध्यान नहीं दिया जाता है। )। एक्स्टेंसिबल मॉड्यूल के सेट में प्रत्येक परिवर्तन के साथ, सेशनफैक्टरी वस्तु को फिर से ध्यान में रखा जाता है।

ऑब्जेक्ट प्रॉक्सी मेथड कॉल हैंडलर थ्रेड कॉन्टेक्स्ट क्लास लोडर (TCCL) ओवरराइड का उपयोग करता है। TCCL के रूप में, जिस समय विधि को बुलाया जाता है, हमारे स्वयं के क्लास लोडर उस विषय को सेट करते हैं जिस पर बाद में चर्चा की जाएगी।

OSGi और ClassLoader

एक सामान्य jvm- आधारित एप्लिकेशन में, क्लास लोडर को पदानुक्रम से जोड़ा जाता है (माता-पिता के संदर्भ में) और अपने माता-पिता के लिए प्रतिनिधिमंडल द्वारा कक्षाओं और संसाधनों को पहले लोड किया जाता है, और यदि असफल हो, तो स्वयं द्वारा। OSGi वातावरण के लिए, यह व्यवहार उपयुक्त नहीं है। इसी तरह, यह एक्सटेंडर के साथ हमारे मामले के लिए उपयुक्त नहीं है। ओएसजीआई कंटेनर में, प्रत्येक मॉड्यूल को अपना स्वयं का क्लास लोडर प्राप्त होता है जो पूरी तरह से इसकी (मॉड्यूल) जरूरतों को पूरा करता है। और मॉड्यूल क्लास लोडर एक अधिक जटिल प्रतिनिधि नेटवर्क से जुड़े हैं। इस तरह के प्रत्येक लोडर में फ्रेमवर्क क्लास के लोडर का लिंक होता है, साथ ही मॉड्यूल के लोडरों से भी, जहां से आयात किया जाता है। यह डेलिगेशन नेटवर्क OSGi कंटेनर में रिज़ॉल्यूशन प्रक्रिया के परिणामस्वरूप बनाया गया है।



एक्सटेंडर के मामले में, एक विशिष्ट मॉड्यूल क्लास लोडर उपयुक्त नहीं है, क्योंकि MANIFEST.MF में आयातित इकाई वर्गों की घोषणा करना संभव नहीं है। एक्सटेंडर के विकास के समय ऐसी कक्षाएं अज्ञात हैं। इसलिए, आपको हमारे स्वयं के व्यवहार के साथ अपने बूटलोडर को लागू करना चाहिए। एक्सटेंडर के लिए क्लास लोडर कोड नीचे प्रस्तुत किया गया है।

 public class ExtenderClassLoader extends ClassLoader { private volatile ClassLoader defaultClassLoader = null; private Set<ExtendedBundle> bundles = new CopyOnWriteArraySet<ExtendedBundle>(); public ClassLoader getDefaultClassLoader() { return defaultClassLoader; } public void setDefaultClassLoader( ClassLoader defaultClassLoader) { this.defaultClassLoader = defaultClassLoader; } public void addBundle( ExtendedBundle bundle) { bundles.add(bundle); } public void removeBundle(ExtendedBundle bundle) { bundles.remove(bundle); } @Override public Class<?> loadClass( String name) throws ClassNotFoundException { Class<?> c = null; for (ExtendedBundle bundle: bundles) { try { c = bundle.loadClass(name); break; } catch (ClassNotFoundException e) {} } if (c == null && getDefaultClassLoader() != null) { try { c = getDefaultClassLoader().loadClass(name); } catch (ClassNotFoundException e) {} } if (c == null) throw new ClassNotFoundException(name); return c; } //   } 

आइए नीचे दिए गए कोड पर करीब से नज़र डालें। उनके काम का मुख्य तर्क लोडक्लास विधि में है। इस बात पर जोर दिया जाना चाहिए कि इस खंड में छोड़े गए संसाधनों को लोड करने के लिए समान तरीके से लागू किए गए तरीके। ExtenderClassLoader में इकाई वर्गों वाले मॉड्यूल का एक संग्रह होता है और उन्हें कक्षाओं और संसाधनों के लोडिंग को दर्शाता है। यह आयात की आवश्यकता के बिना आवश्यक कोड तक पहुंच प्रदान करता है। ExtenderClassLoader शेष आवश्यक वर्गों को लोड करने के लिए डिफ़ॉल्ट बूटलोडर को दर्शाता है। इस कोड की थ्रेड सुरक्षा को कई CopyOnWriteArraySet और थ्रेड-सुरक्षित क्लास लोडर के गैर-अवरुद्ध कार्यान्वयन का उपयोग करके सुनिश्चित किया जाता है।

यह सब एक साथ रखना

इस बिंदु पर, पाठक को यह समझना चाहिए कि हाइबरनेट-एक्सटेंडर के मूल तत्व कैसे काम करते हैं। अब आपको सभी भागों को एक साथ इकट्ठा करने की आवश्यकता है। ऐसा करने के लिए, आपको ओएसएमआई वातावरण में स्प्रिंग डीएम के साथ काम करने के लिए मॉड्यूल को कॉन्फ़िगर करना होगा। ऑब्जेक्ट कॉन्फ़िगरेशन की बेहतर समझ के लिए, हमारे सिस्टम के वर्ग आरेख पर विचार करें।



स्थापित कैनन के अनुसार, स्प्रिंग डीएम मॉड्यूल का कॉन्फ़िगरेशन कम से कम दो फाइलों में विभाजित है। पहला वसंत कंटेनर का वास्तविक विन्यास है। दूसरा OSGi वातावरण के लिए विशिष्ट कॉन्फ़िगरेशन है। हमारे मामले में, ये reference.xml और osgi-reference.xml फाइलें हैं।

स्प्रिंग डीएम के लिए हाइबरनेट-एक्सटेंडर विन्यास वर्ग आरेख के समान है। संदर्भ.xml कॉन्फ़िगरेशन फ़ाइल की शुरुआत में, डेटा स्रोत ऑब्जेक्ट का वर्णन किया जाता है - यह डेटा स्रोत है जिसकी सहायता से डेटाबेस के साथ सभी इंटरैक्शन किए जाते हैं। इसके बाद लेन-देन प्रबंधक ऑब्जेक्ट का कॉन्फ़िगरेशन आता है जो स्प्रिंग वातावरण में लेनदेन समर्थन प्रदान करता है। सेशनफैक्टरी ऑब्जेक्ट हाइबरनेटेशनफैक्टरी का एक उदाहरण है जो ऊपर वर्णित वर्ग है जो कि SFFactory बनाने के लिए जिम्मेदार है। सेशनफैक्टरी का संदर्भ लेनदेन प्रबंधक को दिया जाता है। कॉन्फ़िगरेशन में अगली ऑब्जेक्ट extenderClassLoader है, जिसमें जब defaultClassLoader के रूप में बनाया जाता है, तो डिफ़ॉल्ट वातावरण लोडर स्प्रिंग वातावरण में स्थापित होता है। SessionFactoryCreator ऑब्जेक्ट मॉड्यूल के बारे में परिवर्तित डेटा को ध्यान में रखते हुए, हाइबरनेट पर्यावरण के पुन: संयोजन की शुरुआत करने के सभी बुनियादी काम करता है। हमारे मॉड्यूल का केंद्रीय उद्देश्य एक्सटेंडर है, जो बनाने की प्रक्रिया में, ऑब्जेक्ट्स के संदर्भ प्राप्त करता है: बंडललेनटेक्स्ट, न्यू नमलेस एक्ज़ीक्यूसर, न्यू नेमलेस एक्सटेंडेडबंडलेफ़ैक्ट्री और सेशनफैक्टरीक्रीट। दूसरी ओस्गी-संदर्भ.एक्सएमएल कॉन्फ़िगरेशन फ़ाइल में, ओएसजीआई सेवाएं घोषित की जाती हैं: डेटा स्रोत, लेन-देन प्रबंधक, सेशनफैक्टरी।

context.xml

 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:osgi="http://www.springframework.org/schema/osgi" xmlns:osgi-compendium="http://www.springframework.org/schema/osgi-compendium" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd"> <bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" scope="singleton"> <property name="driverClass" value="org.hsqldb.jdbc.JDBCDriver" /> <property name="jdbcUrl" value="jdbc:hsqldb:hsql://localhost/test" /> <property name="user" value="SA" /> <property name="password" value="" /> </bean> <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager" scope="singleton"> <property name="sessionFactory" ref="sessionFactory" /> </bean> <bean id="sessionFactory" class="iconcerto.hibernate.HibernateSessionFactoryBean" scope="singleton"> <property name="dataSource" ref="dataSource" /> <property name="configurationClass" value="org.hibernate.cfg.AnnotationConfiguration" /> <property name="classLoader" ref="extenderClassLoader" /> </bean> <bean id="extenderClassLoader" class="iconcerto.extender.ExtenderClassLoader" scope="singleton"> <property name="defaultClassLoader"> <bean class="org.springframework.util.ClassUtils" factory-method="getDefaultClassLoader"/> </property> </bean> <bean id="sessionFactoryCreator" class="iconcerto.hibernate.extender.SessionFactoryCreator" scope="singleton"> <property name="extenderClassLoader" ref="extenderClassLoader" /> <property name="sessionFactory" ref="sessionFactory" /> </bean> <bean id="extender" class="iconcerto.extender.Extender" scope="singleton" init-method="initialize"> <property name="bundleContext" ref="bundleContext" /> <property name="executor"> <bean class="java.util.concurrent.Executors" factory-method="newSingleThreadExecutor" /> </property> <property name="extendedBundleFactory"> <bean class="iconcerto.hibernate.extender.HibernateBundleFactory"/> </property> <property name="bundleConsumer" ref="sessionFactoryCreator" /> </bean> </beans> 

OSGi-context.xml

 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://www.springframework.org/schema/osgi" xmlns:osgi-compendium="http://www.springframework.org/schema/osgi-compendium" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-1.2.xsd http://www.springframework.org/schema/osgi-compendium http://www.springframework.org/schema/osgi-compendium/spring-osgi-compendium-1.2.xsd"> <osgi:service ref="dataSource" interface="javax.sql.DataSource" /> <osgi:service ref="transactionManager"> <osgi:interfaces> <value> org.springframework.transaction.support.ResourceTransactionManager </value> </osgi:interfaces> </osgi:service> <osgi:service ref="sessionFactory" interface="org.hibernate.SessionFactory" /> </beans> 

प्रोटोटाइप की कमियाँ

किसी भी प्रोटोटाइप की तरह, हाइबरनेट-एक्सटेंडर में कई खामियां हैं। एक ओर, मुख्य विचार को व्यक्त करना मुश्किल है अगर इसे बड़ी संख्या में माध्यमिक विवरणों के साथ मिलाया जाए। दूसरी ओर, कोई भी बहुत स्पष्ट खामियों का उल्लेख नहीं कर सकता है जो एक वास्तविक अनुप्रयोग में इस कोड के उपयोग को रोकते हैं।

वसंत कॉन्फ़िगरेशन से, आपकी आंख को पकड़ने वाली पहली चीज सीधे संदर्भ में डेटा स्रोत के गुणों को सेट करने की उपस्थिति है। xx फ़ाइल ही। किसी भी वास्तविक एप्लिकेशन को इसमें बदलाव की आवश्यकता होती है। उदाहरण के लिए, संपत्ति-प्लेसहोल्डर के स्प्रिंग तंत्र का उपयोग करके या बाहरी समय में डेटाबेस कनेक्शन मापदंडों में परिवर्तन प्रदान करने वाले अधिक जटिल प्रणाली को लागू करने के लिए एक बाहरी गुण फ़ाइल से इस डेटा को स्थापित करना।

उपरोक्त लिस्टिंग में, लॉगिंग के लिए जिम्मेदार कोड छोड़ा गया है, जिसके बिना मॉड्यूल का लगभग कोई भी उपयोग अकल्पनीय है।

वर्णित कार्यान्वयन में निम्नलिखित गंभीर खामी है। यदि कोई मॉड्यूल एक एक्सटेंशन में जोड़ा जाता है तो क्या होता है, पहले से ही विस्तारित मॉड्यूल, हाइबरनेट एपीआई का उपयोग करके एक ऑपरेशन करता है और लेनदेन के अंदर होता है? इस तरह के एक ऑपरेशन, वर्तमान कार्यान्वयन के तहत, विफलता के लिए बर्बाद है, हालांकि यदि इसे कोड में ध्यान में रखा जाता है, तो एकमात्र असुविधा अब संबंधित प्रासंगिक सत्र ऑब्जेक्ट पर चालान संचालन से संबंधित विशिष्ट अपवादों से निपटने में होगी।

और आखिरी खामी जो मैं उजागर करना चाहता हूं वह एक प्रदर्शन मुद्दा है जो हाइबरनेट रनटाइम वातावरण को पुन: कॉन्फ़िगर करते समय होता है जो प्रत्येक एक्स्टेंसिबल मॉड्यूल में प्रत्येक परिवर्तन के बाद होता है।

थर्ड-पार्टी OSGi फिक्शन

कई जावा पुस्तकालयों को पहले से ही ओएसजीआई में चलाने के लिए तैयार किया गया है, लेकिन दुर्भाग्य से सभी नहीं। इस स्थिति से दो तरीके हैं, या तो तीसरे पक्ष द्वारा तैयार ओएसजीआई-संशोधित संस्करणों का उपयोग करें (उदाहरण के लिए, स्प्रिंगसोर्स सोर्स बंडल बंडल [http://ebr.springsource.com/repository/app/]), या स्वयं पुस्तकालयों के ऐसे संस्करण तैयार करें। उदाहरणों के स्रोत कोड के साथ परियोजना में, इस तरह की तैयारी की जाती है (सबप्रोजेक्ट लिब)। मैं यह नोट करना चाहता हूं कि एक जटिल पुस्तकालय के लिए यह कोई मामूली काम नहीं है। आपको तृतीय-पक्ष कोड द्वारा उपयोग किए जा सकने वाले पैकेज के निर्यात के लिए लाइब्रेरी की संरचना को समझना होगा। आंतरिक लाइब्रेरी तंत्र के कारण अतिरिक्त समस्याएं उत्पन्न हो सकती हैं जो OSGi पर्यावरण के साथ खराब संगत या असंगत हैं। लेकिन यह सब, ज्यादातर मामलों में, एक हल करने योग्य कार्य है। लाइब्रेरी आर्किटेक्चर की तकनीकी समस्याओं को केवल मैन्युअल रूप से हल किया जा सकता है, जबकि विभिन्न यूटिलिटीज (bnd, मावेन, ट्रिक्स आदि) का उपयोग करके निर्यात समस्या को स्वचालित किया जा सकता है।

निष्कर्ष

यह OSGi में हाइबरनेट के साथ काम करने के लिए एक्सटेंडर दृष्टिकोण का वर्णन करता है। केवल एक चीज बची है जिसे आप परिणामस्वरूप मॉड्यूल का उपयोग कर सकते हैं। META-INF / MANIFEST.MF में एंटिटी-क्लास हेडर में एक्स्टेंसिबल मॉड्यूल को पूर्ण हाइबरनेट इकाई वर्ग नामों की एक सूची डालनी चाहिए। इसके बाद, जब आप इस मॉड्यूल को चलाते हैं, तो एक्सटेंडर हमारे ClassLoader कार्यान्वयन का उपयोग करके इन कक्षाओं को लोड करेगा और हाइबरनेट नेटवर्क को फिर से संगठित करेगा। इसके अलावा, हाइबरनेट एपीआई के उपयोग के लिए आवश्यक मॉड्यूल को OSGi सेवा SessionFactory और ResourceTransactionManager को आयात करना चाहिए। उसके बाद, मॉड्यूल सामान्य तरीके से (आधिकारिक गाइड के अनुसार) वसंत वातावरण में हाइबरनेट एपीआई का उपयोग कर सकता है।
यूनिट और इंटीग्रेशन टेस्ट के साथ पूरा एक्सटेंडर कोड googlecode रिपॉजिटरी में उपलब्ध है, जो लिंक लेख के अंत में स्थित है। यह कोड विकसित किया जाएगा, इसलिए इसमें रुचि रखने वाले सभी लोग परिवर्तनों का पालन कर सकते हैं। इस कोड के विकास में भाग लेने की इच्छा रखने वाले मुझसे संपर्क कर सकते हैं। खैर, हमेशा की तरह, जिनके पास कोई सवाल है, टिप्पणी करने के लिए आपका स्वागत है!

अतिरिक्त स्रोत

code.google.com/p/iconcerto/source/browse
www.aqute.biz/Bnd/Bnd
www.aqute.biz/Snippets/Extender
static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html
docs.jboss.org/hibernate/core/3.6/reference/en-US/html
static.springsource.org/osgi/docs/1.2.1/reference/html