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 :-)
Cheers,
Henry
On 15 Jan 2014, at 12:23, Sergey Beryozkin <[email protected]> wrote:
> Hi
> On 14/01/14 21:19, Henry Clout wrote:
>> Hi Sergey.
>>
>> Sure, so long as it's possible for the service implementation to map an
>> attachment to the the generated temp file, that'd work. I guess for the
>> particular use case I was describing it's slightly less clean, since the
>> user needs to take into account the fact that the data may be in memory
>> rather than on disk. But then having access to the file itself is more
>> flexible.
>
> What I've understood so far is that it is really an issue of the temporarily
> files stored in the locations which make it expensive and may be less secure
> to process the actual attachment stream.
>
> So suppose we have an application code accepting InputStream representing a
> given attachment part. IMHO the application code does not need to know or
> deal with the temporarily file which may have or not been created, the
> concern of the application is to read the available stream; as such I'm not
> really keen too on Attachment offering a transferFile operation, IMHO this is
> an extra concern for the application code :-)
>
> IMHO, offering the developers a chance to customize the way
> CachedOutputStream creates temporarily files will solve the problem under the
> hood, while the application code will just continue processing InputStream
> the high level way...
>
> Thanks, Sergey
>
>
>>
>> Yours,
>> Henry
>>
>>
>> On 12 Jan 2014, at 18:19, Sergey Beryozkin <[email protected]> wrote:
>>
>>> Hi Henry, Dan,
>>>
>>> Should we offer an interface for users to create a temporary file instead ?
>>> For example, by default a temp file is created in the system temp drive,
>>> developers can customize it by creating a temp File in the right location
>>> and with the more user-friendly name if needed ?
>>>
>>> Cheers. Sergey
>
>
--
Henry Clout
Software Engineer
Kulu Valley Ltd
91 Goswell Road
London EC1V 7EX
Direct: +44 (0) 207 017 8322
Mobile: +44 (0) 777 576 2963
Office: +44 (0) 207 253 8080
www.kuluvalley.com
—
The Information contained in this e-mail and any attached files are intended
for the named recipient(s) only. It may contain legal, privileged and/or
confidential information and if you are not an intended recipient, you should
not copy, distribute or take any action in reliance on it or disclose its
contents. If you have received this e-mail in error, please notify the sender
immediately and then delete it.
Internet e-mail is not a secure medium. Any reply to this message could be
intercepted and read by someone else. Please bear that in mind when deciding
whether to send material in response.
