[jira] [Updated] (TRINIDAD-2466) FileDownLoadActionListener does not work with filenames with special characters on IE11
[ https://issues.apache.org/jira/browse/TRINIDAD-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-2466: Status: Patch Available (was: Open) FileDownLoadActionListener does not work with filenames with special characters on IE11 --- Key: TRINIDAD-2466 URL: https://issues.apache.org/jira/browse/TRINIDAD-2466 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Kentaro Kinebuchi Attachments: TRINIDAD-2466.patch When tr:fileDownloadActionListener is used and a file is downloaded which has special characters the filename comes out garbled and starts with =_UTF-8_. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2466) FileDownLoadActionListener does not work with filenames with special characters on IE11
Kentaro Kinebuchi created TRINIDAD-2466: --- Summary: FileDownLoadActionListener does not work with filenames with special characters on IE11 Key: TRINIDAD-2466 URL: https://issues.apache.org/jira/browse/TRINIDAD-2466 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Kentaro Kinebuchi When tr:fileDownloadActionListener is used and a file is downloaded which has special characters the filename comes out garbled and starts with =_UTF-8_. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2341) Incorrect assert expression in FileUploadConfiguratorImpl
Kentaro Kinebuchi created TRINIDAD-2341: --- Summary: Incorrect assert expression in FileUploadConfiguratorImpl Key: TRINIDAD-2341 URL: https://issues.apache.org/jira/browse/TRINIDAD-2341 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Kentaro Kinebuchi Test the inputFile component in an environment with debugging enabled so that assertions are enabled. Notice that you cannot upload a file and an assertion is thrown from Line 477: assert(properties != null); The expression is incorrect, it should be: assert(properties == null); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2341) Incorrect assert expression in FileUploadConfiguratorImpl
[ https://issues.apache.org/jira/browse/TRINIDAD-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-2341: Status: Patch Available (was: Open) Incorrect assert expression in FileUploadConfiguratorImpl - Key: TRINIDAD-2341 URL: https://issues.apache.org/jira/browse/TRINIDAD-2341 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Kentaro Kinebuchi Attachments: TRINIDAD-2341.patch Test the inputFile component in an environment with debugging enabled so that assertions are enabled. Notice that you cannot upload a file and an assertion is thrown from Line 477: assert(properties != null); The expression is incorrect, it should be: assert(properties == null); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2324) File uploads are very slow
Kentaro Kinebuchi created TRINIDAD-2324: --- Summary: File uploads are very slow Key: TRINIDAD-2324 URL: https://issues.apache.org/jira/browse/TRINIDAD-2324 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Kentaro Kinebuchi File uploads using the Trinidad File Upload Framework are very slow with uploads typically taking several minutes for files on the order of 100MB. It is substantially slower than FTPing an equivalent file. After profiling the application, most of the sloweness is from inefficiencies in MultipartFormHandler.java. After making a few changes to the method _readline() and also using a BufferedInputStream, the performance was doubled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2324) File uploads are very slow
[ https://issues.apache.org/jira/browse/TRINIDAD-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-2324: Status: Patch Available (was: Open) File uploads are very slow -- Key: TRINIDAD-2324 URL: https://issues.apache.org/jira/browse/TRINIDAD-2324 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Kentaro Kinebuchi Attachments: TRINIDAD-2324.patch File uploads using the Trinidad File Upload Framework are very slow with uploads typically taking several minutes for files on the order of 100MB. It is substantially slower than FTPing an equivalent file. After profiling the application, most of the sloweness is from inefficiencies in MultipartFormHandler.java. After making a few changes to the method _readline() and also using a BufferedInputStream, the performance was doubled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2316) Add support for adding a properties Map to UploadedFile
Kentaro Kinebuchi created TRINIDAD-2316: --- Summary: Add support for adding a properties Map to UploadedFile Key: TRINIDAD-2316 URL: https://issues.apache.org/jira/browse/TRINIDAD-2316 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 2.1.0-core Reporter: Kentaro Kinebuchi This enhancement is so that arbritrary properties can be specified for uploaded files. For example, a description field can be specified for a file. Support should be added for returning a map of properties from the UploadedFile object. Rather than adding new methods to the UploadedFile interface and breaking backward compatibility, the proposal is to create a new abstract class called AbstractUploadedFile with a getProperties() method which returns MapString, Object and have UploadedFileImpl extend this class. Any consumers of UploadedFiles can then check for if it extends this abstract class to see if properties are available. Also, custom file processors will need to return UploadedFile instances which extend AbstractUploadedFile if they need to have the framework add properties. The file properties will be submitted together with the file as a parameter on the form and the value will be marshalled into XML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2316) Add support for adding a properties Map to UploadedFile
[ https://issues.apache.org/jira/browse/TRINIDAD-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462377#comment-13462377 ] Kentaro Kinebuchi commented on TRINIDAD-2316: - Uploaded a patch which implements this functionality Add support for adding a properties Map to UploadedFile --- Key: TRINIDAD-2316 URL: https://issues.apache.org/jira/browse/TRINIDAD-2316 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 2.1.0-core Reporter: Kentaro Kinebuchi Attachments: Trinidad-2316.patch This enhancement is so that arbritrary properties can be specified for uploaded files. For example, a description field can be specified for a file. Support should be added for returning a map of properties from the UploadedFile object. Rather than adding new methods to the UploadedFile interface and breaking backward compatibility, the proposal is to create a new abstract class called AbstractUploadedFile with a getProperties() method which returns MapString, Object and have UploadedFileImpl extend this class. Any consumers of UploadedFiles can then check for if it extends this abstract class to see if properties are available. Also, custom file processors will need to return UploadedFile instances which extend AbstractUploadedFile if they need to have the framework add properties. The file properties will be submitted together with the file as a parameter on the form and the value will be marshalled into XML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2316) Add support for adding a properties Map to UploadedFile
[ https://issues.apache.org/jira/browse/TRINIDAD-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-2316: Status: Patch Available (was: Open) Add support for adding a properties Map to UploadedFile --- Key: TRINIDAD-2316 URL: https://issues.apache.org/jira/browse/TRINIDAD-2316 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 2.1.0-core Reporter: Kentaro Kinebuchi Attachments: Trinidad-2316.patch This enhancement is so that arbritrary properties can be specified for uploaded files. For example, a description field can be specified for a file. Support should be added for returning a map of properties from the UploadedFile object. Rather than adding new methods to the UploadedFile interface and breaking backward compatibility, the proposal is to create a new abstract class called AbstractUploadedFile with a getProperties() method which returns MapString, Object and have UploadedFileImpl extend this class. Any consumers of UploadedFiles can then check for if it extends this abstract class to see if properties are available. Also, custom file processors will need to return UploadedFile instances which extend AbstractUploadedFile if they need to have the framework add properties. The file properties will be submitted together with the file as a parameter on the form and the value will be marshalled into XML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2293) multi file upload does not get replicated in a High Availability environment
[ https://issues.apache.org/jira/browse/TRINIDAD-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-2293: Status: Patch Available (was: Open) multi file upload does not get replicated in a High Availability environment Key: TRINIDAD-2293 URL: https://issues.apache.org/jira/browse/TRINIDAD-2293 Project: MyFaces Trinidad Issue Type: Bug Components: Infrastructure Affects Versions: 2.0.2-core Environment: linux x86 Reporter: Kentaro Kinebuchi Attachments: TRINIDAD-2293.patch In multi file upload, the uploaded files are stored in the user's session before submit. In a HA environment, the session context which is replicated does not contain this file information so if the server goes down then the file data is lost in the replicated server. There are two specific issues which need to be handled in the code: 1. In WebLogic, unless the setAttribute() method is called on the session context, that attribute is not automatically replicated. Hence, all attributes which are updated during multi file upload and we want replicated have to specifically call that method. 2. WebLogic does not replicate all File objects stored in the context. Hence, the path to the temporary file created for each uploaded file needs to be saved in a String in the context so it is replicated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2293) multi file upload does not get replicated in a High Availability environment
[ https://issues.apache.org/jira/browse/TRINIDAD-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13420901#comment-13420901 ] Kentaro Kinebuchi commented on TRINIDAD-2293: - Recall that in multi file upload each file upload is a separate request. Ditto for chunked file transfer, each chunk is a separate request. We store the files chunks in the session until the user submits the form. This fix handles the scenario where lets say we have files A and B. The user add A and uploads it. It's a huge file so it takes 1 hr and the progress bar goes to 100% and finishes. Next, the user decides to add another file B. However, before he starts the upload the server fails and failover puts him on another server where his session is replicated. He adds B, the file is uploaded and then he submits the form. Without this HA fix he will see an upload failure for file A while file B will be ok. This means that not only will he have to spend another 1 hr uploading A again even though it was previously uploaded successfully and is available in the temporary directory on the server, he'll also be confused that the upload came back as Failed even though he saw it upload successfully earlier. We have to call setAttribute instead of getSessionMap().put because WLS only monitors calls to the setAttribute method: http://docs.oracle.com/cd/E15523_01/web./e13709/failover.htm#i1027876 See the section Use setAttribute to Change Session State multi file upload does not get replicated in a High Availability environment Key: TRINIDAD-2293 URL: https://issues.apache.org/jira/browse/TRINIDAD-2293 Project: MyFaces Trinidad Issue Type: Bug Components: Infrastructure Affects Versions: 2.0.2-core Environment: linux x86 Reporter: Kentaro Kinebuchi Attachments: Trinidad-2293.patch In multi file upload, the uploaded files are stored in the user's session before submit. In a HA environment, the session context which is replicated does not contain this file information so if the server goes down then the file data is lost in the replicated server. There are two specific issues which need to be handled in the code: 1. In WebLogic, unless the setAttribute() method is called on the session context, that attribute is not automatically replicated. Hence, all attributes which are updated during multi file upload and we want replicated have to specifically call that method. 2. WebLogic does not replicate all File objects stored in the context. Hence, the path to the temporary file created for each uploaded file needs to be saved in a String in the context so it is replicated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2293) multi file upload does not get replicated in a High Availability environment
[ https://issues.apache.org/jira/browse/TRINIDAD-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13420940#comment-13420940 ] Kentaro Kinebuchi commented on TRINIDAD-2293: - In my specific example the cost of replicating file A is trivial since the file presumably exceeds org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY so the cost is just the replication of a single String denoting the path to the temporary file location. However, there is a cost in the case the file is smaller than org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY. In that case, it would replicate the in-memory file itself and UPLOAD_MAX_MEMORY has a default value of 200KB so the cost is 200KB. The current code does not suffer from race conditions and this code doesn't result from session key clashes because we do not do handle more than one simultaneous upload request at a time, regardless of how many separate upload components we have and how many we have started uploading from. All subsequent upload requests are queued and are processed one by one. If we ran the lifecycle on file A after it completes and then ran the lifecycle on B again later then we'd have consecutive single file uploads rather than a multi-file upload. The reason why we have multi file uploads is because we are running the lifecycle on A and B in the same request. Regarding the server crash during an upload, that is a good point. That is one scenario which is not covered by the fix (and cannot be reasonably covered by any fix). However, I think in that scenario there is less chance of the user getting confused because the file upload would Fail as soon as the server goes down so it would be obvious to the user that something bad happened which requires the file to be re-uploaded. What is bad for the user about my example is that the user sees the Failure only after submit rather than during upload. multi file upload does not get replicated in a High Availability environment Key: TRINIDAD-2293 URL: https://issues.apache.org/jira/browse/TRINIDAD-2293 Project: MyFaces Trinidad Issue Type: Bug Components: Infrastructure Affects Versions: 2.0.2-core Environment: linux x86 Reporter: Kentaro Kinebuchi Attachments: Trinidad-2293.patch In multi file upload, the uploaded files are stored in the user's session before submit. In a HA environment, the session context which is replicated does not contain this file information so if the server goes down then the file data is lost in the replicated server. There are two specific issues which need to be handled in the code: 1. In WebLogic, unless the setAttribute() method is called on the session context, that attribute is not automatically replicated. Hence, all attributes which are updated during multi file upload and we want replicated have to specifically call that method. 2. WebLogic does not replicate all File objects stored in the context. Hence, the path to the temporary file created for each uploaded file needs to be saved in a String in the context so it is replicated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2293) multi file upload does not get replicated in a High Availability environment
Kentaro Kinebuchi created TRINIDAD-2293: --- Summary: multi file upload does not get replicated in a High Availability environment Key: TRINIDAD-2293 URL: https://issues.apache.org/jira/browse/TRINIDAD-2293 Project: MyFaces Trinidad Issue Type: Bug Components: Infrastructure Affects Versions: 2.0.2-core Environment: linux x86 Reporter: Kentaro Kinebuchi In multi file upload, the uploaded files are stored in the user's session before submit. In a HA environment, the session context which is replicated does not contain this file information so if the server goes down then the file data is lost in the replicated server. There are two specific issues which need to be handled in the code: 1. In WebLogic, unless the setAttribute() method is called on the session context, that attribute is not automatically replicated. Hence, all attributes which are updated during multi file upload and we want replicated have to specifically call that method. 2. WebLogic does not replicate all File objects stored in the context. Hence, the path to the temporary file created for each uploaded file needs to be saved in a String in the context so it is replicated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2293) multi file upload does not get replicated in a High Availability environment
[ https://issues.apache.org/jira/browse/TRINIDAD-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-2293: Status: Patch Available (was: Open) multi file upload does not get replicated in a High Availability environment Key: TRINIDAD-2293 URL: https://issues.apache.org/jira/browse/TRINIDAD-2293 Project: MyFaces Trinidad Issue Type: Bug Components: Infrastructure Affects Versions: 2.0.2-core Environment: linux x86 Reporter: Kentaro Kinebuchi Attachments: Trinidad-2293.patch In multi file upload, the uploaded files are stored in the user's session before submit. In a HA environment, the session context which is replicated does not contain this file information so if the server goes down then the file data is lost in the replicated server. There are two specific issues which need to be handled in the code: 1. In WebLogic, unless the setAttribute() method is called on the session context, that attribute is not automatically replicated. Hence, all attributes which are updated during multi file upload and we want replicated have to specifically call that method. 2. WebLogic does not replicate all File objects stored in the context. Hence, the path to the temporary file created for each uploaded file needs to be saved in a String in the context so it is replicated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2291) Binary incompatibility with RequestContext from 2.0.1
[ https://issues.apache.org/jira/browse/TRINIDAD-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-2291: Status: Patch Available (was: Open) Binary incompatibility with RequestContext from 2.0.1 - Key: TRINIDAD-2291 URL: https://issues.apache.org/jira/browse/TRINIDAD-2291 Project: MyFaces Trinidad Issue Type: Bug Components: Infrastructure Affects Versions: 2.1.0-core Reporter: Scott O'Bryan Assignee: Scott O'Bryan Priority: Minor Attachments: TRINIDAD-2291.patch The commit for TRINIDAD-2258 (txn 1330065) introduced a binary compatibility issue from 2.0.1. Essentially 2 method were added to the RequestContext for chunked file uploading. In order to catch new API's, I've been updating the clirr runner tests to ensure binary compatibility with 2.0.1. For this class to be strictly binary compatible, you need to provide a default implementation for these new methods in the abstract class. I understand that there are generally not many implementations of this class, but some mock object also needed to be changed because of this incompatibility and given the nature of these methods, I do not thing a default implementation would be too difficult. Can you please fix this and submit a patch so the clirr runner tests may be updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2289) function _pprControlCapture() causes an error in IE8 when it tries to focus on a PPR'd element
Kentaro Kinebuchi created TRINIDAD-2289: --- Summary: function _pprControlCapture() causes an error in IE8 when it tries to focus on a PPR'd element Key: TRINIDAD-2289 URL: https://issues.apache.org/jira/browse/TRINIDAD-2289 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Environment: Linux x86 Reporter: Kentaro Kinebuchi The PPR Blocking functionality works by blocking all mouse clicks between the start of a PPR update and the end. The element to return focus to, which is the activeElement, is saved off and then after the PPR update completes, focus is returned to it. The problem occurs when that element is PPR'd with another element. IE8 will throw and error and complain that the element is not focusable. While that error is not visible in the UI, it prevents further operations on the page. IE9 does not complain so this issue does not happen in that browser. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2289) function _pprControlCapture() causes an error in IE8 when it tries to focus on a PPR'd element
[ https://issues.apache.org/jira/browse/TRINIDAD-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13414478#comment-13414478 ] Kentaro Kinebuchi commented on TRINIDAD-2289: - Added a patch for this issue. The patch simply puts the focus() call in a try/catch block. function _pprControlCapture() causes an error in IE8 when it tries to focus on a PPR'd element -- Key: TRINIDAD-2289 URL: https://issues.apache.org/jira/browse/TRINIDAD-2289 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Attachments: TRINIDAD-2289.patch The PPR Blocking functionality works by blocking all mouse clicks between the start of a PPR update and the end. The element to return focus to, which is the activeElement, is saved off and then after the PPR update completes, focus is returned to it. The problem occurs when that element is PPR'd with another element. IE8 will throw and error and complain that the element is not focusable. While that error is not visible in the UI, it prevents further operations on the page. IE9 does not complain so this issue does not happen in that browser. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2054) Messages from exceptions in tr:fileDownloadActionListener are not displayed
[ https://issues.apache.org/jira/browse/TRINIDAD-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004816#comment-13004816 ] Kentaro Kinebuchi commented on TRINIDAD-2054: - Good point about the security risk. I updated the patch so that only exceptions from the bean method are included. Yes, there will be two messages. One will be the message from the exception thrown by the bean method and the other will be the current generic error message indicating that the download failed. The rationale for this patch is that currently there is no way for the user to know why the download failed since any exception thrown by the developer from within the bean method is not displayed to the user. With this patch we are giving the developer at least the ability to display a custom error message to the user. MessageFactory.getMessage() calls getLocalizedMessage() so the message should be localized. Messages from exceptions in tr:fileDownloadActionListener are not displayed --- Key: TRINIDAD-2054 URL: https://issues.apache.org/jira/browse/TRINIDAD-2054 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Environment: x86 Reporter: Kentaro Kinebuchi Priority: Minor Attachments: JIRA2054.patch When the bean method referenced by tr:fileDownloadActionListener throws an exception, what is displayed to the user is always a generic message The file was not downloaded or was not downloaded correctly.. The exception message itself is not displayed which makes it very hard for the user to know what actually went wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2054) Messages from exceptions in tr:fileDownloadActionListener are not displayed
[ https://issues.apache.org/jira/browse/TRINIDAD-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-2054: Status: Patch Available (was: Open) Messages from exceptions in tr:fileDownloadActionListener are not displayed --- Key: TRINIDAD-2054 URL: https://issues.apache.org/jira/browse/TRINIDAD-2054 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Environment: x86 Reporter: Kentaro Kinebuchi Priority: Minor When the bean method referenced by tr:fileDownloadActionListener throws an exception, what is displayed to the user is always a generic message The file was not downloaded or was not downloaded correctly.. The exception message itself is not displayed which makes it very hard for the user to know what actually went wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2054) Messages from exceptions in tr:fileDownloadActionListener are not displayed
Messages from exceptions in tr:fileDownloadActionListener are not displayed --- Key: TRINIDAD-2054 URL: https://issues.apache.org/jira/browse/TRINIDAD-2054 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Environment: x86 Reporter: Kentaro Kinebuchi Priority: Minor When the bean method referenced by tr:fileDownloadActionListener throws an exception, what is displayed to the user is always a generic message The file was not downloaded or was not downloaded correctly.. The exception message itself is not displayed which makes it very hard for the user to know what actually went wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2031) Error message displayed on upload failure from custom ChainedUploadedFileProcessor has extra full stop
Error message displayed on upload failure from custom
ChainedUploadedFileProcessor has extra full stop
--
Key: TRINIDAD-2031
URL: https://issues.apache.org/jira/browse/TRINIDAD-2031
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-1
Environment: Linux x86
Reporter: Kentaro Kinebuchi
Priority: Minor
Attachments: bug11677968.patch
Any error message thrown from a custom ChainedUploadedFileProcessor has a .
appended to it because the org.apache.myfaces.trinidad.UPLOAD_FAILURE_detail
string is {0}.. It should simply be {0} instead so that it doesn't make any
assumptions about the message which is being passed.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2031) Error message displayed on upload failure from custom ChainedUploadedFileProcessor has extra full stop
[
https://issues.apache.org/jira/browse/TRINIDAD-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kentaro Kinebuchi updated TRINIDAD-2031:
Status: Patch Available (was: Open)
Error message displayed on upload failure from custom
ChainedUploadedFileProcessor has extra full stop
--
Key: TRINIDAD-2031
URL: https://issues.apache.org/jira/browse/TRINIDAD-2031
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-1
Environment: Linux x86
Reporter: Kentaro Kinebuchi
Priority: Minor
Attachments: bug11677968.patch
Any error message thrown from a custom ChainedUploadedFileProcessor has a .
appended to it because the org.apache.myfaces.trinidad.UPLOAD_FAILURE_detail
string is {0}.. It should simply be {0} instead so that it doesn't make
any assumptions about the message which is being passed.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-1993) Setting tr:validateByteLength maximum property as an EL expression results in an error
[ https://issues.apache.org/jira/browse/TRINIDAD-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-1993: Status: Patch Available (was: Open) Setting tr:validateByteLength maximum property as an EL expression results in an error -- Key: TRINIDAD-1993 URL: https://issues.apache.org/jira/browse/TRINIDAD-1993 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Attachments: bug10432287.patch The stack trace is given below. The error is happening because the maximum property in org.apache.myfaces.trinidad.validator.ByteLengthValidator does not follow convention and is called maximumBytes instead of maximum. This is also causing issues with af:validateByteLength. java.lang.IllegalArgumentException: Invalid attribute name maximum at org.apache.myfaces.trinidad.validator.ValidatorUtils._getPropertyKey(ValidatorUtils.java:116) at org.apache.myfaces.trinidad.validator.ValidatorUtils.setValueExpression(ValidatorUtils.java:80) at org.apache.myfaces.trinidad.validator.ByteLengthValidator.setValueExpression(ByteLengthValidator.java:288) at org.apache.myfaces.trinidadinternal.taglib.validator.ValidateByteLengthTag._setProperties(ValidateByteLengthTag.java:82) at org.apache.myfaces.trinidadinternal.taglib.validator.ValidateByteLengthTag.createValidator(ValidateByteLengthTag.java:71) at org.apache.myfaces.trinidad.webapp.TrinidadValidatorELTag.doStartTag(TrinidadValidatorELTag.java:54) at jsp_servlet.__test1_jspx._jspx___tag4(__test1_jspx.java:293) at jsp_servlet.__test1_jspx._jspx___tag3(__test1_jspx.java:256) at jsp_servlet.__test1_jspx._jspx___tag2(__test1_jspx.java:205) at jsp_servlet.__test1_jspx._jspx___tag1(__test1_jspx.java:155) at jsp_servlet.__test1_jspx._jspx___tag0(__test1_jspx.java:104) at jsp_servlet.__test1_jspx._jspService(__test1_jspx.java:65) at weblogic.servlet.jsp.JspBase.service(JspBase.java:34) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:12 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1993) Setting tr:validateByteLength maximum property as an EL expression results in an error
Setting tr:validateByteLength maximum property as an EL expression results in an error -- Key: TRINIDAD-1993 URL: https://issues.apache.org/jira/browse/TRINIDAD-1993 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Attachments: bug10432287.patch The stack trace is given below. The error is happening because the maximum property in org.apache.myfaces.trinidad.validator.ByteLengthValidator does not follow convention and is called maximumBytes instead of maximum. This is also causing issues with af:validateByteLength. java.lang.IllegalArgumentException: Invalid attribute name maximum at org.apache.myfaces.trinidad.validator.ValidatorUtils._getPropertyKey(ValidatorUtils.java:116) at org.apache.myfaces.trinidad.validator.ValidatorUtils.setValueExpression(ValidatorUtils.java:80) at org.apache.myfaces.trinidad.validator.ByteLengthValidator.setValueExpression(ByteLengthValidator.java:288) at org.apache.myfaces.trinidadinternal.taglib.validator.ValidateByteLengthTag._setProperties(ValidateByteLengthTag.java:82) at org.apache.myfaces.trinidadinternal.taglib.validator.ValidateByteLengthTag.createValidator(ValidateByteLengthTag.java:71) at org.apache.myfaces.trinidad.webapp.TrinidadValidatorELTag.doStartTag(TrinidadValidatorELTag.java:54) at jsp_servlet.__test1_jspx._jspx___tag4(__test1_jspx.java:293) at jsp_servlet.__test1_jspx._jspx___tag3(__test1_jspx.java:256) at jsp_servlet.__test1_jspx._jspx___tag2(__test1_jspx.java:205) at jsp_servlet.__test1_jspx._jspx___tag1(__test1_jspx.java:155) at jsp_servlet.__test1_jspx._jspx___tag0(__test1_jspx.java:104) at jsp_servlet.__test1_jspx._jspService(__test1_jspx.java:65) at weblogic.servlet.jsp.JspBase.service(JspBase.java:34) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:12 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1950) Null pattern handling in DateTimeConverter is inconsistent
Null pattern handling in DateTimeConverter is inconsistent
--
Key: TRINIDAD-1950
URL: https://issues.apache.org/jira/browse/TRINIDAD-1950
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0.3-core
Environment: Linux x86
Reporter: Kentaro Kinebuchi
Priority: Minor
For null patterns, the getPattern() method in DateTimeConverter returns null in
non-Facelets and empty string in Facelets due to TRINIDAD-381. This is causing
inconsistent behavior depending on whether Facelets or non-Facelets is used.
Some of the code in DateTimeConverter does attempt to handle both null and
empty string patters such as in _getDateFormat() but most of the methods simply
check if the pattern is null. It is better to modify getPattern() to always
return null when pattern is either null or empty string.
One example of a problem this inconsistent handling of pattern is causing is
that when we have a DateTime component such as:
af:inputDate value=#{bindings.Hiredate.inputValue}
label=#{bindings.Hiredate.hints.label}
required=#{bindings.Hiredate.hints.mandatory}
shortDesc=#{bindings.Hiredate.hints.tooltip} id=id1
f:validator binding=#{bindings.Hiredate.validator}/
af:convertDateTime pattern=#{bindings.Hiredate.format}/
/af:inputDate
And pattern is null then depending on whether we are using Facelets or
non-Facelets when the user picks a date value it ends up getting formatted
differently. And it's happening because getJSPattern() in DateTimeConverter
only checks for null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1950) Null pattern handling in DateTimeConverter is inconsistent
[
https://issues.apache.org/jira/browse/TRINIDAD-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kentaro Kinebuchi updated TRINIDAD-1950:
Status: Patch Available (was: Open)
Null pattern handling in DateTimeConverter is inconsistent
--
Key: TRINIDAD-1950
URL: https://issues.apache.org/jira/browse/TRINIDAD-1950
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0.3-core
Environment: Linux x86
Reporter: Kentaro Kinebuchi
Priority: Minor
Attachments: bug08927847.patch
For null patterns, the getPattern() method in DateTimeConverter returns null
in non-Facelets and empty string in Facelets due to TRINIDAD-381. This is
causing inconsistent behavior depending on whether Facelets or non-Facelets
is used. Some of the code in DateTimeConverter does attempt to handle both
null and empty string patters such as in _getDateFormat() but most of the
methods simply check if the pattern is null. It is better to modify
getPattern() to always return null when pattern is either null or empty
string.
One example of a problem this inconsistent handling of pattern is causing is
that when we have a DateTime component such as:
af:inputDate value=#{bindings.Hiredate.inputValue}
label=#{bindings.Hiredate.hints.label}
required=#{bindings.Hiredate.hints.mandatory}
shortDesc=#{bindings.Hiredate.hints.tooltip}
id=id1
f:validator binding=#{bindings.Hiredate.validator}/
af:convertDateTime pattern=#{bindings.Hiredate.format}/
/af:inputDate
And pattern is null then depending on whether we are using Facelets or
non-Facelets when the user picks a date value it ends up getting formatted
differently. And it's happening because getJSPattern() in DateTimeConverter
only checks for null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1941) Required field message on af:selectonechoice component incorrect
Required field message on af:selectonechoice component incorrect -- Key: TRINIDAD-1941 URL: https://issues.apache.org/jira/browse/TRINIDAD-1941 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Priority: Trivial If you have af:selectOneChoice that is marked as being required and the user doesn't enter any value, the message thrown is: A selection is required. You must make at least one selection.. Instead the message should be: A selection is required. You must make a selection. The difference is the at least one part of the message. The fix is to update trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/MessageBundle.xrts with resource key=org.apache.myfaces.trinidad.UIXSelectOne.REQUIRED_detailYou must make a selection./resource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1941) Required field message on af:selectonechoice component incorrect
[ https://issues.apache.org/jira/browse/TRINIDAD-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-1941: Status: Patch Available (was: Open) Required field message on af:selectonechoice component incorrect -- Key: TRINIDAD-1941 URL: https://issues.apache.org/jira/browse/TRINIDAD-1941 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Priority: Trivial If you have af:selectOneChoice that is marked as being required and the user doesn't enter any value, the message thrown is: A selection is required. You must make at least one selection.. Instead the message should be: A selection is required. You must make a selection. The difference is the at least one part of the message. The fix is to update trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/MessageBundle.xrts with resource key=org.apache.myfaces.trinidad.UIXSelectOne.REQUIRED_detailYou must make a selection./resource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1941) Required field message on af:selectonechoice component incorrect
[ https://issues.apache.org/jira/browse/TRINIDAD-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-1941: Status: Open (was: Patch Available) Required field message on af:selectonechoice component incorrect -- Key: TRINIDAD-1941 URL: https://issues.apache.org/jira/browse/TRINIDAD-1941 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Priority: Trivial If you have af:selectOneChoice that is marked as being required and the user doesn't enter any value, the message thrown is: A selection is required. You must make at least one selection.. Instead the message should be: A selection is required. You must make a selection. The difference is the at least one part of the message. The fix is to update trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/MessageBundle.xrts with resource key=org.apache.myfaces.trinidad.UIXSelectOne.REQUIRED_detailYou must make a selection./resource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1941) Required field message on af:selectonechoice component incorrect
[ https://issues.apache.org/jira/browse/TRINIDAD-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-1941: Status: Patch Available (was: Open) Required field message on af:selectonechoice component incorrect -- Key: TRINIDAD-1941 URL: https://issues.apache.org/jira/browse/TRINIDAD-1941 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Priority: Trivial Attachments: bug10117191.patch If you have af:selectOneChoice that is marked as being required and the user doesn't enter any value, the message thrown is: A selection is required. You must make at least one selection.. Instead the message should be: A selection is required. You must make a selection. The difference is the at least one part of the message. The fix is to update trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/MessageBundle.xrts with resource key=org.apache.myfaces.trinidad.UIXSelectOne.REQUIRED_detailYou must make a selection./resource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
