cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Clout <henry.cl...@kuluvalley.com>
Subject Re: Accessing temporary file name of attachments
Date Wed, 15 Jan 2014 16:39:29 GMT
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 <sberyozkin@gmail.com> 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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message