[jira] Commented: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails
[ https://issues.apache.org/jira/browse/FILEUPLOAD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514923 ] Jochen Wiedmann commented on FILEUPLOAD-141: The fact that you want the files to be deleted is, IMO, by no means an indicator that others do wish the same. Remove FileItems if FileUploadBase.parseRequest() fails --- Key: FILEUPLOAD-141 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-141 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Environment: commons-fileupload is used for parsing multipart/form-data POST requests in servlets. OS: Linux Reporter: Marcus Klein If the method FileUploadBase.parseRequest() throws a FileUploadException, the already parsed FileItem objects are not accessible and removed by the garbage collector. Now expect a fileupload that fills the servers hard disc with FileItems until no space is left on the device. The method parseRequest() throws a FileUploadException and there are several FileItem objects that still exist in the device because the garbage collector does not run and removes them. This causes failing fileuploads until the garbage collector runs and removes the lost FileItem objects. I suggest calling FileItem.delete() on all FileItem objects created in the method FileUploadBase.parseRequest() if the method is left with a FileUploadException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails
[ https://issues.apache.org/jira/browse/FILEUPLOAD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-141. Resolution: Won't Fix You are free to overwrite the FileItemFactory to return an instance of DiskFileItem, which overrides the method getTempFile() in that sense. Apart from that, changing the current code in your sense would most possibly be the cause of a lot of compatibility problems without gaining too much. I am unaware of any actual FileUpload installation that considers hanging files a real issue. This might be the case in your particular application, but then I believe it's fine that you tune the code to meet your special requirements. Remove FileItems if FileUploadBase.parseRequest() fails --- Key: FILEUPLOAD-141 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-141 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Environment: commons-fileupload is used for parsing multipart/form-data POST requests in servlets. OS: Linux Reporter: Marcus Klein If the method FileUploadBase.parseRequest() throws a FileUploadException, the already parsed FileItem objects are not accessible and removed by the garbage collector. Now expect a fileupload that fills the servers hard disc with FileItems until no space is left on the device. The method parseRequest() throws a FileUploadException and there are several FileItem objects that still exist in the device because the garbage collector does not run and removes them. This causes failing fileuploads until the garbage collector runs and removes the lost FileItem objects. I suggest calling FileItem.delete() on all FileItem objects created in the method FileUploadBase.parseRequest() if the method is left with a FileUploadException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Progressing towards a 1.8.0 release
On 7/19/07, Stephen Colebourne [EMAIL PROTECTED] wrote: But surely, the problem is that maven will pull in collections.jar when it pulls in beanutils.jar, which is unnecessary. Its big, unnecessary dependencies like this that give commons a bad name. Do you know, that you can exclude transitive dependencies when you specify a direct dependency? -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-136) FileUpload race condition with used with Jetty 6
[
https://issues.apache.org/jira/browse/FILEUPLOAD-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513329
]
Jochen Wiedmann commented on FILEUPLOAD-136:
I do not think, that it's the task of the InputStream user to track whether an
InputStream is still usable. In other words, if your diagnosis is right, then I
wouldn't consider this a FileUpload bug.
FileUpload race condition with used with Jetty 6
Key: FILEUPLOAD-136
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-136
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2
Environment: Running on Windows XP SP2 with Jetty 6 embedded and
Firefox 2.0.0.4
Reporter: Keith Kowalczykowski
Priority: Critical
Attachments: FileUploadTest.zip, TestJetty.java
When running commons file upload with Jetty 6, ServletFileUpload.parseRequest
spins and never returns when the user clicks the stop button in their
browser while an upload is in progress.
Reproduction Steps:
* Create a simple servlet / html form which accepts a file upload using
commons file upload (or use the example code below).
* Upload a sufficiently large file that you have time to click the stop
button before the upload completes.
* Observe that the thread is now stuck within file upload.
Other Information:
Using jstack, I was able to get the following trace of where it is blocking.
It looks like it is on a read() call that file upload is making.
at org/mortbay/jetty/HttpParser$Input.blockForContent(HttpParser.java:922)
at org/mortbay/jetty/HttpParser$Input.read(HttpParser.java:897)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:959)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.close(MultipartStream.java:910)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:119)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:64)
at
org/apache/commons/fileupload/FileUploadBase.parseRequest(FileUploadBase.java:354)
at
org/apache/commons/fileupload/servlet/ServletFileUpload.parseRequest(ServletFileUpload.java:126)
at test/Main$1.handle(Main.java:43)
at
org/mortbay/jetty/handler/HandlerWrapper.handle(HandlerWrapper.java:139)
at org/mortbay/jetty/Server.handle(Server.java:285)
at org/mortbay/jetty/HttpConnection.handleRequest(HttpConnection.java:502)
at
org/mortbay/jetty/HttpConnection$RequestHandler.content(HttpConnection.java:835)
at org/mortbay/jetty/HttpParser.parseNext(HttpParser.java:641)
at org/mortbay/jetty/HttpParser.parseAvailable(HttpParser.java:208)
at org/mortbay/jetty/HttpConnection.handle(HttpConnection.java:378)
at
org/mortbay/jetty/bio/SocketConnector$Connection.run(SocketConnector.java:226)
at
org/mortbay/thread/BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
at jrockit/vm/RNI.c2java()V(Native Method)
-- end of trac
Originally I thought this was an issue with our code, however, I have since
isolated it to a simple test case. Bellow is a class file called Main which
when run will instantiate an instance of Jetty on port 8080 and an HTML
document that will post a file upload to the servlet. When the stop button is
pressed, you will see that the line Starting processing is printed, but
neither the Exception occured in processing or Processing completed are
printed. I have a full eclipse project (jars and all) on my machine that I
was planning on uploading with this ticket, however, I don't see a way to
attach a file. Therefore, I have copied and pasted the two files bellow. Let
me know if you want the full project.
=== Main.java ===
/**
*
*/
package test;
import java.io.IOException;
import java.util.List;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
import org.mortbay.jetty.Handler;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.handler.AbstractHandler;
/**
* @author Keith Kowalczykowski
*
*/
public class Main {
public static void main(String[] args) {
Handler handler = new AbstractHandler() {
public void handle(String arg0, HttpServletRequest arg1,
HttpServletResponse arg2, int arg3)
throws IOException,
ServletException
{
System.out.println(Starting processing);
try
[jira] Commented: (FILEUPLOAD-136) FileUpload race condition with used with Jetty 6
[
https://issues.apache.org/jira/browse/FILEUPLOAD-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513345
]
Jochen Wiedmann commented on FILEUPLOAD-136:
I assume, you are referring to the ItemInputStream, are you?
The ItemInputStream is returned to the user, if he or she iterates over the
multipart streams parts. The user *may* close this InputStream, but there's no
requirement that he *must* close it. Even more, the user is not required to
consume the InputStream's contents. For example, the user might read the first
line, detects that he is not interested in this item and calls
FileItemIterator.next().
At that point, we are in the middle of a part's body. In order to skip this
body, we need to find the next boundary, which is exactly what
ItemInputStream.close() does for us.
FileUpload race condition with used with Jetty 6
Key: FILEUPLOAD-136
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-136
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2
Environment: Running on Windows XP SP2 with Jetty 6 embedded and
Firefox 2.0.0.4
Reporter: Keith Kowalczykowski
Priority: Critical
Attachments: FileUploadTest.zip, TestJetty.java
When running commons file upload with Jetty 6, ServletFileUpload.parseRequest
spins and never returns when the user clicks the stop button in their
browser while an upload is in progress.
Reproduction Steps:
* Create a simple servlet / html form which accepts a file upload using
commons file upload (or use the example code below).
* Upload a sufficiently large file that you have time to click the stop
button before the upload completes.
* Observe that the thread is now stuck within file upload.
Other Information:
Using jstack, I was able to get the following trace of where it is blocking.
It looks like it is on a read() call that file upload is making.
at org/mortbay/jetty/HttpParser$Input.blockForContent(HttpParser.java:922)
at org/mortbay/jetty/HttpParser$Input.read(HttpParser.java:897)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:959)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.close(MultipartStream.java:910)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:119)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:64)
at
org/apache/commons/fileupload/FileUploadBase.parseRequest(FileUploadBase.java:354)
at
org/apache/commons/fileupload/servlet/ServletFileUpload.parseRequest(ServletFileUpload.java:126)
at test/Main$1.handle(Main.java:43)
at
org/mortbay/jetty/handler/HandlerWrapper.handle(HandlerWrapper.java:139)
at org/mortbay/jetty/Server.handle(Server.java:285)
at org/mortbay/jetty/HttpConnection.handleRequest(HttpConnection.java:502)
at
org/mortbay/jetty/HttpConnection$RequestHandler.content(HttpConnection.java:835)
at org/mortbay/jetty/HttpParser.parseNext(HttpParser.java:641)
at org/mortbay/jetty/HttpParser.parseAvailable(HttpParser.java:208)
at org/mortbay/jetty/HttpConnection.handle(HttpConnection.java:378)
at
org/mortbay/jetty/bio/SocketConnector$Connection.run(SocketConnector.java:226)
at
org/mortbay/thread/BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
at jrockit/vm/RNI.c2java()V(Native Method)
-- end of trac
Originally I thought this was an issue with our code, however, I have since
isolated it to a simple test case. Bellow is a class file called Main which
when run will instantiate an instance of Jetty on port 8080 and an HTML
document that will post a file upload to the servlet. When the stop button is
pressed, you will see that the line Starting processing is printed, but
neither the Exception occured in processing or Processing completed are
printed. I have a full eclipse project (jars and all) on my machine that I
was planning on uploading with this ticket, however, I don't see a way to
attach a file. Therefore, I have copied and pasted the two files bellow. Let
me know if you want the full project.
=== Main.java ===
/**
*
*/
package test;
import java.io.IOException;
import java.util.List;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
import org.mortbay.jetty.Handler;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.handler.AbstractHandler;
/**
* @author Keith Kowalczykowski
*
*/
public class Main {
public static void main
[jira] Resolved: (FILEUPLOAD-136) FileUpload race condition with used with Jetty 6
[
https://issues.apache.org/jira/browse/FILEUPLOAD-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved FILEUPLOAD-136.
Resolution: Won't Fix
Assignee: Jochen Wiedmann
I can follow your arguments, but I do not intend to change the code for that
reason.
FileUpload race condition with used with Jetty 6
Key: FILEUPLOAD-136
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-136
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2
Environment: Running on Windows XP SP2 with Jetty 6 embedded and
Firefox 2.0.0.4
Reporter: Keith Kowalczykowski
Assignee: Jochen Wiedmann
Priority: Critical
Attachments: FileUploadTest.zip, TestJetty.java
When running commons file upload with Jetty 6, ServletFileUpload.parseRequest
spins and never returns when the user clicks the stop button in their
browser while an upload is in progress.
Reproduction Steps:
* Create a simple servlet / html form which accepts a file upload using
commons file upload (or use the example code below).
* Upload a sufficiently large file that you have time to click the stop
button before the upload completes.
* Observe that the thread is now stuck within file upload.
Other Information:
Using jstack, I was able to get the following trace of where it is blocking.
It looks like it is on a read() call that file upload is making.
at org/mortbay/jetty/HttpParser$Input.blockForContent(HttpParser.java:922)
at org/mortbay/jetty/HttpParser$Input.read(HttpParser.java:897)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:959)
at
org/apache/commons/fileupload/MultipartStream$ItemInputStream.close(MultipartStream.java:910)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:119)
at org/apache/commons/fileupload/util/Streams.copy(Streams.java:64)
at
org/apache/commons/fileupload/FileUploadBase.parseRequest(FileUploadBase.java:354)
at
org/apache/commons/fileupload/servlet/ServletFileUpload.parseRequest(ServletFileUpload.java:126)
at test/Main$1.handle(Main.java:43)
at
org/mortbay/jetty/handler/HandlerWrapper.handle(HandlerWrapper.java:139)
at org/mortbay/jetty/Server.handle(Server.java:285)
at org/mortbay/jetty/HttpConnection.handleRequest(HttpConnection.java:502)
at
org/mortbay/jetty/HttpConnection$RequestHandler.content(HttpConnection.java:835)
at org/mortbay/jetty/HttpParser.parseNext(HttpParser.java:641)
at org/mortbay/jetty/HttpParser.parseAvailable(HttpParser.java:208)
at org/mortbay/jetty/HttpConnection.handle(HttpConnection.java:378)
at
org/mortbay/jetty/bio/SocketConnector$Connection.run(SocketConnector.java:226)
at
org/mortbay/thread/BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
at jrockit/vm/RNI.c2java()V(Native Method)
-- end of trac
Originally I thought this was an issue with our code, however, I have since
isolated it to a simple test case. Bellow is a class file called Main which
when run will instantiate an instance of Jetty on port 8080 and an HTML
document that will post a file upload to the servlet. When the stop button is
pressed, you will see that the line Starting processing is printed, but
neither the Exception occured in processing or Processing completed are
printed. I have a full eclipse project (jars and all) on my machine that I
was planning on uploading with this ticket, however, I don't see a way to
attach a file. Therefore, I have copied and pasted the two files bellow. Let
me know if you want the full project.
=== Main.java ===
/**
*
*/
package test;
import java.io.IOException;
import java.util.List;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
import org.mortbay.jetty.Handler;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.handler.AbstractHandler;
/**
* @author Keith Kowalczykowski
*
*/
public class Main {
public static void main(String[] args) {
Handler handler = new AbstractHandler() {
public void handle(String arg0, HttpServletRequest arg1,
HttpServletResponse arg2, int arg3)
throws IOException,
ServletException
{
System.out.println(Starting processing);
try
Re: [proposal] No VOTE needed to elect ASF committers to commons WAS: Re: request karma to commons validator/i18n
I second Rahul's opinion. I wouldn't want to build high barreers, but I'd prefer to have them. Apart from that, I have never found it a problem to join the Commons. In particular, considering my own invitation which came basically with the first patch. Apart from that, the more important part, as far as I am concerned, is the policy of whether and when I may commit to subprojects. I am sure, that most of us would consider it a rude behaviour if I'd simply start committing to a subproject without a silent or explicit confirmation or even invitation by the subprojects members. If that policy applies to subprojects, then I can't see, why anyone should be considered a member of commons without being a member of at least one subproject. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] No VOTE needed to elect ASF committers to commons WAS: Re: request karma to commons validator/i18n
On 7/8/07, Phil Steitz [EMAIL PROTECTED] wrote: One thing that we shoud remain clear on is that there are *no* subprojects in commons. Call it components, if you like. That doesn't change the fact, that each of them has its own, small, community, which we cannot ignore. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Zip binary download broken for 1.3.2
On 7/4/07, Bob Arnott [EMAIL PROTECTED] wrote: Mainly due to the file being called commons-io-1.3.2-bin.zip where as the link thinks it's called commons-io-1.3.2.zip Thanks, I fixed it in SVN and on /www/jakarta.apache.org. Will take some hours before the changes are synced to the WWW server, though. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Fileupload 1.3 or 2.0?
On 7/4/07, Oleg Kalnichevski [EMAIL PROTECTED] wrote: You may want to take a look at Apache JAMES Mime4j [1] Thanks for the hint, I'm gonna have a look on it. The streaming approach sounds good. -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-140) Means to preserve text parameters when upload limit exceeded
[ https://issues.apache.org/jira/browse/FILEUPLOAD-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-140. Resolution: Won't Fix Fix Version/s: (was: 1.2.1) Assignee: Jochen Wiedmann You are free to use the streaming API, in which case you obviously receive the items, which are read so far. Continuing to read after a limit is exceeded, seems counterproductive, because typically users will see such an exception as early as possible. This also means, that your desire will fail completely, if the exception is raised due to a content-length header. Apart from that, I do believe that this sounds like an invitation for DOS attacks. Means to preserve text parameters when upload limit exceeded Key: FILEUPLOAD-140 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-140 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Paul Benedict Assignee: Jochen Wiedmann I am trying to resolve https://issues.apache.org/struts/browse/STR-2585 but am lacking the means to do it. The current use is with the deprecated DiskFileUpload and I prefer to have this class fixed first. When SizeLimitExceededException is thrown, it does not return the items it has collected thus far. I see two possible solutions which involve adding a property on the exception to return them: (1) Return the parameters thus gathered or (2) finish out the input stream but throw away all file items and return only the text parameters. Otherwise, whenever a the upload exceeds its limit, all other input parameters disappear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-140) Means to preserve text parameters when upload limit exceeded
[ https://issues.apache.org/jira/browse/FILEUPLOAD-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-140. Resolution: Won't Fix Fix Version/s: (was: 1.2.1) Assignee: Jochen Wiedmann You are free to use the streaming API, in which case you obviously receive the items, which are read so far. Continuing to read after a limit is exceeded, seems counterproductive, because typically users will see such an exception as early as possible. This also means, that your desire will fail completely, if the exception is raised due to a content-length header. Apart from that, I do believe that this sounds like an invitation for DOS attacks. Means to preserve text parameters when upload limit exceeded Key: FILEUPLOAD-140 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-140 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Paul Benedict Assignee: Jochen Wiedmann I am trying to resolve https://issues.apache.org/struts/browse/STR-2585 but am lacking the means to do it. The current use is with the deprecated DiskFileUpload and I prefer to have this class fixed first. When SizeLimitExceededException is thrown, it does not return the items it has collected thus far. I see two possible solutions which involve adding a property on the exception to return them: (1) Return the parameters thus gathered or (2) finish out the input stream but throw away all file items and return only the text parameters. Otherwise, whenever a the upload exceeds its limit, all other input parameters disappear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-124) fix website permissions
[
https://issues.apache.org/jira/browse/IO-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509769
]
Jochen Wiedmann commented on IO-124:
Anybody got an explanation? I have just repeated what I already did yesterday:
[EMAIL PROTECTED] /www/jakarta.apache.org/commons/io]$ find . -type d -exec
chmod 775 {} \;
[EMAIL PROTECTED] /www/jakarta.apache.org/commons/io]$ find . -type f -exec
chmod 664 {} \;
[EMAIL PROTECTED] /www/jakarta.apache.org/commons/io]$ chgrp -R jakarta .
No effect. Apart from that, the problem also seems to impact the site, because
http://jakarta.apache.org/commons/io/
and
http://people.apache.org/~jochen/commons-io/site/
look drastically different.
fix website permissions
---
Key: IO-124
URL: https://issues.apache.org/jira/browse/IO-124
Project: Commons IO
Issue Type: Bug
Reporter: Godmar Back
http://jakarta.apache.org/commons/io/api-release/index.html
says:
Forbidden
You don't have permission to access /commons/io/api-release/index.html on
this server.
Apache/2.3.0-dev (Unix) Server at jakarta.apache.org Port 80
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-124) fix website permissions
[ https://issues.apache.org/jira/browse/IO-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann closed IO-124. -- Resolution: Fixed Seems there has been a syncing issue. Both URL's are now shown as expected. fix website permissions --- Key: IO-124 URL: https://issues.apache.org/jira/browse/IO-124 Project: Commons IO Issue Type: Bug Reporter: Godmar Back http://jakarta.apache.org/commons/io/api-release/index.html says: Forbidden You don't have permission to access /commons/io/api-release/index.html on this server. Apache/2.3.0-dev (Unix) Server at jakarta.apache.org Port 80 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 4th attempt: Release commons-io 1.3.2
On 7/3/07, Gary Gregory [EMAIL PROTECTED] wrote: It seems odd that the site (http://jakarta.apache.org/commons/io/) is live but not [announce]'d and the links point to 1.3.1 downloads but are labeled 1.3.2. To the best of my knowledge, it is common to wait 24 hours before announcing, so that the mirrors can catch up. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RFC: Fileupload 1.3 or 2.0?
Hi, when applying the fixes for IO-99 to commons-fileupload, I was originally under the impression, that this would be easily possible without any or at least with fully upward compliant API changes. Until I detected that for reasons, which absolutely escape me, someone made FileItem to implement the Serializable interface. I can only guess, that someone had the idea to put a FileItem into the HttpSession. But resource tracking within a persistent HttpSession, seems to me to be clearly outside the scope of commons-fileupload. At least, this doesn't fit into the default implementation, which assumes temporary files, for good reasons. At first, I have attempted to fix the problem by making the FileCleaner serializable, but Rahul has rightly pointed out, that I am doing nonsense. See http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html for details. I have reverted the changes in commons-io and rethought my approach. The longer I thought about it, the more I came to the conclusion, that the only clean solution is to accept API changes. In particular, let FileItem no longer implement the Serializable interface. While we are at it, we could as well dissolve the the FileItemFactory and the multipart parser. Remove the whole bunch of deprecated methods. In other words, I propose to resolve FILEUPLOAD-120.or FILEUPLOAD-125 finally by dropping binary compatibilty and declaring the next version as commons-fileupload 2.0, not 1.3. I know that others (in particular Martin) had bigger plans for 2.0: Reimplement the thing based on httpcomponents, or commons-codec, or whatever, and stuff like that. Unfortunately I see noone who'd be ready to do that. In particular, not me. Thoughts? Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] RFC: Fileupload 1.3 or 2.0?
On 7/3/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I've read the JIRA's and I don't understand why FileItem/Serializable is relevant. As such I'm struggling to understand this thread :-) It's a design problem. When the DiskFileItem is instantiated, the File isn't necessarily created yet. In other words, the DiskFileItem needs an internal reference to the FileCleaningTracker, which is unfortunately not Serializable. We could continue with ideas like making the FileCleaningTracker transient, but that would violate the contract that the library takes care of removing the temporary files. If there is a minor incompatible change, like making FileItem no longer implement Serializable, then IMO that can be a v2.0 with the same package name. (Minor means that it has no effect on the vast majority of users. In addition, deprecated methods and classes can be removed. If there are larger changes that involve design changes, especially changes to user code (backwards imcompatible) then that should be a v2.0 with a different package name. If you choose the latter option, I would personally prefer to see [fileupload] move to Java 1.5 at the same time. I think, what I intend would be closer to the first scenario. However, I am open for a package name change. I am also open for a move to Java 1.5 sources, because my experiences with retrotranslator are good. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Fileupload 1.3 or 2.0?
On 7/4/07, Martin Cooper [EMAIL PROTECTED] wrote: * We were already starting to clone classes from what was originally HttpClient and is now HttpComponents. One example is the ParameterParser class. When I saw HttpComponents being born, saw a lot of other stuff in there that FileUpload was doing, it looked like it would make a lot of sense to build FileUpload on top of HttpComponents, thus dramatically cutting down the amount of code necessary to build a FileUpload package. I agree with you on that it might make sense to reuse components from outside, if possible. Unfortunately HttpComponents (in the person of Oleg Kalnichevski) has repeatedly declared that he has no interest in adding a multipart parser to httpcomponents, which would be (IMO) the most important part. Instead he suggested to add such a parser to Commons Codec. I personally believe, that this extends the scope of Commons Codec. But yes, if possible, I'd still be interested to reuse another multipart parser. Do you know of any ASL licensed? Also, it would still be good to have a much more clear distinction between what is supposed to be public and what is not. (For example, recall the MultipartStream threads from not so long ago.) Agreed. I was surprised to hear that the multipart parser *is* being reused. Oh, and I'm definitely in favour of going for a 2.0 release and cleaning up some crud along the way. I just don't think I'll be in a position to help any time soon, I'm afraid. As expected, but sad to hear anyways. :-) Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] 4th attempt: Release commons-io 1.3.2
Thanks god, this vote has passed: +1: Stephen, Dion, Oliver, Phil, Rahul, Myself I am ignoring sebb's posting for this release. I'll pick up his comments for the new web site. Hope that suits anyone. Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r552581 - /jakarta/commons/proper/io/tags/commons-io-1.3.2/
Author: jochen Date: Mon Jul 2 13:21:44 2007 New Revision: 552581 URL: http://svn.apache.org/viewvc?view=revrev=552581 Log: (empty) Added: jakarta/commons/proper/io/tags/commons-io-1.3.2/ - copied from r552580, jakarta/commons/proper/io/branches/b1_3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r552583 - in /jakarta/commons/proper/io/branches/b1_3: RELEASE-NOTES.txt src/changes/changes.xml xdocs/upgradeto1_3_2.xml
Author: jochen Date: Mon Jul 2 13:27:13 2007 New Revision: 552583 URL: http://svn.apache.org/viewvc?view=revrev=552583 Log: Web site fixes. Modified: jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml jakarta/commons/proper/io/branches/b1_3/xdocs/upgradeto1_3_2.xml Modified: jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt?view=diffrev=552583r1=552582r2=552583 == --- jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt Mon Jul 2 13:27:13 2007 @@ -40,7 +40,9 @@ - Created the FileCleaningTracker, basically a non-static version of the FileCleaner, which can be controlled by the user. [IO-116] -- The FileCleaner is deprecated. +- The FileCleaner is deprecated. (For reasons of compatibility, the + deprecation warnings are hidden within the 1.3 branch. They'll be + visible, as of version 1.4.) Bug fixes from 1.3.1 Modified: jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml?view=diffrev=552583r1=552582r2=552583 == --- jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml Mon Jul 2 13:27:13 2007 @@ -39,7 +39,7 @@ /properties body -release version=1.3.2 date=2007-May-16 +release version=1.3.2 date=2007-Jul-02 action dev=jochen type=fix issue=IO-115 Some tests, which are implicitly assuming a Unix-like file system, are now skipped on Windows. Modified: jakarta/commons/proper/io/branches/b1_3/xdocs/upgradeto1_3_2.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/xdocs/upgradeto1_3_2.xml?view=diffrev=552583r1=552582r2=552583 == --- jakarta/commons/proper/io/branches/b1_3/xdocs/upgradeto1_3_2.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/xdocs/upgradeto1_3_2.xml Mon Jul 2 13:27:13 2007 @@ -61,7 +61,9 @@ - Created the FileCleaningTracker, basically a non-static version of the FileCleaner, which can be controlled by the user. [IO-116] -- The FileCleaner is deprecated. +- The FileCleaner is deprecated. (For reasons of compatibility, the + deprecation warnings are hidden within the 1.3 branch. They'll be + visible, as of version 1.4.) Bug fixes from 1.3.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r552590 - in /jakarta/commons/proper/io/trunk: pom.xml src/changes/changes.xml src/conf/MANIFEST.MF src/java/org/apache/commons/io/FileCleaningTracker.java xdocs/building.xml xdocs/index.x
Author: jochen
Date: Mon Jul 2 13:47:10 2007
New Revision: 552590
URL: http://svn.apache.org/viewvc?view=revrev=552590
Log:
Merged in changes from 1.3 branch.
Added:
jakarta/commons/proper/io/trunk/xdocs/upgradeto1_3_2.xml
Modified:
jakarta/commons/proper/io/trunk/pom.xml
jakarta/commons/proper/io/trunk/src/changes/changes.xml
jakarta/commons/proper/io/trunk/src/conf/MANIFEST.MF
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaningTracker.java
jakarta/commons/proper/io/trunk/xdocs/building.xml
jakarta/commons/proper/io/trunk/xdocs/index.xml
jakarta/commons/proper/io/trunk/xdocs/navigation.xml
Modified: jakarta/commons/proper/io/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/pom.xml?view=diffrev=552590r1=552589r2=552590
==
--- jakarta/commons/proper/io/trunk/pom.xml (original)
+++ jakarta/commons/proper/io/trunk/pom.xml Mon Jul 2 13:47:10 2007
@@ -22,7 +22,7 @@
parent
groupIdorg.apache.commons/groupId
artifactIdcommons-parent/artifactId
-version2/version
+version3/version
/parent
modelVersion4.0.0/modelVersion
groupIdcommons-io/groupId
@@ -253,4 +253,101 @@
/plugin
/plugins
/reporting
+
+ profiles
+profile
+ idrelease/id
+ build
+plugins
+ plugin
+artifactIdmaven-site-plugin/artifactId
+executions
+ execution
+goals
+ goalsite/goal
+/goals
+phasepackage/phase
+ /execution
+/executions
+ /plugin
+ plugin
+artifactIdmaven-antrun-plugin/artifactId
+executions
+ execution
+goals
+ goalrun/goal
+/goals
+phasepackage/phase
+configuration
+ tasks
+copy todir=${project.build.directory}/site/api-release
+ fileset dir=${project.build.directory}/site/apidocs/
+/copy
+zip
destfile=${project.build.directory}/${artifactId}-${version}-javadoc.jar.new
+ zipfileset
src=${project.build.directory}/${artifactId}-${version}-javadoc.jar/
+ zipfileset dir=. prefix=META-INF
+include name=LICENSE.txt/
+include name=NOTICE.txt/
+ /zipfileset
+/zip
+move
file=${project.build.directory}/${artifactId}-${version}-javadoc.jar.new
+
tofile=${project.build.directory}/${artifactId}-${version}-javadoc.jar/
+zip
destfile=${project.build.directory}/${artifactId}-${version}-sources.jar.new
+ zipfileset
src=${project.build.directory}/${artifactId}-${version}-sources.jar/
+ zipfileset dir=. prefix=META-INF
+include name=LICENSE.txt/
+include name=NOTICE.txt/
+ /zipfileset
+/zip
+move
file=${project.build.directory}/${artifactId}-${version}-sources.jar.new
+
tofile=${project.build.directory}/${artifactId}-${version}-sources.jar/
+ /tasks
+/configuration
+ /execution
+/executions
+ /plugin
+ plugin
+artifactIdmaven-assembly-plugin/artifactId
+executions
+ execution
+goals
+ goalattached/goal
+/goals
+phasepackage/phase
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+profile
+ idrc/id
+ build
+plugins
+ plugin
+artifactIdmaven-site-plugin/artifactId
+executions
+ execution
+goals
+ goalsite/goal
+/goals
+phasepackage/phase
+ /execution
+/executions
+ /plugin
+ plugin
+artifactIdmaven-assembly-plugin/artifactId
+executions
+ execution
+goals
+ goalattached/goal
+/goals
+phasepackage/phase
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+ /profiles
/project
Modified: jakarta/commons/proper/io/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/changes/changes.xml?view=diffrev=552590r1=552589r2=552590
==
--- jakarta/commons/proper/io/trunk/src/changes/changes.xml (original
[jira] Commented: (FILEUPLOAD-59) [fileupload] Memory Issue
[ https://issues.apache.org/jira/browse/FILEUPLOAD-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508738 ] Jochen Wiedmann commented on FILEUPLOAD-59: --- Apart from possible changes, a streaming API was added in 1.2. If you are sensitive for memory considerations, this is the way to go anyways. [fileupload] Memory Issue - Key: FILEUPLOAD-59 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-59 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.0 Final Environment: Operating System: All Platform: All Reporter: Vimil Saju The reason for out of memory exception is that a FileItem object is created for each request parameter whether it is file or an ordinary string parameter. the FileItem object has a field of type DeferredFileStream which is initialized to 262144 bytes (256 Kb) so if there are around 1000 request parameters, around 256 MB of space will be required to hold the request parameters even though most parameters may require only 8 to 10 bytes of memory for storage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-59) [fileupload] Memory Issue
[ https://issues.apache.org/jira/browse/FILEUPLOAD-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508745 ] Jochen Wiedmann commented on FILEUPLOAD-59: --- I see absolutely no reason, why we should still support 1.1. This applies, in particular, to memory considerations and stuff like that. The streaming API was invented exactly for that purpose. [fileupload] Memory Issue - Key: FILEUPLOAD-59 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-59 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.0 Final Environment: Operating System: All Platform: All Reporter: Vimil Saju The reason for out of memory exception is that a FileItem object is created for each request parameter whether it is file or an ordinary string parameter. the FileItem object has a field of type DeferredFileStream which is initialized to 262144 bytes (256 Kb) so if there are around 1000 request parameters, around 256 MB of space will be required to hold the request parameters even though most parameters may require only 8 to 10 bytes of memory for storage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-138) Fail to upload small files
[ https://issues.apache.org/jira/browse/FILEUPLOAD-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-138. Resolution: Duplicate Fix Version/s: 1.2.1 Assignee: Jochen Wiedmann The question for the required version of commons-io is answered by the POM file, which is distributed together with the jar file. Fail to upload small files -- Key: FILEUPLOAD-138 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-138 Project: Commons FileUpload Issue Type: Bug Environment: Tomcat 5.5 on Suse Linux 10.0 Reporter: Martin Gröger Assignee: Jochen Wiedmann Priority: Critical Fix For: 1.2.1 Upload for very small files failed. The size (of failing) is lass than 58/59 bytes. It depends on the exact size of the keepRegion variable of the MultipartStream. Files less than this size contain no data at the target. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-138) Fail to upload small files
[ https://issues.apache.org/jira/browse/FILEUPLOAD-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508542 ] Jochen Wiedmann commented on FILEUPLOAD-138: This is most likely a duplicate of FILEUPLOAD-135. Please check, whether you still have problems with the current snapshot, as available from http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/fileupload/commons-fileupload/1.3-SNAPSHOT/ Fail to upload small files -- Key: FILEUPLOAD-138 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-138 Project: Commons FileUpload Issue Type: Bug Environment: Tomcat 5.5 on Suse Linux 10.0 Reporter: Martin Gröger Priority: Critical Upload for very small files failed. The size (of failing) is lass than 58/59 bytes. It depends on the exact size of the keepRegion variable of the MultipartStream. Files less than this size contain no data at the target. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r551000 - in /jakarta/commons/proper/fileupload/trunk: ./ src/changes/ src/java/org/apache/commons/fileupload/ src/test/org/apache/commons/fileupload/
Author: jochen
Date: Tue Jun 26 17:59:16 2007
New Revision: 551000
URL: http://svn.apache.org/viewvc?view=revrev=551000
Log:
Short files could cause an unexpected end of the item stream.
PR: FILEUPLOAD-135
Submitted-By: Alexander Sova [EMAIL PROTECTED]
Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/StreamingTest.java
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diffrev=551000r1=550999r2=551000
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Tue Jun 26 17:59:16 2007
@@ -105,6 +105,10 @@
email[EMAIL PROTECTED]/email
/contributor
contributor
+ nameAlexander Sova/name
+ email[EMAIL PROTECTED]/email
+/contributor
+contributor
nameThomas Vandahl/name
email[EMAIL PROTECTED]/email
/contributor
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diffrev=551000r1=550999r2=551000
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Tue Jun 26
17:59:16 2007
@@ -64,56 +64,50 @@
due-to=Thomas Vandahl due-to-email=[EMAIL PROTECTED]
DiskFileItem.toString() could throw an NPE.
/action
+ action dev=jochen type=fix issue=FILEUPLOAD-135
+ due-to=Alexander Sova due-to-email=[EMAIL PROTECTED]
+Short files could cause an unexpected end of the item stream.
+ /action
/release
release version=1.2 date=2007-02-13
-
action dev=jochen type=fix due-to=Aaron Freeman
due-to-email=[EMAIL PROTECTED]
Made Streams.asString static.
/action
-
action dev=jochen type=update issue=FILEUPLOAD-109
Eliminated duplicate code.
/action
-
action dev=jochen type=add issue=FILEUPLOAD-112
Added a streaming API.
/action
-
action dev=jochen type=fix issue=FILEUPLOAD-93
Eliminated the necessity of a content-length header.
/action
-
action dev=jochen type=fix issue=FILEUPLOAD-108
due-to=Amichai Rothman due-to-email=[EMAIL PROTECTED]
Eliminated the limitation of a maximum size for a single
header line. (The total size of all headers is already
limited, so there's no need for another limit.)
/action
-
action dev=jochen type=add issue=FILEUPLOAD-87
Added the ProgressListener, which allows to implement a
progress bar.
/action
-
action dev=jochen type=add issue=FILEUPLOAD-111
due-to=Amichai Rothman due-to-email=[EMAIL PROTECTED]
Added support for header continuation lines.
/action
-
action dev=jochen type=add issue=FILEUPLOAD-88
due-to=Andrey Aristarkhov due-to-email=[EMAIL PROTECTED]
It is now possible to limit the actual file size and not
the request size.
/action
-
action dev=jochen type=add issue=FILEUPLOAD-120
due-to=Henry Yandell due-to-email=[EMAIL PROTECTED]
Added the FileCleanerCleanup as an example for how to close
down the FileCleaner's reaper thread nicely.
/action
-
action dev=jochen type=fix issue=FILEUPLOAD-123
A descriptive NPE is now thrown, if the FileItemFactory
has not been set.
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java?view=diffrev=551000r1=550999r2=551000
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
Tue Jun 26 17:59:16 2007
@@ -92,4 +92,8 @@
cause.printStackTrace(writer);
}
}
+
+public Throwable getCause() {
+return cause
[jira] Resolved: (FILEUPLOAD-135) InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS
[ https://issues.apache.org/jira/browse/FILEUPLOAD-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-135. Resolution: Fixed Fix Version/s: 1.2.1 Assignee: Jochen Wiedmann Applied, thank you! InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS --- Key: FILEUPLOAD-135 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-135 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2, 1.2.1 Environment: Windows XP Browser: Firefox 1.5.0.11 Protocol: HTTPS Reporter: Alexander Sova Assignee: Jochen Wiedmann Fix For: 1.2.1 Attachments: commons-fileupload-1.1-bug-short-file-eof.patch, commons-fileupload-1.2-bug-short-file-eof.patch, FILEUPLOAD135.patch This problem happens only with files shorer then boundary string generated by browser and only with Firefox using HTTPS protocol. For some reason in this particular environment inputStream.read() in MultipartStream.ItemInputStream.makeAvailable() reads not whole HTTP response body, but only file content before boundary string. I've created a patch fixing this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-137) MultipartStream public API broken
[ https://issues.apache.org/jira/browse/FILEUPLOAD-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-137. Resolution: Fixed Fix Version/s: 1.2.1 Assignee: Jochen Wiedmann MultipartStream public API broken - Key: FILEUPLOAD-137 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-137 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2 Reporter: Mark Sinke Assignee: Jochen Wiedmann Fix For: 1.2.1 In commons-transaction 1.2 the MultipartStream class has 2 public constructors. Both are deprecated; however their implementation delegates to non-visible (package-private) constructors. There are two issues here: 1. the deprecated, delegating constructors use a null pointer for the progress notifier, which in turn yield a NullPointerException when you try to use them 2. the non-deprecated constructors are not visible. Hence, I cannot really upgrade from 1.0 to 1.2. Thanks, Mark. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-110) MultipartStream's keep region padding is either unnecessary or untested (and undocumented)
[ https://issues.apache.org/jira/browse/FILEUPLOAD-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-110. Resolution: Fixed Assignee: Jochen Wiedmann The extra bytes are no longer used. MultipartStream's keep region padding is either unnecessary or untested (and undocumented) -- Key: FILEUPLOAD-110 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-110 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.1 Final Reporter: Amichai Rothman Assignee: Jochen Wiedmann Priority: Minor Attachments: commons-fileupload-1.1-bug-removed-keep-region.patch MultipartStream has logic and constants related to a keep region which, according to the docs, is The amount of data, in bytes, that must be kept in the buffer in order to detect delimiters reliably. However, why that region is needed, why the padding is set to 3, and what makes it more reliable, is undocumented. Furthermore, when setting KEEP_REGION_PAD to zero (which effectively bypasses the extra keep region padding mechanism - it simply uses the boundary delimiter size, which makes sense), all tests pass successfully. so... either the extra padding is required but whatever it is required for is untested and undocumented, which should be corrected, or it is indeed unneeded, in which case all the keep region related code and constants can be deleted, and the code where the actual delimiters are searched for can be modified to simply use the boundary length instead of keepRegion. Note: I suspect the keep region pad may be a patch to compensate for the skipPreamble() patch which modifies the global boundary, calls a method which uses it, and the restores the global variable. If this is the case, this can all be reorganized in a clear and straightforward manner (with no awkward patches) by using an internal utility method that simply reads data into a given outputstream until a given delimiter is reached. this can then be used by readHeaders, readBodyData, discardBodyData, and skipPreamble, all of which require this same basic underlying functionality. I'd be happy to provide this code change, if this seems like a correct analysis to you... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r551002 - /jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java
Author: jochen
Date: Tue Jun 26 18:33:05 2007
New Revision: 551002
URL: http://svn.apache.org/viewvc?view=revrev=551002
Log:
Removed the @deprecation tags.
Modified:
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java
Modified:
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java?view=diffrev=551002r1=551001r2=551002
==
---
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java
(original)
+++
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java
Tue Jun 26 18:33:05 2007
@@ -35,7 +35,6 @@
* @author Noel Bergman
* @author Martin Cooper
* @version $Id$
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker}
*/
public class FileCleaner {
/**
@@ -52,7 +51,6 @@
* @param file the file to be tracked, not null
* @param marker the marker object used to track the file, not null
* @throws NullPointerException if the file is null
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#track(File,
Object)}.
*/
public static void track(File file, Object marker) {
theInstance.track(file, marker);
@@ -67,7 +65,6 @@
* @param marker the marker object used to track the file, not null
* @param deleteStrategy the strategy to delete the file, null means
normal
* @throws NullPointerException if the file is null
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#track(File,
Object, FileDeleteStrategy)}.
*/
public static void track(File file, Object marker, FileDeleteStrategy
deleteStrategy) {
theInstance.track(file, marker, deleteStrategy);
@@ -81,7 +78,6 @@
* @param path the full path to the file to be tracked, not null
* @param marker the marker object used to track the file, not null
* @throws NullPointerException if the path is null
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#track(String,
Object)}.
*/
public static void track(String path, Object marker) {
theInstance.track(path, marker);
@@ -96,7 +92,6 @@
* @param marker the marker object used to track the file, not null
* @param deleteStrategy the strategy to delete the file, null means
normal
* @throws NullPointerException if the path is null
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#track(String,
Object, FileDeleteStrategy)}.
*/
public static void track(String path, Object marker, FileDeleteStrategy
deleteStrategy) {
theInstance.track(path, marker, deleteStrategy);
@@ -108,7 +103,6 @@
* awaiting deletion.
*
* @return the number of files being tracked
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#getTrackCount()}.
*/
public static int getTrackCount() {
return theInstance.getTrackCount();
@@ -134,7 +128,6 @@
* This method allows the thread to be terminated. Simply call this method
* in the resource cleanup code, such as [EMAIL PROTECTED]
javax.servlet.ServletContextListener#contextDestroyed}.
* One called, no new objects can be tracked by the file cleaner.
- * @deprecated Use [EMAIL PROTECTED]
FileCleaningTracker#exitWhenFinished()}.
*/
public static synchronized void exitWhenFinished() {
theInstance.exitWhenFinished();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r551003 - /jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml
Author: jochen
Date: Tue Jun 26 18:35:56 2007
New Revision: 551003
URL: http://svn.apache.org/viewvc?view=revrev=551003
Log:
Using the -src suffix now for the source distribution.
Modified:
jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml
Modified: jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml?view=diffrev=551003r1=551002r2=551003
==
--- jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml (original)
+++ jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml Tue Jun
26 18:35:56 2007
@@ -20,9 +20,7 @@
formattar.gz/format
formatzip/format
/formats
-!--
baseDirectory${project.build.finalName}-src/baseDirectory
- --
fileSets
fileSet
includes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r551004 - /jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml
Author: jochen
Date: Tue Jun 26 18:50:28 2007
New Revision: 551004
URL: http://svn.apache.org/viewvc?view=revrev=551004
Log:
Using the -src suffix now for the source distribution.
Modified:
jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml
Modified: jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml?view=diffrev=551004r1=551003r2=551004
==
--- jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml (original)
+++ jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml Tue Jun
26 18:50:28 2007
@@ -20,7 +20,7 @@
formattar.gz/format
formatzip/format
/formats
-baseDirectory${project.build.finalName}-src/baseDirectory
+baseDirectorycommons-io-1.3.2-src/baseDirectory
fileSets
fileSet
includes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: fileUpload bug report
On 6/20/07, Nils Miehe [EMAIL PROTECTED] wrote: I'm quite sure I found a bug in the fileUpload module: Might be related to FILEUPLOAD-135, which I have applied tonight. Checkout the latest source and verify whether that fixes your problem. -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] 4th attempt: Release commons-io 1.3.2
Hi, I have prepared a further release candidate, with the following changes: - Deprecation tags have been removed from the FileCleaner. (In the 1.3 branch only, not in the trunk.) The discussion has clearly shown, that opinions vary on this topic, nevertheless I feel forced to make that change against my personal opinion. IMO, releasing a 1.4 release with as little changes as that would be the greater evil. - The extracted source distribution is now using the -src suffix. - The .md5 and .sha1 files meet the commons standard and have the format checksum *filename Please cast your vote. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
On 6/20/07, Phil Steitz [EMAIL PROTECTED] wrote: It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. My point of view is that he or she who demands such work (going through the docs and find all occurrencies of 1.3.2 and such is a nontrivial work and will easily take two hours or so) should be ready to do it for himself *or* leave it up to me to decide. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] 3rd attempt: Release commons-io 1.3.2
Hi, Here's the result of the vote: +1: Sebb, Oliver, Niall, Ben, Myself -1: Stephen No votes from Henri and Dion. My understanding is, that Stephen's vote isn't counted as a veto, but I'd like to ask you to correct me, if I'm wrong. In which case the vote had failed. Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Are positive votes valid for further RC`s?
Hi, I'd like to bring up an issue from the vote on commons-io: Henri Yandell wrote: Personally I feel that when voting on a new rc dist, the previous +1s still count (by lazyness) and its really about converting the -1s over to +1s. How do others think here? It would certainly save a lot of time, given the fact that commons developers tend to ignore RC votes with increasing numbers. Thanks, Jochen -- View this message in context: http://www.nabble.com/-VOTE--3rd-attempt%3A-Release-commons-io-1.3.2-tf3880798.html#a11206232 Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-123) LineIterator should call close on itself when hasNext() returns false.
[
https://issues.apache.org/jira/browse/IO-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506368
]
Jochen Wiedmann commented on IO-123:
Agree with Stephen's comment and suggest to close this as WONTFIX.
LineIterator should call close on itself when hasNext() returns false.
--
Key: IO-123
URL: https://issues.apache.org/jira/browse/IO-123
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.3.1
Reporter: Dalibor Novak
Priority: Minor
Fix For: 1.3.2
LineIterator should call close on itself when hasNext() returns false. This
would enable us to write something like this:
for (LineIterator lit = FileUtils.lineIterator(csvFile); lit.hasNext(); )
{
//do something
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Testing maven-artifact-manager patches
Hi, I'd like to test a patch for the maven-artifact-manager. My first though was to simply build Maven 2.0.7 from source, but that fails. Is there any other possibility to test my patch? Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing maven-artifact-manager patches
On 6/20/07, Rahul Akolkar [EMAIL PROTECTED] wrote: Wrong list? Sorry, you're right. -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-137) MultipartStream public API broken
[ https://issues.apache.org/jira/browse/FILEUPLOAD-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505818 ] Jochen Wiedmann commented on FILEUPLOAD-137: How's that related to commons-transaction? MultipartStream public API broken - Key: FILEUPLOAD-137 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-137 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2 Reporter: Mark Sinke In commons-transaction 1.2 the MultipartStream class has 2 public constructors. Both are deprecated; however their implementation delegates to non-visible (package-private) constructors. There are two issues here: 1. the deprecated, delegating constructors use a null pointer for the progress notifier, which in turn yield a NullPointerException when you try to use them 2. the non-deprecated constructors are not visible. Hence, I cannot really upgrade from 1.0 to 1.2. Thanks, Mark. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-137) MultipartStream public API broken
[ https://issues.apache.org/jira/browse/FILEUPLOAD-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505819 ] Jochen Wiedmann commented on FILEUPLOAD-137: Apart from that: Why do you use the MultipartStream class directly? Making it public was an error, which I am trying to fix in 1.2. MultipartStream public API broken - Key: FILEUPLOAD-137 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-137 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2 Reporter: Mark Sinke In commons-transaction 1.2 the MultipartStream class has 2 public constructors. Both are deprecated; however their implementation delegates to non-visible (package-private) constructors. There are two issues here: 1. the deprecated, delegating constructors use a null pointer for the progress notifier, which in turn yield a NullPointerException when you try to use them 2. the non-deprecated constructors are not visible. Hence, I cannot really upgrade from 1.0 to 1.2. Thanks, Mark. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Still no votes! (WAS: [VOTE] 3rd attempt: Release commons-io 1.3.2)
We still do not have the required three votes by PMC members for a release. See http://www.nabble.com/-VOTE--3rd-attempt:-Release-commons-io-1.3.2-t3880798.html for details. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd attempt: Release commons-io 1.3.2
On 6/13/07, Dion Gillard [EMAIL PROTECTED] wrote: The deployed site below still says Validator as the title. Is this fixed? I see that Niall has already fixed this. We do not need a separate vote to include this fix, do we? -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd attempt: Release commons-io 1.3.2
On 6/12/07, Ben Speakmon [EMAIL PROTECTED] wrote: I can't find the GPG key you used to sign the tarballs -- it's not in http://www.apache.org/dist/jakarta/commons/io/KEYS and there isn't a KEYS file in the svn. Looks good otherwise. +0 as is, with +1 once the key is updated and I can verify the sigs. Rats, I already *had* a proposed KEYS file in my dist directory, but seems I removed it. Ok, I have created a KEYS file for future use, which you find at http://people.apache.org/~jochen/commons-io/dist/KEYS together with the other files. Hope, that's fine. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still no votes! (WAS: [VOTE] 3rd attempt: Release commons-io 1.3.2)
On 6/13/07, Dion Gillard [EMAIL PROTECTED] wrote: There are still unanswered questions on the original thread (from memory): - KEYS used to sign the release - Site title I've already replied to these in separate votes. - Deprecation of FileCleaner My opinion here is different from Stephen's. If the use of a class is no longer recommended (which I strongly believe, giving the experiences with fileupload), then it's deprecated, point release or not. You may think different and here and take it as a reason for a -1. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: centralized KEYS file?
And replace the current KEYS files with soft links? Dunno how the mirrors handle that. -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd attempt: Release commons-io 1.3.2
On 6/13/07, Henri Yandell [EMAIL PROTECTED] wrote: * tar.gz files match zips for structure. What does that mean? In Opera I got broken images on this page. http://people.apache.org/~jochen/commons-io/site/changes-report.html You are right, this is http://jira.codehaus.org/browse/MSITE-190 I suggest that I fix this manually in the deployed site. Same on this useless looking report (in that it will always be out of date): http://people.apache.org/~jochen/commons-io/site/jira-report.html Again, I have no problem to remove it from the deployed site. Personally I feel that when voting on a new rc dist, the previous +1s still count (by lazyness) and its really about converting the -1s over to +1s. That's interesting. If others feel the same, then I'd like to see this fixed somewhere. I'll bring up a different thread on that. I'm -1 with respect to the md5s. Presuming you did them by hand, it's something you can easily fix without rerolling anything. Even if not, I'd just fix them by hand anyway. Ok, as you are the second one asking for it, I've changed it. Same for the .sha1 files. I'm -0 on the validator bit meaning a reroll. I dislike how Maven1 puts the site in the binary and am looking forward to doing a Maven2 build and finding a way to only put the real docs in the binary (javadoc, release notes and user guide). That's a matter of opinion. I for my part do like if the site is included. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd attempt: Release commons-io 1.3.2
How to handle this? We have only three votes: [+1] Sebb, Jochen [-0] Stephen but we need at least three positive votes from PMC members? Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd attempt: Release commons-io 1.3.2
On 6/7/07, sebb [EMAIL PROTECTED] wrote: Are the jar archives necessary? Yes. Other projects tend only to release zip and tar.gz. The jar files are released implicitly, via the Maven repositories. The only difference is that I do this explicitly. Jochen -- Women have the ability to wind you round their little finger. Daughters can use all of the fingers together. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r544971 - /jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaningTracker.java
Author: jochen
Date: Wed Jun 6 14:58:43 2007
New Revision: 544971
URL: http://svn.apache.org/viewvc?view=revrev=544971
Log:
Reverting the changes from revision 518770. Rahul Akolkar has convinced me that
the FileCleaningTracker should not be declared serializable, because it isn't.
Modified:
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaningTracker.java
Modified:
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaningTracker.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaningTracker.java?view=diffrev=544971r1=544970r2=544971
==
---
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaningTracker.java
(original)
+++
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaningTracker.java
Wed Jun 6 14:58:43 2007
@@ -17,8 +17,6 @@
package org.apache.commons.io;
import java.io.File;
-import java.io.ObjectStreamException;
-import java.io.Serializable;
import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;
import java.util.Collection;
@@ -42,28 +40,23 @@
* @author Martin Cooper
* @version $Id: FileCleaner.java 490987 2006-12-29 12:11:48Z scolebourne $
*/
-public class FileCleaningTracker implements Serializable {
-/**
- * UID for serializing instances of this class.
- */
-private static final long serialVersionUID = -8153509976492548871L;
-
+public class FileCleaningTracker {
/**
* Queue of codeTracker/code instances being watched.
*/
-transient ReferenceQueue /* Tracker */ q = new ReferenceQueue();
+ReferenceQueue /* Tracker */ q = new ReferenceQueue();
/**
* Collection of codeTracker/code instances in existence.
*/
-final transient Collection /* Tracker */ trackers = new Vector(); //
synchronized
+final Collection /* Tracker */ trackers = new Vector(); // synchronized
/**
* Whether to terminate the thread when the tracking is complete.
*/
-transient volatile boolean exitWhenFinished = false;
+volatile boolean exitWhenFinished = false;
/**
* The thread that will clean up registered files.
*/
-transient Thread reaper;
+Thread reaper;
//---
/**
@@ -262,14 +255,4 @@
}
}
-/**
- * This method is called when an instance is deserialized.
- * It replaces the deserialized instance with a new, fresh
- * instance.
- * @return A new instance, which hasn't been in use so far.
- * @throws ObjectStreamException Not actually thrown.
- */
-private Object readResolve() throws ObjectStreamException {
-return new FileCleaningTracker();
-}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io][fileupload] svn commit: r518770 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/FileCleaningTracker.java test/org/apache/commons/io/FileUtilsCleanDirectoryTestCase.java
On 3/16/08, Rahul Akolkar wrote: On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jochen Date: Thu Mar 15 15:02:46 2007 New Revision: 518770 URL: http://svn.apache.org/viewvc?view=revrev=518770 Log: Made the FileCleaningTracker serializable. This is required by commons-fileupload, because the DiskFileItem's may be part of the HTTP session while still carrying a reference to the tracker. snip/ I think this particular solution is sub-optimal in a couple of aspects: * The instances aren't really serializable so its a bit of a truth in advertising infringement * Its introducing a tighter coupling between the next releases of [io] and [fileupload], which is fine if we can buy that there is evidence that the change would be helpful to [io] in isolation. I think identical behavior (for what this is worth) can be obtained by reverting this commit and having a transient lazily-initialized FileCleaningTracker in DiskFileItem, which addresses the two bullets above, and the NotSerializableExceptions that you may otherwise witness at container shutdown. WDYT? I haven't really though about the fileupload part, but you have convinced me that this must be addressed by fileupload and not by io. I have therefore reverted my patch in the 1.3 branch. I will also revert the same patch in the trunk after the 1.3.2 release is out when I merge the release related changes in. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] 3rd attempt: Release commons-io 1.3.2
Hi, I have created a new distribution and a new site which you find at http://people.apache.org/~jochen/commons-io/dist http://people.apache.org/~jochen/commons-io/site This version matches revision 544971, which I intend to tag as commons-io-1.3.2 in case of a successful vote. Compared to the previous vote, the following changes have been made: - Rahul Akolkar has convinced me, that the FileCleaningTracker should not be declared serializable, because it isn't. The resulting issues must be resolved within commons-fileupload and not commons-io. - As observed by Niall Pemberton, the -sources and -javadoc jar files did not contain LICENSE.txt and NOTICE.txt files. This is now ensured by the POM. It is an open issue for me, whether this change can be pushed up to the commons-parent POM. Please cast your vote. Jochen [ ] +1 [ ] =0 [ ] -1 -- Women have the ability to wind you round their little finger. Daughters can use all of the fingers together. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-135) InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS
[ https://issues.apache.org/jira/browse/FILEUPLOAD-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502147 ] Jochen Wiedmann commented on FILEUPLOAD-135: This test case doesn't help me understand the problem. The important part is the multipart document, which triggers the problem. We'd need a code sample that creates such a multipart document (compare, for example, the methid StreamingTest.newRequest; btw, note that this method creates file items which are clearly smaller than the boundary) or at least the multipart document itself, which you can catch with tools like tcpmon or Wireshark. InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS --- Key: FILEUPLOAD-135 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-135 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2, 1.2.1 Environment: Windows XP Browser: Firefox 1.5.0.11 Protocol: HTTPS Reporter: Alexander Sova Attachments: commons-fileupload-1.1-bug-short-file-eof.patch, commons-fileupload-1.2-bug-short-file-eof.patch This problem happens only with files shorer then boundary string generated by browser and only with Firefox using HTTPS protocol. For some reason in this particular environment inputStream.read() in MultipartStream.ItemInputStream.makeAvailable() reads not whole HTTP response body, but only file content before boundary string. I've created a patch fixing this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r544995 - in /jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk: DiskFileItem.java DiskFileItemFactory.java
Author: jochen
Date: Wed Jun 6 16:51:28 2007
New Revision: 544995
URL: http://svn.apache.org/viewvc?view=revrev=544995
Log:
Documented that the FileCleaningTracker may be null
to disable tracking.
PR: FILEUPLOAD-133
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java?view=diffrev=544995r1=544994r2=544995
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Wed Jun 6 16:51:28 2007
@@ -216,7 +216,8 @@
* Constructs a new codeDiskFileItem/code instance.
*
* @param tracker The tracker, which is responsible for deleting
- * the temporary file.
+ * the temporary file. May be null, if the file
+ * doesn't need to be tracked.
* @param fieldName The name of the form field.
* @param contentType The content type passed by the browser or
* codenull/code if not specified.
@@ -648,10 +649,11 @@
/**
- * Creates and returns a [EMAIL PROTECTED] java.io.File File} representing
a uniquely
- * named temporary file in the configured repository path. The lifetime of
- * the file is tied to the lifetime of the codeFileItem/code instance;
- * the file will be deleted when the instance is garbage collected.
+ * pCreates and returns a [EMAIL PROTECTED] java.io.File File}
representing a uniquely
+ * named temporary file in the configured repository path./p
+ * pIf the file item factory has an associated [EMAIL PROTECTED]
FileCleaningTracker},
+ * then the lifetime of the file is tied to the lifetime of the
codeFileItem/code
+ * instance: The file will be deleted when the instance is garbage
collected./p
*
* @return The [EMAIL PROTECTED] java.io.File File} to be used for
temporary storage.
*/
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java?view=diffrev=544995r1=544994r2=544995
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
Wed Jun 6 16:51:28 2007
@@ -85,8 +85,9 @@
/**
- * The instance of [EMAIL PROTECTED] FileCleaningTracker}, which is
responsible
- * for deleting temporary files.
+ * pThe instance of [EMAIL PROTECTED] FileCleaningTracker}, which is
responsible
+ * for deleting temporary files./p
+ * pMay be null, if tracking files is not required./p
*/
private FileCleaningTracker fileCleaningTracker;
@@ -130,7 +131,8 @@
* which files will be created, should the item size
* exceed the threshold.
* @param tracker The tracker, which is responsible to delete
- * temporary files.
+ * temporary files. May be null, if files don't need
+ * to be tracked.
*/
public DiskFileItemFactory(FileCleaningTracker tracker, int sizeThreshold,
File repository) {
@@ -226,7 +228,8 @@
* Returns the tracker, which is responsible for deleting temporary
* files.
* @return An instance of [EMAIL PROTECTED] FileCleaningTracker}, defaults
to
- * [EMAIL PROTECTED] FileCleaner#getInstance()}.
+ * [EMAIL PROTECTED] FileCleaner#getInstance()}. Null, if temporary files
+ * aren't tracked.
*/
public FileCleaningTracker getFileCleaningTracker() {
return fileCleaningTracker;
@@ -236,7 +239,8 @@
* Returns the tracker, which is responsible for deleting temporary
* files.
* @param pTracker An instance of [EMAIL PROTECTED] FileCleaningTracker},
- * which will from now on track the created files.
+ * which will from now on track the created files. May be null
+ * to disable tracking.
*/
public void setFileCleaningTracker(FileCleaningTracker pTracker) {
fileCleaningTracker = pTracker
svn commit: r544997 - /jakarta/commons/proper/fileupload/trunk/xdocs/using.xml
Author: jochen Date: Wed Jun 6 16:54:33 2007 New Revision: 544997 URL: http://svn.apache.org/viewvc?view=revrev=544997 Log: (empty) Modified: jakarta/commons/proper/fileupload/trunk/xdocs/using.xml Modified: jakarta/commons/proper/fileupload/trunk/xdocs/using.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/xdocs/using.xml?view=diffrev=544997r1=544996r2=544997 == --- jakarta/commons/proper/fileupload/trunk/xdocs/using.xml (original) +++ jakarta/commons/proper/fileupload/trunk/xdocs/using.xml Wed Jun 6 16:54:33 2007 @@ -332,6 +332,14 @@ } ]]/source /subsection + +subsection name=Disabling cleanup of temporary files + p +To disable tracking of temporary files, you may set the +codeFileCleaningTracker/code to null. Consequently, +created files will no longer be tracked. In particular, +they will no longer be deleted automatically./p +/subsection /section section name=Interaction with virus scanners - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-133) Refactor use of FileCleaner into plugable strategy to allow overriding.
[
https://issues.apache.org/jira/browse/FILEUPLOAD-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved FILEUPLOAD-133.
Resolution: Fixed
The existing implementation already allows to set the FileCleaningTracker to
null, in which case your requirements are met. I'll document the possibility,
though.
Refactor use of FileCleaner into plugable strategy to allow overriding.
---
Key: FILEUPLOAD-133
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-133
Project: Commons FileUpload
Issue Type: Improvement
Affects Versions: 1.2
Reporter: Ben Sommerville
Priority: Minor
For applications that do not want to use the FileCleaner service it would be
very useful to allow this to be overridden.
This could be done by refactoring the use of the FileCleaner into a plugable
strategy.
e..g
interface TemporaryFileCleaner {
void register(FileItem item, File file );
}
The DiskFileItem could have a default implementation of the strategy that
invokes FileCleaner.track. However if required an application could supply a
different stategy to the factory for use by all the items.
I'll try to post a patch implementing this in the next couple of days
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r545004 - in /jakarta/commons/proper/fileupload/trunk: pom.xml src/changes/changes.xml src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Author: jochen
Date: Wed Jun 6 17:05:29 2007
New Revision: 545004
URL: http://svn.apache.org/viewvc?view=revrev=545004
Log:
DiskFileItem.toString() could throw an NPE.
PR: FILEUPLOAD-134
Submitted-by: Thomas Vandahl, [EMAIL PROTECTED]
Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diffrev=545004r1=545003r2=545004
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Wed Jun 6 17:05:29 2007
@@ -97,16 +97,20 @@
email[EMAIL PROTECTED]/email
/contributor
contributor
+ nameMichael Macaluso/name
+ email[EMAIL PROTECTED]/email
+/contributor
+contributor
nameAmichai Rothman/name
email[EMAIL PROTECTED]/email
/contributor
contributor
- nameHenry Yandell/name
- email[EMAIL PROTECTED]/email
+ nameThomas Vandahl/name
+ email[EMAIL PROTECTED]/email
/contributor
contributor
- nameMichael Macaluso/name
- email[EMAIL PROTECTED]/email
+ nameHenry Yandell/name
+ email[EMAIL PROTECTED]/email
/contributor
/contributors
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diffrev=545004r1=545003r2=545004
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Wed Jun 6
17:05:29 2007
@@ -60,6 +60,10 @@
A MalformedStreamException is now thrown, if the size of an items
headers exceeds HEADER_PART_SIZE_MAX;
/action
+ action dev=jochen type=fix issue=FILEUPLOAD-134
+ due-to=Thomas Vandahl due-to-email=[EMAIL PROTECTED]
+DiskFileItem.toString() could throw an NPE.
+ /action
/release
release version=1.2 date=2007-02-13
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java?view=diffrev=545004r1=545003r2=545004
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Wed Jun 6 17:05:29 2007
@@ -629,7 +629,7 @@
* memory.
*/
public File getStoreLocation() {
-return dfos.getFile();
+return dfos == null ? null : dfos.getFile();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-134) A factory-created DiskFileItem does not have an initialized dfos, causing NullPointerExceptions if getOutputStream() is not called.
[
https://issues.apache.org/jira/browse/FILEUPLOAD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved FILEUPLOAD-134.
Resolution: Fixed
Fix Version/s: 1.2.1
The method DiskFileItem.getStorageLocation() is now checking for dfos == null.
A factory-created DiskFileItem does not have an initialized dfos, causing
NullPointerExceptions if getOutputStream() is not called.
---
Key: FILEUPLOAD-134
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-134
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2
Reporter: Thomas Vandahl
Fix For: 1.2.1
When upgrading the Turbine code to commons-fileupload 1.2, I got NPEs in Unit
tests dealing with DiskFileItems. In that special case, a FileItem was
created like this:
ParameterParser pp = new DefaultParameterParser();
DiskFileItemFactory factory = new DiskFileItemFactory(10240, new
File(.));
FileItem test = factory.createItem(upload-field,
application/octet-stream, false, null);
pp.add(upload-field, test);
assertTrue(pp.toString().startsWith({upload-field=[name=null));
pp.toString() causes a call to test.toString() which (among other things)
calls dfos.getFile(). This fails because dfos is not initialized before
getOutputStream() is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] svn commit: r543805 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
On 6/3/07, Rahul Akolkar [EMAIL PROTECTED] wrote: Rumor has it that putting the license comment as a child of the root is a workaround. Sounds plausible, is that true? Sounds plausible, that this is a rumor. :-) -- Women have the ability to wind you round their little finger. Daughters can use all of the fingers together. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r543816 - /jakarta/commons/proper/io/branches/b1_3/pom.xml
Author: jochen
Date: Sat Jun 2 17:46:16 2007
New Revision: 543816
URL: http://svn.apache.org/viewvc?view=revrev=543816
Log:
Ensured that the -sources and -javadoc jar files contain META-INF/LICENSE and
META-INF/NOTICE.
Modified:
jakarta/commons/proper/io/branches/b1_3/pom.xml
Modified: jakarta/commons/proper/io/branches/b1_3/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/pom.xml?view=diffrev=543816r1=543815r2=543816
==
--- jakarta/commons/proper/io/branches/b1_3/pom.xml (original)
+++ jakarta/commons/proper/io/branches/b1_3/pom.xml Sat Jun 2 17:46:16 2007
@@ -22,7 +22,7 @@
parent
groupIdorg.apache.commons/groupId
artifactIdcommons-parent/artifactId
-version2/version
+version3/version
/parent
modelVersion4.0.0/modelVersion
groupIdcommons-io/groupId
@@ -202,27 +202,37 @@
build
sourceDirectorysrc/java/sourceDirectory
testSourceDirectorysrc/test/testSourceDirectory
- plugins
-plugin
- groupIdorg.apache.maven.plugins/groupId
- artifactIdmaven-surefire-plugin/artifactId
-configuration
- includes
-include**/*Test*/include
- /includes
- excludes
-exclude**/*AbstractTestCase*/exclude
-exclude**/AllIOTestSuite*/exclude
-exclude**/PackageTestSuite*/exclude
-exclude**/testtools/**/exclude
-
-!-- http://jira.codehaus.org/browse/SUREFIRE-44 --
-exclude**/*$*/exclude
- /excludes
- /configuration
-/plugin
- /plugins
-/build
+plugins
+ plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-surefire-plugin/artifactId
+configuration
+ includes
+include**/*Test*/include
+ /includes
+ excludes
+exclude**/*AbstractTestCase*/exclude
+exclude**/AllIOTestSuite*/exclude
+exclude**/PackageTestSuite*/exclude
+exclude**/testtools/**/exclude
+
+!-- http://jira.codehaus.org/browse/SUREFIRE-44 --
+exclude**/*$*/exclude
+ /excludes
+/configuration
+ /plugin
+ plugin
+artifactIdmaven-assembly-plugin/artifactId
+configuration
+ descriptors
+descriptorsrc/main/assembly/bin.xml/descriptor
+descriptorsrc/main/assembly/src.xml/descriptor
+ /descriptors
+ tarLongFileModegnu/tarLongFileMode
+/configuration
+ /plugin
+/plugins
+ /build
reporting
plugins
@@ -241,16 +251,6 @@
/reportSet
/reportSets
/plugin
- plugin
-artifactIdmaven-assembly-plugin/artifactId
-configuration
- descriptors
-descriptorsrc/main/assembly/bin.xml/descriptor
-descriptorsrc/main/assembly/src.xml/descriptor
- /descriptors
- tarLongFileModegnu/tarLongFileMode
-/configuration
- /plugin
/plugins
/reporting
@@ -283,6 +283,24 @@
copy todir=${project.build.directory}/site/api-release
fileset dir=${project.build.directory}/site/apidocs/
/copy
+zip
destfile=${project.build.directory}/${artifactId}-${version}-javadoc.jar.new
+ zipfileset
src=${project.build.directory}/${artifactId}-${version}-javadoc.jar/
+ zipfileset dir=. prefix=META-INF
+include name=LICENSE.txt/
+include name=NOTICE.txt/
+ /zipfileset
+/zip
+move
file=${project.build.directory}/${artifactId}-${version}-javadoc.jar.new
+
tofile=${project.build.directory}/${artifactId}-${version}-javadoc.jar/
+zip
destfile=${project.build.directory}/${artifactId}-${version}-sources.jar.new
+ zipfileset
src=${project.build.directory}/${artifactId}-${version}-sources.jar/
+ zipfileset dir=. prefix=META-INF
+include name=LICENSE.txt/
+include name=NOTICE.txt/
+ /zipfileset
+/zip
+move
file=${project.build.directory}/${artifactId}-${version}-sources.jar.new
+
tofile=${project.build.directory}/${artifactId}-${version}-sources.jar/
/tasks
/configuration
/execution
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: fileupload help
On 6/1/07, Samshuijzen, A. (0771492) [EMAIL PROTECTED] wrote: I've been trying it for 2 days now, but still got a nullpointerexception And why don't you think that the NPE's stacktrace wouldn't be the first thing we'd like to see? Jochen -- Women have the ability to wind you round their little finger. Daughters can use all of the fingers together. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
rant I think we need to establish a little bit more of an agile edge here at commons. Boy we suck at release votes. /rant +1 I surely hope that the proposed chair has an eye on it. :-) -- Women have the ability to wind you round their little finger. Daughters can use all of the fingers together. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3 (take 2)
On 5/30/07, Dennis Lundberg [EMAIL PROTECTED] wrote: This is the second attempt to release version 3 of commons-parent. +1 -- Women have the ability to wind you round their little finger. Daughters can use all of the fingers together. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
On 5/29/07, Dennis Lundberg [EMAIL PROTECTED] wrote: 1. Remove the build/pluginManagement sections from the profiles, as those are not needed. These were added after the last release, when Niall updated to the newer sources plugin. 2. Lock down the version for the javadoc and jxr plugins I'll hold my commit until I get someones approval, as this is an ongoing vote. I volunteer to do the actual release of the pom. If we can do that quick and you're holding the next vote, then I'd be +1 for both. My main target is to have a version of the pom which makes use of the sources plugin 2.0.3. Jochen -- Women have the ability to wind you round their little finger. Daughters can use all of the fingers together. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
I don't know how to deal with this thread. The discussion was related to further improvement of the commons-parent. IMO, this is far from blocking the proposed release. (As I wrote, in particular in the case of the commons-parent, nothing prevents us from further releases real soon, if the discussed improvements have been made.) Nevertheless, only Niall confirmed a release. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-135) InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS
[ https://issues.apache.org/jira/browse/FILEUPLOAD-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499448 ] Jochen Wiedmann commented on FILEUPLOAD-135: Before applying your patch, I'd like to understand the problem. Would it be possible for you to provide a test case, which fails with 1.2 and works with your patch? Preferrably a patch against the test suite, but a sample http body should do. InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS --- Key: FILEUPLOAD-135 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-135 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2, 1.2.1 Environment: Windows XP Browser: Firefox 1.5.0.11 Protocol: HTTPS Reporter: Alexander Sova Attachments: commons-fileupload-1.1-bug-short-file-eof.patch, commons-fileupload-1.2-bug-short-file-eof.patch I was able to reproduce this problem happens only with files shorer then boundary string generated by browser and only with Firefox using HTTPS protocol. For some reason in this particular environment inputStream.read() in MultipartStream.ItemInputStream.makeAvailable() reads not whole HTTP response body, but only file content before boundary string. I've created a patch fixing this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release commons-parent 3
Hi, I'd like to push out version 3 of the commons-parent project. The changes in maven-sources-plugin 2.0.3 allow to get rid of the maven-antrun hack and that's reason enough, IMO. I'd suggest to take revision 534137, change the version number in 3 and deploy that. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Move to a minimum of JDK 1.4?
On 5/18/07, Stephen Colebourne [EMAIL PROTECTED] wrote: My preference would be to support JDK1.3 and JDK1.5 versions, rather than JDK1.4. I do not understand your intention. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons compress status?
On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: VFS is a filesystem abstraction layer. It may use the library but should not provide the implementation IMO. +1, compression is a rather important topic in itself. -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: Ehm... could we first sort out the repository question I brought up? ...and preferably also the related release process? We should also add the version numbers to the plugins. I'd say: let's work this out over the weekend and re-start the vote in a couple of days. I do think, that introducing a new deployment mechanism is a larger disruption than the changes made so far in 3-SNAPSHOT. In other words, I'd prefer to see this in a separate release. Apart from that, what prevents us from publishing version 3 now and a version 4, if the above questions are resolved? I do not understand this oh, just wait until I've got my favourite feature in whenever it comes to a release of the commons-parent. This thing doesn't need exhaustive QA or something like that, and it's not like we weren't able to manage 12 releases of it every year. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/18/07, Henri Yandell [EMAIL PROTECTED] wrote: No votes yet, so I wanted to ask what your thoughts were on including: http://issues.apache.org/jira/browse/IO-117 in 1.3.2? Fine with me, if you apply it to both branch and trunk. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/18/07, Rahul Akolkar [EMAIL PROTECTED] wrote: Was there a response to my comment [1] about r518770? Sorry, I wasn't reading your comment. But, to be honest, I have to admit that after reading it, I do not understand what you propose as a better solution? Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r538941 - in /jakarta/commons/proper/io/branches/b1_3: PROPOSAL.html STATUS.html build.xml doap_io.rdf pom.xml src/main/assembly/bin.xml xdocs/style/project.css
Author: jochen Date: Thu May 17 07:30:58 2007 New Revision: 538941 URL: http://svn.apache.org/viewvc?view=revrev=538941 Log: Making the RAT plugin happy. Modified: jakarta/commons/proper/io/branches/b1_3/PROPOSAL.html jakarta/commons/proper/io/branches/b1_3/STATUS.html jakarta/commons/proper/io/branches/b1_3/build.xml jakarta/commons/proper/io/branches/b1_3/doap_io.rdf jakarta/commons/proper/io/branches/b1_3/pom.xml jakarta/commons/proper/io/branches/b1_3/src/main/assembly/bin.xml jakarta/commons/proper/io/branches/b1_3/xdocs/style/project.css Modified: jakarta/commons/proper/io/branches/b1_3/PROPOSAL.html URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/PROPOSAL.html?view=diffrev=538941r1=538940r2=538941 == --- jakarta/commons/proper/io/branches/b1_3/PROPOSAL.html (original) +++ jakarta/commons/proper/io/branches/b1_3/PROPOSAL.html Thu May 17 07:30:58 2007 @@ -1,4 +1,20 @@ !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- html head titleProposal for IO Package/title Modified: jakarta/commons/proper/io/branches/b1_3/STATUS.html URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/STATUS.html?view=diffrev=538941r1=538940r2=538941 == --- jakarta/commons/proper/io/branches/b1_3/STATUS.html (original) +++ jakarta/commons/proper/io/branches/b1_3/STATUS.html Thu May 17 07:30:58 2007 @@ -1,4 +1,20 @@ !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- html head titleStatus File for Jakarta Commons IO Component/title Modified: jakarta/commons/proper/io/branches/b1_3/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/build.xml?view=diffrev=538941r1=538940r2=538941 == --- jakarta/commons/proper/io/branches/b1_3/build.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/build.xml Thu May 17 07:30:58 2007 @@ -1,6 +1,23 @@ ?xml version=1.0 encoding=UTF-8? !-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- + +!-- Based on maven generated file on date October 1 2005 Added overview to javadoc Include license in jar Modified: jakarta/commons/proper/io/branches/b1_3/doap_io.rdf URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/doap_io.rdf?view=diffrev=538941r1=538940r2=538941 == --- jakarta/commons/proper/io
[VOTE] 2nd attempt: Release commons-io 1.3.2
Hi, I have fixed the issues with the file permissions and added license headers to most of the files, with the only exception of MANIFEST.MF. Now, I'd like to call for another vote on the release of commons-io 1.3.2. The proposed distributables can be found at http://people.apache.org/~jochen/commons-io/dist A KEYS file is included. The proposed site is at http://people.apache.org/~jochen/commons-io/site Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/17/07, Antonio Petrelli [EMAIL PROTECTED] wrote: Hey wait a moment! I don't want to annoy you, but if a JAR has been created and made available to the public, it is typical to create a new version (in your case 1.3.3). As Wendy (Smoak) noted, when someone writes in the mailing list about a 1.3.2 version, you will say what 1.3.2 version?. It could be a nightmare to track it. I don't think that a few license headers are a problem, but anyway... We haven't yet released a version 1.3.2. Of course, if we had, then I'd never dare to call this 1.3.2 again. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/17/07, sebb [EMAIL PROTECTED] wrote: The site report page http://people.apache.org/~jochen/commons-io/site/project-reports.html says that the RAT report is a Report on binary and source API differences between releases That's a bug in the rat-maven-plugin and cannot easily be fixed now. Sorry, Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r538699 - /jakarta/commons/proper/io/branches/b1_3/
Author: jochen Date: Wed May 16 12:55:33 2007 New Revision: 538699 URL: http://svn.apache.org/viewvc?view=revrev=538699 Log: (empty) Added: jakarta/commons/proper/io/branches/b1_3/ - copied from r538698, jakarta/commons/proper/io/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[IO] Created 1.3 branch
Hi, in light of the ongoing discussions regarding commons-io, I have created a branch https://svn.apache.org/repos/asf/jakarta/commons/proper/io/branches/b1_3 Reasons: - It will allow me to make release related changes without disturbing other peoples work. For example, I'll roll back the version numbers from 1.4-SNAPSHOT to 1.3.2. - If commons-io is actually switching to JDK 1.4, then it makes quite some sense to have a maintenance branch for 1.3. - It doesn't make too much sense, if Niall defers work just to wait for a release out of the trunk. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r538703 - in /jakarta/commons/proper/io/branches/b1_3: build.xml pom.xml project.xml
Author: jochen
Date: Wed May 16 13:04:50 2007
New Revision: 538703
URL: http://svn.apache.org/viewvc?view=revrev=538703
Log: (empty)
Modified:
jakarta/commons/proper/io/branches/b1_3/build.xml
jakarta/commons/proper/io/branches/b1_3/pom.xml
jakarta/commons/proper/io/branches/b1_3/project.xml
Modified: jakarta/commons/proper/io/branches/b1_3/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/build.xml?view=diffrev=538703r1=538702r2=538703
==
--- jakarta/commons/proper/io/branches/b1_3/build.xml (original)
+++ jakarta/commons/proper/io/branches/b1_3/build.xml Wed May 16 13:04:50 2007
@@ -26,7 +26,7 @@
/property
property name=testreportdir value=${basedir}/build/test-reports
/property
- property name=final.name value=commons-io-1.4-SNAPSHOT /
+ property name=final.name value=commons-io-1.3.2 /
property name=dist.build.dir value=${basedir}/build/dist-build /
property name=dist.bin value=${dist.build.dir}/${final.name} /
property name=dist.src value=${dist.build.dir}/${final.name}-src /
@@ -272,7 +272,7 @@
/tstamp
property name=copyright value=Copyright amp;copy; The Apache
Software Foundation. All Rights Reserved.
/property
-property name=title value=IO 1.4-SNAPSHOT
+property name=title value=IO 1.3.2
/property
javadoc use=true private=true destdir=${javadocdir} author=true
version=true sourcepath=${basedir}/src/java
packagenames=org.apache.commons.io.*
overview=src/java/org/apache/commons/io/overview.html
classpath
Modified: jakarta/commons/proper/io/branches/b1_3/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/pom.xml?view=diffrev=538703r1=538702r2=538703
==
--- jakarta/commons/proper/io/branches/b1_3/pom.xml (original)
+++ jakarta/commons/proper/io/branches/b1_3/pom.xml Wed May 16 13:04:50 2007
@@ -27,7 +27,7 @@
modelVersion4.0.0/modelVersion
groupIdcommons-io/groupId
artifactIdcommons-io/artifactId
- version1.4-SNAPSHOT/version
+ version1.3.2/version
nameCommons IO/name
inceptionYear2002/inceptionYear
Modified: jakarta/commons/proper/io/branches/b1_3/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/project.xml?view=diffrev=538703r1=538702r2=538703
==
--- jakarta/commons/proper/io/branches/b1_3/project.xml (original)
+++ jakarta/commons/proper/io/branches/b1_3/project.xml Wed May 16 13:04:50 2007
@@ -21,7 +21,7 @@
nameIO/name
groupIdcommons-io/groupId
artifactIdcommons-io/artifactId
- currentVersion1.4-SNAPSHOT/currentVersion
+ currentVersion1.3.2/currentVersion
inceptionYear2002/inceptionYear
shortDescriptionCommons IO/shortDescription
description
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r538709 - /jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml
Author: jochen Date: Wed May 16 13:18:28 2007 New Revision: 538709 URL: http://svn.apache.org/viewvc?view=revrev=538709 Log: (empty) Modified: jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml Modified: jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml?view=diffrev=538709r1=538708r2=538709 == --- jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml Wed May 16 13:18:28 2007 @@ -39,7 +39,7 @@ /properties body -release version=1.4 date=Not yet released +release version=1.4 date=2007-May-16 action dev=jochen type=fix issue=IO-115 Some tests, which are implicitly assuming a Unix-like file system, are now skipped on Windows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r538711 - /jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml
Author: jochen Date: Wed May 16 13:20:43 2007 New Revision: 538711 URL: http://svn.apache.org/viewvc?view=revrev=538711 Log: Fixed typo. Modified: jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml Modified: jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml?view=diffrev=538711r1=538710r2=538711 == --- jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml Wed May 16 13:20:43 2007 @@ -39,7 +39,7 @@ /properties body -release version=1.4 date=2007-May-16 +release version=1.4 date=2007-May-16 action dev=jochen type=fix issue=IO-115 Some tests, which are implicitly assuming a Unix-like file system, are now skipped on Windows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r538725 - in /jakarta/commons/proper/io/branches/b1_3: RELEASE-NOTES.txt src/conf/MANIFEST.MF xdocs/building.xml xdocs/index.xml xdocs/navigation.xml xdocs/upgradeto1_3_2.xml xdocs/upgrade
Author: jochen Date: Wed May 16 13:47:54 2007 New Revision: 538725 URL: http://svn.apache.org/viewvc?view=revrev=538725 Log: Release related changes. Added: jakarta/commons/proper/io/branches/b1_3/xdocs/upgradeto1_3_2.xml - copied, changed from r538699, jakarta/commons/proper/io/branches/b1_3/xdocs/upgradeto1_4.xml Removed: jakarta/commons/proper/io/branches/b1_3/xdocs/upgradeto1_4.xml Modified: jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt jakarta/commons/proper/io/branches/b1_3/src/conf/MANIFEST.MF jakarta/commons/proper/io/branches/b1_3/xdocs/building.xml jakarta/commons/proper/io/branches/b1_3/xdocs/index.xml jakarta/commons/proper/io/branches/b1_3/xdocs/navigation.xml Modified: jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt?view=diffrev=538725r1=538724r2=538725 == --- jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt Wed May 16 13:47:54 2007 @@ -1,7 +1,7 @@ $Id$ Commons IO Package - Version 1.3.1 + Version 1.3.2 Release Notes @@ -15,6 +15,15 @@ and endian transformation classes. +Compatibility with 1.3.1 +-- +Binary compatible - Yes + +Source compatible - Yes + +Semantic compatible - Yes + + Compatibility with 1.3 -- Binary compatible - No @@ -26,12 +35,29 @@ Semantic compatible - Yes +Enhancements since 1.3.1 + + +- Created the FileCleaningTracker, basically a non-static version of the + FileCleaner, which can be controlled by the user. [IO-116] +- The FileCleaner is deprecated. + + +Bug fixes from 1.3.1 + + +- Some tests, which are implicitly assuming a Unix-like file system, are + now skipped on Windows. [IO-115] + + + Bug fixes from 1.3 -- - FileUtils - NPE in openOutputStream(File) when file has no parent in path [IO-112] - readFileToString(File) is not static [IO-113] + Feedback Modified: jakarta/commons/proper/io/branches/b1_3/src/conf/MANIFEST.MF URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/conf/MANIFEST.MF?view=diffrev=538725r1=538724r2=538725 == --- jakarta/commons/proper/io/branches/b1_3/src/conf/MANIFEST.MF (original) +++ jakarta/commons/proper/io/branches/b1_3/src/conf/MANIFEST.MF Wed May 16 13:47:54 2007 @@ -1,10 +1,10 @@ Manifest-Version: 1.0 Package: org.apache.commons.io Extension-Name: commons-io -Specification-Version: 1.3.1 +Specification-Version: 1.3.2 Specification-Vendor: Apache Software Foundation Specification-Title: Commons IO -Implementation-Version: 1.3.1 +Implementation-Version: 1.3.2 Implementation-Vendor: Apache Software Foundation Implementation-Title: Commons IO Implementation-Vendor-Id: org.apache Modified: jakarta/commons/proper/io/branches/b1_3/xdocs/building.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/xdocs/building.xml?view=diffrev=538725r1=538724r2=538725 == --- jakarta/commons/proper/io/branches/b1_3/xdocs/building.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/xdocs/building.xml Wed May 16 13:47:54 2007 @@ -29,6 +29,7 @@ /p p You may also be interested in the upgrade notes:br / + Upgrade a href=upgradeto1_3_2.htmlfrom 1.3, or 1.3.1 to 1.3.2/abr / Upgrade a href=upgradeto1_3_1.htmlfrom 1.3 to 1.3.1/abr / Upgrade a href=upgradeto1_3.htmlfrom 1.2 to 1.3/abr / Upgrade a href=upgradeto1_2.htmlfrom 1.1 to 1.2/abr / Modified: jakarta/commons/proper/io/branches/b1_3/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/xdocs/index.xml?view=diffrev=538725r1=538724r2=538725 == --- jakarta/commons/proper/io/branches/b1_3/xdocs/index.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/xdocs/index.xml Wed May 16 13:47:54 2007 @@ -40,13 +40,14 @@ p A getting started a href=description.htmluser guide/a is available, as are some IO a href=bestpractices.htmlbest practices/a -and various a href=maven-reports.htmlproject reports/a. +and various a href=project-reports.htmlproject reports/a. /p p The JavaDoc API documents are available online: /p ul -liThe a href=api-release/index.htmlcurrent release 1.3.1/a/li +liThe a href=api-release/index.htmlcurrent release 1.3.2/a/li +liThe a href=api-1.3.1/index.htmlprevious version 1.3.1/a/li liThe a href=api-1.3/index.htmlprevious version 1.3/a/li liThe a href=api-1.2/index.htmlprevious version 1.2/a/li
svn commit: r538726 - /jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml
Author: jochen Date: Wed May 16 13:51:13 2007 New Revision: 538726 URL: http://svn.apache.org/viewvc?view=revrev=538726 Log: Invalid version number. Modified: jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml Modified: jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml?view=diffrev=538726r1=538725r2=538726 == --- jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml Wed May 16 13:51:13 2007 @@ -39,7 +39,7 @@ /properties body -release version=1.4 date=2007-May-16 +release version=1.3.2 date=2007-May-16 action dev=jochen type=fix issue=IO-115 Some tests, which are implicitly assuming a Unix-like file system, are now skipped on Windows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release commons-io 1.3.2
Hi, I'd like to call for a vote on the release of commons-io 1.3.2. The proposed distributables can be found at http://people.apache.org/~jochen/commons-io/dist A KEYS file is included. The proposed site is at http://people.apache.org/~jochen/commons-io/site It includes a RAT report. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RfC: Release commons-io-1.3.2
Hi, the commons-io project has been rather silent in the last months, apart from IO-116. Unfortunately, this bug is a blocker for the next release of commons-fileupload. Therefore, I'd like to ask whether anyone would object a bug fix release 1.3.2? If noone intervenes, I'd start a formal vote, with me as the release manager. Thanks, Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r538287 - /jakarta/commons/proper/io/trunk/src/changes/changes.xml
Author: jochen Date: Tue May 15 12:43:51 2007 New Revision: 538287 URL: http://svn.apache.org/viewvc?view=revrev=538287 Log: Closing IO-115. Modified: jakarta/commons/proper/io/trunk/src/changes/changes.xml Modified: jakarta/commons/proper/io/trunk/src/changes/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/changes/changes.xml?view=diffrev=538287r1=538286r2=538287 == --- jakarta/commons/proper/io/trunk/src/changes/changes.xml (original) +++ jakarta/commons/proper/io/trunk/src/changes/changes.xml Tue May 15 12:43:51 2007 @@ -40,6 +40,10 @@ body release version=1.4 date=Not yet released + action dev=jochen type=fix issue=IO-115 +Some tests, which are implicitly assuming a Unix-like file +system, are now skipped on Windows. + /action action dev=jochen type=fix issue=IO-116 Created the FileCleaningTracker, basically a non-static version of the FileCleaner, which can be controlled by - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-115) FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available
[ https://issues.apache.org/jira/browse/IO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved IO-115. Resolution: Fixed After two months without reply, it seems valid to assume that my unintentional change didn'd cause any problems. Closing. FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available -- Key: IO-115 URL: https://issues.apache.org/jira/browse/IO-115 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3.1 Reporter: Joerg Schaible Fix For: 1.4 Some tests in FileUtilsCleanDirectoryTestCase try to delete files that have been set to read-only. This is expected to throw an exception. To set the read-only flag the method chmod() tries to execute the unix chmod command. If this fails (which should normally be the case on windows), the test is ignored. If Posix tools are available e.g. from Cygwin, MKS Toolkit, Microsoft's Posix Tools or similar ones the test fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r538289 - /jakarta/commons/proper/io/trunk/pom.xml
Author: jochen Date: Tue May 15 12:45:14 2007 New Revision: 538289 URL: http://svn.apache.org/viewvc?view=revrev=538289 Log: Upgrade to commons-parent 2. Modified: jakarta/commons/proper/io/trunk/pom.xml Modified: jakarta/commons/proper/io/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/pom.xml?view=diffrev=538289r1=538288r2=538289 == --- jakarta/commons/proper/io/trunk/pom.xml (original) +++ jakarta/commons/proper/io/trunk/pom.xml Tue May 15 12:45:14 2007 @@ -22,7 +22,7 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-parent/artifactId -version1/version +version2/version /parent modelVersion4.0.0/modelVersion groupIdcommons-io/groupId - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Going TLP?
On 5/2/07, Henri Yandell [EMAIL PROTECTED] wrote: (http://wiki.apache.org/jakarta-commons/TLPResolution) and secondly, anyone want to volunteer to chair things? As you are one of the most active persons here and also the one who is pushing this forward: How about yourself? :-) Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUpload errors
On 4/14/07, Kirill Maksimov [EMAIL PROTECTED] wrote: For example, on the page http://jakarta.apache.org/commons/fileupload/streaming.html is some outdated code Instead of 'item.openStream(stream)' should be 'item.getInputStream(Stream)'. Why do you think so? The interface FileItemStream doesn't have a method getInputStream? Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload]
On 4/4/07, Kate McSwiney [EMAIL PROTECTED] wrote: i was hoping somebody could help!i have connected to the server and i am able to read the files that are on the server, but now i want to upload a text file from the local host to the server and i am having abit of trouble. i have included the commons.io library but still seems to show errors for FileInputStream is = new FileInputStream( file ); or is there another way i should be uploading Create a bug report in http://issues.apache.org/jira and add relevant information. (Stack trace, log files, whatever you can think of) -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-74) [fileupload] Model FileUpload model to mimic javax.servlet.Request
[ https://issues.apache.org/jira/browse/FILEUPLOAD-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-74. --- Resolution: Won't Fix See my previous comment. [fileupload] Model FileUpload model to mimic javax.servlet.Request -- Key: FILEUPLOAD-74 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-74 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.0 Final Environment: Operating System: other Platform: All Reporter: Will Stranathan Priority: Minor Attachments: AbstractMultipartParameter.java, AbstractMultipartRequest.java, docmp.zip, FileUploadBase.java.patch, FileUploadBase.java.patch, FileUploadBase.java.patch, FileUploadFilter.java, FileUploadFilter.java, FileUploadRequest.java, FileUploadServletRequest.java, FileUploadServletRequestWrapper.java, filter.patch, StandardFileUploadServletRequest.java, TransientParameter.java, TransientRequest.java, UploadServlet.java Request to make the API more consistent with the getParameter(String name) and getParameterValues(String name) models of javax.servlet.Request. 1) For FileUpload to have getParemeter(String name) or getParameterValues (String name) - should implemented on top of the current API so that there are no backward-compatibility issues. 2) At LEAST working out a kink where multi-valued parameters actually appear as separate FileItems with the same value returned by getFieldName(). Example of new model: DiskFileUpload upload = new DiskFileUpload(); // Now, rather than applying an Iterator to parseRequest, // call the same method, but pull the individual items from the // DiskFileUpload object itself upload.parseRequest(request); FileItem myfile = (FileItem)upload.getParameter(myfile); // And this looks ALMOST like ServletRequest.getParameter(String name) String lastname = (String)upload.getParameter(lastname); String[] favoriteColours = upload.getParameterValues(favoritecolours); Alternately, a getFileItem(String name) method could be added in order to shield the user from having to cast the result of getParameter(String name) to a FileItem - and this same method could wrap ordinary field values in FileItems similarly to the way they are returned in the Iterator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r526346 - in /jakarta/commons/proper/fileupload/trunk/src: changes/changes.xml java/org/apache/commons/fileupload/MultipartStream.java
Author: jochen
Date: Fri Apr 6 19:04:55 2007
New Revision: 526346
URL: http://svn.apache.org/viewvc?view=revrev=526346
Log:
A MalformedStreamException is now thrown, if the size of an
items headers exceeds HEADER_PART_SIZE_MAX.
PR: FILEUPLOAD-116
Submitted-by: Amichai Rothman [EMAIL PROTECTED]
Modified:
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diffrev=526346r1=526345r2=526346
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Fri Apr 6
19:04:55 2007
@@ -55,6 +55,11 @@
due-to=Michael Macaluso due-to-email=[EMAIL PROTECTED]
Added support for accessing the file item headers.
/action
+ action dev=jochen type=fix issue=FILEUPLOAD-116
+ due-to=Amichai Rothman due-to-email=[EMAIL PROTECTED]
+A MalformedStreamException is now thrown, if the size of an items
+headers exceeds HEADER_PART_SIZE_MAX;
+ /action
/release
release version=1.2 date=2007-02-13
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java?view=diffrev=526346r1=526345r2=526346
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Fri Apr 6 19:04:55 2007
@@ -530,26 +530,27 @@
public String readHeaders()
throws MalformedStreamException {
int i = 0;
-byte[] b = new byte[1];
+byte b;
// to support multi-byte characters
ByteArrayOutputStream baos = new ByteArrayOutputStream();
-int sizeMax = HEADER_PART_SIZE_MAX;
int size = 0;
while (i HEADER_SEPARATOR.length) {
try {
-b[0] = readByte();
+b = readByte();
} catch (IOException e) {
throw new MalformedStreamException(Stream ended
unexpectedly);
}
-size++;
-if (b[0] == HEADER_SEPARATOR[i]) {
+if (++size HEADER_PART_SIZE_MAX) {
+throw new MalformedStreamException(
+Header section has more than + HEADER_PART_SIZE_MAX
++ bytes (maybe it is not properly terminated));
+}
+if (b == HEADER_SEPARATOR[i]) {
i++;
} else {
i = 0;
}
-if (size = sizeMax) {
-baos.write(b[0]);
-}
+baos.write(b);
}
String headers = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-116) max headers size is checked but improperly handled
[ https://issues.apache.org/jira/browse/FILEUPLOAD-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-116. Resolution: Fixed Applied, thank you. max headers size is checked but improperly handled -- Key: FILEUPLOAD-116 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-116 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2 Reporter: Amichai Rothman Priority: Minor Attachments: commons-fileupload-1.2-bug-max-header-size.patch MultipartStream enforces a maximum headers section size limit to prevent abuse. However, when the limit is reached, it silently discards the rest of the headers block, and returns an invalid partial headers string back to FileUploadBase. There it may, depending on the data and location of the cutoff, either return partial headers, return among them an invalid header, or throw an undocumented IllegalStateException. Instead, it should inform the caller that the headers are not properly processed - whether or not the oversized headers are due to a malformed stream or not, after cutting them off they certainly become malformed. The attached patch fixes this by having MultipartStream throw a MalformedStreamException when the limit is reached, as it does if other errors occur. This both leaves existing error handling (whomever catches such an exception) unchanged, and seems right since an extremely oversized header block is likely due to a malformed stream. This change further guarantees that if the exception is not thrown, the returned headers string must be valid, which simplifies processing in FileUploadBase (also included in the patch). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-131) MultipartStream always assumes transfer encoding to be BINARY
[ https://issues.apache.org/jira/browse/FILEUPLOAD-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487376 ] Jochen Wiedmann commented on FILEUPLOAD-131: Question posted to [EMAIL PROTECTED], see http://www.nabble.com/Handling-content-transfer-encoding-encoding-and-multipart-requests-with-httpcomponents-tf3539561.html MultipartStream always assumes transfer encoding to be BINARY - Key: FILEUPLOAD-131 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-131 Project: Commons FileUpload Issue Type: Bug Environment: N/A Reporter: Walco van Loon MultipartStream always assumes transfer encoding to be BINARY and does not handle 'Content-Transfer-Encoding' header at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-132) How do we retrieve the HTTP Headers in the request?
[ https://issues.apache.org/jira/browse/FILEUPLOAD-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-132. Resolution: Fixed I understand that you want the global HTTP request headers, as opposed to the per-file headers? If it is indeed the former, then you simply have to query the HttpServletRequest object, which you supplied yourself when creating the ServletFileUpload object. If it should be the latter, then your issue is a duplicate of FILEUPLOAD-130 which has already been resolved. How do we retrieve the HTTP Headers in the request? --- Key: FILEUPLOAD-132 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-132 Project: Commons FileUpload Issue Type: Wish Affects Versions: 1.2 Environment: Open Suse 10.1 Reporter: Lewis Choo Man I would like to retrieve the HTTP request headers from the org.apache.commons.fileupload.FileUpload class, while still being able to save any file that is embedded in the HTTP body. Is there a public method to do so? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Going TLP?
I've got a question: If we have commons.apache.org, what will be the difference to jakarta.apache.org, apart from the missing projects? Why do we expect that c.a.p will work, although we assume that j.a.p didn't? Thanks, Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] docs on doing maven2 releases
Hi, Torsten, On 4/4/07, Torsten Curdt [EMAIL PROTECTED] wrote: it looks like the repository from the profile is not getting selected. Instead the artifacts are getting copied in the default as far as I remember, -Prc was for uploading a snapshot release. You've got to use -Prelease. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
