2009-11-24 26 views
12

आज एक व्यक्ति ने मुझे बताया कि "जावा ईई प्रोग्रामर फाइलों पर नहीं लिखते हैं"। मैं जावा ईई कंटेनर के भीतर से फ़ाइलों को क्यों नहीं लिख सकता (उदाहरण के लिए जेबॉस से)? गलत क्या है?जावा ईई प्रोग्रामर फाइलों को नहीं लिखते

उत्तर

16

सबसे अच्छा पेज को देखने के लिए इस एक है: http://www.oracle.com/technetwork/java/restrictions-142267.html

यह जावा ईई प्रोग्रामिंग मॉडल से अधिक प्रतिबंध विस्तार से शामिल किया गया।

सुरक्षा, पोर्टेबिलिटी, क्लस्टरिंग, थ्रेडिंग के ऊपर उल्लिखित बिंदु के अलावा लेनदेन और त्रुटि प्रबंधन पर विचार करें (फाइल सिस्टम लेनदेन नहीं हैं)।

हालांकि JVM में कोई काला जादू नहीं हो रहा है और आप फ़ाइलों को बना सकते हैं (जब तक आपके पास संबंधित अधिकार हैं), स्थिर चर का उपयोग करें, और धागे बनाएं यदि आप जानते हैं कि आप क्या कर रहे हैं।

अनुपालन के लिए जेसीए कनेक्टर को कूदने और लिखने के बजाय इन प्रतिबंधों का आमतौर पर सुझाव क्यों दिया जाता है, यह समझने में समय लगता है।

+4

हालांकि कोई "काला जादू" नहीं हो सकता है, कंटेनर का JVM सुरक्षा प्रबंधक सेट हो सकता है ताकि फ़ाइल निर्माण संभव नहीं हो सके –

+2

लिंक टूटा हुआ है, बेवकूफ ओरेकल लोग जावा –

+1

@ BorisŠuška को मारता है यह लिंक बहुत समान दिखता है मूल: http://www.oracle.com/technetwork/java/restrictions-142267.html – ewernli

31

आप जावा ईई कंटेनर के भीतर ही सब कुछ करना चाहिए: आप कोई निश्चित है कि आप फाइल सिस्टम के लिए किसी भी लगातार उपयोग होगा हो सकता है। इस के लिए कई कारण हैं, सबसे स्पष्ट किया जा रहा है कि एक कंटेनर के भीतर चल रहे अनुप्रयोगों होगा:

  • कोई निश्चित है कि एक EJB के किसी भी बाद मंगलाचरण भी एक ही के उपयोग के साथ ही भौतिक सर्वर पर होगा फ़ाइलें/फाइल सिस्टम (क्लस्टरिंग पर जैसे)
  • एक दूसरे को
(गोपनीय डेटा जो कि किसी अन्य एप्लिकेशन पढ़ सकता है लेखन एक अनुप्रयोग)
  • कोई सुरक्षा के मुद्दों (एक से अधिक आवेदन एक ही फाइल को लिखने का प्रयास कर रहा) के साथ हस्तक्षेप की कोई संभावना नहीं

    तुम भी मान लेना चाहिए कि आप नहीं करना चाहिए:

    • अपने स्वयं के धागे (कंटेनर आप के लिए यह प्रबंधन करेगा बनाएँ; यदि आप अपना खुद का बना आप
    • उपयोग सॉकेट-आईओ (सुरक्षा के मुद्दों को भी है CPU समय के कंटेनर में अन्य अनुप्रयोगों))
  • 5

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

    1

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

    तो जब आप इसे कर सकते हैं, तो अभ्यास में, आपको बहुत सी छोटी समस्याएं आती हैं जो जावा ईई में फ़ाइलों को संभालने में बहुत मुश्किल होती हैं।

    +0

    बकवास - जे 2 ईई स्पेक फ्लाई पर छवियों की पीढ़ी जैसी कई चीजों के लिए अपनी खुद की एपीआई प्रदान नहीं करता है। –

    +0

    और आपका मुद्दा है? यदि छवि निर्माण API जे 2 ईई संगत है, तो सब ठीक है। जब यह स्थानीय फाइलें नहीं होती है और बनाता है, तो आप परेशानी में हैं। लेकिन यह एक तथ्य है कि आईओ एपीआई जे 2 ईई अनुपालन नहीं है। –

    3

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

    4

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

    कारण पहले से ही अन्य उत्तर में दिया गया है:

    • सुरक्षा मुद्दे
    • पोर्टेबिलिटी मुद्दों
    • क्लस्टरिंग मुद्दों
    • थ्रेडिंग मुद्दों

    अंत में, के लिए सबसे अच्छा संसाधन ये मामले एक डेटाबेस है।

    3

    आपको एक एंटरप्राइज़ सूचना प्रणाली (ईआईएस) के रूप में एक फाइल सिस्टम पर विचार करना चाहिए। फिर आप एक संसाधन एडाप्टर बना सकते हैं जो इस ईआईएस को एक्सेस करता है, जो एक जेडीबीसी एडाप्टर के समान होता है जो डेटाबेस तक पहुंचता है। कल्पना यहां है: http://java.sun.com/j2ee/connector/download.html। इसका मतलब है कि फ़ाइल का उपयोग संभव है, लेकिन अधिक जटिल है। यह कल्पना आपको वर्क नामक कुछ प्रकार के "धागे" बनाने की अनुमति देती है।

    1

    विरासत गैर-जे 2 सिस्टम के साथ अंतःक्रिया करने के लिए, आपको कभी-कभी सॉकेट i/o, फाइलों को लिखने जैसी "बुरी चीजें" करना पड़ता है। सभी दुनिया के सर्वश्रेष्ठ में j2ee spec होगा सख्ती से पालन किया, लेकिन लोग निष्पक्षता और नौकरी पाने के लिए हर समय गैर-जे 2 चीजों से दूर हो जाते हैं। इन चीजों को सुरक्षित और विचारपूर्वक बंद करने के तरीके हैं।

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