[jira] [Commented] (MYFACES-3894) Make the duplicate client id check optional in development mode
[ https://issues.apache.org/jira/browse/MYFACES-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002865#comment-14002865 ] Adam Balazs commented on MYFACES-3894: -- Hi Thomas, It's the SSI-15 issue. Its created with the Survey Sampling International 's pro acc. Make the duplicate client id check optional in development mode --- Key: MYFACES-3894 URL: https://issues.apache.org/jira/browse/MYFACES-3894 Project: MyFaces Core Issue Type: Wish Reporter: Adam Balazs Priority: Minor Hi, I just wanted to start using JRebel with JSF, and found out that there are some issues with the JRebel - MyFaces - PrimeFaces combo. It seems that some of the PF components generates invalid component trees, which cause the MyFaces throwing DuplicateIdException in development mode. The strange thing is that we are using these components in production for more than 2 years now, and never noticed any issues with them, so I guess, the guys at PF worked this around very well. I've already reported this to them with my company's PRO account. As I browsed the code of PF I realized that fixing this behavior is not so easy and can take more time, so I just wonder if - as a quick fix - you can make the duplicate id check algorithm optional in development mode too. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3894) Make the duplicate client id check optional in development mode
[ https://issues.apache.org/jira/browse/MYFACES-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003039#comment-14003039 ] Leonardo Uribe commented on MYFACES-3894: - The problem here is it should not be duplicate ids in the component tree anytime. It has sense to disable this but only on production environment as a performance flag, once the developer knows that the app does not have duplicate id problems. Make the duplicate client id check optional in development mode --- Key: MYFACES-3894 URL: https://issues.apache.org/jira/browse/MYFACES-3894 Project: MyFaces Core Issue Type: Wish Reporter: Adam Balazs Priority: Minor Hi, I just wanted to start using JRebel with JSF, and found out that there are some issues with the JRebel - MyFaces - PrimeFaces combo. It seems that some of the PF components generates invalid component trees, which cause the MyFaces throwing DuplicateIdException in development mode. The strange thing is that we are using these components in production for more than 2 years now, and never noticed any issues with them, so I guess, the guys at PF worked this around very well. I've already reported this to them with my company's PRO account. As I browsed the code of PF I realized that fixing this behavior is not so easy and can take more time, so I just wonder if - as a quick fix - you can make the duplicate id check algorithm optional in development mode too. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MYFACES-3893) NullPointerException in ErrorPageWriter._writeAttributes [Line 1304]
[ https://issues.apache.org/jira/browse/MYFACES-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3893. - Resolution: Fixed Fix Version/s: 2.2.4 Assignee: Leonardo Uribe Thanks to Fabio for provide this patch. NullPointerException in ErrorPageWriter._writeAttributes [Line 1304] Key: MYFACES-3893 URL: https://issues.apache.org/jira/browse/MYFACES-3893 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.3 Environment: myfaces 2.2.3, Primefaces 5.0 Reporter: Fabio Assignee: Leonardo Uribe Priority: Trivial Fix For: 2.2.4 In org.apache.myfaces.renderkit.ErrorPageWriter on line 1304 I get a NullPinterException that is caught afterwards, I think it could be better to just check for m!=null instead of catching an exception and than doing nothing. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3894) Make the duplicate client id check optional in development mode
[ https://issues.apache.org/jira/browse/MYFACES-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003195#comment-14003195 ] Adam Balazs commented on MYFACES-3894: -- So it turned out that I had a wrong understanding of the p:tree component. It looks like that it holds UIData components, because it generates the rowkey into the clientId, but actually it is not. Instead the UITreeNode extends the UIColumn class, so it is not a namingContainer nor a UniqueIdVendor. Thanks for all your help and time. Make the duplicate client id check optional in development mode --- Key: MYFACES-3894 URL: https://issues.apache.org/jira/browse/MYFACES-3894 Project: MyFaces Core Issue Type: Wish Reporter: Adam Balazs Priority: Minor Hi, I just wanted to start using JRebel with JSF, and found out that there are some issues with the JRebel - MyFaces - PrimeFaces combo. It seems that some of the PF components generates invalid component trees, which cause the MyFaces throwing DuplicateIdException in development mode. The strange thing is that we are using these components in production for more than 2 years now, and never noticed any issues with them, so I guess, the guys at PF worked this around very well. I've already reported this to them with my company's PRO account. As I browsed the code of PF I realized that fixing this behavior is not so easy and can take more time, so I just wonder if - as a quick fix - you can make the duplicate id check algorithm optional in development mode too. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TOBAGO-1394) Avoid StringIndexOutOfBoundsException in ResourceServlet
[ https://issues.apache.org/jira/browse/TOBAGO-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003432#comment-14003432 ] Hudson commented on TOBAGO-1394: SUCCESS: Integrated in tobago-trunk #1179 (See [https://builds.apache.org/job/tobago-trunk/1179/]) TOBAGO-1394: Avoid StringIndexOutOfBoundsException in ResourceServlet (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1595129) * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/servlet/ResourceServlet.java Avoid StringIndexOutOfBoundsException in ResourceServlet Key: TOBAGO-1394 URL: https://issues.apache.org/jira/browse/TOBAGO-1394 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.0.0-beta-3 Reporter: Dennis Kieselhorst Assignee: Udo Schnurpfeil Priority: Trivial Fix For: 2.0.0-beta-4 May 07, 2014 3:23:12 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [ResourceServlet] in context with path [/intraday] threw exception java.lang.StringIndexOutOfBoundsException: String index out of range: 36 at java.lang.String.charAt(String.java:658) at org.apache.myfaces.tobago.servlet.ResourceServlet.doGet(ResourceServlet.java:132) at javax.servlet.http.HttpServlet.service(HttpServlet.java:635) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TOBAGO-1395) Set Content Type Options header to nosniff
[ https://issues.apache.org/jira/browse/TOBAGO-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003433#comment-14003433 ] Hudson commented on TOBAGO-1395: SUCCESS: Integrated in tobago-trunk #1179 (See [https://builds.apache.org/job/tobago-trunk/1179/]) TOBAGO-1395: Set Content Type Options header to nosniff - patch applied - doing some enhancements (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1595204) * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/ajax/AjaxUtils.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/config/TobagoConfig.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/ajax/AjaxResponseRenderer.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigFragment.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigImpl.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigParser.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigSorter.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/util/ResponseUtils.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/servlet/ResourceServlet.java * /myfaces/tobago/trunk/tobago-core/src/main/resources/org/apache/myfaces/tobago/config/tobago-config-2.0.xsd * /myfaces/tobago/trunk/tobago-core/src/test/java/org/apache/myfaces/tobago/internal/config/TobagoConfigParserUnitTest.java * /myfaces/tobago/trunk/tobago-core/src/test/resources/tobago-config-2.0.xml * /myfaces/tobago/trunk/tobago-core/src/test/resources/tobago-config-untidy-2.0.xml * /myfaces/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/java/org/apache/myfaces/tobago/renderkit/html/standard/standard/tag/PageRenderer.java Set Content Type Options header to nosniff -- Key: TOBAGO-1395 URL: https://issues.apache.org/jira/browse/TOBAGO-1395 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 2.0.0-beta-3 Reporter: Dennis Kieselhorst Priority: Minor Fix For: 2.0.0-beta-4, 2.0.0, 3.0.0-alpha-1 Attachments: TOBAGO-1395.patch Content sniffing allows malicious users to use polyglots (a file that is valid as multiple content types). This can be used to execute XSS attacks. The X-Content-Type-Options should be set to nosniff by default to avoid this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TOBAGO-1396) Integration of an HTML editor (WYSIWYG)
[ https://issues.apache.org/jira/browse/TOBAGO-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003434#comment-14003434 ] Hudson commented on TOBAGO-1396: SUCCESS: Integrated in tobago-trunk #1179 (See [https://builds.apache.org/job/tobago-trunk/1179/]) TOBAGO-1396: Integration of an HTML editor (WYSIWYG) - examples (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1595144) * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/35-wysiwyg * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/35-wysiwyg/00-tinymce * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/35-wysiwyg/00-tinymce/tinymce.js * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/35-wysiwyg/00-tinymce/tinymce.xhtml * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/35-wysiwyg/01-ckeditor * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/35-wysiwyg/01-ckeditor/ckeditor.xhtml * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/35-wysiwyg/01-ckeditor/demo-ckeditor.js * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/35-wysiwyg/wysiwyg-editor.xhtml TOBAGO-1396: Integration of an HTML editor (WYSIWYG) - removing old stuff (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1594907) * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/clientConfig/ThemeConfigViewController.java * /myfaces/tobago/trunk/tobago-extension/tobago-deprecation/src/main/java/org/apache/myfaces/tobago/renderkit/html/standard * /myfaces/tobago/trunk/tobago-extension/tobago-deprecation/src/main/java/org/apache/myfaces/tobago/renderkit/html/standard/standard * /myfaces/tobago/trunk/tobago-extension/tobago-deprecation/src/main/java/org/apache/myfaces/tobago/renderkit/html/standard/standard/tag * /myfaces/tobago/trunk/tobago-extension/tobago-deprecation/src/main/java/org/apache/myfaces/tobago/renderkit/html/standard/standard/tag/RichTextEditorRenderer.java * /myfaces/tobago/trunk/tobago-extension/tobago-sandbox/src/main/java/org/apache/myfaces/tobago/internal/taglib/sandbox/RichTextEditorTag.java * /myfaces/tobago/trunk/tobago-extension/tobago-sandbox/src/main/java/org/apache/myfaces/tobago/internal/taglib/sandbox/RichTextEditorTagDeclaration.java * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/image/tobago-richtext-edit.gif * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/image/tobago-richtext-editHover.gif * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/image/tobago-richtext-preview.gif * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/image/tobago-richtext-previewHover.gif * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago-theme-config.properties * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago.properties.xml * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago_de.properties.xml * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/style/tobago.css * /myfaces/tobago/trunk/tobago-theme/tobago-theme-speyside/src/main/less/org/apache/myfaces/tobago/renderkit/html/speyside/standard/style/tobago.less * /myfaces/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/java/org/apache/myfaces/tobago/renderkit/html/standard/standard/tag/RichTextEditorRenderer.java Integration of an HTML editor (WYSIWYG) --- Key: TOBAGO-1396 URL: https://issues.apache.org/jira/browse/TOBAGO-1396 Project: MyFaces Tobago Issue Type: New Feature Components: Demo Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Demonstration of the integration of an HTML editor. You can embed an HTML editor in Tobago easily, but there is no HTML editor component in Tobago. The reason is, there a many web-based editors in the web available, with different licenses, different features (and different bugs). So Tobago should not implement it's own HTML editor. But we show how an HTML
[jira] [Created] (PORTLETBRIDGE-234) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure.
Ross Clewley created PORTLETBRIDGE-234: -- Summary: remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure. Key: PORTLETBRIDGE-234 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-234 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0 Reporter: Ross Clewley Assignee: Michael Freedman Compiling the portlet bridge impl project on trunk produces the following compilation error. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project portlet-bridge-impl: Compilation failure [ERROR] /myfaces-trunk/impl/src/main/java/org/apache/myfaces/portlet/faces/bridge/scope/BridgeRequestScopeRepository.java:[55,28] error: name clash: remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure, yet neither overrides the other -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PORTLETBRIDGE-234) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure.
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003635#comment-14003635
]
Ross Clewley commented on PORTLETBRIDGE-234:
The signature of the remove method in BridgeRequestScopeRepository is
public BridgeRequestScope remove(String key)
Confusingly, BridgeRequestScope is not a class name in this context but a
generics type parameter name (this is somewhat misleading and probably ought to
be cleaned up):
public class BridgeRequestScopeRepositoryString, BridgeRequestScope extends
ConcurrentMapString, Object
extends LinkedHashMapString, BridgeRequestScope
Therefore BridgeRequestScope will be erased at runtime, leading to the conflict
with the superclass method from HashMap which is declared as:
public V remove(Object key) { }.
remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap
have the same erasure.
---
Key: PORTLETBRIDGE-234
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-234
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 3.0.0
Reporter: Ross Clewley
Assignee: Michael Freedman
Compiling the portlet bridge impl project on trunk produces the following
compilation error.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile
(default-compile) on project portlet-bridge-impl: Compilation failure
[ERROR]
/myfaces-trunk/impl/src/main/java/org/apache/myfaces/portlet/faces/bridge/scope/BridgeRequestScopeRepository.java:[55,28]
error: name clash: remove(String) in BridgeRequestScopeRepository and
remove(Object) in HashMap have the same erasure, yet neither overrides the
other
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PORTLETBRIDGE-234) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Clewley updated PORTLETBRIDGE-234: --- Status: Patch Available (was: Open) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure. --- Key: PORTLETBRIDGE-234 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-234 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0 Reporter: Ross Clewley Assignee: Michael Freedman Compiling the portlet bridge impl project on trunk produces the following compilation error. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project portlet-bridge-impl: Compilation failure [ERROR] /myfaces-trunk/impl/src/main/java/org/apache/myfaces/portlet/faces/bridge/scope/BridgeRequestScopeRepository.java:[55,28] error: name clash: remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure, yet neither overrides the other -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PORTLETBRIDGE-234) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Clewley updated PORTLETBRIDGE-234: --- Status: Open (was: Patch Available) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure. --- Key: PORTLETBRIDGE-234 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-234 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0 Reporter: Ross Clewley Assignee: Michael Freedman Compiling the portlet bridge impl project on trunk produces the following compilation error. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project portlet-bridge-impl: Compilation failure [ERROR] /myfaces-trunk/impl/src/main/java/org/apache/myfaces/portlet/faces/bridge/scope/BridgeRequestScopeRepository.java:[55,28] error: name clash: remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure, yet neither overrides the other -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PORTLETBRIDGE-234) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003668#comment-14003668 ] Ross Clewley edited comment on PORTLETBRIDGE-234 at 5/20/14 5:24 PM: - !portletbridge-234.patch! changes the signature of the remove method such that the key parameter is of type Object. The method can therefore override the superclass remove method. I've also changed the generics parameterization of the class so that it's not using BridgeRequestScope as a generics type parameter. The TCK test have been run and pass. was (Author: rclewley): This patch changes the signature of the remove method such that the key parameter is of type Object. The method can therefore override the superclass remove method. I've also changed the generics parameterization of the class so that it's not using BridgeRequestScope as a generics type parameter. The TCK test have been run and pass. remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure. --- Key: PORTLETBRIDGE-234 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-234 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0 Reporter: Ross Clewley Assignee: Michael Freedman Attachments: portletbridge-234.patch Compiling the portlet bridge impl project on trunk produces the following compilation error. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project portlet-bridge-impl: Compilation failure [ERROR] /myfaces-trunk/impl/src/main/java/org/apache/myfaces/portlet/faces/bridge/scope/BridgeRequestScopeRepository.java:[55,28] error: name clash: remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure, yet neither overrides the other -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PORTLETBRIDGE-234) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Clewley updated PORTLETBRIDGE-234: --- Status: Patch Available (was: Open) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure. --- Key: PORTLETBRIDGE-234 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-234 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0 Reporter: Ross Clewley Assignee: Michael Freedman Attachments: portletbridge-234.patch Compiling the portlet bridge impl project on trunk produces the following compilation error. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project portlet-bridge-impl: Compilation failure [ERROR] /myfaces-trunk/impl/src/main/java/org/apache/myfaces/portlet/faces/bridge/scope/BridgeRequestScopeRepository.java:[55,28] error: name clash: remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure, yet neither overrides the other -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PORTLETBRIDGE-234) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003668#comment-14003668 ] Ross Clewley edited comment on PORTLETBRIDGE-234 at 5/20/14 5:26 PM: - [^portletbridge-234.patch] changes the signature of the remove method such that the key parameter is of type Object. The method can therefore override the superclass remove method. I've also changed the generics parameterization of the class so that it's not using BridgeRequestScope as a generics type parameter. The TCK test have been run and pass. The patch is for trunk. The issue only affects trunk. was (Author: rclewley): [^portletbridge-234.patch] changes the signature of the remove method such that the key parameter is of type Object. The method can therefore override the superclass remove method. I've also changed the generics parameterization of the class so that it's not using BridgeRequestScope as a generics type parameter. The TCK test have been run and pass. remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure. --- Key: PORTLETBRIDGE-234 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-234 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0 Reporter: Ross Clewley Assignee: Michael Freedman Attachments: portletbridge-234.patch Compiling the portlet bridge impl project on trunk produces the following compilation error. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project portlet-bridge-impl: Compilation failure [ERROR] /myfaces-trunk/impl/src/main/java/org/apache/myfaces/portlet/faces/bridge/scope/BridgeRequestScopeRepository.java:[55,28] error: name clash: remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure, yet neither overrides the other -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PORTLETBRIDGE-234) remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003668#comment-14003668 ] Ross Clewley edited comment on PORTLETBRIDGE-234 at 5/20/14 5:25 PM: - [^portletbridge-234.patch] changes the signature of the remove method such that the key parameter is of type Object. The method can therefore override the superclass remove method. I've also changed the generics parameterization of the class so that it's not using BridgeRequestScope as a generics type parameter. The TCK test have been run and pass. was (Author: rclewley): !portletbridge-234.patch! changes the signature of the remove method such that the key parameter is of type Object. The method can therefore override the superclass remove method. I've also changed the generics parameterization of the class so that it's not using BridgeRequestScope as a generics type parameter. The TCK test have been run and pass. remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure. --- Key: PORTLETBRIDGE-234 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-234 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0 Reporter: Ross Clewley Assignee: Michael Freedman Attachments: portletbridge-234.patch Compiling the portlet bridge impl project on trunk produces the following compilation error. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project portlet-bridge-impl: Compilation failure [ERROR] /myfaces-trunk/impl/src/main/java/org/apache/myfaces/portlet/faces/bridge/scope/BridgeRequestScopeRepository.java:[55,28] error: name clash: remove(String) in BridgeRequestScopeRepository and remove(Object) in HashMap have the same erasure, yet neither overrides the other -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PORTLETBRIDGE-235) Security Vulnerability exposed via viewId related request parameters.
Ross Clewley created PORTLETBRIDGE-235: -- Summary: Security Vulnerability exposed via viewId related request parameters. Key: PORTLETBRIDGE-235 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-235 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Ross Clewley Assignee: Michael Freedman Priority: Critical The Portlet bridge allows the request parameters _jsfBridgeViewId, _jsfBridgeViewPath, __jpfbJSFTARGET and __jpfbJSFResTARGET to influence the viewId that is passed across a trust boundary to the JSF implementation. If the viewId is an absolute URL, that can result in that URL being retrieved and the document being executed as a facelet view definition file, allowing arbitrary java code to be executed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Deleted] (PORTLETBRIDGE-235) Security Vulnerability exposed via viewId related request parameters.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott O'Bryan deleted PORTLETBRIDGE-235: Security Vulnerability exposed via viewId related request parameters. -- Key: PORTLETBRIDGE-235 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-235 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Ross Clewley Assignee: Scott O'Bryan Priority: Critical The Portlet Bridge has a security vulnerability in which in which the request parameters _jsfBridgeViewId, __jpfbJSFTARGET and __jpfbJSFResTARGET are not restricted to valid filename characters. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2474) AutoSubmitUtils and XhtmlUtils can cause a thread deadlock
Andrew Robinson created TRINIDAD-2474: - Summary: AutoSubmitUtils and XhtmlUtils can cause a thread deadlock Key: TRINIDAD-2474 URL: https://issues.apache.org/jira/browse/TRINIDAD-2474 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson AutoSubmitUtils calls XhtmlScriptletFactory.registerAllScriptlets which in tern uses XhtmlUtils which has a static initializer that calls XhtmlScriptletFactory.registerAllScriptlets. If another thread uses XhtmlUtils, that initialization will wait on the AutoSubmitUtils which is waiting to use XhtmlUtils, deadlocking the threads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TRINIDAD-2474) AutoSubmitUtils and XhtmlUtils can cause a thread deadlock
[ https://issues.apache.org/jira/browse/TRINIDAD-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2474. --- Resolution: Fixed Fix Version/s: 2.1.1-core Assignee: Andrew Robinson Remove the redundant call to XhtmlScriptletFactory.registerAllScriptlets in AutoSubmitUtils. This will prevent the thread deadlock issue by ensuring that only XhtmlUtils calls XhtmlScriptletFactory.registerAllScriptlets Committed revision 1596427. AutoSubmitUtils and XhtmlUtils can cause a thread deadlock -- Key: TRINIDAD-2474 URL: https://issues.apache.org/jira/browse/TRINIDAD-2474 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core AutoSubmitUtils calls XhtmlScriptletFactory.registerAllScriptlets which in tern uses XhtmlUtils which has a static initializer that calls XhtmlScriptletFactory.registerAllScriptlets. If another thread uses XhtmlUtils, that initialization will wait on the AutoSubmitUtils which is waiting to use XhtmlUtils, deadlocking the threads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2475) org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION context parameter warning in non Production stage
Anand V Nath created TRINIDAD-2475:
--
Summary: org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION
context parameter warning in non Production stage
Key: TRINIDAD-2475
URL: https://issues.apache.org/jira/browse/TRINIDAD-2475
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Priority: Minor
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl
ViewHandlerImpl _checkTimestamp Apache Trinidad is running with time-stamp
checking enabled. This should not be used in a production environment. See the
org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION property in
WEB-INF/web.xml
This warning message is presented in non ProjectStage.Production mode also.
Further we coerce true for this parameter in development mode, which is not
correct according to the public documentation here:
http://myfaces.apache.org/trinidad/devguide/configuration.html
{quote}
org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION
If this parameter is enabled by setting to true, Apache Trinidad will
automatically check the modification date of your JSPs and skinning CSS files,
and discard saved state when they change; this makes development easier, but
adds overhead that should be avoided when your application is deployed. For
applications that run in ProjectStage.Production, the value is false and all
other stages use true as their default value. However, a user can override
the ProjectStage behavior by using this flag.
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TRINIDAD-2475) org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION context parameter warning in non Production stage
[
https://issues.apache.org/jira/browse/TRINIDAD-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand V Nath updated TRINIDAD-2475:
---
Status: Patch Available (was: Open)
org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION context parameter warning
in non Production stage
-
Key: TRINIDAD-2475
URL: https://issues.apache.org/jira/browse/TRINIDAD-2475
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Priority: Minor
Attachments: bug-17768650.patch
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl
ViewHandlerImpl _checkTimestamp Apache Trinidad is running with
time-stamp checking enabled. This should not be used in a production
environment. See the org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION
property in WEB-INF/web.xml
This warning message is logged in non ProjectStage.Production mode also.
Further we coerce true for this parameter in ProjectStage.Development mode,
which is not correct according to the public documentation here:
http://myfaces.apache.org/trinidad/devguide/configuration.html
{quote}
org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION
If this parameter is enabled by setting to true, Apache Trinidad will
automatically check the modification date of your JSPs and skinning CSS
files, and discard saved state when they change; this makes development
easier, but adds overhead that should be avoided when your application is
deployed. For applications that run in ProjectStage.Production, the value is
false and all other stages use true as their default value. However, a
user can override the ProjectStage behavior by using this flag.
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
