Problem mit Spring FileUpload
Ich habe die folgende code-block, das ist der Umgang mit meinem Datei-upload von einem Foto, dass ich mit meiner Spring MVC web-Anwendung. Ich bin mit Spring MVC CommonsMultipartFileResolver zu handhaben Datei-uploads.
if(model.getPhoto() != null){
if(!model.getPhoto().isEmpty()){
MultipartFile file = model.getPhoto();
String fileName = file.getOriginalFilename();
String filePath = baseDirectory + fileName;
FileOutputStream fos = new FileOutputStream(filePath);
try
{
fos.write(file.getBytes());
agentProfile.setPhotoUri(fileName);
}
catch (IllegalStateException e)
{
System.out.println(e);
}
finally
{
fos.close();
}
}
}
In meinem app-servlet.xml Datei habe ich folgenden code zum konfigurieren der MultipartFile resolver bean.
<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
</bean>
Ich bin erleben einige zufällige Probleme, wenn ich Fotos hochladen.
1)Wenn gehe ich zum hochladen von einem kleineren Foto, etwa 3 kb oder so, Es wird erfolgreich hochgeladen wurden.
2)Wenn gehe ich zum hochladen von einem etwas größeren Foto, wird es erstellt die Datei im Verzeichnis, aber mit einer Größe von 0 bytes und gibt die folgende Fehlermeldung.
java.lang.IllegalStateException: File has been moved - cannot be read again
org.springframework.web.multipart.commons.CommonsMultipartFile.getBytes(CommonsMultipartFile.java:112)
com.mmz.admin.mvc.controller.AddAgentController.processFinish(AddAgentController.java:145)
org.springframework.web.servlet.mvc.AbstractWizardFormController.validatePagesAndFinish(AbstractWizardFormController.java:642)
org.springframework.web.servlet.mvc.AbstractWizardFormController.processFormSubmission(AbstractWizardFormController.java:492)
org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormController.java:265)
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:874)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:808)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:476)
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:441)
javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
Ich habe versucht ein paar verschiedene Optionen zu konfigurieren, die Multipart resolver wie das zu handhaben ist eine CommonsMultipartFile - Objekt im Gegensatz zu einem einfachen MultipartFile - Objekt, aber nichts änderte sich.
Ich habe auch versucht, manuell konfigurieren Sie die maximale upload-Größe in der CommonsMultipartFileResolver bean mit der folgenden Eigenschaft.
<property name="maxUploadSize" value="1024000000"/>
nichts geändert. Ich bin nicht sicher, was die CommonsMultipartResolver standardmäßig so weit wie Größe der Datei, die hochgeladen werden können, aber das ist nicht meine Frage.
Mir wurde gesagt, dass das problem, das ich erlebt, die aufgrund eines Problems in der Multipart-parser/handler, dass der Frühling mit. Ich hatte den letzten post über das gleiche problem, und da neue Informationen gefunden, wollte umbuchen mit den neuen Informationen. Die alte post finden Sie unter CommonsMultipartFileResolver Problem
Ich das Gefühl, dass ich habe fast jede Ressource im internet finden Sie zusätzliche Dokumentation, aber nicht in der Lage bin, um das problem herauszufinden.
Bitte helfen Sie mir herauszufinden, was ist Los mit diesem, und wenn es eine bessere, einfacher Lösung um vielleicht den explorer die Optionen, aber ich würde lieber bleiben mit meiner aktuellen Methode, wenn ich eine Lösung finden können.
BEARBEITEN
Hinweis - ich habe experimentiert mit der unterschiedlichen Größe, Fotos hochladen, und ich glaube, dass die Grenze, ist es mir erlaubt, der upload ist etwa 10Kb. Etwas größer als 10Kb ist, wodurch es zu brechen und gib mir den oben genannten Fehler.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Nach tun eine Menge Forschung, ich habe mein problem gelöst. Es stellt sich heraus, dass es ist nicht der standardmäßige Grenzwert für die maximale Anzahl von bytes, die Sie hochladen können mit CommonsMultipartFileResolver natürlich können Sie in Ihrem bean, was Sie wollen für diesen Betrag durch die Einstellung der folgenden Eigenschaft.
Es ist auch eine Eigenschaft maxInMemorySize ermöglicht Ihnen die Angabe der maximalen Größe, die erlaubt, bevor die Dateien auf die Festplatte geschrieben werden. Obwohl dies funktioniert auf die gleiche Weise wie die maximale upload-Größe, wenn Sie nicht den Betrag anzugeben, Standard ist 1024 bytes. Dies würde erklären, es zu brechen, wenn ich versuchte zum hochladen einer großen Datei.
Damit Dateien, die größer als 1024 bytes, die hochgeladen werden, müssen Sie erhöhen die maxInMemorySize Wert auf das, was Sie benötigen, wie die folgenden...
Dies ist, was passte auf mein problem. Ich habe gelernt, dass diese Eigenschaft standardmäßig auf 1024, wenn ich die überprüfung der Dokumentation für CommonsFileUpload Dokumentation.
Können Sie sich diese Dokumentation an CommonsFileUpload Dokumentation
Ich hoffe, dies hilft jemand, da es nicht sehr gute Dokumentation über die Verwendung der CommonsMultipartFile.
Ich bemerken, dieser Fehler tritt nur auf, wenn die Datei über 1024 bytes UND Sie versuchen, die Datei zu Lesen, zweimal. Als CitadelCSAlum erwähnt, die Einstellung maxInMemorySize = maxUploadSize werden dieses Problem beheben, aber sollte man im Hinterkopf behalten Speichernutzung. Wenn der Speicher ist ein Anliegen, ist eine weitere option zu schreiben, die multipart-Datei Daten in eine temp-Datei auf dem ersten zu Lesen und zu verwenden, dass die Datei für die spätere liest. Wenn Sie nicht Lesen Sie die zweimal, die Sie sollten nicht erhöhen müssen maxInMemorySize.
Ausnahme Sie verweisen in Ihrer Frage heißt es: "die Datei wurde verschoben - nicht erneut gelesen werden kann". Dies deshalb, weil wir versuchen, zu Lesen inputstream mehr als einmal aus multipart-Datei.
Ich auch konfrontiert dieses Problem zu einer Zeit, und in meinem Fall, zuerst habe ich überprüft, den Inhalt der Datei, und nach, dass ich versuchte, es zu retten mit "transferTo" - Methode im Frühjahr MultiPart. Diese Ausnahme kommt, wenn ich versuche zu nutzen "transferTo" - Methode. Hier fordere ich für inputstream zweimal.
Ich nicht vor diesem Problem, wenn die Datei zu klein ist. In "transferTo" - Methode gibt es einen internen Aufruf für "isAvailable" - Methode. Bitte Folgen Sie dem code-segment unten:
link: http://grepcode.com/file/repo1.maven.org/maven2/org.springframework/spring-web/3.2.1.RELEASE/org/springframework/web/multipart/commons/CommonsMultipartFile.java#CommonsMultipartFile.isAvailable%28%29
Beobachtungen:
Wenn es zu klein ist, der Frühling im Gedächtnis zu speichern und wenn wir Fragen, für die Datei ermittelt werden aus dem Speicher. Wir können Fragen, für die es mehrfach, weil die Datei im Speicher.
Wenn es groß genug ist, wird der Frühling speichern Sie es als eine temporäre Datei, die wir nicht kennen den Ort, aber nachdem wir gelesen inputstream einmal, die Datei kann gelöscht werden intern von Frühling. Dann, wenn wir Sie bitten, das zweite mal, dass der Fehler sagt, "nicht erneut gelesen werden kann".
Also meine Lösung ist die erste, die ich habe, um es zu speichern in server-Speicherort verwenden "transferTo" - Methode und ermittelt werden, dass die lokale Datei zu überprüfen oder andere Sekunde Zeit brauchen.
Ich denke, es ist nicht gut, zu erhöhen "maxUploadSize" in "multipartResolver" bean als es verbraucht mehr Speicher, wenn die Datei zu groß ist.
DispatcherServlet.doDispatch()
führt cleanup von multi-part Anforderungen nach der Anfrage bearbeitet wurde, werden, wenn die Prozedur zurückgegeben hat (es sei denn, der Frühling weiß, dass die Anfrage asynchron ist, z.B. markiert mit@Async
). Also, wenn request-handler setzenMultipartFile
zu Warteschlange, wird später behandelt werden – Pech.