[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]
[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]
[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]
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]
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]
[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]
[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]
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]
[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]
[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]
[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]
[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]
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]
[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]
Re: FileUpload Question
On 3/31/07, Thomas Vanck [EMAIL PROTECTED] wrote:
Hi !
I'm using FileUpload in my Java/Tomcat project. I've a problem, which
is I think mentioned in the FAQ, but no solution is offered there.
Searching the web and asking on boards didn't yield any results.
I've written the following code:
package requestHandler;
import javax.servlet.http.*;
import org.apache.commons.fileupload.*;
import org.apache.commons.fileupload.servlet.*;
import org.apache.commons.fileupload.disk.*;
import java.io.*;
import java.util.*;
public class PictureHandler extends HttpServlet {
static final long serialVersionUID = 6;
public void doPost( HttpServletRequest request , HttpServletResponse
response ) {
FileItemFactory ff = new DiskFileItemFactory();
ServletFileUpload upload = new ServletFileUpload( ff );
if( ServletFileUpload.isMultipartContent( request ) ) {
try {
List filelist = upload.parseRequest( request );
System.out.println( filelist.size(): +
filelist.size() );
Iterator it = filelist.iterator();
while( it.hasNext() ) {
FileItem pic = (FileItem) it.next();
String filename = pic.getName();
pic.write( new File(
/User/toom/Desktop/mypic/ , filename ) );
System.out.println(Datei
geschrieben...);
}
} catch ( Exception e ) { e.printStackTrace(); return; }
}
try {
request.getRequestDispatcher(upload_pictures.jsp).forward(
request , response ); return; } catch (Exception e) {
e.printStackTrace(); }
}
}
Now, when calling this servlet with a multipart/data form request, my
doPost tells me that filelist.size() has length 0. So I expect some
preprocessing is done with this request. But how can I tell Tomcat,
not to preprocess this data ?
Hi,
first of all, please be so kind to direkt such questions to
commons-dev@jakarta.apache.org or to a similar mailing list and not to
me privately.
Second, I assume that you are referring to version 1.2 of
commons-fileupload. If you have a look at the code of parseRequest(),
then you'll find the following:
FileItemIterator iter = getItemIterator(ctx);
List items = new ArrayList();
...
while (iter.hasNext()) {
FileItemStream item = iter.next();
FileItem fileItem = fac.createItem(item.getFieldName(),
item.getContentType(), item.isFormField(),
item.getName());
...
items.add(fileItem);
}
return items;
In other words, what the method returns is just a simple ArrayList,
without any magic. Reformulated again, filelist.size() is zero, if,
and only if, the Iterator returns nothing. If that's not the case then
you have detected an error in java.util.ArrayList, which I doubt.
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]
[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_12485460 ] Jochen Wiedmann commented on FILEUPLOAD-131: It is questionable, whether anyone is ready to add support for transfer encoding to the current framework. In other words, this issue can only be solved if someone takes the job to rewrite the parser to use an external library like Jakarta httpcore. 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-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-130. Resolution: Fixed Fix Version/s: 1.2.1 Assignee: Jochen Wiedmann Ok, following your suggestions #2 and #3. Add ability to get any header from the FileItem and FileItemStream interfaces - Key: FILEUPLOAD-130 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Michael Macaluso Assigned To: Jochen Wiedmann Priority: Minor Fix For: 1.2.1 Attachments: FILEUPLOAD-130.patch, FileUpload-130_1.patch, FileUpload-130_2.patch The FileItem and FileItemStream interfaces should have a way to return back any header that was encountered during the header parsing for an Item. Currently, from the FileItemStatus you can only get information from the 2 pre-defined headers Content-Type and Content-Disposition (Sort-of because the header can not be accessed raw). Other than the interface changes (including the change to pass them along in the FileItemFactory interface), it appears that all changes can be made within the FileUploadBase.java file. FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create the FileItemStreamImpl on lines 877 and 887 do not include the headers map. Further, the parseRequest method uses the FileItemStream interface to build the FileItem, so you should always have the headers in question. The reason for this request is that we have an application that is sending per-part headers (not precluded by the specs as far as we know of) to provide more information than name and content-type and using the FileUpload project means that we can no longer find out those header values. [Also, not completely sure, but I believe FileUploadBase.createItem(Map, boolean) on line 480 is not referenced anymore in this project.] -- 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] Updated: (FILEUPLOAD-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated FILEUPLOAD-130: --- Attachment: FILEUPLOAD-130.patch Please validate this alternate proposal, which is based on your last patch, but smaller. Add ability to get any header from the FileItem and FileItemStream interfaces - Key: FILEUPLOAD-130 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Michael Macaluso Priority: Minor Attachments: FILEUPLOAD-130.patch, FileUpload-130_1.patch, FileUpload-130_2.patch The FileItem and FileItemStream interfaces should have a way to return back any header that was encountered during the header parsing for an Item. Currently, from the FileItemStatus you can only get information from the 2 pre-defined headers Content-Type and Content-Disposition (Sort-of because the header can not be accessed raw). Other than the interface changes (including the change to pass them along in the FileItemFactory interface), it appears that all changes can be made within the FileUploadBase.java file. FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create the FileItemStreamImpl on lines 877 and 887 do not include the headers map. Further, the parseRequest method uses the FileItemStream interface to build the FileItem, so you should always have the headers in question. The reason for this request is that we have an application that is sending per-part headers (not precluded by the specs as far as we know of) to provide more information than name and content-type and using the FileUpload project means that we can no longer find out those header values. [Also, not completely sure, but I believe FileUploadBase.createItem(Map, boolean) on line 480 is not referenced anymore in this project.] -- 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] Updated: (FILEUPLOAD-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated FILEUPLOAD-130: --- Priority: Minor (was: Blocker) This is, of course, not a blocker. Add ability to get any header from the FileItem and FileItemStream interfaces - Key: FILEUPLOAD-130 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Michael Macaluso Priority: Minor The FileItem and FileItemStream interfaces should have a way to return back any header that was encountered during the header parsing for an Item. Currently, from the FileItemStatus you can only get information from the 2 pre-defined headers Content-Type and Content-Disposition (Sort-of because the header can not be accessed raw). Other than the interface changes (including the change to pass them along in the FileItemFactory interface), it appears that all changes can be made within the FileUploadBase.java file. FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create the FileItemStreamImpl on lines 877 and 887 do not include the headers map. Further, the parseRequest method uses the FileItemStream interface to build the FileItem, so you should always have the headers in question. The reason for this request is that we have an application that is sending per-part headers (not precluded by the specs as far as we know of) to provide more information than name and content-type and using the FileUpload project means that we can no longer find out those header values. [Also, not completely sure, but I believe FileUploadBase.createItem(Map, boolean) on line 480 is not referenced anymore in this project.] -- 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-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483136 ] Jochen Wiedmann commented on FILEUPLOAD-130: Have got a patch? Add ability to get any header from the FileItem and FileItemStream interfaces - Key: FILEUPLOAD-130 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Michael Macaluso Priority: Minor The FileItem and FileItemStream interfaces should have a way to return back any header that was encountered during the header parsing for an Item. Currently, from the FileItemStatus you can only get information from the 2 pre-defined headers Content-Type and Content-Disposition (Sort-of because the header can not be accessed raw). Other than the interface changes (including the change to pass them along in the FileItemFactory interface), it appears that all changes can be made within the FileUploadBase.java file. FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create the FileItemStreamImpl on lines 877 and 887 do not include the headers map. Further, the parseRequest method uses the FileItemStream interface to build the FileItem, so you should always have the headers in question. The reason for this request is that we have an application that is sending per-part headers (not precluded by the specs as far as we know of) to provide more information than name and content-type and using the FileUpload project means that we can no longer find out those header values. [Also, not completely sure, but I believe FileUploadBase.createItem(Map, boolean) on line 480 is not referenced anymore in this project.] -- 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-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483261 ] Jochen Wiedmann commented on FILEUPLOAD-130: The fact that this issue is important for you is not sufficient for making it a blocker. If the support of header information were as important as you consider it, then an enhancement request would be available long ago. As for creating the patch: Check out the software svn co https://svn.apache.org/repos/asf/jakarta/commons/proper/fileupload/trunk commons-fileupload change it as you like and then run svn diff See the subversion manuals for details. Add ability to get any header from the FileItem and FileItemStream interfaces - Key: FILEUPLOAD-130 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Michael Macaluso Priority: Minor The FileItem and FileItemStream interfaces should have a way to return back any header that was encountered during the header parsing for an Item. Currently, from the FileItemStatus you can only get information from the 2 pre-defined headers Content-Type and Content-Disposition (Sort-of because the header can not be accessed raw). Other than the interface changes (including the change to pass them along in the FileItemFactory interface), it appears that all changes can be made within the FileUploadBase.java file. FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create the FileItemStreamImpl on lines 877 and 887 do not include the headers map. Further, the parseRequest method uses the FileItemStream interface to build the FileItem, so you should always have the headers in question. The reason for this request is that we have an application that is sending per-part headers (not precluded by the specs as far as we know of) to provide more information than name and content-type and using the FileUpload project means that we can no longer find out those header values. [Also, not completely sure, but I believe FileUploadBase.createItem(Map, boolean) on line 480 is not referenced anymore in this project.] -- 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-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483302 ] Jochen Wiedmann commented on FILEUPLOAD-130: The Maven builds are the leading scripts and actually supported. The Ant build script is provided as a convenience for the user only and validated for release builds only. The download from m1-snapshot-repository is the right one. Add ability to get any header from the FileItem and FileItemStream interfaces - Key: FILEUPLOAD-130 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Michael Macaluso Priority: Minor The FileItem and FileItemStream interfaces should have a way to return back any header that was encountered during the header parsing for an Item. Currently, from the FileItemStatus you can only get information from the 2 pre-defined headers Content-Type and Content-Disposition (Sort-of because the header can not be accessed raw). Other than the interface changes (including the change to pass them along in the FileItemFactory interface), it appears that all changes can be made within the FileUploadBase.java file. FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create the FileItemStreamImpl on lines 877 and 887 do not include the headers map. Further, the parseRequest method uses the FileItemStream interface to build the FileItem, so you should always have the headers in question. The reason for this request is that we have an application that is sending per-part headers (not precluded by the specs as far as we know of) to provide more information than name and content-type and using the FileUpload project means that we can no longer find out those header values. [Also, not completely sure, but I believe FileUploadBase.createItem(Map, boolean) on line 480 is not referenced anymore in this project.] -- 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-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483429 ] Jochen Wiedmann commented on FILEUPLOAD-130: Well done. Nevertheless, I'd like to ask you a few things. The patches impact on the public API is drastical. Either we make a lot of constructors deprecated (which we just did for 1.2, when the streaming API was introduced) or we do indeed remove constructors. The latter decision won't survive a public vote on the commons-dev (see, for example, http://marc.info/?t=11636122114r=1w=2 ). I'd like to propose a different approach: Rather than extending the FileItem interface, let the implementations of FileItem and FileItemStream silently implement MutableFileItemHeaders. In FileUploadBase, you can check, whether the FileItemStream implements MutableFileItemHeaders. If it does, store the headers, otherwise discard them. (Note, that we are completely upwards compatible in that case.) Likewise, when creating the instance of FileItem. You'll note, that this will reduce the size of your patch greatly. Is that okay for you? If so, please resubmit a new patch. (And do not forget the docs! An entry to the FAQ should do, but some words in the User Guide won't harm.) Add ability to get any header from the FileItem and FileItemStream interfaces - Key: FILEUPLOAD-130 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Michael Macaluso Priority: Minor Attachments: FileUpload-130_1.patch The FileItem and FileItemStream interfaces should have a way to return back any header that was encountered during the header parsing for an Item. Currently, from the FileItemStatus you can only get information from the 2 pre-defined headers Content-Type and Content-Disposition (Sort-of because the header can not be accessed raw). Other than the interface changes (including the change to pass them along in the FileItemFactory interface), it appears that all changes can be made within the FileUploadBase.java file. FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create the FileItemStreamImpl on lines 877 and 887 do not include the headers map. Further, the parseRequest method uses the FileItemStream interface to build the FileItem, so you should always have the headers in question. The reason for this request is that we have an application that is sending per-part headers (not precluded by the specs as far as we know of) to provide more information than name and content-type and using the FileUpload project means that we can no longer find out those header values. [Also, not completely sure, but I believe FileUploadBase.createItem(Map, boolean) on line 480 is not referenced anymore in this project.] -- 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-129) MockHttpServletRequest doesn't compile against Servlet 2.4
[ https://issues.apache.org/jira/browse/FILEUPLOAD-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-129. Resolution: Fixed Applied MockHttpServletRequest doesn't compile against Servlet 2.4 -- Key: FILEUPLOAD-129 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-129 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Henri Yandell Assigned To: Henri Yandell Priority: Minor Fix For: 1.2.1 I think we lost this patch during the merge of the streaming code. Least I thought it had been applied. http://www.sourcelabs.com/dashboards/sash-1.2/patches/commons-fileupload-1.1-1/SUP-520.diff -- 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: [Collections] Maven help needed
On 3/20/07, Stephen Kestle [EMAIL PROTECTED] wrote: (http://svn.apache.org/repos/asf/jakarta/commons/proper/collections/branches/collections_jdk5_branch). * There's a project.xml instead of pom.xml * The pom version is 3 instead of 4 Looks like you need Maven 1, not 2. Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] fileupload failed.
On 3/19/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070319/fileupload.log I am sorry, but I haven't got a clue what's wrong. I have deployed an instance of commons-io-1.4-SNAPSHOT, so everything should be fine. Any ideas? Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (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:comment-tabpanel#action_12481882 ] Jochen Wiedmann commented on IO-115: Checking this in was unintentional. My plan was to discuss the issue before actually committing it. However, this issue is of course a good platform to discuss the necessary steps. I am ready to revert the change, if this should be desired. Otherwise, someone else should resove the issue. 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]
Re: [nightly build] fileupload failed.
On 3/17/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: /20070317/fileupload.log Where can I inspect this log file? Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] fileupload failed.
On 3/17/07, Henri Yandell [EMAIL PROTECTED] wrote: Probably because the nightly builds aren't deployed to the snapshots yet. Phil had to expire his key for doing that, and as an empty passphrase ssh is a bit of an ssh issue, I've avoided turning that back on. That seems to be the problem, indeed. I have deployed a snapshot of commons-io, hope that will work tomorrow. Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] fileupload failed.
On 3/16/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: /20070316/fileupload.log This is most possibly because I forgot to upgrade to commons-io-1.4-SNAPSHOT in the project.xml and build.xml files. Fixed. -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-116) Replace static FileCleaner methods
[ https://issues.apache.org/jira/browse/IO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved IO-116. Resolution: Fixed Applied. Henri, I did not pick up your suggestion to put the test case into FileCleaner itself. It seems to be to unusual to me and personally I do prefer a clean separation between test and tested code. If anyone starts this style elsewhere, I am ready to change that later. Replace static FileCleaner methods -- Key: IO-116 URL: https://issues.apache.org/jira/browse/IO-116 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 1.3.1 Reporter: Jochen Wiedmann Priority: Critical Fix For: 1.4 Attachments: commons-io-filecleaningtracker.patch, commons-io-filecleaningtracker.patch The attached patch aims to finally resolve the problems, which are named in IO-99, FILEUPLOAD-120, and FILEUPLOAD-125. I choosed a conservative strategy: Basically I copied the FileCleaner class to an instantiable class FileCleaningTracker with instance methods. The static FileCleaner methods are now implemented by a static instance of FileCleaningTracker. (The name FileCleaningTracker is, of course, questionable. The FileCleaningTestCase was also created by simply copying FileCleaner to FileCleaningTestCase. FileCleanerTestCase is now similarly implemented as a subclass of FileCleanerTestCase which uses the static instance of FileCleaner rather than a dynamically created instance. -- 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: Changing the groupId for commons-io
On 3/14/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I've failed to be convinced by any argument to change any groupId. It really doesn't seem to cause any harm leaving it as is, so lets leave it as is. Don't you believe that the Maven 1 conventions were changed with a good reason? It's absolutely plausible that the system of a root directory with hundreds or thousands of groupId's doesn't scale well. Apart from that, you are using a tool that draws its power from the conventions to which you adhere. So, why not adhere to it? Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Nag: IO-116
Hi, may I ask for a review and possible application of IO-116? I would like to make commons-fileupload to depend on it as soon as possible. Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nag: IO-116
On 3/13/07, Henri Yandell [EMAIL PROTECTED] wrote: Is the patch out of date? Should not be, there are no changes in commons-io since then. I have created a new patch. Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-116) Replace static FileCleaner methods
[ https://issues.apache.org/jira/browse/IO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated IO-116: --- Attachment: commons-io-filecleaningtracker.patch Same patch, next attempt Replace static FileCleaner methods -- Key: IO-116 URL: https://issues.apache.org/jira/browse/IO-116 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 1.3.1 Reporter: Jochen Wiedmann Priority: Critical Fix For: 1.4 Attachments: commons-io-filecleaningtracker.patch, commons-io-filecleaningtracker.patch The attached patch aims to finally resolve the problems, which are named in IO-99, FILEUPLOAD-120, and FILEUPLOAD-125. I choosed a conservative strategy: Basically I copied the FileCleaner class to an instantiable class FileCleaningTracker with instance methods. The static FileCleaner methods are now implemented by a static instance of FileCleaningTracker. (The name FileCleaningTracker is, of course, questionable. The FileCleaningTestCase was also created by simply copying FileCleaner to FileCleaningTestCase. FileCleanerTestCase is now similarly implemented as a subclass of FileCleanerTestCase which uses the static instance of FileCleaner rather than a dynamically created instance. -- 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]
Changing the groupId for commons-io
Hi, would anyone mind if I change the groupId of commons-io to org.apache.commons? Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
