Hi Sergey.
I don't think we'd want to create the file in its final destination because:
i) The destination base directory and path vary from service method to service
method, and are also a function of the request parameters. I wouldn't have
thought there would be sufficient information in the interface you're proposing
to figure this out, and even if there were I'm not sure it sounds like a good
idea to pull this out of the service methods.
ii) We don't really want to copy a file directly to the target until the
request has been validated. Other processes operate over the target directory
which require the input to have been validated.
However, let's say the interface were something like (caveat: I don't know if
this is possible!) :
import java.io.File;
import org.apache.cxf.jaxrs.ext.multipart.Attachment;
public interface TempFileGenerator {
/**
* Return a file which will be used as the destination for the payload
* for the given attachment.
* @param attachment
* @return
*/
File generateTempFile(Attachment attachment);
}
Then an implementation which would achieve what we were after would be:
public class MyTempFileGenerator implements TempFileGenerator {
private File tempBasePath;
@Override
public File generateTempFile(Attachment attachment) {
return new File(tempBasePath, attachment.getContentId());
}
}
So our service implementation could then figure out where the temp file is (if
not in memory) based on the Attachment object. This is what I meant when I
mentioned that that the service implementation should be able to figure out the
temp file location.
If this is what you were proposing for the temp file interface (or something
comparable), then it would work for the use case I was describing.
Cheers,
Henry
On 15 Jan 2014, at 14:14, Sergey Beryozkin <[email protected]> wrote:
> Hi Henry
> On 15/01/14 13:53, Henry Clout wrote:
>> Hi Sergey.
>>
>> For us at least this wouldn't really address our problem. Our flow is:
>>
>> - Content is uploaded to CXF.
>> - Our service method performs some validation on the input.
>> - If all is ok, the content is moved to the correct place.
>>
>> In our case, the correct place is a location on a NAS. The CXF temp file
>> location is also on the NAS So to go via an InputStream, we have pull the
>> data from the NAS across the network into memory, then transfer it out again
>> over the network back to the NAS. Even on a gigabit network, this is a
>> significant slowdown for large files vs a file rename, which is what
>> transferTo amounts to if the CXF temp directory is placed on the NAS.
>>
>> Dealing exclusively with InputStreams prevents any kind of file move style
>> optimisation. I agree that this is an application specific optimisation,
>> but I guess I thought it would be useful if CXF could allow this kind of
>> functionality via some sort of interface to those that would benefit from
>> it. My gut feeling was that it wasn't just us who are using CXF to transfer
>> large files, so someone else may benefit from this functionality.
>>
>> As it happens, we've worked around this by using Spring multipart parsing
>> within CXF:
>>
>> @POST
>> @Path("/kulus/{guid}/media")
>> public void addMediaToKulu(@PathParam("guid") String guid) throws
>> IOException {
>> MultipartFile multipartFile = null;
>> if (commonsMultipartResolver.isMultipart(httpServletRequest)) {
>> MultipartHttpServletRequest multipartHttpServletRequest
>> = commonsMultipartResolver.resolveMultipart(httpServletRequest);
>> Iterator<String> fileNamesIterator =
>> multipartHttpServletRequest.getFileNames();
>> if (fileNamesIterator.hasNext()) {
>> String firstFileName = fileNamesIterator.next();
>> multipartFile =
>> multipartHttpServletRequest.getFile(firstFileName);
>> }
>> }
>> // We call multipartFile.transferTo(file) later on ...
>> }
>>
>> At the end of the day, maybe this workaround is sufficient rather than
>> changing the core CXF code. I guess if you think this functionality
>> wouldn't be useful to others, then I'm happy to accept that :-)
>>
> What I'm not getting is this:
>
> Suppose CXF will let developers customize the way, or rather, where temp
> files are created and I guess with the option to be notified when a temp file
> needs to be closed. In your case you'd register a handler which would ensure
> that if a temporarily file is needed then it would be created immediately in
> the right place.
>
> So now you have an InputStream, possible completely in the memory and may be
> backed up by a temp file in the right location.
>
> Can you please explain again why that won't be sufficient in your case ?
>
> Thanks, Sergey
