[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12706086#action_12706086 ] Manfred Geiler commented on ORCHESTRA-40: - The LOG.error should be replaced by a LOG.debug in the TransactionTokenPhaseListener. (looks like a debugging remainder) A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705595#action_12705595 ] Manfred Geiler commented on ORCHESTRA-40: - MANAGED_BEAN_NAME = org.apache.myfaces.orchestra.TransactionToken is suboptimal because dots are (officially) not allowed within a managed bean name. Only underscores, letters and digits are allowed according to jsf spec. A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2154) mobile internet explorer version 6.12 issue
[
https://issues.apache.org/jira/browse/MYFACES-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Geiler updated MYFACES-2154:
Status: Patch Available (was: Open)
mobile internet explorer version 6.12 issue
---
Key: MYFACES-2154
URL: https://issues.apache.org/jira/browse/MYFACES-2154
Project: MyFaces Core
Issue Type: Improvement
Components: General
Environment: mobile internet explorer version 6.12
MyFaces v???
Reporter: Manfred Geiler
Tobias Bräuer reported the following issue:
Hello,
There is a problem with mobile internet explorer version 6.12 and
myfaces. The browser sends a Accept:
application/vnd.wap.mms-message;*/*. We solved that problem by adding
the following code in the class
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils at
line 1619. If used with tomahawk, the same fix is needed there.
I have no idea how your community process works, but feel free to add
the code to your repository.
if (contentTypeListString == null) {
FacesContext context =
FacesContext.getCurrentInstance();
if (context != null) {
contentTypeListString = (String)
context.getExternalContext()
.getRequestHeaderMap().get(Accept);
// There is a windows mobile IE client (6.12)
sending
// application/vnd.wap.mms-message;*/*
// This is a workaround ...
if (contentTypeListString
.startsWith(application/vnd.wap.mms-message;*/*)) {
contentTypeListString = */*;
}
}
if (contentTypeListString == null) {
if (log.isDebugEnabled())
log
.debug(No content
type list given, creating
HtmlResponseWriterImpl with default content type.);
contentTypeListString = HTML_CONTENT_TYPE;
}
}
Cheers,
Tobias Bräuer
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2154) mobile internet explorer version 6.12 issue
mobile internet explorer version 6.12 issue
---
Key: MYFACES-2154
URL: https://issues.apache.org/jira/browse/MYFACES-2154
Project: MyFaces Core
Issue Type: Improvement
Components: General
Environment: mobile internet explorer version 6.12
MyFaces v???
Reporter: Manfred Geiler
Tobias Bräuer reported the following issue:
Hello,
There is a problem with mobile internet explorer version 6.12 and
myfaces. The browser sends a Accept:
application/vnd.wap.mms-message;*/*. We solved that problem by adding
the following code in the class
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils at
line 1619. If used with tomahawk, the same fix is needed there.
I have no idea how your community process works, but feel free to add
the code to your repository.
if (contentTypeListString == null) {
FacesContext context = FacesContext.getCurrentInstance();
if (context != null) {
contentTypeListString = (String)
context.getExternalContext()
.getRequestHeaderMap().get(Accept);
// There is a windows mobile IE client (6.12)
sending
// application/vnd.wap.mms-message;*/*
// This is a workaround ...
if (contentTypeListString
.startsWith(application/vnd.wap.mms-message;*/*)) {
contentTypeListString = */*;
}
}
if (contentTypeListString == null) {
if (log.isDebugEnabled())
log
.debug(No content type
list given, creating
HtmlResponseWriterImpl with default content type.);
contentTypeListString = HTML_CONTENT_TYPE;
}
}
Cheers,
Tobias Bräuer
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-152) ResponseWriter.endDocument() abuse breaks ADF Faces
[ https://issues.apache.org/jira/browse/MYFACES-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler updated MYFACES-152: --- Status: Open (was: Patch Available) ResponseWriter.endDocument() abuse breaks ADF Faces --- Key: MYFACES-152 URL: https://issues.apache.org/jira/browse/MYFACES-152 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.0.9m9 Reporter: Adam Winer Assignee: Bruno Aranda Priority: Critical I've been shown some problems lately with MyFaces 1.0.9 and ADF Faces. The problems specifically trace to MyFaces's use of ResponseWriter.endDocument() to output Javascript. Since ADF Faces runs with its own RenderKit (and therefore its own ResponseWriter), this Javascript is getting dropped and not written. I'd recommend (both as JSF EG guy and ADF Faces guy) that this MyFaces code be moved *out* of ResponseWriter.endDocument(). Specifically: - ResponseWriter.endDocument() is not guaranteed to be called before the close of or even the close of , and therefore this script cannot be safely output at this point. It's quite likely that changes in JSF 1.2 will essentially guarantee that endDocument() is not called until the close of all output. - This is not really the intent of ResponseWriter.endDocument(). In HTML, it should be a no-op. It's there for more bizarre scenarios like a ResponseWriter outputting a SOAP envelope around a response. - It's breaking ADF Faces. :) A significantly cleaner way to output needed Javascript is to add it as needed from the Renderers that require it (using a request-scoped attribute to track if its been added already). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-152) ResponseWriter.endDocument() abuse breaks ADF Faces
[ https://issues.apache.org/jira/browse/MYFACES-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler updated MYFACES-152: --- Status: Patch Available (was: Reopened) ResponseWriter.endDocument() abuse breaks ADF Faces --- Key: MYFACES-152 URL: https://issues.apache.org/jira/browse/MYFACES-152 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.0.9m9 Reporter: Adam Winer Assignee: Bruno Aranda Priority: Critical I've been shown some problems lately with MyFaces 1.0.9 and ADF Faces. The problems specifically trace to MyFaces's use of ResponseWriter.endDocument() to output Javascript. Since ADF Faces runs with its own RenderKit (and therefore its own ResponseWriter), this Javascript is getting dropped and not written. I'd recommend (both as JSF EG guy and ADF Faces guy) that this MyFaces code be moved *out* of ResponseWriter.endDocument(). Specifically: - ResponseWriter.endDocument() is not guaranteed to be called before the close of or even the close of , and therefore this script cannot be safely output at this point. It's quite likely that changes in JSF 1.2 will essentially guarantee that endDocument() is not called until the close of all output. - This is not really the intent of ResponseWriter.endDocument(). In HTML, it should be a no-op. It's there for more bizarre scenarios like a ResponseWriter outputting a SOAP envelope around a response. - It's breaking ADF Faces. :) A significantly cleaner way to output needed Javascript is to add it as needed from the Renderers that require it (using a request-scoped attribute to track if its been added already). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1291) t:graphicImage doesnot generate XHTML complaint code
[ https://issues.apache.org/jira/browse/TOMAHAWK-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609182#action_12609182 ] Manfred Geiler commented on TOMAHAWK-1291: -- +1 for a strict (but sweet-tempered) behaviour that means: - log a nag warning - render a non-empty alt attribute with a meaningful default text if the developer omits the attribute (or provides an empty one) t:graphicImage doesnot generate XHTML complaint code Key: TOMAHAWK-1291 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1291 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.7-SNAPSHOT Reporter: Hazem Saleh Assignee: Hazem Saleh Fix For: 1.1.7-SNAPSHOT -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1803) noscript elements should be rendered for better WAI support
noscript elements should be rendered for better WAI support - Key: MYFACES-1803 URL: https://issues.apache.org/jira/browse/MYFACES-1803 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 1.2.0, 1.1.5 Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Minor According to the Web Accessibility Initiative (WAI) guidelines (http://www.w3.org/WAI/) for every script element there should also be a noscript element. Although standard JSF apps won't function without Javascript, it is possibly to write accessible apps if the developer provides alternative paths (outputLinks instead of commandLinks, etc.) through the application. Automated web accessibility check tools signal missing noscript elements as errors. For most script elements we render in the JSF core now, it might be difficult or even impossible (eg commandLink) to automatically render alternative code that would work with scripting disabled. But anyway, we should at least render noscript elements that tell the user why the app does not run in his browser. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1774) HtmlLinkRenderer should output amp; instead of as the url param separator within href attribute according to HTML Spec
[ https://issues.apache.org/jira/browse/MYFACES-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544732 ] Manfred Geiler commented on MYFACES-1774: - We should introduce a config param as suggested by Mario: http://www.nabble.com/Rendering-%22-amp-%22-instead-of-%22-%22-for-href-attribute-tf4849854.html HtmlLinkRenderer should output amp; instead of as the url param separator within href attribute according to HTML Spec - Key: MYFACES-1774 URL: https://issues.apache.org/jira/browse/MYFACES-1774 Project: MyFaces Core Issue Type: Bug Components: General, JSR-127, JSR-252 Affects Versions: 1.1.5, 1.2.0 Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Minor Currently a h:outputLink with nested f:param components is rendered as a href=somepage?foo=1bar=2.../a According to http://www.w3.org/TR/html401/ the character entity amp; should be used instead of : Authors should use amp; (ASCII decimal 38) instead of to avoid confusion with the beginning of a character reference (entity reference open delimiter). Authors should also use amp; in attribute values since character references are allowed within CDATA attribute values. Though current browsers seem to have no problem with characters within href attributes, this issue gets serious when using XHTML. Not using the character entity amp; instead of leads to invalid (not well-formed) XML data! Therefore I think we should fix this. BTW, the RI renders the wrong as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1774) HtmlLinkRenderer should output amp; instead of as the url param separator within href attribute according to HTML Spec
HtmlLinkRenderer should output amp; instead of as the url param separator within href attribute according to HTML Spec - Key: MYFACES-1774 URL: https://issues.apache.org/jira/browse/MYFACES-1774 Project: MyFaces Core Issue Type: Bug Components: General, JSR-127, JSR-252 Affects Versions: 1.2.0, 1.1.5 Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Minor Currently a h:outputLink with nested f:param components is rendered as a href=somepage?foo=1bar=2.../a According to http://www.w3.org/TR/html401/ the character entity amp; should be used instead of : Authors should use amp; (ASCII decimal 38) instead of to avoid confusion with the beginning of a character reference (entity reference open delimiter). Authors should also use amp; in attribute values since character references are allowed within CDATA attribute values. Though current browsers seem to have no problem with characters within href attributes, this issue gets serious when using XHTML. Not using the character entity amp; instead of leads to invalid (not well-formed) XML data! Therefore I think we should fix this. BTW, the RI renders the wrong as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1700) each h:form generated an input with same id=javax.faces.ViewState
[ https://issues.apache.org/jira/browse/MYFACES-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler resolved MYFACES-1700. - Resolution: Fixed Fix Version/s: 1.1.6-SNAPSHOT Assignee: Manfred Geiler This is a spec bug in JSF 1.2: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/render/ResponseStateManager.html#VIEW_STATE_PARAM However, the id is actually not needed (in MyFaces) unless some special (AJAX) components wanna do some Javascript magic. Therefore I added a (MyFaces specific) config parameter: org.apache.myfaces.RENDER_VIEWSTATE_ID The default value is false for backwards compatibility. So, adding context-param description Do not render the javax.jsf.ViewState id attribute for view state hidden inputs. Necessary for valid XHTML on multiple forms on one page. /description param-nameorg.apache.myfaces.RENDER_VIEWSTATE_ID/param-name param-valuefalse/param-value /context-param to your web.xml makes multiple form jsf pages XHTML valid. --Manfred each h:form generated an input with same id=javax.faces.ViewState Key: MYFACES-1700 URL: https://issues.apache.org/jira/browse/MYFACES-1700 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5 Environment: I am using Tomcat 5.5. inside of JBoss 4.0.2. Reporter: Marcus Beyer Assignee: Manfred Geiler Fix For: 1.1.6-SNAPSHOT On pages with more than one h:form, each one generates an element which has always the same id, which is invalid HTML. Looks like this: .../scriptinput type=hidden name=javax.faces.ViewState id=javax.faces.ViewState value=... //form I tried to put it inside f:subview as a workaround, but that did not work either (the ids did not change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-1700) each h:form generated an input with same id=javax.faces.ViewState
[ https://issues.apache.org/jira/browse/MYFACES-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543599 ] manolito edited comment on MYFACES-1700 at 11/19/07 8:43 AM: --- This is a spec bug in JSF 1.2: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/render/ResponseStateManager.html#VIEW_STATE_PARAM However, the id is actually not needed (in MyFaces) unless some special (AJAX) components wanna do some Javascript magic. Therefore I added a (MyFaces specific) config parameter: org.apache.myfaces.RENDER_VIEWSTATE_ID The default value is true for backwards compatibility. So, adding context-param description Do not render the javax.jsf.ViewState id attribute for view state hidden inputs. Necessary for valid XHTML on multiple forms on one page. /description param-nameorg.apache.myfaces.RENDER_VIEWSTATE_ID/param-name param-valuefalse/param-value /context-param to your web.xml makes multiple form jsf pages XHTML valid. --Manfred was (Author: manolito): This is a spec bug in JSF 1.2: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/render/ResponseStateManager.html#VIEW_STATE_PARAM However, the id is actually not needed (in MyFaces) unless some special (AJAX) components wanna do some Javascript magic. Therefore I added a (MyFaces specific) config parameter: org.apache.myfaces.RENDER_VIEWSTATE_ID The default value is false for backwards compatibility. So, adding context-param description Do not render the javax.jsf.ViewState id attribute for view state hidden inputs. Necessary for valid XHTML on multiple forms on one page. /description param-nameorg.apache.myfaces.RENDER_VIEWSTATE_ID/param-name param-valuefalse/param-value /context-param to your web.xml makes multiple form jsf pages XHTML valid. --Manfred each h:form generated an input with same id=javax.faces.ViewState Key: MYFACES-1700 URL: https://issues.apache.org/jira/browse/MYFACES-1700 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5 Environment: I am using Tomcat 5.5. inside of JBoss 4.0.2. Reporter: Marcus Beyer Assignee: Manfred Geiler Fix For: 1.1.6-SNAPSHOT On pages with more than one h:form, each one generates an element which has always the same id, which is invalid HTML. Looks like this: .../scriptinput type=hidden name=javax.faces.ViewState id=javax.faces.ViewState value=... //form I tried to put it inside f:subview as a workaround, but that did not work either (the ids did not change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-13) Switch to new MyFaces Master POM
Switch to new MyFaces Master POM Key: PORTLETBRIDGE-13 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-13 Project: MyFaces Portlet Bridge Issue Type: Task Components: General Affects Versions: 1.0.0-SNAPSHOT Reporter: Manfred Geiler Portlet Bridge should switch to new MyFaces Master POM: groupId=org.apache.myfaces artifactId=myfaces version=3-SNAPSHOT in the meantime (2 has some flaws) and switch to version 3 as soon as it is released. --Manfred -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1143) Tree2 renders nonconformant XHTML code
Tree2 renders nonconformant XHTML code -- Key: TOMAHAWK-1143 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1143 Project: MyFaces Tomahawk Issue Type: Bug Components: Tree2 Affects Versions: 1.1.6, 1.1.5 Reporter: Manfred Geiler Assignee: Manfred Geiler Fix For: 1.1.7-SNAPSHOT - background attribute not allowed for td - img without alt attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1763) forceId feature renders foo[idx] style ids when used within datatable
forceId feature renders foo[idx] style ids when used within datatable --- Key: MYFACES-1763 URL: https://issues.apache.org/jira/browse/MYFACES-1763 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.1.5, 1.1.4, 1.1.3 Reporter: Manfred Geiler Priority: Minor id attributes with square brackets are not allowed according to W3C strict html or xhtml the forceId feature should render foo.idx instead of foo[idx] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1764) always render trtd if a datatable has no rows to stay html/xhtml dtd conformant?
always render trtd if a datatable has no rows to stay html/xhtml dtd conformant? Key: MYFACES-1764 URL: https://issues.apache.org/jira/browse/MYFACES-1764 Project: MyFaces Core Issue Type: Improvement Components: General Reporter: Manfred Geiler Priority: Minor According to dtd (html and xhtml) a tbody must not be empty. it must at least have one tr which must at least have one td. And in xhtml each table must have a tbody. So, what should the dataTable render when there is a rowCount of 0? Perhaps just rendering tbodytrtd/td/tr/tbody is ok? Empty cells won't be rendered anyway. But is it really ok for all browsers? WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1764) always render trtd if a datatable has no rows to stay html/xhtml dtd conformant?
[ https://issues.apache.org/jira/browse/MYFACES-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541064 ] Manfred Geiler commented on MYFACES-1764: - Did some tests with Firefox 2.0.0.9 and IE 6. Looks ok and http://validator.w3.org/ is now happy with dataTables that render no rows. always render trtd if a datatable has no rows to stay html/xhtml dtd conformant? Key: MYFACES-1764 URL: https://issues.apache.org/jira/browse/MYFACES-1764 Project: MyFaces Core Issue Type: Improvement Components: General Reporter: Manfred Geiler Priority: Minor Attachments: always_tr_in_tbody.patch According to dtd (html and xhtml) a tbody must not be empty. it must at least have one tr which must at least have one td. And in xhtml each table must have a tbody. So, what should the dataTable render when there is a rowCount of 0? Perhaps just rendering tbodytrtd/td/tr/tbody is ok? Empty cells won't be rendered anyway. But is it really ok for all browsers? WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1764) always render trtd if a datatable has no rows to stay html/xhtml dtd conformant?
[ https://issues.apache.org/jira/browse/MYFACES-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler updated MYFACES-1764: Resolution: Fixed Fix Version/s: 1.2.1-SNAPSHOT 1.1.6-SNAPSHOT Assignee: Manfred Geiler Status: Resolved (was: Patch Available) applied the patch always render trtd if a datatable has no rows to stay html/xhtml dtd conformant? Key: MYFACES-1764 URL: https://issues.apache.org/jira/browse/MYFACES-1764 Project: MyFaces Core Issue Type: Improvement Components: General Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Minor Fix For: 1.1.6-SNAPSHOT, 1.2.1-SNAPSHOT Attachments: always_tr_in_tbody.patch According to dtd (html and xhtml) a tbody must not be empty. it must at least have one tr which must at least have one td. And in xhtml each table must have a tbody. So, what should the dataTable render when there is a rowCount of 0? Perhaps just rendering tbodytrtd/td/tr/tbody is ok? Empty cells won't be rendered anyway. But is it really ok for all browsers? WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1764) always render trtd if a datatable has no rows to stay html/xhtml dtd conformant?
[ https://issues.apache.org/jira/browse/MYFACES-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler updated MYFACES-1764: Status: Patch Available (was: Open) always render trtd if a datatable has no rows to stay html/xhtml dtd conformant? Key: MYFACES-1764 URL: https://issues.apache.org/jira/browse/MYFACES-1764 Project: MyFaces Core Issue Type: Improvement Components: General Reporter: Manfred Geiler Priority: Minor Attachments: always_tr_in_tbody.patch According to dtd (html and xhtml) a tbody must not be empty. it must at least have one tr which must at least have one td. And in xhtml each table must have a tbody. So, what should the dataTable render when there is a rowCount of 0? Perhaps just rendering tbodytrtd/td/tr/tbody is ok? Empty cells won't be rendered anyway. But is it really ok for all browsers? WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-99) Change Parent Pom to MyFaces instead of Apache
[ https://issues.apache.org/jira/browse/TRINIDAD-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler resolved TRINIDAD-99. Resolution: Duplicate TRINIDAD-801 Change Parent Pom to MyFaces instead of Apache -- Key: TRINIDAD-99 URL: https://issues.apache.org/jira/browse/TRINIDAD-99 Project: MyFaces Trinidad Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Priority: Minor update the poms to have a myfaces master pom as parent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-801) Trinidad should use the new MyFaces Master POM
Trinidad should use the new MyFaces Master POM -- Key: TRINIDAD-801 URL: https://issues.apache.org/jira/browse/TRINIDAD-801 Project: MyFaces Trinidad Issue Type: Task Components: Build Affects Versions: 1.0.4-core, 1.2.4-core Reporter: Manfred Geiler parent groupIdorg.apache/groupId artifactIdapache/artifactId version4/version /parent should be replaced by parent groupIdorg.apache.myfaces/groupId artifactIdmyfaces/artifactId version2/version /parent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-801) Trinidad should use the new MyFaces Master POM
[ https://issues.apache.org/jira/browse/TRINIDAD-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540428 ] Manfred Geiler commented on TRINIDAD-801: - today or tomorrow - depends on mirrors... Trinidad should use the new MyFaces Master POM -- Key: TRINIDAD-801 URL: https://issues.apache.org/jira/browse/TRINIDAD-801 Project: MyFaces Trinidad Issue Type: Task Components: Build Affects Versions: 1.0.4-core, 1.2.4-core Reporter: Manfred Geiler parent groupIdorg.apache/groupId artifactIdapache/artifactId version4/version /parent should be replaced by parent groupIdorg.apache.myfaces/groupId artifactIdmyfaces/artifactId version2/version /parent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-983) Cross-site scripting in autoscroll parameter
[ https://issues.apache.org/jira/browse/TOMAHAWK-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506446 ] Manfred Geiler commented on TOMAHAWK-983: - The HtmlRendererUtils class is different! Cross-site scripting in autoscroll parameter Key: TOMAHAWK-983 URL: https://issues.apache.org/jira/browse/TOMAHAWK-983 Project: MyFaces Tomahawk Issue Type: Bug Components: ExtensionsFilter Affects Versions: 1.1.1, 1.1.2, 1.1.3, 1.1.5 Environment: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7d Reporter: rajat Assignee: Manfred Geiler Priority: Critical Fix For: 1.1.6 The autoscroll parameter inserted in the requests is vulnerable to cross-site scripting attacks. If the POST request containing the autoscroll parameter is fuzzed to include something on the lines of autoScroll=0%2C275);//--/scriptIMG%20src=bla%20onerror=alert(document.cookie)script( , one can see the JavaScript pop-up. This appears to be a vulnerability throughout the JSF apps. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1666) HtmlResponseWriterImpl implements different encoding behaviour for the two writeText methods
HtmlResponseWriterImpl implements different encoding behaviour for the two writeText methods Key: MYFACES-1666 URL: https://issues.apache.org/jira/browse/MYFACES-1666 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5 Reporter: Manfred Geiler Assignee: Manfred Geiler HtmlResponseWriterImpl implements different behaviour for the two writeText methods: * writeText(Object value, String componentPropertyName) does not encode successive spaces and newlines * writeText(char cbuf[], int off, int len) does encode successive spaces and newlines RI does not encode in both variants. IMO both methods SHOULD encode successive spaces and newlines to render the corresponding HTML syntax (nbsp; and br/). Therefore we should (re)add this feature and make it switchable via a MyFaces Option STRICT_RI_MODE or something like that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1667) META-INF/faces-config.xml loading is done in wrong order
META-INF/faces-config.xml loading is done in wrong order Key: MYFACES-1667 URL: https://issues.apache.org/jira/browse/MYFACES-1667 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5 Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Minor Chapter 10.3.2 Application Startup Behavior of the spec says: Search for all resources named META-INF/faces-config.xml in the ServletContext resource paths for this web application, and load each as a JSF configuration resource (in reverse order of the order in which they are returned by getResources()). FacesConfigurator.feedClassloaderConfigurations does NOT iterate in reverse order. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-881) All NOTICE.txt and LICENSE.txt files and the related licenses dirs should be moved to subfolder META-INF
[ https://issues.apache.org/jira/browse/TOMAHAWK-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler resolved TOMAHAWK-881. - Resolution: Fixed Fix Version/s: 1.1.5 Assignee: Manfred Geiler All NOTICE.txt and LICENSE.txt files and the related licenses dirs should be moved to subfolder META-INF Key: TOMAHAWK-881 URL: https://issues.apache.org/jira/browse/TOMAHAWK-881 Project: MyFaces Tomahawk Issue Type: Task Affects Versions: 1.1.5-SNAPSHOT Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Minor Fix For: 1.1.5 All NOTICE.txt and LICENSE.txt files and the related licenses dirs should be moved to subfolder META-INF (Seems to be best practice now for all apache projects) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1025) NOTICE.txt and LICENSE.txt are missing in javadoc and tlddoc jars
NOTICE.txt and LICENSE.txt are missing in javadoc and tlddoc jars - Key: TOMAHAWK-1025 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1025 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.6, 1.1.5, 1.1.3, 1.1.2, 1.1.1 Reporter: Manfred Geiler Assignee: Manfred Geiler -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1665) Use remote-resources maven plugin for NOTICE.txt and LICENSE.txt
Use remote-resources maven plugin for NOTICE.txt and LICENSE.txt Key: MYFACES-1665 URL: https://issues.apache.org/jira/browse/MYFACES-1665 Project: MyFaces Core Issue Type: Improvement Components: build process Reporter: Manfred Geiler Assignee: Manfred Geiler Instead of having hundreds of spread NOTICE.txt and LICENSE.txt files we should use the remote-resources plugin like Trinidad does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TOMAHAWK-983) Cross-site scripting in autoscroll parameter
[ https://issues.apache.org/jira/browse/TOMAHAWK-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504163 ] Manfred Geiler edited comment on TOMAHAWK-983 at 6/15/07 12:02 AM: --- Thanks rajat for submitting this issue. Sorry for the delay. A priority Critical would have given this issue more attention... was: Thanks rajat for submitting this issue. Sorry for the delay. A priority Critical would have given this one more attention... Cross-site scripting in autoscroll parameter Key: TOMAHAWK-983 URL: https://issues.apache.org/jira/browse/TOMAHAWK-983 Project: MyFaces Tomahawk Issue Type: Bug Components: ExtensionsFilter Affects Versions: 1.1.1, 1.1.2, 1.1.3, 1.1.5 Environment: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7d Reporter: rajat Assignee: Manfred Geiler Priority: Critical Fix For: 1.1.6 The autoscroll parameter inserted in the requests is vulnerable to cross-site scripting attacks. If the POST request containing the autoscroll parameter is fuzzed to include something on the lines of autoScroll=0%2C275);//--/scriptIMG%20src=bla%20onerror=alert(document.cookie)script( , one can see the JavaScript pop-up. This appears to be a vulnerability throughout the JSF apps. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1024) t:commandButton does not cause rendering of oamSetHiddenInput javascript function
t:commandButton does not cause rendering of oamSetHiddenInput javascript function - Key: TOMAHAWK-1024 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1024 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended CommandLink/CommandButton Affects Versions: 1.1.5, 1.1.6 Reporter: Manfred Geiler The Extended CommandButton does not cause the oamSetHiddenInput javascript function to be rendered while the Extended CommandLink does. The oamSetHiddenInput function is necessary for the autoscroll feature to work. You may verify with the attached test page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1021) CVE-2007-3101
[ https://issues.apache.org/jira/browse/TOMAHAWK-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler resolved TOMAHAWK-1021. -- Resolution: Duplicate TOMAHAWK-983 CVE-2007-3101 - Key: TOMAHAWK-1021 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1021 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.1, 1.1.2, 1.1.3, 1.1.5, 1.1.6, 1.1.7-SNAPSHOT Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Critical Fix For: 1.1.6 Security issue - public disclosure after fix release 1.1.6 is published iDefense Vendor Notification [IDEF2542] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-983) Cross-site scripting in autoscroll parameter
[ https://issues.apache.org/jira/browse/TOMAHAWK-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504163 ] Manfred Geiler commented on TOMAHAWK-983: - Thanks rajat for submitting this issue. Sorry for the delay. A priority Critical would have given this one more attention... Cross-site scripting in autoscroll parameter Key: TOMAHAWK-983 URL: https://issues.apache.org/jira/browse/TOMAHAWK-983 Project: MyFaces Tomahawk Issue Type: Bug Components: ExtensionsFilter Affects Versions: 1.1.1, 1.1.2, 1.1.3, 1.1.5 Environment: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7d Reporter: rajat Assignee: Manfred Geiler Priority: Critical Fix For: 1.1.6 The autoscroll parameter inserted in the requests is vulnerable to cross-site scripting attacks. If the POST request containing the autoscroll parameter is fuzzed to include something on the lines of autoScroll=0%2C275);//--/scriptIMG%20src=bla%20onerror=alert(document.cookie)script( , one can see the JavaScript pop-up. This appears to be a vulnerability throughout the JSF apps. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-983) Cross-site scripting in autoscroll parameter
[ https://issues.apache.org/jira/browse/TOMAHAWK-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler resolved TOMAHAWK-983. - Resolution: Fixed Cross-site scripting in autoscroll parameter Key: TOMAHAWK-983 URL: https://issues.apache.org/jira/browse/TOMAHAWK-983 Project: MyFaces Tomahawk Issue Type: Bug Components: ExtensionsFilter Affects Versions: 1.1.1, 1.1.2, 1.1.3, 1.1.5 Environment: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7d Reporter: rajat Assignee: Manfred Geiler Priority: Critical Fix For: 1.1.6 The autoscroll parameter inserted in the requests is vulnerable to cross-site scripting attacks. If the POST request containing the autoscroll parameter is fuzzed to include something on the lines of autoScroll=0%2C275);//--/scriptIMG%20src=bla%20onerror=alert(document.cookie)script( , one can see the JavaScript pop-up. This appears to be a vulnerability throughout the JSF apps. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1021) iDefense Vendor Notification [IDEF2542]
iDefense Vendor Notification [IDEF2542] --- Key: TOMAHAWK-1021 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1021 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5, 1.1.3, 1.1.2, 1.1.1, 1.1.6, 1.1.7-SNAPSHOT Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Critical Fix For: 1.1.6 Security issue - public disclosure after fix release 1.1.6 is published -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1662) Move autoscroll feature from shared HtmlRendererUtils to Tomahawk
Move autoscroll feature from shared HtmlRendererUtils to Tomahawk - Key: MYFACES-1662 URL: https://issues.apache.org/jira/browse/MYFACES-1662 Project: MyFaces Core Issue Type: Task Components: General Affects Versions: 1.1.5, 1.1.6-SNAPSHOT, 1.1.6, 1.2.0-SNAPSHOT Reporter: Manfred Geiler Priority: Minor The class org.apache.myfaces.shared.renderkit.html.HtmlRendererUtils implements the javascript rendering for the Autoscroll feature. Since this is only used by the Tomahawk implementation the related code should be moved to some Tomahawk utility class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1630) Update the website now that Trinidad is out of incubator
[ https://issues.apache.org/jira/browse/MYFACES-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496083 ] Manfred Geiler commented on MYFACES-1630: - Adam, you should now have commit rights. Feel free to apply this patch yourself... :) Update the website now that Trinidad is out of incubator Key: MYFACES-1630 URL: https://issues.apache.org/jira/browse/MYFACES-1630 Project: MyFaces Core Issue Type: Task Components: website Reporter: Adam Winer Assigned To: Adam Winer Attachments: site.patch Trinidad's out of incubator, and needs to be added as a project link. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-944) Maven assembly build should also create a source archive
Maven assembly build should also create a source archive Key: TOMAHAWK-944 URL: https://issues.apache.org/jira/browse/TOMAHAWK-944 Project: MyFaces Tomahawk Issue Type: Improvement Components: Examples Affects Versions: 1.1.3, 1.1.2, 1.1.1, 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT, 1.1.5 Reporter: Manfred Geiler Assigned To: Manfred Geiler Fix For: 1.1.6-SNAPSHOT Currently the examples assembly build only creates the binary archive (containing the war). A tomahawk-examples-1.1.5-SNAPSHOT-src.zip in addition to that would be nice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1534) Add rat-maven-plugin to the build process
Add rat-maven-plugin to the build process - Key: MYFACES-1534 URL: https://issues.apache.org/jira/browse/MYFACES-1534 Project: MyFaces Core Issue Type: Improvement Components: build process Affects Versions: 1.1.6-SNAPSHOT Reporter: Manfred Geiler Assigned To: Manfred Geiler http://mojo.codehaus.org/rat-maven-plugin/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1481) MyFacesGenericPortlet does not work in a cluster
[ https://issues.apache.org/jira/browse/MYFACES-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler resolved MYFACES-1481. - Resolution: Fixed Fix Version/s: (was: 1.1.4.1-SNAPSHOT) 1.1.5-SNAPSHOT Stan, this one is fixed for 1.1.5, right? MyFacesGenericPortlet does not work in a cluster Key: MYFACES-1481 URL: https://issues.apache.org/jira/browse/MYFACES-1481 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 1.1.4 Reporter: John Gilbert Assigned To: Stan Silvert Fix For: 1.1.5-SNAPSHOT The problem is that ServletFacesContextImpl is not serializable and processAction places one in the session. Here is a link to a discussion on the JBoss Forum. http://jboss.org/index.html?module=bbop=viewtopicp=3981103#3981103 Here is a link to the workaround I created. http://taylor.cvs.sourceforge.net/taylor/taylor/commons/src/main/java/net/taylor/portlet/MyFacesGenericPortlet.java?view=markup -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-765) t:inputCalendar/ stops working
[ https://issues.apache.org/jira/browse/MYFACES-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472925 ] Manfred Geiler commented on MYFACES-765: This is no longer an issue, is it? t:inputCalendar/ stops working Key: MYFACES-765 URL: https://issues.apache.org/jira/browse/MYFACES-765 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.1 Environment: JDK 1.4.2, Unix, Windows, Resin 3.0.14 Reporter: Boris Kovalenko Assigned To: Martin Marinschek Priority: Critical Today, 31.10.2005 t:inputCalendar stops working with exception. Not sure but may be this is regarding to TZ change? [2005-10-31 10:38:59.315] Error Rendering View [2005-10-31 10:38:59.315] java.lang.IllegalStateException: Client-id : calendar_1130737139296_link is duplicated in the faces tree. [2005-10-31 10:38:59.315] at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:241) [2005-10-31 10:38:59.315] at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255) [2005-10-31 10:38:59.315] at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255) [2005-10-31 10:38:59.315] at org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:204) [2005-10-31 10:38:59.315] at org.apache.myfaces.renderkit.html.util.DummyFormUtils.writeDummyForm(DummyFormUtils.java:111) [2005-10-31 10:38:59.315] at org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl.endDocument(HtmlResponseWriterImpl.java:156) [2005-10-31 10:38:59.315] at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:449) [2005-10-31 10:38:59.315] at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:352) [2005-10-31 10:38:59.315] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:107) [2005-10-31 10:38:59.315] at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:99) [2005-10-31 10:38:59.315] at org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) [2005-10-31 10:38:59.315] at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70) [2005-10-31 10:38:59.315] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:163) [2005-10-31 10:38:59.315] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:208) [2005-10-31 10:38:59.315] at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:396) [2005-10-31 10:38:59.315] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:363) [2005-10-31 10:38:59.315] at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490) [2005-10-31 10:38:59.315] at com.caucho.util.ThreadPool.run(ThreadPool.java:423) [2005-10-31 10:38:59.315] at java.lang.Thread.run(Thread.java:534) [10:38:59.316] Took Type: java.io.PrintWriter [2005-10-31 10:38:59.316] Took Type: java.io.PrintWriter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-881) All NOTICE.txt and LICENSE.txt files and the related licenses dirs should be moved to subfolder META-INF
All NOTICE.txt and LICENSE.txt files and the related licenses dirs should be moved to subfolder META-INF Key: TOMAHAWK-881 URL: https://issues.apache.org/jira/browse/TOMAHAWK-881 Project: MyFaces Tomahawk Issue Type: Task Affects Versions: 1.1.5-SNAPSHOT Reporter: Manfred Geiler Priority: Minor All NOTICE.txt and LICENSE.txt files and the related licenses dirs should be moved to subfolder META-INF (Seems to be best practice now for all apache projects) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1503) h:selectOneMenu does not update value binding when a custom converter is used
[
https://issues.apache.org/jira/browse/MYFACES-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Geiler resolved MYFACES-1503.
-
Resolution: Incomplete
Jiri, can you give you additional information on this issue? i.e. are there
validation errors that prevents model from getting updated?
h:selectOneMenu does not update value binding when a custom converter is used
-
Key: MYFACES-1503
URL: https://issues.apache.org/jira/browse/MYFACES-1503
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.4
Environment: JBoss 4.0.5
Reporter: Ji?í Hofman
Priority: Blocker
When used custom converter MyObject - String Id, String Id - MyObject,
h:selectOneMenu does not update value binding. I was testing the binding with
h:inputText and there it works OK.
Following works:
h:inputText
value=#{GlossInstrumentCapture.instrument.denominationCurrency} /
Following does not:
h:selectOneMenu
value=#{GlossInstrumentCapture.instrument.denominationCurrency}
f:selectItems
value=#{GlossInstrumentCapture.definition.currencies} /
/h:selectOneMenu
public InstrumentLabel getDenominationCurrency();
public void setDenominationCurrency(InstrumentLabel denominationCurrency);
for (InstrumentLabel currency : definition.getCurrencies()) {
SelectItem item = new SelectItem(currency, currency.getName());
currencies.add(item);
}
public ListSelectItem getCurrencies() {
return currencies;
}
Converter is called properly, works properly. When the form is submitted,
converter is called and in case of inputText value binding
(GlossInstrumentCapture.instrument.denominationCurrency) is updated. In case
of selectOneMenu, MyFaces weirdly and SILENTLY skips UPDATE_MODEL_VALUES and
INVOKE_APPLICATION and renders current /previous/ view.
Thanks, Jiri
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1513) myfaces-api has unnecessary commons-digester dependency
myfaces-api has unnecessary commons-digester dependency --- Key: MYFACES-1513 URL: http://issues.apache.org/jira/browse/MYFACES-1513 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.4 Reporter: Manfred Geiler Priority: Minor Fix For: 1.1.5-SNAPSHOT pom.xml of myFaces-api defines the following dependency: dependency groupIdcommons-digester/groupId artifactIdcommons-digester/artifactId version1.6/version scopecompile/scope exclusions exclusion artifactIdxml-apis/artifactId groupIdxml-apis/groupId /exclusion /exclusions /dependency This one is unnecessary and should be moved to myfaces-impl where there is a real dependency from DigesterFacesConfigUnmarshallerImpl class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1411) Lifecycle phase executions repetitions
[
http://issues.apache.org/jira/browse/MYFACES-1411?page=comments#action_12452163
]
Manfred Geiler commented on MYFACES-1411:
-
Just checked the ICLA files.
It has still not arrived (or been processed).
Nikolay, can you please check, what could have happened to your fax?
Thanks,
Manfred
Lifecycle phase executions repetitions
--
Key: MYFACES-1411
URL: http://issues.apache.org/jira/browse/MYFACES-1411
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
Assigned To: Martin Marinschek
Fix For: 1.1.5-SNAPSHOT
Attachments: ApplyRequestValuesExecutor.java,
InvokeApplicationExecutor.java, LifecycleImpl.java, PhaseExecutor.java,
ProcessValidationsExecutor.java, RenderResponseExecutor.java,
RestoreViewExecutor.java, UpdateModelValuesExecutor.java
Every phase in LifecycleImpl looks like:
private boolean applyRequestValues(FacesContext facesContext,
PhaseListenerManager phaseListenerMgr)
throws FacesException
{
boolean skipFurtherProcessing = false;
if (log.isTraceEnabled()) log.trace(entering applyRequestValues in
+ LifecycleImpl.class.getName());
try {
phaseListenerMgr.informPhaseListenersBefore(PhaseId.APPLY_REQUEST_VALUES);
if(isResponseComplete(facesContext, applyRequestValues, true))
{
// have to return right away
return true;
}
if(shouldRenderResponse(facesContext, applyRequestValues, true))
{
skipFurtherProcessing = true;
}
facesContext.getViewRoot().processDecodes(facesContext);
} finally {
phaseListenerMgr.informPhaseListenersAfter(PhaseId.APPLY_REQUEST_VALUES);
}
if (isResponseComplete(facesContext, applyRequestValues, false)
|| shouldRenderResponse(facesContext,
applyRequestValues, false))
{
// since this phase is completed we don't need to
return right away even if the response is completed
skipFurtherProcessing = true;
}
if (!skipFurtherProcessing log.isTraceEnabled())
log.trace(exiting applyRequestValues in
+ LifecycleImpl.class.getName());
return skipFurtherProcessing;
}
And that is repeated as many times as phases are. The fix will be to extract
the common behavior in a method, that receives one additional parameter -
PhaseExecutor and delegate to it the real execution.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1409) incorrect behavior after RESTORE_VIEW responseComplete
[ http://issues.apache.org/jira/browse/MYFACES-1409?page=comments#action_12452172 ] Manfred Geiler commented on MYFACES-1409: - I don't get it. Your log documents correct behaviour: After the first RESTORE_VIEW when responseComplete = true there is no RENDER_RESPONSE following. In the next (new!) Lifecycle, after the second RESTORE_VIEW the responseComplete = false (!) and the RENDER_RESPONSE is executed. This is ok. Please, more info on that issue. Thanks, Manfred incorrect behavior after RESTORE_VIEW responseComplete -- Key: MYFACES-1409 URL: http://issues.apache.org/jira/browse/MYFACES-1409 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT Environment: Windows XP, apache-tomcat-5.5.17 Reporter: Leonid Mikhailov Fix For: 1.1.5-SNAPSHOT Attachments: ajax-progress-bar-jsf-MyFaces.war The following behavior appears to be incorrect in myfaces implementation of JSF. After FacesContext.responseComplete is issued in the afterPhase method of the PhaseListener at the RESTORE_VIEW phase, myfaces implementation skips to RENDER_RESPONSE phase. This appears to be incorrect, as following a call to FacesContext.responseComplete JSF implementation should exit JSF lifecycle completely, i.e. the next phase of the lifecycle should be again RESTORE_VIEW. This problem can be observed when running Sun's Progress Bar with JSF and AJAX Sample with myfaces libraries on Tomcat. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1420) Null Pointer Exception in SelectItemsIterator.next() if binding is null
[ http://issues.apache.org/jira/browse/MYFACES-1420?page=all ] Manfred Geiler updated MYFACES-1420: Status: Resolved (was: Patch Available) Resolution: Fixed Assignee: Manfred Geiler patch applied Null Pointer Exception in SelectItemsIterator.next() if binding is null --- Key: MYFACES-1420 URL: http://issues.apache.org/jira/browse/MYFACES-1420 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT, 1.1.4 Environment: Linux Fedora core 5 Reporter: Horia Barca Assigned To: Manfred Geiler Fix For: 1.1.5-SNAPSHOT Attachments: _SelectItemsIterator.patch, SelectItemsIterator_modified.java NPE is thrown at line 183 of org.apache.myfaces.shared_impl.util.SelectItemsIterator.next() if value binding property of the current UISelectItems component is null. This is not relevant, as the exception expected at that place in the code is IllegalArgumentException. By constructing the IllegalArgumentException message, a check whether the binding is null should be made, like it's done at line 143 of the same class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (TOMAHAWK-684) New attribute activePanelTabVar for HtmlPanelTabbedPane
[ http://issues.apache.org/jira/browse/TOMAHAWK-684?page=all ] Manfred Geiler reopened TOMAHAWK-684: - The new attribute is called _activePanelTabVar. Should be activePanelTabVar, right? New attribute activePanelTabVar for HtmlPanelTabbedPane --- Key: TOMAHAWK-684 URL: http://issues.apache.org/jira/browse/TOMAHAWK-684 Project: MyFaces Tomahawk Issue Type: New Feature Affects Versions: 1.1.5-SNAPSHOT Reporter: Thomas Spiegl Assigned To: Thomas Spiegl Priority: Minor Fix For: 1.1.5-SNAPSHOT HtmlPanelTabbedPane has a new attribute activePanelTabVar. When rendering a panelTab a Boolean variable is set in request scope. True means that the currently rendered panelTab is active. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-788) Request attributes lost when using MyFaces in Portlet
[ http://issues.apache.org/jira/browse/MYFACES-788?page=all ] Manfred Geiler updated MYFACES-788: --- Status: Open (was: Patch Available) Request attributes lost when using MyFaces in Portlet - Key: MYFACES-788 URL: http://issues.apache.org/jira/browse/MYFACES-788 Project: MyFaces Core Type: Bug Versions: 1.1.0 Reporter: Michael Lipp Request attributes set in Phases prior to the rendering phase are no longer available in the rendering phase. This behaviour is easily explainable from a portlet writer's point of view (he knows about the distinction between the ActionRequest and the RenderRequest). From the JSF implementor's point of view (who knows only about a single request) this behaviour leads -- during the rendering phase -- to the unexplicable unavailability of all request attributes set prior to the rendering phase. Looking through the JSF spec, I found no indication that request scope attributes may be lost during the processing of a (from the JSF user's point of view) single request. So I thing the portlet JSF bridge should ensure the carrying over of request attributes between the action and the render request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1149) StateUtils has a static inializer that calls FacesContext.getCurrentInstance()
StateUtils has a static inializer that calls FacesContext.getCurrentInstance() -- Key: MYFACES-1149 URL: http://issues.apache.org/jira/browse/MYFACES-1149 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT Reporter: Manfred Geiler Assigned to: Dennis Byrne In a multi-threaded environment or when using multiple webapps within one container this is subject to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-750) Need synchronization in LifecycleImpl
[ http://issues.apache.org/jira/browse/MYFACES-750?page=all ]
Manfred Geiler resolved MYFACES-750:
Fix Version: Nightly
Resolution: Fixed
Actually implemented a slightly different solution than was suggested. But
synchronized is the right solution here, Thanks!
Need synchronization in LifecycleImpl
-
Key: MYFACES-750
URL: http://issues.apache.org/jira/browse/MYFACES-750
Project: MyFaces Core
Type: Bug
Components: Implementation
Versions: 1.1.0
Environment: Weblogic 8.1, AIX
Reporter: Sam Schneider
Assignee: Manfred Geiler
Fix For: Nightly
Getting this exception when removing a bean as a listener:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:462)
at java.util.AbstractList$Itr.next(AbstractList.java:433)
at java.util.AbstractCollection.remove(AbstractCollection.java:268)
at
org.apache.myfaces.lifecycle.LifecycleImpl.removePhaseListener(LifecycleImpl.java:411)
at
com.erac.riskmgmt.ice.web.AbstractPageBean.afterPhase(AbstractPageBean.java:128)
The method call at AbstractPageBean:128 is
getLifecycle().removePhaseListener(this);
protected Lifecycle getLifecycle() {
String lifecycleId =
getExternalContext().getInitParameter(javax.faces.LIFECYCLE_ID);
if ((lifecycleId == null) || (lifecycleId.length() == 0)) {
lifecycleId = LifecycleFactory.DEFAULT_LIFECYCLE;
}
LifecycleFactory lifecycleFactory = (LifecycleFactory)
FactoryFinder.getFactory(
FactoryFinder.LIFECYCLE_FACTORY);
return lifecycleFactory.getLifecycle(lifecycleId);
}
Basically what's happening from a request perspective is that we have a
custom ViewHandler that creates the backing bean that's registered for a
given view id (custom registry using a HashMap that's created as a managed
bean and maintained manually in faces-config). When the backing bean is
created it adds itself as a listener and when the AFTER RENDER_RESPONSE is
executed the bean removes itself as a listener (as above at line 128 in
AbstractPageBean). No problems are observed in low-load situations, but when
we sent the application to benchmarking simulating ~200 concurrent users we
noticed this problem. It looks like easiest fix is to synchronize the array
list on adding and removing listeners (currently we've worked around this by
using an external lock to synchronize add/remove calls from our
AbstractPageBean).
However, It looks like there is also a potential problem with the call to
getPhaseListeners() in that it creates a cached array that's later copied
back into a *new* ArrayList in addPhaseListener(...) and
removePhaseListener(...). Since there is no synchronization if someone
called getPhaseListeners() and then two/N different threads tried to add
listeners 1..N listeners could be lost (all would check for a null
_phaseListenerList and multiple threads could potentially attempt to create a
new _phaseListenerList and add/remove the PhaseListener) -- of course the
converse problem would be that two/N different threads tried to remove phase
listeners and the 1..N listeners would not be removed (they would be recopied
in on another thread).
What would simplify this whole business greatly would be to remove the cached
list and simply synchronize on the ArrayList on the add/remove/getListeners:
public void addPhaseListener(PhaseListener phaseListener)
{
if(phaseListener == null)
{
throw new NullPointerException(PhaseListener must not be null.);
}
// create _phaseListenerList at class scope -- so no more null-checks for it
synchronized(_phaseListenerList) {
_phaseListenerList.add(phaseListener);
}
}
public void removePhaseListener(PhaseListener phaseListener)
{
synchronized(_phaseListenerList) {
_phaseListenerList.remove(phaseListener);
}
}
public PhaseListener[] getPhaseListeners()
{
synchronized(_phaseListenerList) {
return (PhaseListener[])_phaseListenerList.toArray(new
PhaseListener[_phaseListenerList.size()]);
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1055) add colspan (and header/footer colspan) attributes to tomahawk extended column tag
[ http://issues.apache.org/jira/browse/MYFACES-1055?page=all ] Manfred Geiler updated MYFACES-1055: Priority: Minor (was: Major) add colspan (and header/footer colspan) attributes to tomahawk extended column tag -- Key: MYFACES-1055 URL: http://issues.apache.org/jira/browse/MYFACES-1055 Project: MyFaces Type: Improvement Components: Tomahawk Versions: 1.1.1 Reporter: Lance Frohman Priority: Minor Attachments: HtmlColumn.java.patch, HtmlColumnTag.java.patch, HtmlColumns.java.patch, HtmlSimpleColumn.java.patch, HtmlTableRenderer.java.patch, column.xml.patch, test.zip, tomahawk_column_attributes.xml.patch I added three new attributes to the tomahawk column tag (I didn't change the columns tag - I don't even know if that would make sense). The new attributes are colspan, headercolspan, and footercolspan. All the changes involve adding these attributes, except there is also a change to HtmlTableRenderer, to implement it. There is a new routine, amISpannedOver, to check to see if the column is spanned over. This replaces JIRA-426, it can be deleted. The attached test.zip file is for testing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-446) inputFileUpload field state is not restored if validation fails
[ http://issues.apache.org/jira/browse/MYFACES-446?page=all ] Manfred Geiler updated MYFACES-446: --- Priority: Minor (was: Blocker) inputFileUpload field state is not restored if validation fails --- Key: MYFACES-446 URL: http://issues.apache.org/jira/browse/MYFACES-446 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: Windows XP/Solaris 8 Tomcat 5 Reporter: Mark Faine Assignee: Martin Marinschek Priority: Minor If validation fails on a page containing an inputFileUpload control the state of all the fields is restored except for the inputFileUpload component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-446) inputFileUpload field state is not restored if validation fails
[ http://issues.apache.org/jira/browse/MYFACES-446?page=all ] Manfred Geiler resolved MYFACES-446: Resolution: Won't Fix Any more comments on this? inputFileUpload field state is not restored if validation fails --- Key: MYFACES-446 URL: http://issues.apache.org/jira/browse/MYFACES-446 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: Windows XP/Solaris 8 Tomcat 5 Reporter: Mark Faine Assignee: Martin Marinschek Priority: Minor If validation fails on a page containing an inputFileUpload control the state of all the fields is restored except for the inputFileUpload component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-472) Cannot configure RenderKitFactory through META-INF/services
[ http://issues.apache.org/jira/browse/MYFACES-472?page=all ]
Manfred Geiler resolved MYFACES-472:
Resolution: Fixed
Cannot configure RenderKitFactory through META-INF/services
---
Key: MYFACES-472
URL: http://issues.apache.org/jira/browse/MYFACES-472
Project: MyFaces
Type: Bug
Components: JSR-127
Versions: 1.0.9 beta
Reporter: sean schofield
Assignee: Manfred Geiler
Fix For: Nightly Build
If there is no render kit configured via WEB-INF/faces-config.xml,
ServletContext init param or META-INF/faces-config.xml then JSF
implementation must check META-INF/services directory for a file with a
filename equal to the name of the factory.
From page 10-6 of the spec:
If a META-INF/services/{factory-class-name} resource is visible to the web
application class loader for the calling application (typically as a result
of being present in the manifest of a JAR file), its first line is read and
assumed to be the name of the factory implementation class to use.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-359) JspViewHandlerImpl.createView doesn't play nice with decorators
[ http://issues.apache.org/jira/browse/MYFACES-359?page=all ] Manfred Geiler resolved MYFACES-359: Fix Version: Nightly Build Resolution: Fixed patch applied JspViewHandlerImpl.createView doesn't play nice with decorators --- Key: MYFACES-359 URL: http://issues.apache.org/jira/browse/MYFACES-359 Project: MyFaces Type: Bug Versions: Nightly Build, 1.0.9 beta Reporter: Howard Abrams Assignee: Manfred Geiler Fix For: Nightly Build Attachments: JspViewHandlerImpl.patch JspViewHandlerImpl.createView calls the local version of calculateLocale and calculateRenderKitId. It should get the viewHandler from the application instance (as it does in restoreView) and then call the instance's mehtods,otherwise any decorator methods won't get called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-117) styleClass attribute Ignored for commandNavigation tag
[ http://issues.apache.org/jira/browse/MYFACES-117?page=all ]
Manfred Geiler resolved MYFACES-117:
Assign To: Manfred Geiler
Resolution: Fixed
Fix Version: Nightly Build
Applied Brunos patch, because it won't harm anyone. It is intuitive that
defining the styleClass at the component itself - of course - overrides any
other indirect styleClass. So if someone overrides the commandNavigation
styleClass he propably knows what he is doing ;-)
styleClass attribute Ignored for commandNavigation tag
--
Key: MYFACES-117
URL: http://issues.apache.org/jira/browse/MYFACES-117
Project: MyFaces
Type: Bug
Versions: 1.0.7 beta
Environment: Window XP, Tomcat
Reporter: Ted Jones
Assignee: Manfred Geiler
Fix For: Nightly Build
Attachments: MYFACES-117_patch.txt
The panelNavigation stlye class values are picked up, but using the
styleClass attribute in the commanNavigation tag has no effect.
x:panelNavigation
id=license_nav
styleClass=navigation
separatorClass=navseparator
itemClass=navitem
activeItemClass=navitem_active
openItemClass=navitem_open
x:commandNavigation
id=customerNavID
action=customer
actionListener=#{navigateBean.customerSelected}
immediate=true
value=Customer
styleClass=#{navigateBean.customerStyleClass}/
x:commandNavigation
id=infoNavID
action=licenseinfo
actionListener=#{navigateBean.infoSelected}
value=License Info
styleClass=#{navigateBean.customerStyleClass}/
/x:panelNavigation
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-211) Undesired dependency on ApplicationImpl in FacesConfigurator
Undesired dependency on ApplicationImpl in FacesConfigurator Key: MYFACES-211 URL: http://issues.apache.org/jira/browse/MYFACES-211 Project: MyFaces Type: Bug Reporter: Manfred Geiler Originally reported by Walter Snel: You recent additions related to the configurability of Converters created a dependency on a particular Application implementation in the FacesConfigurator. I noticed this because I'm using a custom ApplicationFactory that returns a custom Facade (with augmentations) to the ApplicationImpl class. In this case the FacesConfigurator doesn't call the addConverterConfiguration. This, later on, leads to horrible nullpointer exceptions when any of standard converters are used. Perhaps you could consider using relfection instead of the current 'instanceof' mechanism to find out if the addConverterConfiguration() method is supported ? With kind regards, Walter Snel -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-211) Undesired dependency on ApplicationImpl in FacesConfigurator
[ http://issues.apache.org/jira/browse/MYFACES-211?page=all ] Manfred Geiler resolved MYFACES-211: Resolution: Duplicate see MYFACES-210 Undesired dependency on ApplicationImpl in FacesConfigurator Key: MYFACES-211 URL: http://issues.apache.org/jira/browse/MYFACES-211 Project: MyFaces Type: Bug Reporter: Manfred Geiler Originally reported by Walter Snel: You recent additions related to the configurability of Converters created a dependency on a particular Application implementation in the FacesConfigurator. I noticed this because I'm using a custom ApplicationFactory that returns a custom Facade (with augmentations) to the ApplicationImpl class. In this case the FacesConfigurator doesn't call the addConverterConfiguration. This, later on, leads to horrible nullpointer exceptions when any of standard converters are used. Perhaps you could consider using relfection instead of the current 'instanceof' mechanism to find out if the addConverterConfiguration() method is supported ? With kind regards, Walter Snel -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-189) Valuebinding in Converter and Validator attributes do not work for dynamic beans
[ http://issues.apache.org/jira/browse/MYFACES-189?page=history ]
Manfred Geiler updated MYFACES-189:
---
type: New Feature (was: Bug)
If you really want to add this feature, please do it in a derived
x:convertNumber tag/converter so that it is clearly separated as an extension
to specified standard behaviour.
Valuebinding in Converter and Validator attributes do not work for dynamic
beans
Key: MYFACES-189
URL: http://issues.apache.org/jira/browse/MYFACES-189
Project: MyFaces
Type: New Feature
Versions: Nightly Build
Reporter: Mathias Broekelmann
It is not possible to use a value binding which references a dynamically
created bean (like the row in a datatable) in the converter and validator
tags. These valuebindings are evaluated at creation time (doStartTag() method
in the tag).
Here is an example which will not work:
h:datatable value=#{data.rows} var=row
h:column
h:outputText value=#{row.numberValue}
f:convertNumber minFractionDigits=#{row.numberScale}/ -- this will
not work since row is not found.
/h:outputText
/h:column
/h:datatable
I'will provide the patches if there will be an agreement that this should
work. Since it is not a problem to evaluate the bindings at the right time
(when converting or validating the value).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-179) UIInput.updateModel(...) hides a RuntimeException
[ http://issues.apache.org/jira/browse/MYFACES-179?page=history ]
Manfred Geiler resolved MYFACES-179:
Assign To: Manfred Geiler
Resolution: Fixed
Fix Version: 1.0.9 beta
UIInput.updateModel(...) hides a RuntimeException
-
Key: MYFACES-179
URL: http://issues.apache.org/jira/browse/MYFACES-179
Project: MyFaces
Type: Improvement
Versions: Nightly Build
Reporter: Mathias Broekelmann
Assignee: Manfred Geiler
Priority: Minor
Fix For: 1.0.9 beta
If a RuntimeException is thrown in the Method
UIInput.updateModel(FacesContext) an error message is generated but without
any stacktrace. This causes a lot of trouble for the user to find the cause
of the error.
Here is a patch to write the stacktrace:
Index: UIInput.java
===
RCS file:
/home/cvspublic/incubator-myfaces/src/jsfapi/javax/faces/component/UIInput.java,v
retrieving revision 1.16
diff -u -r1.16 UIInput.java
--- UIInput.java 4 Mar 2005 00:28:45 - 1.16
+++ UIInput.java 12 Apr 2005 11:13:34 -
@@ -252,6 +252,7 @@
catch (RuntimeException e)
{
//Object[] args = {getId()};
+ context.getExternalContext().log(e.getMessage(), e);
_MessageUtils.addErrorMessage(context,
this,CONVERSION_MESSAGE_ID,new Object[]{getId()});
setValid(false);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-171) Wrong src tree for UIColumns
Wrong src tree for UIColumns Key: MYFACES-171 URL: http://issues.apache.org/jira/browse/MYFACES-171 Project: MyFaces Type: Task Versions: 1.0.9 beta Reporter: Manfred Geiler Priority: Minor UIColumns class for new crosstable component should be moved from share src tree to components tree. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-149) NullPointerException in _SharedRendererUtils.getConvertedUISelectManyValue
[
http://issues.apache.org/jira/browse/MYFACES-149?page=comments#action_62259 ]
Manfred Geiler commented on MYFACES-149:
Fixed, but slightly different than proposed:
All callers of _SharedRendererUtils.getConvertedUISelectManyValue where
modified, such that the submittedValue cannot be null.
NullPointerException in _SharedRendererUtils.getConvertedUISelectManyValue
Key: MYFACES-149
URL: http://issues.apache.org/jira/browse/MYFACES-149
Project: MyFaces
Type: Bug
Versions: 1.0.9 beta
Environment: Tomcat 5.5.9
JDK 1.5.0_01-b08
Reporter: Jochen Schwörer
Fix For: 1.0.9 beta
When no selection is made in the selection list the following exception
occures:
java.lang.NullPointerException
org.apache.myfaces.renderkit._SharedRendererUtils.getConvertedUISelectManyValue(_SharedRendererUtils.java:183)
org.apache.myfaces.renderkit.RendererUtils.getConvertedUISelectManyValue(RendererUtils.java:792)
org.apache.myfaces.renderkit.html.HtmlListboxRendererBase.getConvertedValue(HtmlListboxRendererBase.java:143)
javax.faces.component.UISelectMany.getConvertedValue(UISelectMany.java:295)
javax.faces.component.UIInput.validate(UIInput.java:291)
javax.faces.component.UISelectMany.validate(UISelectMany.java:284)
javax.faces.component.UIInput.processValidators(UIInput.java:166)
javax.faces.component.UIForm.processValidators(UIForm.java:66)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:418)
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:162)
org.apache.myfaces.lifecycle.LifecycleImpl.processValidations(LifecycleImpl.java:208)
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:92)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:109)
org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:115)
I fixed it by adding the following code to the beginning of
_SharedRendererUtils.getConvertedUISelectManyValue() in both places
(javax.faces.component and org.apache.myfaces.renderkit)
code
if (submittedValue == null)
{
return submittedValue;
}
/code
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-149) NullPointerException in _SharedRendererUtils.getConvertedUISelectManyValue
[ http://issues.apache.org/jira/browse/MYFACES-149?page=history ]
Manfred Geiler resolved MYFACES-149:
Assign To: Manfred Geiler
Resolution: Fixed
Fix Version: 1.0.9 beta
NullPointerException in _SharedRendererUtils.getConvertedUISelectManyValue
Key: MYFACES-149
URL: http://issues.apache.org/jira/browse/MYFACES-149
Project: MyFaces
Type: Bug
Versions: 1.0.9 beta
Environment: Tomcat 5.5.9
JDK 1.5.0_01-b08
Reporter: Jochen Schwörer
Assignee: Manfred Geiler
Fix For: 1.0.9 beta
When no selection is made in the selection list the following exception
occures:
java.lang.NullPointerException
org.apache.myfaces.renderkit._SharedRendererUtils.getConvertedUISelectManyValue(_SharedRendererUtils.java:183)
org.apache.myfaces.renderkit.RendererUtils.getConvertedUISelectManyValue(RendererUtils.java:792)
org.apache.myfaces.renderkit.html.HtmlListboxRendererBase.getConvertedValue(HtmlListboxRendererBase.java:143)
javax.faces.component.UISelectMany.getConvertedValue(UISelectMany.java:295)
javax.faces.component.UIInput.validate(UIInput.java:291)
javax.faces.component.UISelectMany.validate(UISelectMany.java:284)
javax.faces.component.UIInput.processValidators(UIInput.java:166)
javax.faces.component.UIForm.processValidators(UIForm.java:66)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:418)
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:162)
org.apache.myfaces.lifecycle.LifecycleImpl.processValidations(LifecycleImpl.java:208)
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:92)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:109)
org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:115)
I fixed it by adding the following code to the beginning of
_SharedRendererUtils.getConvertedUISelectManyValue() in both places
(javax.faces.component and org.apache.myfaces.renderkit)
code
if (submittedValue == null)
{
return submittedValue;
}
/code
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-157) Null pointer exception in selectManyListbox when using converter
[ http://issues.apache.org/jira/browse/MYFACES-157?page=history ]
Manfred Geiler resolved MYFACES-157:
Resolution: Duplicate
Fix Version: 1.0.9 beta
(was: Nightly Build)
Duplicate of MYFACES-149, see comments there for details on the fix
Null pointer exception in selectManyListbox when using converter
Key: MYFACES-157
URL: http://issues.apache.org/jira/browse/MYFACES-157
Project: MyFaces
Type: Bug
Versions: 1.0.9 beta
Environment: Windows XP SP2
Reporter: Whitney Hunter
Assignee: Manfred Geiler
Priority: Critical
Fix For: 1.0.9 beta
I believe that this is a new bug in 1.0.9. It seems to not exist in 1.0.8.
When I have jsp code like this:
f:view
h:form
h:panelGrid columns=1
h:selectManyListbox
f:selectItem itemLabel=one itemValue=one /
f:selectItem itemLabel=two itemValue=two /
f:selectItem itemLabel=three itemValue=three /
f:converter converterId=converter /
/h:selectManyListbox
h:commandButton value=submit
actionListener=#{controller.submit} /
/h:panelGrid
/h:form
/f:view
I get a NullPointerException when I submit the form without selecting
anything in the list box (no problem when a selection is made).
Here is the stack trace:
java.lang.NullPointerException
at
org.apache.myfaces.renderkit._SharedRendererUtils.getConvertedUISelectManyValue(_SharedRendererUtils.java:151)
at
org.apache.myfaces.renderkit.RendererUtils.getConvertedUISelectManyValue(RendererUtils.java:792)
at
org.apache.myfaces.renderkit.html.HtmlListboxRendererBase.getConvertedValue(HtmlListboxRendererBase.java:143)
at
javax.faces.component.UISelectMany.getConvertedValue(UISelectMany.java:295)
at javax.faces.component.UIInput.validate(UIInput.java:291)
at javax.faces.component.UISelectMany.validate(UISelectMany.java:284)
at javax.faces.component.UIInput.processValidators(UIInput.java:166)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:427)
at javax.faces.component.UIForm.processValidators(UIForm.java:66)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:427)
at
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:162)
at
org.apache.myfaces.lifecycle.LifecycleImpl.processValidations(LifecycleImpl.java:208)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:92)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:109)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at
[jira] Commented: (MYFACES-114) visibleOnUserRole not working
[ http://issues.apache.org/jira/browse/MYFACES-114?page=comments#action_61944 ] Manfred Geiler commented on MYFACES-114: It works for me, perhaps a Tomcat 5.0.28 issue? Do you have special ServletFilters or something like that? Could you please try the enabledOnUserRole attribute, too? I tell you, the only thing we do is call the facesContext.getExternalContext().isUserInRole() method. Have a look at org.apache.myfaces.component.UserRoleUtils Also, would it be best to name the attribute renderedOnUserRole to be more consistent with standard JSF attributes? Yes. Historical: visibleOnUserRole already existed when there was no rendered attribute specified yet. ;-) But for backwards compatibility we should rather leave visibleOnUserRole and mark it deprecated. -M visibleOnUserRole not working - Key: MYFACES-114 URL: http://issues.apache.org/jira/browse/MYFACES-114 Project: MyFaces Type: Bug Versions: Nightly Build Environment: tomcat 5.0.28, JDK 1.5.0_01 Reporter: Alessandro Polverini I made what I think could be the smallest test, and that is the source of the page: [EMAIL PROTECTED] contentType=text/html% [EMAIL PROTECTED] pageEncoding=UTF-8% %@ taglib uri=http://java.sun.com/jsf/html; prefix=h % %@ taglib uri=http://java.sun.com/jsf/core; prefix=f % %@ taglib uri=http://myfaces.apache.org/extensions; prefix=x% htmlbody f:view x:outputText value=MyFaces says current user has role dummy visibleOnUserRole=dummy/BR/ servlet says current user has role dummy: %= request.isUserInRole(dummy) %BR/ /f:view /body/html And the output is: MyFaces says current user has role dummy servlet says current user has role dummy: false So I think something is wrong in myfaces implementation since request.isUserInRole() return false but outputText is showing the text anyway. I'm using tomcat 5.0.28 with JDBC realm and authentication it's running fine for the other aspects. Also, would it be best to name the attribute renderedOnUserRole to be more consistent with standard JSF attributes? Thanks, Alex -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-143) JspTilesViewHandlerImpl expects everything to be a Tiles definition
[ http://issues.apache.org/jira/browse/MYFACES-143?page=history ] Manfred Geiler resolved MYFACES-143: Resolution: Won't Fix JspTilesViewHandlerImpl expects everything to be a Tiles definition --- Key: MYFACES-143 URL: http://issues.apache.org/jira/browse/MYFACES-143 Project: MyFaces Type: Improvement Versions: 1.0.8 beta Reporter: sean schofield I brought this up on the mailing list a long time ago. Basically if you are using the Tiles view handler than you cannot have stand alone JSF pages. In other words, you cannot navigate to foo.jsf because the view handler thinks that there is a tiles definition named foo somewhere. So you end up with a NPE. It would be nice if the view handler attempted to handle in the normal fashion if there is no associated Tile definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
[ http://issues.apache.org/jira/browse/MYFACES-108?page=comments#action_59590 ] Manfred Geiler commented on MYFACES-108: Yes, true if you have a classical one form page. Then the submitted (invalid) value is also always part of the normal request parameters and the component could get it from there. But: Imagine a more complex page with two forms side by side. Now the user enters something in form 1 and submits it. The entered value is invalid, so the model bean is not updated yet. The submitted value gets redisplayed (somehow). Next the user does something in form 2 and submits it. Now the submitted value in form 1 will disappear, because the model does not know anything of this value and the component in form 1 would not have saved state information about the submitted value. You might say why should someone have two forms on one page?. Well, with complex page designs (tiles) you cannot always have just one form. Imagine the following practical user interface example: One tile displays an input wizard where the user should enter some information. Another tile displays a help tile aside (perhaps a help component with index and search feature). User enters a bad value in the input form. Page is redisplayed. User uses the help component to find the reason why the entered value is not allowed. He uses the search feature of the help component, so he submits a form other than the input form. If we would not save state, all entered values would disappear now. Not very user friendly. ;-) UIInput should not store submitted value in the state - Key: MYFACES-108 URL: http://issues.apache.org/jira/browse/MYFACES-108 Project: MyFaces Type: Improvement Versions: 1.0.7 beta, 1.0.8 beta Reporter: sean schofield Priority: Trivial Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being stored will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
