2012-05-14 9 views
12

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

यह अच्छा काम करता है अगर पूरे पेड़ को एक बार में बनाया जा रहा है, लेकिन यदि एनोटिप्सेज में केवल एक फ़ाइल बनाई गई है (उदाहरण के लिए, जब मैं ग्रहण में फ़ाइल को सहेजता हूं), प्रोसेसर केवल उस प्रकार को देखता है, और बनाता है एक अपूर्ण रजिस्टर। मैं इस परिदृश्य में अन्य प्रकार की जांच कैसे कर सकता हूं?

+0

आप किस एनोटेशन प्रोसेसर का उपयोग कर रहे हैं? –

+0

जावा 6 एपीआई (javax.annotation.processing.AbstractProcessor का विस्तार) –

+0

+1 का उपयोग करके मैंने खुद को लिखा था। अपनी खुद की जांच से यह उपलब्ध नहीं है, लेकिन अगर यह है तो मैं वास्तव में इसके बारे में जानना चाहता हूं। –

उत्तर

6

मैंने अभी यह काफी हल किया है। मैंने जो किया वह थोड़ा हैकी है, लेकिन मूल रूप से प्रत्येक एनोटेटेड क्लास के लिए मैं देखता हूं, मैं इसका नाम हैशसेट में जोड़ता हूं। फिर मैं एक फ़ाइल खोलने के लिए Filer.getResource() का उपयोग करता हूं जहां मैंने पहले देखे गए एनोटेटेड कक्षाओं को रिकॉर्ड किया है, और हैशसेट में भी उन्हें जोड़ें। फिर मैं रजिस्टर क्लास उत्पन्न करता हूं, और पूरे हैशसेट को उसी संसाधन में लिखता हूं जिसमें Filer.createResource() है। इससे समस्याएं उत्पन्न हो जाएंगी यदि मैं एक एनोटेटेड प्रकार हटा देता हूं, क्योंकि यह अभी भी उस फ़ाइल में दर्ज किया जाएगा, लेकिन मैं इसे प्रोजेक्ट को साफ़ कर सकता हूं या इसे हल करने के लिए उस फ़ाइल को हटा सकता हूं।

संपादित करें: साथ ही, मेरा मानना ​​है कि उपयुक्त "मूल तत्व" को Filer.createSource() में पारित करने से ग्रहण उन निर्भरताओं को सही तरीके से ट्रैक करने की अनुमति देनी चाहिए, लेकिन ऐसा नहीं है। शायद यह एक ग्रहण बग है।

+0

क्या आपको यह कोड कहीं भी साझा किया गया है? मुझे आपके दृष्टिकोण में दिलचस्पी है। –

+0

यह कंपनी के स्वामित्व वाली कोड है, लेकिन अगर मैंने कभी भी निजी परियोजना के लिए ऐसा कुछ लिखा है तो यह –

+0

उपलब्ध होगा, मैंने एक [जेनेरिक लाइब्रेरी] (https://github.com/sentinelt/evo-classindex) लिखा है इस। मुझे यह पृष्ठ मिला, क्योंकि मेरी लाइब्रेरी एक ही समस्या से पीड़ित है ... –

1

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

एक समाधान वृद्धिशील संकलन का समर्थन करने के लिए अपने वास्तुकला को बदलना है। उदाहरण के लिए, प्रत्येक एनोटेटेड HandlerClass के लिए, RegisterHandlerClass क्लास उत्पन्न करें जो हैंडलर क्लास को पंजीकृत करता है।

ऐसा कहा जाता है कि आप जो कर रहे हैं, वह लगता है कि रनटाइम पर बेहतर होगा, शायद Reflections जैसे टूल की मदद से।

+1

यह एंड्रॉइड कोड है, और ऐसा लगता है कि उनमें से अधिकांश ढांचे एंड्रॉइड पर काम नहीं करते हैं; किसी भी मामले में, यदि संभव हो तो मैं क्लासपाथ स्कैनिंग से बचना चाहता हूं। यदि मैं RegisterHandlerClass मार्ग चला गया, तो यह वास्तव में कैसे मदद करेगा? बोलने के लिए "रजिस्टरों के रजिस्टर" के बिना, मैं उन कक्षाओं को उपयुक्त हैंडलर कक्षा पंजीकृत करने के लिए कैसे प्राप्त कर सकता हूं? –

+0

यदि समस्या यह है कि हैंडलर क्लासेस लोड नहीं किए जा रहे हैं, तो मेरा RegisterHandlerClass विचार या तो काम नहीं करेगा। आप इसके बजाय प्रति हैंडलर क्लास में एक संसाधन फ़ाइल बना सकते हैं और उन्हें सभी एक ही निर्देशिका में डाल सकते हैं और फिर रनटाइम पर उस निर्देशिका को स्कैन कर सकते हैं। –

संबंधित मुद्दे