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
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.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
