This library will be redeveloped to make it a nicer api, while still keeping the original intent in mind, of keeping the library simple, and thus attractive as an alternative to the Apache Upload lib. I have created a 'multipartrequest' module in the CVS, and imported the original source code. a BRANCH_1_0 has been created to save the old code. A RELEASE_1_0_RC1 tag has been added to this code in case any bugfixes are made to the old branch.
The HEAD branch is where version 2.0 of the multipartrequest lib will be developed. There will not be a lot of development. What is planned is a change in package structure - net.iamvegan.http.multipartrequest for the multipartrequest classes, instead of the original http.utils.multipartrequest package.
No support for CGI, the MultipartRequest and ServletMultipartRequest classes will be merged into a new HttpServletMultipartRequest
All deprecated methods will be removed.
All methods that provide access to File objects instead of input streams will also be removed.
All access to the temporary filename will be obfuscated inside the class structure.
Consideration of utilising the Factory method to enable configuration of such as the max upload size, encoding, etc, as well as temporary upload directory.
So for example a new MultipartRequestServletFactory would be constructed in the init() method with the encoding / max upload directory, temporary directory, etc.
Then in the doPost / doGet method the HttpMultipartServletRequest would be constructed as follows:
However there is also consideration if possible (i have not even looked at this yet, so cannot remember if its possible), of extending the original HttpServletRequest, with the multipart specific methods only, otherwise all the other http request methods would be implemented invisibly.
I still have to explore this, and see if it can be done easily.
I do not want to do a lot of work, but I am conscious that the quality of the code and especially the API in the original 1.31RC1 is terrible and a good example of what an relatively inexperienced programmer can do. I don't promise to make it perfect, as in most cases I won't actually be doing anything more than copy and paste, but at least if anyone else decides to download and use it, they will be using the lib with a better API, and a less confusing API for that matter too.
I still have to remind myself of the contents of the servlet api, which I have not looked at closely for a while now, so my ideas may change by the time 2.0 is released. Once 2.0 is released, I envision this project settling down to its lack of activity again ;-)
Cheers
Jason
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since HttpServletRequest is an interface, the easiest way might be to extend javax.servlet.http.HttpServletRequestWrapper and override particular methods as required, such as:
And throw a runtime exception on these methods:
ServletInputStream getInputStream()
java.io.BufferedReader getReader()
That would probably do it.
That way when constructing the HttpMultipartServletRequest, could pass in a reference to the HttpServletRequest, which would call super(request) on the HttpServletRequestWrapper
Should theoretically all work very nicely. The rest of the config, such as temp directory, upload limits, etc would be configured from Factory.
Then we can provide the additional methods from the original API including:
java.util.Enumeration getFileParameterNames()
java.io.InputStream getFileContents(String strName)
long getFileSize(String strName)
String getFilename(String strName) (originally called getBaseFilename(String) )
The following methods from the original API would disappear:
File getFile(String)
getFileSystemName(String)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also the encoding functionality introduced into the original api would be discarded in favour of using the info from the HttpServletRequest getEncoding method.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is still only support for a single file per name though, and this won't be fixed, as in the end we are really only refactoring the interface to the library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
API version 2.00b4 is stable. Bug fixes will be applied to the internal structure as required, and the javadocs will be further updated. However I do not envision the api to change much beyond what it is now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Further changes resulted in a almost complete api for 2.00b6. An encoding parameter still needs to be provided in the all arguments constructor. If set to null will use default encoding from either the HttpServletRequest.getEncoding() method or the default constant set internally. This will be done for 2.00b7, at which time the api will be static, and tests will be undertaken to ensure its stable, and a final 2.00 will be made available. At this time, the project will return to its inactive state!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2.00b10 will introduce a ProgressListener concept thanks to JSPWiki dev Janne Jalkanen, and as I get time I will be adding a unit test suite to the project, before final 2.0 is released.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This library will be redeveloped to make it a nicer api, while still keeping the original intent in mind, of keeping the library simple, and thus attractive as an alternative to the Apache Upload lib. I have created a 'multipartrequest' module in the CVS, and imported the original source code. a BRANCH_1_0 has been created to save the old code. A RELEASE_1_0_RC1 tag has been added to this code in case any bugfixes are made to the old branch.
The HEAD branch is where version 2.0 of the multipartrequest lib will be developed. There will not be a lot of development. What is planned is a change in package structure - net.iamvegan.http.multipartrequest for the multipartrequest classes, instead of the original http.utils.multipartrequest package.
No support for CGI, the MultipartRequest and ServletMultipartRequest classes will be merged into a new HttpServletMultipartRequest
All deprecated methods will be removed.
All methods that provide access to File objects instead of input streams will also be removed.
All access to the temporary filename will be obfuscated inside the class structure.
Consideration of utilising the Factory method to enable configuration of such as the max upload size, encoding, etc, as well as temporary upload directory.
So for example a new MultipartRequestServletFactory would be constructed in the init() method with the encoding / max upload directory, temporary directory, etc.
Then in the doPost / doGet method the HttpMultipartServletRequest would be constructed as follows:
HttpMultipartServletRequest multipartRequest = multipartFactory.create(request);
However there is also consideration if possible (i have not even looked at this yet, so cannot remember if its possible), of extending the original HttpServletRequest, with the multipart specific methods only, otherwise all the other http request methods would be implemented invisibly.
I still have to explore this, and see if it can be done easily.
I do not want to do a lot of work, but I am conscious that the quality of the code and especially the API in the original 1.31RC1 is terrible and a good example of what an relatively inexperienced programmer can do. I don't promise to make it perfect, as in most cases I won't actually be doing anything more than copy and paste, but at least if anyone else decides to download and use it, they will be using the lib with a better API, and a less confusing API for that matter too.
I still have to remind myself of the contents of the servlet api, which I have not looked at closely for a while now, so my ideas may change by the time 2.0 is released. Once 2.0 is released, I envision this project settling down to its lack of activity again ;-)
Cheers
Jason
Since HttpServletRequest is an interface, the easiest way might be to extend javax.servlet.http.HttpServletRequestWrapper and override particular methods as required, such as:
java.lang.String getParameter(java.lang.String name)
java.util.Map getParameterMap()
java.util.Enumeration getParameterNames()
java.lang.String[] getParameterValues(java.lang.String name)
And throw a runtime exception on these methods:
ServletInputStream getInputStream()
java.io.BufferedReader getReader()
That would probably do it.
That way when constructing the HttpMultipartServletRequest, could pass in a reference to the HttpServletRequest, which would call super(request) on the HttpServletRequestWrapper
Should theoretically all work very nicely. The rest of the config, such as temp directory, upload limits, etc would be configured from Factory.
Then we can provide the additional methods from the original API including:
java.util.Enumeration getFileParameterNames()
java.io.InputStream getFileContents(String strName)
long getFileSize(String strName)
String getFilename(String strName) (originally called getBaseFilename(String) )
The following methods from the original API would disappear:
File getFile(String)
getFileSystemName(String)
Also the encoding functionality introduced into the original api would be discarded in favour of using the info from the HttpServletRequest getEncoding method.
Consider renaming java.io.InputStream getFileContents(String strName) to
java.io.InputStream getFileInputStream(String strName)
There is still only support for a single file per name though, and this won't be fixed, as in the end we are really only refactoring the interface to the library.
First cut of the API is done and released, check out the javadocs here:
http://multipartrequest.iamvegan.net/javadocs/
Cheers
Jason
API version 2.00b4 is stable. Bug fixes will be applied to the internal structure as required, and the javadocs will be further updated. However I do not envision the api to change much beyond what it is now.
Further changes resulted in a almost complete api for 2.00b6. An encoding parameter still needs to be provided in the all arguments constructor. If set to null will use default encoding from either the HttpServletRequest.getEncoding() method or the default constant set internally. This will be done for 2.00b7, at which time the api will be static, and tests will be undertaken to ensure its stable, and a final 2.00 will be made available. At this time, the project will return to its inactive state!
2.00b10 will introduce a ProgressListener concept thanks to JSPWiki dev Janne Jalkanen, and as I get time I will be adding a unit test suite to the project, before final 2.0 is released.