Загрузка многостраничного файла на Google Appengine с использованием jersey-1.7
Я написал приложение в Google Appengine с Джерси для обработки простой загрузки файлов. Это прекрасно работает, когда он был на майке 1.2. В более поздних версиях (текущий 1.7) вводится @FormDataParam для обработки входов multipart/form. Я использую jersey-multipart и зависимость mimepull. Кажется, что новый способ сделать это создание временных файлов в appengine, которые все мы знаем, является незаконным...
Я что-то упустил или сделал что-то не так, потому что Джерси теперь якобы совместим с AppEngine?
@POST
@Path("upload")
@Consumes(MediaType.MULTIPART_FORM_DATA)
public void upload(@FormDataParam("file") InputStream in) { .... }
Вышеуказанное не будет выполнено при вызове с этими исключениями...
/upload
java.lang.SecurityException: Unable to create temporary file
at java.io.File.checkAndCreate(File.java:1778)
at java.io.File.createTempFile(File.java:1870)
at java.io.File.createTempFile(File.java:1907)
at org.jvnet.mimepull.MemoryData.createNext(MemoryData.java:87)
at org.jvnet.mimepull.Chunk.createNext(Chunk.java:59)
at org.jvnet.mimepull.DataHead.addBody(DataHead.java:82)
at org.jvnet.mimepull.MIMEPart.addBody(MIMEPart.java:192)
at org.jvnet.mimepull.MIMEMessage.makeProgress(MIMEMessage.java:235)
at org.jvnet.mimepull.MIMEMessage.parseAll(MIMEMessage.java:176)
at org.jvnet.mimepull.MIMEMessage.getAttachments(MIMEMessage.java:101)
at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readMultiPart(MultiPartReaderClientSide.java:177)
at com.sun.jersey.multipart.impl.MultiPartReaderServerSide.readMultiPart(MultiPartReaderServerSide.java:80)
at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom(MultiPartReaderClientSide.java:139)
at com.sun.jersey.multipart.impl.MultiPartReaderClientSide.readFrom(MultiPartReaderClientSide.java:77)
at com.sun.jersey.spi.container.ContainerRequest.getEntity(ContainerRequest.java:474)
at com.sun.jersey.spi.container.ContainerRequest.getEntity(ContainerRequest.java:538)
У кого есть ключ? Есть ли способ сделать что-то, не позволяя mimepull создавать временный файл?
Ответы
Ответ 1
Для файлов, размер которых превышает размер по умолчанию, multipart
создаст временный файл. Чтобы этого избежать - создание файла невозможно на gae - вы можете создать файл jersey-multipart-config.properties
в папке ресурсов проекта и добавить к нему эту строку:
bufferThreshold = -1
Затем код - тот, который вы дали:
@POST
@Consumes(MediaType.MULTIPART_FORM_DATA)
public Response post(@FormDataParam("file") InputStream stream, @FormDataParam("file") FormDataContentDisposition disposition) throws IOException {
post(file, disposition.getFileName());
return Response.ok().build();
}
Ответ 2
В интересах тех, кто борется при использовании Eclipse с GPE (плагин Google для Eclipse), я даю это слегка измененное решение, полученное из ответа @yves.
Я тестировал его с помощью App Engine SDK 1.9.10
и Jersey 2.12
. Он не будет работать с App Engine SDK 1.9.6 -> 1.9.9
среди других из-за другой проблемы.
В папке \war\WEB-INF\classes
создайте новый файл с именем jersey-multipart-config.properties
. Отредактируйте файл, чтобы он содержал строку jersey.config.multipart.bufferThreshold = -1
.
Примечание, что папка \classes
скрыта в Eclipse, поэтому найдите папку в проводнике файлов операционной системы (например, проводник Windows).
Теперь, когда функция multipart
инициализируется (при инициализации сервлета Джерси) и когда выполняется загрузка файла (по запросу на сообщение сержанта Сервера), временный файл больше не будет создан, и GAE не будет жаловаться.
Ответ 3
Очень важно поместить файл jersey-multipart-config.properties
под WEB-INF/classes
внутри WAR.
Обычно в файловой структуре WAR вы помещаете файлы конфигурации (web.xml
, appengine-web.xml
) в WEB-INF/
, но здесь вам нужно поместить в WEB-INF/classes
.
Пример конфигурации Maven:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<archiveClasses>true</archiveClasses>
<webResources>
<resource>
<directory>${basedir}/src/main/webapp/WEB-INF</directory>
<filtering>true</filtering>
<targetPath>WEB-INF</targetPath>
</resource>
<resource>
<directory>${basedir}/src/main/resources</directory>
<targetPath>WEB-INF/classes</targetPath>
</resource>
</webResources>
</configuration>
</plugin>
И ваша структура проекта может выглядеть так:
![Project Structure]()
Содержание jersey-multipart-config.properties
с Джерси 2.x:
jersey.config.multipart.bufferThreshold = -1
Ответ 4
Я нашел решение программным образом избежать использования временного создания файла (очень полезно для реализации GAE)
Мое решение состоит в создании нового поставщика MultiPartReader... ниже моего кода
@Provider
@Consumes("multipart/*")
public class GaeMultiPartReader implements MessageBodyReader<MultiPart> {
final Log logger = org.apache.commons.logging.LogFactory.getLog(getClass());
private final Providers providers;
private final CloseableService closeableService;
private final MIMEConfig mimeConfig;
private String getFixedHeaderValue(Header h) {
String result = h.getValue();
if (h.getName().equals("Content-Disposition") && (result.indexOf("filename=") != -1)) {
try {
result = new String(result.getBytes(), "utf8");
} catch (UnsupportedEncodingException e) {
final String msg = "Can't convert header \"Content-Disposition\" to UTF8 format.";
logger.error(msg,e);
throw new RuntimeException(msg);
}
}
return result;
}
public GaeMultiPartReader(@Context Providers providers, @Context MultiPartConfig config,
@Context CloseableService closeableService) {
this.providers = providers;
if (config == null) {
final String msg = "The MultiPartConfig instance we expected is not present. "
+ "Have you registered the MultiPartConfigProvider class?";
logger.error( msg );
throw new IllegalArgumentException(msg);
}
this.closeableService = closeableService;
mimeConfig = new MIMEConfig();
//mimeConfig.setMemoryThreshold(config.getBufferThreshold());
mimeConfig.setMemoryThreshold(-1L); // GAE FIX
}
@Override
public boolean isReadable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType) {
return MultiPart.class.isAssignableFrom(type);
}
@Override
public MultiPart readFrom(Class<MultiPart> type, Type genericType, Annotation[] annotations, MediaType mediaType,
MultivaluedMap<String, String> headers, InputStream stream) throws IOException, WebApplicationException {
try {
MIMEMessage mm = new MIMEMessage(stream, mediaType.getParameters().get("boundary"), mimeConfig);
boolean formData = false;
MultiPart multiPart = null;
if (MediaTypes.typeEquals(mediaType, MediaType.MULTIPART_FORM_DATA_TYPE)) {
multiPart = new FormDataMultiPart();
formData = true;
} else {
multiPart = new MultiPart();
}
multiPart.setProviders(providers);
if (!formData) {
multiPart.setMediaType(mediaType);
}
for (MIMEPart mp : mm.getAttachments()) {
BodyPart bodyPart = null;
if (formData) {
bodyPart = new FormDataBodyPart();
} else {
bodyPart = new BodyPart();
}
bodyPart.setProviders(providers);
for (Header h : mp.getAllHeaders()) {
bodyPart.getHeaders().add(h.getName(), getFixedHeaderValue(h));
}
try {
String contentType = bodyPart.getHeaders().getFirst("Content-Type");
if (contentType != null) {
bodyPart.setMediaType(MediaType.valueOf(contentType));
}
bodyPart.getContentDisposition();
} catch (IllegalArgumentException ex) {
logger.error( "readFrom error", ex );
throw new WebApplicationException(ex, 400);
}
bodyPart.setEntity(new BodyPartEntity(mp));
multiPart.getBodyParts().add(bodyPart);
}
if (closeableService != null) {
closeableService.add(multiPart);
}
return multiPart;
} catch (MIMEParsingException ex) {
logger.error( "readFrom error", ex );
throw new WebApplicationException(ex, 400);
}
}
}
Ответ 5
Мы столкнулись с аналогичной проблемой, Jetty не позволил нам загружать файлы более 9194 байт (внезапно - один день), после чего мы поняли, что кто-то взял наш пользовательский доступ из /tmp, что соответствует java.io.tmpdir в некоторых версиях Linux, поэтому Jetty не смог сохранить загруженный файл, и мы получили ошибку 400.