2012-12-26 19 views
6

में मल्टीपार्ट कॉन्फिग में प्रोग्रामेटिक पहुंच मैं अपने आवेदन में फ़ाइल अपलोड को लागू करने के लिए सर्वलेट 3 @MultiPartConfig एनोटेशन का उपयोग करता हूं। मुझे रनटाइम पर मल्टीपार्ट-कॉन्फ़िगरेशन स्थान पैरामीटर सेट करना होगा (एनोटेशन पैरामीटर में हार्डकोड नहीं)। क्या servlet की multipart-config के प्रोग्रामेटिक पहुंच के लिए कोई एपीआई है?सर्वलेट 3.0

धन्यवाद

उत्तर

5
@MultiPartConfig

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

@Override 
protected void doPost(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) 
     throws ServletException, IOException { 

    httpServletResponse.setContentType("text/html"); 
    PrintWriter printWriter = httpServletResponse.getWriter(); 

    InputStream inputStream; 
    FileOutputStream fileOutputStream; 

    for (Part part : httpServletRequest.getParts()) { 

     inputStream = httpServletRequest.getPart(part.getName()).getInputStream(); 
     int i = inputStream.available(); 
     byte[] b = new byte[i]; 
     inputStream.read(b); 
     String fileName = ""; 

     for (String temp : part.getHeader("content-disposition").split(";")) { 
      if (temp.trim().startsWith("filename")) { 
       fileName = temp.substring(temp.indexOf('=') + 1).trim().replace("\"", ""); 
      } 
     } 

     String uploadDir = "/temp"; 
     fileOutputStream = new FileOutputStream(uploadDir + "/" + fileName); 
     fileOutputStream.write(b); 
     inputStream.close(); 
     fileOutputStream.close(); 

     printWriter.write("Uploaded file " + uploadDir + "/" + fileName + "."); 
    } 
} 
+0

के साथ इस साफ उदाहरण पर नजर आप @MultiPartConfig उपयोग कर रहे हैं और फिर एक क्रम फ़ाइल स्थान की जरूरत है आपके पास "पुनः अपलोड" करने के अलावा कोई अन्य विकल्प नहीं है भागों। –

0

मैं भी अपने एक ही समस्या थी और समाधान सरल है: मानक सर्वलेट 3.0 फाइल अपलोड है नहीं पर्याप्त: बस अपाचे FileUpload कॉमन्स से जार हड़पने और आप

काम हो गया बस स्ट्रीमिंग एपीआई

ServletFileUpload upload = new ServletFileUpload(); 

    // Parse the request 
    FileItemIterator iter = upload.getItemIterator(request); 
    while (iter.hasNext()) { 
     FileItemStream item = iter.next(); 
     String name = item.getFieldName(); 
     InputStream stream = item.openStream(); 
     if (item.isFormField() == false) 
      System.out.println("File field " + name + " with file name " 
      + item.getName() + " detected."); 
      FileOutputStream fos = new FileOutputStream("your_location"); 
      Streams.copy (stream, fos, true); 

     } 
    } 
+0

प्रश्न @MultiPartConfig और फ़ाइल अपलोड के बारे में था, जिसे आपने संबोधित नहीं किया था। आप अनुरोध पर पहले से ही किसी आइटम से स्ट्रीमिंग कर रहे हैं (मेमोरी में अपलोड किया गया), और इसका मतलब है कि आप इसे फिर से "पुनः अपलोड" पढ़ रहे हैं। –

+0

@ ब्रायन रींडेल जो मामला नहीं है, मैं फिर से अपलोड नहीं कर रहा हूं, स्ट्रीमिंग एपीआई के साथ मैं जो करता हूं वह अनुरोध की प्रत्यक्ष पार्सिंग है जिसमें कोई अस्थायी फ़ाइलें या स्मृति में कैशिंग नहीं है। वास्तव में स्ट्रीमिंग एपीआई के साथ इसका लाभ है: मेमोरी कुशल और तेज प्रसंस्करण, कृपया http://commons.apache.org/proper/commons-fileupload/streaming.html –

+0

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

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