Re: Problem moving from file upload servlet to JSP
On 19/04/2010 17:06, Ken Bowen wrote:
Using Tomcat 6.0.18 (to be 6.0.26) and Google App Engine, for parallel
development (different db tech)
Short form: I need to accept a file upload in a servlet, do some
computations on the upload, and then transition to a JSP with some data
resulting from the computations. I'm having some trouble with the
transition at the end. I need either to make the current code work or
find an
alternate way to achieve the goal.
Long form. Here's the html for file upload (vanilla):
form name=csvUploadForm action=csvfileupload method=post
enctype=multipart/form-data
File:input type=file name=csvfile2uploadbr/br
input type=submit name=Submit value=Upload CSV File
onclick=uploadCSVFile();return false;
/form
Here's the servlet mapping for the receiving/processing servlet:
servlet-mapping
servlet-nameCSVFileUpload/servlet-name
url-pattern/csvfileupload/*/url-pattern
/servlet-mapping
Why use a wildcard instead of an absolute/explicit path, in both the
action attribute and in the url-pattern?
The CSVFileUpload servlet doPost method uses
org.apache.commons.fileupload.servlet.ServletFileUpload;
to accept and process the upload, and puts the resulting data into the
db. If I don't care about duplicates or partial matches,
this works fine; at the end of the servlet processing, I execute
response.sendRedirect(/myStartPage.jsp);
-- where response is the doPost's HttpServletResponse.
Now I need to deal with partial matches between incoming data from the
upload, and information already in the db. Specifically,
I need to interact with the user to determine how to resolve the
ambiguities. I /thought/ I could create a bean with the necessary computed
info, use setAttribute to attach the bean to request (the doPost's
HttpServletRequest), and then forward to a JSP with code like this:
String nextJSP = /nextPage.jsp;
RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(nextJSP);
dispatcher.forward(request, response);
/myStartPage.jsp or /nextPage.jsp?
When does the redirect occur and when does the forward occur, it's not
entirely clear.
Unfortunately, I'm running into the following errors showing in the log:
WARNING: Nested in javax.servlet.ServletException:
org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException: the
request doesn't contain a multipart/form-data or multipart/mixed stream,
content type header is null:
org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException: the
request doesn't contain a multipart/form-data or multipart/mixed stream,
content type header is null
at
org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.init(FileUploadBase.java:885)
at
org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
at
org.apache.commons.fileupload.servlet.ServletFileUpload.getItemIterator(ServletFileUpload.java:148)
at
com.formrunner.servlets.CSVFileUploadServlet.doPost(CSVFileUploadServlet.java:53)
at
com.formrunner.servlets.CSVFileUploadServlet.doGet(CSVFileUploadServlet.java:29)
What's at CSVFileUploadServlet.java:53?
The browser actually displays the nextPage.jsp page. However, if one
then clicks any navigation button, you get a version of the warning
above showing in the browser.
So you're catching the exception before executing the forward?
I'm assuming that the CSVFileUpload servlet processing of the upload has
stripped the request; hence the errors.
I'm not sure I concur, it seems a little unclear as to what is really
happening at this point.
p
My goal is to get from the CSVFileUpload servlet to the nextPage.jsp
with the partialMatch data in hand. In the normal use case, this
will only be a couple of text lines. However, at the extreme it could
be hundreds of lines of mismatches. I really don't care how I
accomplish the transition to nextPage.jsp, so if there's a better way
than what I'm attempting here, please let me know.
{Anything written on the web would be great.} [I assume that I could
store the partialMatch data in the db under some appropriate key, get
to nextPage using response.sendRedirect, and then retrieve the info, but
that seems like more of a hack than ought to be necessary here.]
Thanks in advance,
Ken
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
signature.asc
Description: OpenPGP digital signature
Re: Problem moving from file upload servlet to JSP
Ken Bowen wrote: ... Long form. Here's the html for file upload (vanilla): form name=csvUploadForm action=csvfileupload method=post enctype=multipart/form-data File:input type=file name=csvfile2uploadbr/br input type=submit name=Submit value=Upload CSV File onclick=uploadCSVFile();return false; /form Without and before getting to the Java stuff, I do not really understand why above you have a button of type submit, but with an onClick event triggering a javascript function. Either the button should be of type button and have an onClick event handler, or it should be of type submit and not have an event handler. I suspect that by specifying both, you may be generating 2 actions and confusing the browser and/or the receiving end. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem moving from file upload servlet to JSP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ken,
On 4/19/2010 12:06 PM, Ken Bowen wrote:
form name=csvUploadForm action=csvfileupload method=post
enctype=multipart/form-data File:input type=file
name=csvfile2uploadbr/br input type=submit name=Submit
value=Upload CSV File onclick=uploadCSVFile();return false;
/form
Looks good, except for that uploadCSVFile javascript trigger. Why not
just do a regular file upload? Is this some kinda AJAX thing?
The CSVFileUpload servlet doPost method uses
org.apache.commons.fileupload.servlet.ServletFileUpload; to accept
and process the upload, and puts the resulting data into the db. If
I don't care about duplicates or partial matches, this works fine; at
the end of the servlet processing, I execute
response.sendRedirect(/myStartPage.jsp); -- where response is the
doPost's HttpServletResponse.
That seems fine (ignoring the mismatch between myStartPage.jsp and
nextPage.jsp).
String nextJSP = /nextPage.jsp; RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(nextJSP);
dispatcher.forward(request, response);
That's the correct way to do a forward.
Unfortunately, I'm running into the following errors showing in the
log:
WARNING: Nested in javax.servlet.ServletException:
org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException:
the request doesn't contain a multipart/form-data or multipart/mixed
stream, content type header is null:
org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException:
the request doesn't contain a multipart/form-data or multipart/mixed
stream, content type header is null at
org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.init(FileUploadBase.java:885)
at
org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
at
org.apache.commons.fileupload.servlet.ServletFileUpload.getItemIterator(ServletFileUpload.java:148)
at
com.formrunner.servlets.CSVFileUploadServlet.doPost(CSVFileUploadServlet.java:53)
at
com.formrunner.servlets.CSVFileUploadServlet.doGet(CSVFileUploadServlet.java:29)
From
the information you've given, it looks like the
CSVFileUploadServlet is being invoked on a request that doesn't have the
proper formatting. You might want to change your CSVFileUploadServlet to
check the Content-Type of the request before invoking the
commons-file-upload stuff so you can give a better error message to your
users.
This could be happening due to a couple of reasons:
1. Your URL mapping is too wide-reaching and the CVS upload servlet is
handling the request to /nextPage.jsp, which would be weird.
2. Your are seeing an error for a request other than the one you think
you are.
I recommend checking for the Content-Type and then dumping a bunch of
information about the request if it's not multipart/form-data: things
like the URL, method and maybe the parameters, too.
The browser actually displays the nextPage.jsp page. However, if
one then clicks any navigation button, you get a version of the
warning above showing in the browser.
Do you have a link like a href= that could be going to the wrong
place? Presumably, navigation links shouldn't take you to the
CSVFileUploadServlet... only form POSTs.
My goal is to get from the CSVFileUpload servlet to the nextPage.jsp
with the partialMatch data in hand.
...whatever that is.
In the normal use case, this will only be a couple of text lines.
However, at the extreme it could be hundreds of lines of mismatches.
I really don't care how I accomplish the transition to nextPage.jsp,
so if there's a better way than what I'm attempting here, please let
me know. {Anything written on the web would be great.} [I assume
that I could store the partialMatch data in the db under some
appropriate key, get to nextPage using response.sendRedirect, and
then retrieve the info, but that seems like more of a hack than ought
to be necessary here.]
Keeping state in the request is always risky, because after it's over,
the user has to re-submit everything in order to basically see the same
result. It's idempotent, but not particularly elegant.
Keeping state in the session is always risky because the session can
expire /and/ you can also bust your heap if it's a lot of data. If
session timeouts are a concern, you have to encode a bunch of
information in the request to recover the session in those cases.
Putting the data into the database is not particularly convenient, but
it will save you from worries about memory exhaustion as well as having
to repeatedly shuttle lots of data from the client to the server and
back. Think: do you want your users to have to re-upload files after the
mismatches have been identified and resolved? Or, do you just want to
apply whatever mitigation steps have been chosen by the user on the data
already on the server?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -
Re: Problem moving from file upload servlet to JSP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 4/19/2010 5:19 PM, André Warnier wrote: Ken Bowen wrote: ... Long form. Here's the html for file upload (vanilla): form name=csvUploadForm action=csvfileupload method=post enctype=multipart/form-data File:input type=file name=csvfile2uploadbr/br input type=submit name=Submit value=Upload CSV File onclick=uploadCSVFile();return false; /form Without and before getting to the Java stuff, I do not really understand why above you have a button of type submit, but with an onClick event triggering a javascript function. Either the button should be of type button and have an onClick event handler, or it should be of type submit and not have an event handler. An exception is the case where you want a page that works both with and without Javascript enabled: the input type=submit allows the form to submit in the standard way when no Javascript is present, but allows the (presumably mind-blowingly fantastic) Javascript alternative to run when appropriate. You can't get this behavior from type=button. I suspect that by specifying both, you may be generating 2 actions and confusing the browser and/or the receiving end. The return false; at the end of the trigger indicates that the event handler will (duh) return false. When that happens, the browser is supposed to basically drop the event and not send it to the default handler, which would result in the form being submitted in the traditional way. This is actually a pretty standard Javascript implementation. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvMyiUACgkQ9CaO5/Lv0PBb9wCeJZcEXufKdj7RG6MhAz8eIG0p o3gAoMCjAaMOmzhjs2q8mzlZiwSs7Yx/ =1Z8E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Problem moving from file upload servlet to JSP
You sure about that? I've got mine that way (button of type submit, but with an onClick event triggering a javascript function.) and it works fine. André Warnier wrote: ... Long form. Here's the html for file upload (vanilla): form name=csvUploadForm action=csvfileupload method=post enctype=multipart/form-data File:input type=file name=csvfile2uploadbr/br input type=submit name=Submit value=Upload CSV File onclick=uploadCSVFile();return false; /form Without and before getting to the Java stuff, I do not really understand why above you have a button of type submit, but with an onClick event triggering a javascript function. Either the button should be of type button and have an onClick event handler, or it should be of type submit and not have an event handler. I suspect that by specifying both, you may be generating 2 actions and confusing the browser and/or the receiving end. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem moving from file upload servlet to JSP
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 4/19/2010 5:19 PM, André Warnier wrote: Ken Bowen wrote: ... Long form. Here's the html for file upload (vanilla): form name=csvUploadForm action=csvfileupload method=post enctype=multipart/form-data File:input type=file name=csvfile2uploadbr/br input type=submit name=Submit value=Upload CSV File onclick=uploadCSVFile();return false; /form Without and before getting to the Java stuff, I do not really understand why above you have a button of type submit, but with an onClick event triggering a javascript function. Either the button should be of type button and have an onClick event handler, or it should be of type submit and not have an event handler. An exception is the case where you want a page that works both with and without Javascript enabled: the input type=submit allows the form to submit in the standard way when no Javascript is present, but allows the (presumably mind-blowingly fantastic) Javascript alternative to run when appropriate. You can't get this behavior from type=button. I suspect that by specifying both, you may be generating 2 actions and confusing the browser and/or the receiving end. The return false; at the end of the trigger indicates that the event handler will (duh) return false. When that happens, the browser is supposed to basically drop the event and not send it to the default handler, which would result in the form being submitted in the traditional way. This is actually a pretty standard Javascript implementation. Ok, I'll accept that explanation. Which still leaves us in the dark concerning the content of that javascript uploadCSVFile() function which is probably the one used in this case then to post the form content to the server. I must admit I still don't see the need of it in this case, since the form as it is without the onClick would submit the file just as well. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Problem moving from file upload servlet to JSP
My guess is that he may have other various pieces of validation tied to it, client side. And he might even have some client-side validation intertwined for the type of file in an array, - i.e. .xls, .doc., .txt etc. as an acceptable file type to upload, though, like you, I have no idea not having seen all of his form and code accompanying it. -Original Message- From: André Warnier wrote: The return false; at the end of the trigger indicates that the event handler will (duh) return false. When that happens, the browser is supposed to basically drop the event and not send it to the default handler, which would result in the form being submitted in the traditional way. This is actually a pretty standard Javascript implementation. Ok, I'll accept that explanation. Which still leaves us in the dark concerning the content of that javascript uploadCSVFile() function which is probably the one used in this case then to post the form content to the server. I must admit I still don't see the need of it in this case, since the form as it is without the onClick would submit the file just as well. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem moving from file upload servlet to JSP
Just aritfacts of step by step changes (as I come to understand various thingies): should be type button, but gives no evidence of two events. On Apr 19, 2010, at 5:19 PM, André Warnier wrote: Ken Bowen wrote: ... Long form. Here's the html for file upload (vanilla): form name=csvUploadForm action=csvfileupload method=post enctype=multipart/form-data File:input type=file name=csvfile2uploadbr/br input type=submit name=Submit value=Upload CSV File onclick=uploadCSVFile();return false; /form Without and before getting to the Java stuff, I do not really understand why above you have a button of type submit, but with an onClick event triggering a javascript function. Either the button should be of type button and have an onClick event handler, or it should be of type submit and not have an event handler. I suspect that by specifying both, you may be generating 2 actions and confusing the browser and/or the receiving end. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem moving from file upload servlet to JSP
On 19/04/2010 22:21, Christopher Schultz wrote:
Ken,
On 4/19/2010 12:06 PM, Ken Bowen wrote:
form name=csvUploadForm action=csvfileupload method=post
enctype=multipart/form-data File:input type=file
name=csvfile2uploadbr/br input type=submit name=Submit
value=Upload CSV File onclick=uploadCSVFile();return false;
/form
Looks good, except for that uploadCSVFile javascript trigger. Why not
just do a regular file upload? Is this some kinda AJAX thing?
The CSVFileUpload servlet doPost method uses
org.apache.commons.fileupload.servlet.ServletFileUpload; to accept
and process the upload, and puts the resulting data into the db. If
I don't care about duplicates or partial matches, this works fine; at
the end of the servlet processing, I execute
response.sendRedirect(/myStartPage.jsp); -- where response is the
doPost's HttpServletResponse.
That seems fine (ignoring the mismatch between myStartPage.jsp and
nextPage.jsp).
... and that one is a redirect one is a forward?
p (confused)
String nextJSP = /nextPage.jsp; RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(nextJSP);
dispatcher.forward(request, response);
That's the correct way to do a forward.
Unfortunately, I'm running into the following errors showing in the
log:
WARNING: Nested in javax.servlet.ServletException:
org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException:
the request doesn't contain a multipart/form-data or multipart/mixed
stream, content type header is null:
org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException:
the request doesn't contain a multipart/form-data or multipart/mixed
stream, content type header is null at
org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.init(FileUploadBase.java:885)
at
org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
at
org.apache.commons.fileupload.servlet.ServletFileUpload.getItemIterator(ServletFileUpload.java:148)
at
com.formrunner.servlets.CSVFileUploadServlet.doPost(CSVFileUploadServlet.java:53)
at
com.formrunner.servlets.CSVFileUploadServlet.doGet(CSVFileUploadServlet.java:29)
From
the information you've given, it looks like the
CSVFileUploadServlet is being invoked on a request that doesn't have the
proper formatting. You might want to change your CSVFileUploadServlet to
check the Content-Type of the request before invoking the
commons-file-upload stuff so you can give a better error message to your
users.
This could be happening due to a couple of reasons:
1. Your URL mapping is too wide-reaching and the CVS upload servlet is
handling the request to /nextPage.jsp, which would be weird.
2. Your are seeing an error for a request other than the one you think
you are.
I recommend checking for the Content-Type and then dumping a bunch of
information about the request if it's not multipart/form-data: things
like the URL, method and maybe the parameters, too.
The browser actually displays the nextPage.jsp page. However, if
one then clicks any navigation button, you get a version of the
warning above showing in the browser.
Do you have a link like a href= that could be going to the wrong
place? Presumably, navigation links shouldn't take you to the
CSVFileUploadServlet... only form POSTs.
My goal is to get from the CSVFileUpload servlet to the nextPage.jsp
with the partialMatch data in hand.
...whatever that is.
In the normal use case, this will only be a couple of text lines.
However, at the extreme it could be hundreds of lines of mismatches.
I really don't care how I accomplish the transition to nextPage.jsp,
so if there's a better way than what I'm attempting here, please let
me know. {Anything written on the web would be great.} [I assume
that I could store the partialMatch data in the db under some
appropriate key, get to nextPage using response.sendRedirect, and
then retrieve the info, but that seems like more of a hack than ought
to be necessary here.]
Keeping state in the request is always risky, because after it's over,
the user has to re-submit everything in order to basically see the same
result. It's idempotent, but not particularly elegant.
Keeping state in the session is always risky because the session can
expire /and/ you can also bust your heap if it's a lot of data. If
session timeouts are a concern, you have to encode a bunch of
information in the request to recover the session in those cases.
Putting the data into the database is not particularly convenient, but
it will save you from worries about memory exhaustion as well as having
to repeatedly shuttle lots of data from the client to the server and
back. Think: do you want your users to have to re-upload files after the
mismatches have been identified and resolved? Or, do you just want to
apply whatever mitigation steps have been chosen by the user on the data
already on
Re: Problem moving from file upload servlet to JSP
The confusion results from the fact that I initially used the redirect
in the simple case.
Then I tried to switch to the forward in the more complicated case,
and got in a mess.
But now I've simply stored everything in the db right away, and used a
redirect
to get to the jsp where I do all the work.
On Apr 19, 2010, at 7:29 PM, Pid wrote:
On 19/04/2010 22:21, Christopher Schultz wrote:
Ken,
On 4/19/2010 12:06 PM, Ken Bowen wrote:
form name=csvUploadForm action=csvfileupload method=post
enctype=multipart/form-data File:input type=file
name=csvfile2uploadbr/br input type=submit name=Submit
value=Upload CSV File onclick=uploadCSVFile();return false;
/form
Looks good, except for that uploadCSVFile javascript trigger. Why
not
just do a regular file upload? Is this some kinda AJAX thing?
The CSVFileUpload servlet doPost method uses
org.apache.commons.fileupload.servlet.ServletFileUpload; to accept
and process the upload, and puts the resulting data into the db. If
I don't care about duplicates or partial matches, this works fine;
at
the end of the servlet processing, I execute
response.sendRedirect(/myStartPage.jsp); -- where response is the
doPost's HttpServletResponse.
That seems fine (ignoring the mismatch between myStartPage.jsp and
nextPage.jsp).
... and that one is a redirect one is a forward?
p (confused)
String nextJSP = /nextPage.jsp; RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(nextJSP);
dispatcher.forward(request, response);
That's the correct way to do a forward.
Unfortunately, I'm running into the following errors showing in the
log:
WARNING: Nested in javax.servlet.ServletException:
org.apache.commons.fileupload.FileUploadBase
$InvalidContentTypeException:
the request doesn't contain a multipart/form-data or multipart/mixed
stream, content type header is null:
org.apache.commons.fileupload.FileUploadBase
$InvalidContentTypeException:
the request doesn't contain a multipart/form-data or multipart/mixed
stream, content type header is null at
org.apache.commons.fileupload.FileUploadBase
$FileItemIteratorImpl.init(FileUploadBase.java:885)
at
org
.apache
.commons
.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
at
org
.apache
.commons
.fileupload
.servlet.ServletFileUpload.getItemIterator(ServletFileUpload.java:
148)
at
com
.formrunner
.servlets.CSVFileUploadServlet.doPost(CSVFileUploadServlet.java:53)
at
com
.formrunner
.servlets.CSVFileUploadServlet.doGet(CSVFileUploadServlet.java:29)
From
the information you've given, it looks like the
CSVFileUploadServlet is being invoked on a request that doesn't
have the
proper formatting. You might want to change your
CSVFileUploadServlet to
check the Content-Type of the request before invoking the
commons-file-upload stuff so you can give a better error message to
your
users.
This could be happening due to a couple of reasons:
1. Your URL mapping is too wide-reaching and the CVS upload servlet
is
handling the request to /nextPage.jsp, which would be weird.
2. Your are seeing an error for a request other than the one you
think
you are.
I recommend checking for the Content-Type and then dumping a bunch of
information about the request if it's not multipart/form-data: things
like the URL, method and maybe the parameters, too.
The browser actually displays the nextPage.jsp page. However, if
one then clicks any navigation button, you get a version of the
warning above showing in the browser.
Do you have a link like a href= that could be going to the wrong
place? Presumably, navigation links shouldn't take you to the
CSVFileUploadServlet... only form POSTs.
My goal is to get from the CSVFileUpload servlet to the nextPage.jsp
with the partialMatch data in hand.
...whatever that is.
In the normal use case, this will only be a couple of text lines.
However, at the extreme it could be hundreds of lines of mismatches.
I really don't care how I accomplish the transition to nextPage.jsp,
so if there's a better way than what I'm attempting here, please let
me know. {Anything written on the web would be great.} [I assume
that I could store the partialMatch data in the db under some
appropriate key, get to nextPage using response.sendRedirect, and
then retrieve the info, but that seems like more of a hack than
ought
to be necessary here.]
Keeping state in the request is always risky, because after it's
over,
the user has to re-submit everything in order to basically see the
same
result. It's idempotent, but not particularly elegant.
Keeping state in the session is always risky because the session can
expire /and/ you can also bust your heap if it's a lot of data. If
session timeouts are a concern, you have to encode a bunch of
information in the request to recover the session in those cases.
Putting the data into the database is not particularly convenient,
but
it will save you from worries about memory exhaustion as
