[jira] Created: (FILEUPLOAD-155) Fix documentation on resource clean up in conjunction with DiskFileItemFactory
Fix documentation on resource clean up in conjunction with DiskFileItemFactory -- Key: FILEUPLOAD-155 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-155 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2.1 Reporter: Jörg Heinicke 1. http://commons.apache.org/fileupload/using.html: return new DiskFileItemFactory(fileCleaningTracker, DiskFileItemFactory.DEFAULT_SIZE_THRESHOLD, repository); DiskFileItemFactory does not have such a constructor. 2. http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/disk/DiskFileItemFactory.html When using the DiskFileItemFactory, then you should consider the following: Temporary files are automatically deleted as soon as they are no longer needed. (More precisely, when the corresponding instance of File is garbage collected.) Cleaning up those files is done by an instance of FileCleaningTracker, and an associated thread. In a complex environment, for example in a web application, you should consider terminating this thread, for example, when your web application ends. See the section on Resource cleanup in the users guide of commons-fileupload. That's at least not precise. By default there is no FileCleaningTracker. 3. http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/disk/DiskFileItemFactory.html#getFileCleaningTracker() Returns: An instance of FileCleaningTracker, defaults to FileCleaner.getInstance(). Null, if temporary files aren't tracked. There is no default tracker. 4. http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/disk/DiskFileItemFactory.html#setFileCleaningTracker(org.apache.commons.io.FileCleaningTracker) Returns the tracker, which is responsible for deleting temporary files. Obviously wrong for setter. CopyPaste error from getter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FILEUPLOAD-155) Fix documentation on resource clean up in conjunction with DiskFileItemFactory
[ https://issues.apache.org/jira/browse/FILEUPLOAD-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated FILEUPLOAD-155: - Priority: Minor (was: Major) Fix documentation on resource clean up in conjunction with DiskFileItemFactory -- Key: FILEUPLOAD-155 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-155 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2.1 Reporter: Jörg Heinicke Priority: Minor 1. http://commons.apache.org/fileupload/using.html: return new DiskFileItemFactory(fileCleaningTracker, DiskFileItemFactory.DEFAULT_SIZE_THRESHOLD, repository); DiskFileItemFactory does not have such a constructor. 2. http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/disk/DiskFileItemFactory.html When using the DiskFileItemFactory, then you should consider the following: Temporary files are automatically deleted as soon as they are no longer needed. (More precisely, when the corresponding instance of File is garbage collected.) Cleaning up those files is done by an instance of FileCleaningTracker, and an associated thread. In a complex environment, for example in a web application, you should consider terminating this thread, for example, when your web application ends. See the section on Resource cleanup in the users guide of commons-fileupload. That's at least not precise. By default there is no FileCleaningTracker. 3. http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/disk/DiskFileItemFactory.html#getFileCleaningTracker() Returns: An instance of FileCleaningTracker, defaults to FileCleaner.getInstance(). Null, if temporary files aren't tracked. There is no default tracker. 4. http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/disk/DiskFileItemFactory.html#setFileCleaningTracker(org.apache.commons.io.FileCleaningTracker) Returns the tracker, which is responsible for deleting temporary files. Obviously wrong for setter. CopyPaste error from getter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JXPATH-120) ClassCastException in ServletRequestHandler.setProperty()
ClassCastException in ServletRequestHandler.setProperty() - Key: JXPATH-120 URL: https://issues.apache.org/jira/browse/JXPATH-120 Project: Commons JXPath Issue Type: Bug Reporter: Emmanuel Bourg Fix For: 1.3 Setting a property on a JXPath context bound to a ServletRequest throws a ClassCastException. The request parameter in ServletRequestHandler.setProperty() should be cast into a ServletRequestAndContext instead of a ServletRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-434) Add DateUtils.ceiling() method
[ https://issues.apache.org/jira/browse/LANG-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593821#action_12593821 ] Robert Scholte commented on LANG-434: - If you follow java's Math-api, it would be DateUtils.ceil(Date d, int field) and not ceiling. And ceil would give you the next full value, which means you need to add that last millisecond. Following your examples: if you had the datetime of 28 Mar 2002 13:45:01.231, if you passed with HOUR, it would return 28 Mar 2002 14:00:00.000. If this was passed with MONTH, it would return 1 Apr 2002 00:00:00.000. Add DateUtils.ceiling() method -- Key: LANG-434 URL: https://issues.apache.org/jira/browse/LANG-434 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.4 Reporter: Travis Reeder It would be nice to have a DateUtils.ceiling methods which would be the opposite of truncate (which is equivalent to floor) DateUtils.ceiling(Date d, int field); For example, if you had the datetime of 28 Mar 2002 13:45:01.231, if you passed with HOUR, it would return 28 Mar 2002 13:59:59.999. If this was passed with MONTH, it would return 31 Mar 2002 23:59:59.999. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JXPATH-120) ClassCastException in ServletRequestHandler.setProperty()
[ https://issues.apache.org/jira/browse/JXPATH-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved JXPATH-120. --- Resolution: Fixed Fix applied on thr trunk ClassCastException in ServletRequestHandler.setProperty() - Key: JXPATH-120 URL: https://issues.apache.org/jira/browse/JXPATH-120 Project: Commons JXPath Issue Type: Bug Reporter: Emmanuel Bourg Fix For: 1.3 Setting a property on a JXPath context bound to a ServletRequest throws a ClassCastException. The request parameter in ServletRequestHandler.setProperty() should be cast into a ServletRequestAndContext instead of a ServletRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
