Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of sberyozkin@gmail.com
 designates 209.85.212.179 as permitted sender)
Message-ID: <52D67DCE.2080506@gmail.com>
Date: Wed, 15 Jan 2014 12:23:42 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: Accessing temporary file name of attachments
References: 
 <CAMnZqcUb2MHivS7JNeHcN5Y2RWcSXYigr=fT9DwrAQPYu4=8Wg@mail.gmail.com>
 <CAOtGrG+aMcFuVNSrnJLF3wWJSyPzXxydC-2yzzWJ_tL_HeHzww@mail.gmail.com>
 <CAMnZqcUCpoY-8zw+ZAkvpJRM-G_a272dFwchdcQTJviLFYz-EQ@mail.gmail.com>
 <2B0C5377-A082-4B36-AED6-3A884A42F906@kuluvalley.com>
 <8318ED09-0787-4AFB-A6ED-E036D0CC8A72@apache.org>
 <C2FC14B8-E7C2-4058-A0CA-D29B5D15B536@kuluvalley.com>
 <52D2DC9A.20609@gmail.com>
 <A357C523-A5B1-4A2A-A195-0E00732BD5CB@kuluvalley.com>
In-Reply-To: <A357C523-A5B1-4A2A-A195-0E00732BD5CB@kuluvalley.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

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 <sberyozkin@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