You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Graham Ford <gr...@gmail.com> on 2014/01/06 11:35:31 UTC
Accessing temporary file name of attachments
Hi,
We are having an issue with attachments to a REST call we are making. We
have set up the attachment-directory property so that the file is written
to a set directory, but we then need to move it to somewhere else. We can
do this by accessing the InputStream from the attachment and then using an
OutputStream to write the file, but this is not very performant from us.
The temporary directory is located on a network drive, and we want to move
it to another directory on this drive, meaning a simple file move/rename
would be the ideal way to do this.
The problem is that the temporary file it written with a random name, and
so although we know which directory is resides in, we don't know which file
in that directory is the one from the current call. So, is there either a
way of getting the name of the temporary file that has been written, or is
there another way that we would be able to accomplish what we want to do?
Hope this is clear, and please feel free to ask if anything doesn't make
sense!
Thanks
Graham
Re: Accessing temporary file name of attachments
Posted by Graham Ford <gr...@kuluvalley.com>.
Hi Sergey,
I'm not sure that it would be possible to make it any more configurable, as
I think the name will always need to have some element of randomness to it,
to avoid clashes if the same file is uploaded concurrently, or multiple
times.
However, if it was possible to access the name of the temp file that has
been created, I think that, for now, that would be enough, at least for
what we are trying to do. I notice that when the file is written to disk,
the InputStream is actually a CachedOutputStream, and this does have the
path to the file, however, it is not possible to cast the
CachedOutputStream to an input stream and access the name. I guess there is
some inner class that wraps the OutputStream somewhere but if it was
possible to abstract that somehow, that would be good.
Another, but no doubt more complicated, solution might be to do something
similar to Spring. They have a class called MultipartFile, which has a
method called transferTo. This uses commons-fileupload to move the file
using different techniques depending on where the file is. If the file has
been written to disk it will try to call renameTo on a File, and if that
fails it will copy it using Input/OutputStream streams. If the file is in
memory it will again use Input/OutputStream to do the copy. If you look at
the source of DiskFileItem.write() then you will get a better idea of what
I mean. That was there is a common way of moving a file from an attachment,
where ever it resides.
Thanks for the help so far!
Graham
On 7 January 2014 11:57, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi
> It may make sense indeed to simplify an access to the underlying temp file
> or perhaps make the naming more configurable,
> I'm not sure yet how this can be done but hope we can come up with some
> solution
> Thanks, Sergey
>
>
> On Mon, Jan 6, 2014 at 12:35 PM, Graham Ford <gr...@gmail.com>
> wrote:
>
> > Hi,
> >
> > We are having an issue with attachments to a REST call we are making. We
> > have set up the attachment-directory property so that the file is written
> > to a set directory, but we then need to move it to somewhere else. We can
> > do this by accessing the InputStream from the attachment and then using
> an
> > OutputStream to write the file, but this is not very performant from us.
> > The temporary directory is located on a network drive, and we want to
> move
> > it to another directory on this drive, meaning a simple file move/rename
> > would be the ideal way to do this.
> >
> > The problem is that the temporary file it written with a random name, and
> > so although we know which directory is resides in, we don't know which
> file
> > in that directory is the one from the current call. So, is there either a
> > way of getting the name of the temporary file that has been written, or
> is
> > there another way that we would be able to accomplish what we want to do?
> >
> > Hope this is clear, and please feel free to ask if anything doesn't make
> > sense!
> >
> > Thanks
> > Graham
> >
>
>
>
> --
> Sergey Beryozkin
>
> http://sberyozkin.blogspot.com
> Talend - http://www.talend.com
>
--
Graham Ford
Software Developer
Kulu Valley Ltd.
91 Goswell Road
London EC1V 7EX
Direct: +44 207 017 8326
Tel: +44 207 253 8080
Fax: +44 207 017 8338
Web: www.kuluvalley.com
Privacy and Confidentiality
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.
Re: Accessing temporary file name of attachments
Posted by Henry Clout <he...@gmail.com>.
Hi Sergey.
I've created a patch to implement the transferTo(File) functionality Graham was describing.
https://issues.apache.org/jira/browse/CXF-5489
It's not the *most* beautiful thing I've ever written, but it's the best I could do whilst keeping to the interface contracts. I've tested it against 2.7.5 which is what we're using with our app, the patch is for the current trunk build.
Could you let me know if this is something that could be included in the codebase please?
Thanks,
Henry
>
> ---------- Forwarded message ----------
> From: Sergey Beryozkin <sb...@gmail.com>
> Date: 7 January 2014 11:57
> Subject: Re: Accessing temporary file name of attachments
> To: "users@cxf.apache.org" <us...@cxf.apache.org>
>
>
> Hi
> It may make sense indeed to simplify an access to the underlying temp file
> or perhaps make the naming more configurable,
> I'm not sure yet how this can be done but hope we can come up with some
> solution
> Thanks, Sergey
>
Re: Accessing temporary file name of attachments
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hmm...
I start thinking that may be I've misunderstood the issue and applying
your original patch (with possible modifications as indicated by Dan) is
the simplest/cheapest solution in the end,
Dan if you are OK then may be we can indeed work on the patch
Thanks, Sergey
On 15/01/14 16:39, Henry Clout wrote:
> 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 <sb...@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
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Accessing temporary file name of attachments
Posted by Henry Clout <he...@kuluvalley.com>.
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 <sb...@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
Re: Accessing temporary file name of attachments
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@gmail.com> 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 <sb...@gmail.com> 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
Re: Accessing temporary file name of attachments
Posted by Henry Clout <he...@kuluvalley.com>.
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 <sb...@gmail.com> 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 <sb...@gmail.com> 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.
Re: Accessing temporary file name of attachments
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@gmail.com> 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
Re: Accessing temporary file name of attachments
Posted by Henry Clout <he...@kuluvalley.com>.
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.
Yours,
Henry
On 12 Jan 2014, at 18:19, Sergey Beryozkin <sb...@gmail.com> 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
Re: Accessing temporary file name of attachments
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
On 10/01/14 16:55, Henry Clout wrote:
> Hi Dan.
>
> Thanks for the feedback.
>
> The utilities methods could be moved to IOUtils, FileUtils, whichever you like -- I can do that. I guess the bigger question is if you think the interface is worthwhile. For us it's very useful since we're uploading large files (>5G) and the cost of moving that data around is considerable. File moves, therefore, are a nice win. I would have thought this might be useful to others too.
>
> FWIW, this is the Spring interface I've copied: http://docs.spring.io/spring/docs/1.2.x/api/org/springframework/web/multipart/MultipartFile.html#transferTo(java.io.File)
>
> Anyway, let me know if you have any more thoughts on the viability of this functionality.
>
> Henry
>
>
> On 10 Jan 2014, at 15:58, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> On Jan 10, 2014, at 8:54 AM, Henry Clout <he...@kuluvalley.com> wrote:
>>
>>> Hi Sergey.
>>>
>>> I've created a patch to implement the transferTo(File) functionality Graham was describing.
>>>
>>> https://issues.apache.org/jira/browse/CXF-5489
>>
>> Just a quick look at the patch. Likely not something we’d apply. We have a few util classes already that handle some of this. IOUtils, FileUtils, etc… Not really sure we need the interface for this either. Need to think about that part a bit more.
>>
>> Dan
>>
>>
>>> It's not the *most* beautiful thing I've ever written, but it's the best I could do whilst keeping to the interface contracts. I've tested it against 2.7.5 which is what we're using with our app, the patch is for the current trunk build.
>>>
>>> Could you let me know if this is something that could be included in the codebase please?
>>>
>>> Thanks,
>>>
>>> Henry
>>>
>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Sergey Beryozkin <sb...@gmail.com>
>>>> Date: 7 January 2014 11:57
>>>> Subject: Re: Accessing temporary file name of attachments
>>>> To: "users@cxf.apache.org" <us...@cxf.apache.org>
>>>>
>>>>
>>>> Hi
>>>> It may make sense indeed to simplify an access to the underlying temp file
>>>> or perhaps make the naming more configurable,
>>>> I'm not sure yet how this can be done but hope we can come up with some
>>>> solution
>>>> Thanks, Sergey
>>>>
>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>
> --
>
> 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.
>
>
--
Re: Accessing temporary file name of attachments
Posted by Henry Clout <he...@kuluvalley.com>.
Hi Dan.
Thanks for the feedback.
The utilities methods could be moved to IOUtils, FileUtils, whichever you like -- I can do that. I guess the bigger question is if you think the interface is worthwhile. For us it's very useful since we're uploading large files (>5G) and the cost of moving that data around is considerable. File moves, therefore, are a nice win. I would have thought this might be useful to others too.
FWIW, this is the Spring interface I've copied: http://docs.spring.io/spring/docs/1.2.x/api/org/springframework/web/multipart/MultipartFile.html#transferTo(java.io.File)
Anyway, let me know if you have any more thoughts on the viability of this functionality.
Henry
On 10 Jan 2014, at 15:58, Daniel Kulp <dk...@apache.org> wrote:
>
> On Jan 10, 2014, at 8:54 AM, Henry Clout <he...@kuluvalley.com> wrote:
>
>> Hi Sergey.
>>
>> I've created a patch to implement the transferTo(File) functionality Graham was describing.
>>
>> https://issues.apache.org/jira/browse/CXF-5489
>
> Just a quick look at the patch. Likely not something we’d apply. We have a few util classes already that handle some of this. IOUtils, FileUtils, etc… Not really sure we need the interface for this either. Need to think about that part a bit more.
>
> Dan
>
>
>> It's not the *most* beautiful thing I've ever written, but it's the best I could do whilst keeping to the interface contracts. I've tested it against 2.7.5 which is what we're using with our app, the patch is for the current trunk build.
>>
>> Could you let me know if this is something that could be included in the codebase please?
>>
>> Thanks,
>>
>> Henry
>>
>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Sergey Beryozkin <sb...@gmail.com>
>>> Date: 7 January 2014 11:57
>>> Subject: Re: Accessing temporary file name of attachments
>>> To: "users@cxf.apache.org" <us...@cxf.apache.org>
>>>
>>>
>>> Hi
>>> It may make sense indeed to simplify an access to the underlying temp file
>>> or perhaps make the naming more configurable,
>>> I'm not sure yet how this can be done but hope we can come up with some
>>> solution
>>> Thanks, Sergey
>>>
>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
--
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.
Re: Accessing temporary file name of attachments
Posted by Daniel Kulp <dk...@apache.org>.
On Jan 10, 2014, at 8:54 AM, Henry Clout <he...@kuluvalley.com> wrote:
> Hi Sergey.
>
> I've created a patch to implement the transferTo(File) functionality Graham was describing.
>
> https://issues.apache.org/jira/browse/CXF-5489
Just a quick look at the patch. Likely not something we’d apply. We have a few util classes already that handle some of this. IOUtils, FileUtils, etc… Not really sure we need the interface for this either. Need to think about that part a bit more.
Dan
> It's not the *most* beautiful thing I've ever written, but it's the best I could do whilst keeping to the interface contracts. I've tested it against 2.7.5 which is what we're using with our app, the patch is for the current trunk build.
>
> Could you let me know if this is something that could be included in the codebase please?
>
> Thanks,
>
> Henry
>
>
>>
>> ---------- Forwarded message ----------
>> From: Sergey Beryozkin <sb...@gmail.com>
>> Date: 7 January 2014 11:57
>> Subject: Re: Accessing temporary file name of attachments
>> To: "users@cxf.apache.org" <us...@cxf.apache.org>
>>
>>
>> Hi
>> It may make sense indeed to simplify an access to the underlying temp file
>> or perhaps make the naming more configurable,
>> I'm not sure yet how this can be done but hope we can come up with some
>> solution
>> Thanks, Sergey
>>
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Accessing temporary file name of attachments
Posted by Henry Clout <he...@kuluvalley.com>.
Hi Sergey.
I've created a patch to implement the transferTo(File) functionality Graham was describing.
https://issues.apache.org/jira/browse/CXF-5489
It's not the *most* beautiful thing I've ever written, but it's the best I could do whilst keeping to the interface contracts. I've tested it against 2.7.5 which is what we're using with our app, the patch is for the current trunk build.
Could you let me know if this is something that could be included in the codebase please?
Thanks,
Henry
>
> ---------- Forwarded message ----------
> From: Sergey Beryozkin <sb...@gmail.com>
> Date: 7 January 2014 11:57
> Subject: Re: Accessing temporary file name of attachments
> To: "users@cxf.apache.org" <us...@cxf.apache.org>
>
>
> Hi
> It may make sense indeed to simplify an access to the underlying temp file
> or perhaps make the naming more configurable,
> I'm not sure yet how this can be done but hope we can come up with some
> solution
> Thanks, Sergey
>
Re: Accessing temporary file name of attachments
Posted by Henry Clout <he...@gmail.com>.
Hi Sergey.
I've created a patch to implement the transferTo(File) functionality Graham was describing.
https://issues.apache.org/jira/browse/CXF-5489
It's not the *most* beautiful thing I've ever written, but it's the best I could do whilst keeping to the interface contracts. I've tested it against 2.7.5 which is what we're using with our app, the patch is for the current trunk build.
Could you let me know if this is something that could be included in the codebase please?
Thanks,
Henry
>
> ---------- Forwarded message ----------
> From: Sergey Beryozkin <sb...@gmail.com>
> Date: 7 January 2014 11:57
> Subject: Re: Accessing temporary file name of attachments
> To: "users@cxf.apache.org" <us...@cxf.apache.org>
>
>
> Hi
> It may make sense indeed to simplify an access to the underlying temp file
> or perhaps make the naming more configurable,
> I'm not sure yet how this can be done but hope we can come up with some
> solution
> Thanks, Sergey
>
Re: Accessing temporary file name of attachments
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
It may make sense indeed to simplify an access to the underlying temp file
or perhaps make the naming more configurable,
I'm not sure yet how this can be done but hope we can come up with some
solution
Thanks, Sergey
On Mon, Jan 6, 2014 at 12:35 PM, Graham Ford <gr...@gmail.com> wrote:
> Hi,
>
> We are having an issue with attachments to a REST call we are making. We
> have set up the attachment-directory property so that the file is written
> to a set directory, but we then need to move it to somewhere else. We can
> do this by accessing the InputStream from the attachment and then using an
> OutputStream to write the file, but this is not very performant from us.
> The temporary directory is located on a network drive, and we want to move
> it to another directory on this drive, meaning a simple file move/rename
> would be the ideal way to do this.
>
> The problem is that the temporary file it written with a random name, and
> so although we know which directory is resides in, we don't know which file
> in that directory is the one from the current call. So, is there either a
> way of getting the name of the temporary file that has been written, or is
> there another way that we would be able to accomplish what we want to do?
>
> Hope this is clear, and please feel free to ask if anything doesn't make
> sense!
>
> Thanks
> Graham
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com