Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.7DR#1
-
Fix Version/s: 1.8.2-EE-GA_P01, 1.8.3
-
Component/s: ICE-Components
-
Labels:None
-
Environment:All
-
ICEsoft Forum Reference:
Description
Users would prefer to have access to a stream for saving the uploaded file directly into a database, instead of to the filesystem.
The way that the commons upload code works, is that we receive the file in chunks, and probably wouldn't want to expose those intricacies to the application layer. So if the application could provide the ice:inputFile component an OutputStream with which to write to, then that would be the simplest approach.
The way that the commons upload code works, is that we receive the file in chunks, and probably wouldn't want to expose those intricacies to the application layer. So if the application could provide the ice:inputFile component an OutputStream with which to write to, then that would be the simplest approach.
Activity
Mark Collette
created issue -
Ken Fyten
made changes -
Field | Original Value | New Value |
---|---|---|
Fix Version/s | 1.7 [ 10080 ] |
Ken Fyten
made changes -
Fix Version/s | 1.7.1 [ 10122 ] | |
Fix Version/s | 1.7 [ 10080 ] |
Ken Fyten
made changes -
Fix Version/s | 1.7.1 [ 10122 ] |
Tyler Johnson
made changes -
Salesforce Case | [50070000009KEJz] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #20685 | Wed Feb 17 17:18:41 MST 2010 | mark.collette | |
Files Changed | ||||
ADD
/icefaces/scratchpads/patches/ICE-2198
|
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #20727 | Mon Feb 22 11:16:18 MST 2010 | mark.collette | |
Files Changed | ||||
MODIFY
/icefaces/scratchpads/patches/ICE-2198/icefaces/core/src/com/icesoft/faces/component/inputfile/UploadConfig.java
MODIFY /icefaces/scratchpads/patches/ICE-2198/icefaces/core/src/com/icesoft/faces/component/inputfile/FileInfo.java MODIFY /icefaces/scratchpads/patches/ICE-2198/icefaces/component/src/com/icesoft/faces/component/inputfile/InputFile.java MODIFY /icefaces/scratchpads/patches/ICE-2198/icefaces/core/src/com/icesoft/faces/webapp/http/core/UploadServer.java MODIFY /icefaces/scratchpads/patches/ICE-2198/icefaces/component-metadata/src/main/resources/conf/ice_cust_properties/cust-inputFile-props.xml MODIFY /icefaces/scratchpads/patches/ICE-2198/icefaces/core/src/com/icesoft/faces/component/inputfile/UploadStateHolder.java |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #20733 | Mon Feb 22 12:13:57 MST 2010 | mark.collette | |
Files Changed | ||||
ADD
/icefaces/scratchpads/patches/ICE-2198/icefaces/core/src/com/icesoft/faces/component/inputfile/FileUploadNullOutputStreamException.java
|
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #20769 | Tue Feb 23 16:24:29 MST 2010 | mark.collette | |
Files Changed | ||||
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/component/inputfile/UploadStateHolder.java
MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/component/inputfile/FileInfo.java MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/component/inputfile/UploadConfig.java MODIFY /icefaces/trunk/icefaces/component/src/com/icesoft/faces/component/inputfile/InputFile.java ADD /icefaces/trunk/icefaces/core/src/com/icesoft/faces/component/inputfile/FileUploadNullOutputStreamException.java MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/core/UploadServer.java MODIFY /icefaces/trunk/icefaces/component-metadata/src/main/resources/conf/ice_cust_properties/cust-inputFile-props.xml |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #20783 | Wed Feb 24 12:15:10 MST 2010 | mark.collette | Fix for BeanPropertiesTest |
Files Changed | ||||
MODIFY
/icefaces/trunk/icefaces/component/src/com/icesoft/faces/component/inputfile/InputFile.java
MODIFY /icefaces/trunk/icefaces/component-metadata/src/main/resources/conf/ice_cust_properties/cust-inputFile-props.xml |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #20789 | Wed Feb 24 17:40:34 MST 2010 | mark.collette | Fix for BeanPropertiesTest |
Files Changed | ||||
MODIFY
/icefaces/scratchpads/patches/ICE-2198/icefaces/component/src/com/icesoft/faces/component/inputfile/InputFile.java
MODIFY /icefaces/scratchpads/patches/ICE-2198/icefaces/component-metadata/src/main/resources/conf/ice_cust_properties/cust-inputFile-props.xml |
Mark Collette
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Fix Version/s | 1.8.2-EE-GA_P01 [ 10220 ] | |
Fix Version/s | 1.8.3 [ 10211 ] | |
Resolution | Fixed [ 1 ] | |
Assignee | Mark Collette [ mark.collette ] |
Mark Collette
made changes -
Summary | Allow inputFile to save file to database | Allow inputFile to save file to OutputStream |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Assignee | Mark Collette [ mark.collette ] |
Compared various methods of providing file information, while skipping the filesystem:
1. Writing to a byte[], which could then be set in the FileInfo structure, for the application to pickup in the actionListener. The main problem with this approach is the potentially large memory overhead on a user by user basis, which could easily blow the heap if there is a noticeable load of uploaders, particularly because of how the byte[] would have to be growable, and so the max memory usage could be several times larger than the number of users * max quota.
2. The InputStream to the socket data is passed on to the application, so it can read it. This is fraught with too many things that could go wrong. First off, the reading of that InputStream is what pushes the progress notification system, which makes the lifecycles happen. But the application would have to be given the InputStream within a lifecycle, leading to the likelihood of nested lifecycles, or a much more complicated usage model. Also, the ending lifecycle, that causes the iframe result to be sent, has to be done in a timely manner. Putting this under application control increases the likelihood of this not being done when it has to be.
3. The application provides an OutputStream, which could be a ByteArrayOutputStream, or one for a database BLOB/CLOB, or whatever it needs, to the InputFile component, via a ValueBinding attribute on the InputFile. The UploadServer would need to do an initial lifecycle to access this OutputStream, with progress=0. The existence of the OutputStream could be indicated, and accessed via the existing UploadConfig mechanism. Once the UploadServer has it, it would simply substitute that application OutputStream in place of whatever FileOutputStream it would have otherwise created. The quota mechanism would have to be rethought, since this currently relies on checking the written file size. Hopefully something could be done to not have actually written more than the quota to the application OutputStream or FileOutputStream, since that seems like a flaw in the quota that once can temporarily write more than the acceptable amount.