Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
From: Henry Clout <henry.clout@kuluvalley.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_3F1003DB-DCEA-485E-830F-9A42BE469DBA"
Message-Id: <6FA5AF6F-37BE-4C25-B68A-DA4298439274@kuluvalley.com>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: Accessing temporary file name of attachments
Date: Wed, 15 Jan 2014 16:39:29 +0000
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>
 <52D67DCE.2080506@gmail.com>
 <6BC22B88-6B3E-48EF-BCD6-6E163CECDF2E@kuluvalley.com>
 <52D697DE.9090309@gmail.com>
To: users@cxf.apache.org
In-Reply-To: <52D697DE.9090309@gmail.com>

--Apple-Mail=_3F1003DB-DCEA-485E-830F-9A42BE469DBA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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;
=09
	@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.
>>=20
>> For us at least this wouldn't really address our problem.  Our flow =
is:
>>=20
>> - 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> As it happens, we've worked around this by using Spring multipart =
parsing within CXF:
>>=20
>> 	@POST
>> 	@Path("/kulus/{guid}/media")
>> 	public void addMediaToKulu(@PathParam("guid") String guid) =
throws IOException {
>> 		MultipartFile multipartFile =3D null;
>> 		if =
(commonsMultipartResolver.isMultipart(httpServletRequest)) {
>> 			MultipartHttpServletRequest =
multipartHttpServletRequest =3D =
commonsMultipartResolver.resolveMultipart(httpServletRequest);
>> 			Iterator<String> fileNamesIterator =3D =
multipartHttpServletRequest.getFileNames();
>> 			if (fileNamesIterator.hasNext()) {
>> 				String firstFileName =3D =
fileNamesIterator.next();
>> 				multipartFile =3D =
multipartHttpServletRequest.getFile(firstFileName);
>> 			}
>> 		}
>> 		// We call multipartFile.transferTo(file) later on ...
>> 	}
>>=20
>> 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 :-)
>>=20
> What I'm not getting is this:
>=20
> 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.
>=20
> So now you have an InputStream, possible completely in the memory and =
may be backed up by a temp file in the right location.
>=20
> Can you please explain again why that won't be sufficient in your case =
?
>=20
> Thanks, Sergey


--Apple-Mail=_3F1003DB-DCEA-485E-830F-9A42BE469DBA--