[jira] [Updated] (MYFACES-3229) ServletExternalContextImpl.encodeRedirectURL() doesn't handle existing query parameters correctly
[ https://issues.apache.org/jira/browse/MYFACES-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated MYFACES-3229: - Status: Patch Available (was: Open) ServletExternalContextImpl.encodeRedirectURL() doesn't handle existing query parameters correctly - Key: MYFACES-3229 URL: https://issues.apache.org/jira/browse/MYFACES-3229 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.1 Reporter: Christian Kaltepoth Attachments: MYFACES-3229-failing-unit-test.patch, MYFACES-3229-fix.patch ServletExternalContextImpl.encodeRedirectURL() doesn't work correctly if the base URL already contains encoded query parameters. In this case the resulting URL contains the query parameter encoded twice, which completely breaks them. Take a look at this example: externalContext.encodeRedirectURL(/test?p1=a+b, null); Result /test?p1=a%2Bb Another example are encoded ampersand: externalContext.encodeRedirectURL(/test?p1=a%26b, null); Result /test?p1=a%2526b The root cause of the problem seems to be that ServletExternalContextImpl.encodeURL() doesn't decode the query parameters while parsing the base URL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3229) ServletExternalContextImpl.encodeRedirectURL() doesn't handle existing query parameters correctly
ServletExternalContextImpl.encodeRedirectURL() doesn't handle existing query parameters correctly - Key: MYFACES-3229 URL: https://issues.apache.org/jira/browse/MYFACES-3229 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.1 Reporter: Christian Kaltepoth ServletExternalContextImpl.encodeRedirectURL() doesn't work correctly if the base URL already contains encoded query parameters. In this case the resulting URL contains the query parameter encoded twice, which completely breaks them. Take a look at this example: externalContext.encodeRedirectURL(/test?p1=a+b, null); Result /test?p1=a%2Bb Another example are encoded ampersand: externalContext.encodeRedirectURL(/test?p1=a%26b, null); Result /test?p1=a%2526b The root cause of the problem seems to be that ServletExternalContextImpl.encodeURL() doesn't decode the query parameters while parsing the base URL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3229) ServletExternalContextImpl.encodeRedirectURL() doesn't handle existing query parameters correctly
[ https://issues.apache.org/jira/browse/MYFACES-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067054#comment-13067054 ] Christian Kaltepoth commented on MYFACES-3229: -- Sorry, I forgot to mention that both MyFaces 2.0.x and 2.1.x seem to be affected! ServletExternalContextImpl.encodeRedirectURL() doesn't handle existing query parameters correctly - Key: MYFACES-3229 URL: https://issues.apache.org/jira/browse/MYFACES-3229 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.1 Reporter: Christian Kaltepoth Attachments: MYFACES-3229-failing-unit-test.patch ServletExternalContextImpl.encodeRedirectURL() doesn't work correctly if the base URL already contains encoded query parameters. In this case the resulting URL contains the query parameter encoded twice, which completely breaks them. Take a look at this example: externalContext.encodeRedirectURL(/test?p1=a+b, null); Result /test?p1=a%2Bb Another example are encoded ampersand: externalContext.encodeRedirectURL(/test?p1=a%26b, null); Result /test?p1=a%2526b The root cause of the problem seems to be that ServletExternalContextImpl.encodeURL() doesn't decode the query parameters while parsing the base URL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-1560) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors
[ https://issues.apache.org/jira/browse/TOMAHAWK-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980584#action_12980584 ] Christian Kaltepoth commented on TOMAHAWK-1560: --- Here is a link to the JBoss issue that Stan created regarding this: https://issues.jboss.org/browse/JBAS-8800 However, I think that this issue should also be fixed in the Trinidad/Tomahawk/Commons TLDs. It is undeniable that the current TLDs are not readable by a validating parser because they do not validate against the schema. And that is something that should be fixed for future versions. Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors --- Key: TOMAHAWK-1560 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1560 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.10 Reporter: Kennard Consulting Priority: Critical Attachments: TOMAHAWK-1560.patch Original Estimate: 1h Remaining Estimate: 1h Tomahawk 1.1.10 for JSF 1.2 fails to deploy on the recently released JBoss AS 6. This appears to be because of errors in tomahawk.tld. I managed to resolve it by taking the following steps (any of which may be sub-optimal): 1. Changed xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; to xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; (i.e. the first half of the schemaLocation was missing) 2. Removed display-name tag (is a bad element name?) 3. Removed all description tags (they contain invalid markup?) Regards, Richard. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1560) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors
[ https://issues.apache.org/jira/browse/TOMAHAWK-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated TOMAHAWK-1560: -- Status: Patch Available (was: Open) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors --- Key: TOMAHAWK-1560 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1560 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.10 Reporter: Kennard Consulting Priority: Critical Original Estimate: 1h Remaining Estimate: 1h Tomahawk 1.1.10 for JSF 1.2 fails to deploy on the recently released JBoss AS 6. This appears to be because of errors in tomahawk.tld. I managed to resolve it by taking the following steps (any of which may be sub-optimal): 1. Changed xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; to xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; (i.e. the first half of the schemaLocation was missing) 2. Removed display-name tag (is a bad element name?) 3. Removed all description tags (they contain invalid markup?) Regards, Richard. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1560) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors
[ https://issues.apache.org/jira/browse/TOMAHAWK-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12977219#action_12977219 ] Christian Kaltepoth commented on TOMAHAWK-1560: --- I had similar issues with MyFaces Commons Converters 1.0.1 for JSF 1.2 on JBoss 6.0.0.Final. The root cause is that the MyFaces Builder Plugin creates an invalid TLD file that doesn't validate against the required XSD schema (http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd). I identified the following problems: * The schemaLocation attribute is missing the XML namespace (see 1. in original bug report). * The description and display-name elements inside the taglib element are misplaced. The correct order (according to the XSD schema) is: description, then display-name and then the other child elements. * A description element must be the first child element inside tag and attribute elements. JBoss 6.0.0 is very strict in parsing the TLD files and fails because of the reasons mentioned above. You can reproduce the schema incompatibility with Eclipse by renaming the TLD file to .xml and running the XML Validation on that file (Right-Click on file - Validate). I attached a patch against the current trunk of the MyFaces Builder Plugin's tomahawk12.vm which generates the TLD files for Tomahawk an Commons. Please note that I'm not completely sure whether Tomahawk and Commons for JSF 1.2 are the only artifacts that are affected. I saw that trinidad-tld12.vm is also erroneous but didn't check in detail. Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors --- Key: TOMAHAWK-1560 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1560 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.10 Reporter: Kennard Consulting Priority: Critical Original Estimate: 1h Remaining Estimate: 1h Tomahawk 1.1.10 for JSF 1.2 fails to deploy on the recently released JBoss AS 6. This appears to be because of errors in tomahawk.tld. I managed to resolve it by taking the following steps (any of which may be sub-optimal): 1. Changed xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; to xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; (i.e. the first half of the schemaLocation was missing) 2. Removed display-name tag (is a bad element name?) 3. Removed all description tags (they contain invalid markup?) Regards, Richard. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1560) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors
[ https://issues.apache.org/jira/browse/TOMAHAWK-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12977221#action_12977221 ] Christian Kaltepoth commented on TOMAHAWK-1560: --- Ups, just saw that I didn't click on Grant license to ASF for inclusion in ASF works radio button! Of cause I do! :-) Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors --- Key: TOMAHAWK-1560 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1560 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.10 Reporter: Kennard Consulting Priority: Critical Attachments: TOMAHAWK-1560.patch Original Estimate: 1h Remaining Estimate: 1h Tomahawk 1.1.10 for JSF 1.2 fails to deploy on the recently released JBoss AS 6. This appears to be because of errors in tomahawk.tld. I managed to resolve it by taking the following steps (any of which may be sub-optimal): 1. Changed xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; to xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; (i.e. the first half of the schemaLocation was missing) 2. Removed display-name tag (is a bad element name?) 3. Removed all description tags (they contain invalid markup?) Regards, Richard. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2927) Invalid handling of null values in listboxes and menus
[
https://issues.apache.org/jira/browse/MYFACES-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966035#action_12966035
]
Christian Kaltepoth commented on MYFACES-2927:
--
Hi Leonardo,
thank you very much for looking at this issue and applying my patch.
Just for your information: I had a quick look at the Mojarra source and saw
that they do not use a converter if the current value is already a String.
See line 501 in HtmlBasicRenderer:
http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/HtmlBasicRenderer.java
In my opinion this behavior makes sense. Why should the renderer call
Converter.getAsString() for a value that is already available in its String
representation.
Just my two cents! :-)
Invalid handling of null values in listboxes and menus
--
Key: MYFACES-2927
URL: https://issues.apache.org/jira/browse/MYFACES-2927
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.1
Reporter: Christian Kaltepoth
Assignee: Leonardo Uribe
Fix For: 2.0.3-SNAPSHOT
Attachments: MYFACES-2927.patch
I discovered that MyFaces doesn't seem to handle null values correctly in
listboxes and menus.
See the following example showing a h:selectOneMenu used to select an enum
value:
@ManagedBean
@RequestScoped
public class TestBean {
public enum Level {
HIGH, MEDIUM, LOW
}
private Level level;
public String action() {
FacesContext.getCurrentInstance().addMessage(null,
new FacesMessage(Submitted level: + level));
return null;
}
}
And the following view:
h:selectOneMenu value=#{testBean.level} label=Level
f:selectItem itemValue=#{null} itemLabel=Unknown/
f:selectItem itemValue=HIGHitemLabel=High/
f:selectItem itemValue=MEDIUM itemLabel=Medium/
f:selectItem itemValue=LOW itemLabel=Level/
/h:selectOneMenu
h:commandButton action=#{testBean.action} value=Go/
Clicking the Go button will result in the validation error: Level:
'Unknown' must be convertible to an enum.
If the value of the select item is null, MyFaces won't render the value
attribute of the option and so the browser will submit the label as its value:
select id=levelForm:level name=levelForm:level size=1
option selected=selectedUnknown/option
option value=HIGHHigh/option
option value=MEDIUMMedium/option
option value=LOWLevel/option
/select
Mojarra instead renders an empty value attribute in this situation:
option value= selected=selectedUnknown/option
I've created a patch fixing this issue against the current trunk of
myfaces-shared and attached it to this ticket.
You can see the sample application reproducing this issue here:
http://github.com/chkal/myfaces-tests/tree/menu-null-value
And download it here:
http://github.com/chkal/myfaces-tests/archives/menu-null-value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2927) Invalid handling of null values in listboxes and menus
[
https://issues.apache.org/jira/browse/MYFACES-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966049#action_12966049
]
Christian Kaltepoth commented on MYFACES-2927:
--
Hi Jakob,
thank you very much for the clarification. I checked the issue and totally
agree to your argumentation. Mojarra isn't spec compliant regarding this.
Regards
Christian
Invalid handling of null values in listboxes and menus
--
Key: MYFACES-2927
URL: https://issues.apache.org/jira/browse/MYFACES-2927
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.1
Reporter: Christian Kaltepoth
Assignee: Leonardo Uribe
Fix For: 2.0.3-SNAPSHOT
Attachments: MYFACES-2927.patch
I discovered that MyFaces doesn't seem to handle null values correctly in
listboxes and menus.
See the following example showing a h:selectOneMenu used to select an enum
value:
@ManagedBean
@RequestScoped
public class TestBean {
public enum Level {
HIGH, MEDIUM, LOW
}
private Level level;
public String action() {
FacesContext.getCurrentInstance().addMessage(null,
new FacesMessage(Submitted level: + level));
return null;
}
}
And the following view:
h:selectOneMenu value=#{testBean.level} label=Level
f:selectItem itemValue=#{null} itemLabel=Unknown/
f:selectItem itemValue=HIGHitemLabel=High/
f:selectItem itemValue=MEDIUM itemLabel=Medium/
f:selectItem itemValue=LOW itemLabel=Level/
/h:selectOneMenu
h:commandButton action=#{testBean.action} value=Go/
Clicking the Go button will result in the validation error: Level:
'Unknown' must be convertible to an enum.
If the value of the select item is null, MyFaces won't render the value
attribute of the option and so the browser will submit the label as its value:
select id=levelForm:level name=levelForm:level size=1
option selected=selectedUnknown/option
option value=HIGHHigh/option
option value=MEDIUMMedium/option
option value=LOWLevel/option
/select
Mojarra instead renders an empty value attribute in this situation:
option value= selected=selectedUnknown/option
I've created a patch fixing this issue against the current trunk of
myfaces-shared and attached it to this ticket.
You can see the sample application reproducing this issue here:
http://github.com/chkal/myfaces-tests/tree/menu-null-value
And download it here:
http://github.com/chkal/myfaces-tests/archives/menu-null-value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2954) ExternalContext.encodeRedirectURL() fails if 'baseUrl' contains empty parameters
ExternalContext.encodeRedirectURL() fails if 'baseUrl' contains empty parameters Key: MYFACES-2954 URL: https://issues.apache.org/jira/browse/MYFACES-2954 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.3-SNAPSHOT Reporter: Christian Kaltepoth Calling ExternalContext.encodeRedirectURL() with a baseUrl containing empty parameters fails with an ArrayIndexOutOfBoundsException. Example: externalContext.encodeRedirectURL(/test?p1=p2=test, null) The spec contains the following statement regarding this method: This method must be able to encode the parameters to a baseUrl that may or may not have existing query parameters I've attached a unit test and a patch for this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2954) ExternalContext.encodeRedirectURL() fails if 'baseUrl' contains empty parameters
[ https://issues.apache.org/jira/browse/MYFACES-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated MYFACES-2954: - Status: Patch Available (was: Open) ExternalContext.encodeRedirectURL() fails if 'baseUrl' contains empty parameters Key: MYFACES-2954 URL: https://issues.apache.org/jira/browse/MYFACES-2954 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.3-SNAPSHOT Reporter: Christian Kaltepoth Attachments: MYFACES-2954-fix.patch, MYFACES-2954-test.patch Calling ExternalContext.encodeRedirectURL() with a baseUrl containing empty parameters fails with an ArrayIndexOutOfBoundsException. Example: externalContext.encodeRedirectURL(/test?p1=p2=test, null) The spec contains the following statement regarding this method: This method must be able to encode the parameters to a baseUrl that may or may not have existing query parameters I've attached a unit test and a patch for this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2931) Regression: Template areas get lost when using ui:include
[ https://issues.apache.org/jira/browse/MYFACES-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916382#action_12916382 ] Christian Kaltepoth commented on MYFACES-2931: -- Hi Leonardo, I think you are right. I wasn't aware of the problems described in MYFACES-2753. I originally thought that inheriting template areas to files imported via ui:include would be some kind of nice-to-have feature that won't break anything and is spec compliant (as the spec doesn't explicitly include a statement regarding this). I see you did some intensive research on this topic! ;-) Keep up the good work! :-) Regression: Template areas get lost when using ui:include Key: MYFACES-2931 URL: https://issues.apache.org/jira/browse/MYFACES-2931 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.2 Reporter: Christian Kaltepoth Template areas specified with ui:define are not visible in files that the template includes with ui:include. See the following example. The template: http://github.com/chkal/myfaces-tests/blob/vdl-insert-bug/src/main/webapp/template.xhtml The file included by the template: http://github.com/chkal/myfaces-tests/blob/vdl-insert-bug/src/main/webapp/header.xhtml The page using the template: http://github.com/chkal/myfaces-tests/blob/vdl-insert-bug/src/main/webapp/page.xhtml MyFaces 2.0.2 will show Wrong Title in the title div, which is the default value of the ui:insert. MyFaces 2.0.1 and Mojarra will instead display Correct Title, which is the value definied in page.xhtml via ui:define. You can download an example application demonstrating this issue here: http://github.com/chkal/myfaces-tests/archives/vdl-insert-bug Start the app with: mvn jetty:run The page is then available here: http://localhost:9090/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2931) Regression: Template areas get lost when using ui:include
Regression: Template areas get lost when using ui:include Key: MYFACES-2931 URL: https://issues.apache.org/jira/browse/MYFACES-2931 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.2 Reporter: Christian Kaltepoth Template areas specified with ui:define are not visible in files that the template includes with ui:include. See the following example. The template: http://github.com/chkal/myfaces-tests/blob/vdl-insert-bug/src/main/webapp/template.xhtml The file included by the template: http://github.com/chkal/myfaces-tests/blob/vdl-insert-bug/src/main/webapp/header.xhtml The page using the template: http://github.com/chkal/myfaces-tests/blob/vdl-insert-bug/src/main/webapp/page.xhtml MyFaces 2.0.2 will show Wrong Title in the title div, which is the default value of the ui:insert. MyFaces 2.0.1 and Mojarra will instead display Correct Title, which is the value definied in page.xhtml via ui:define. You can download an example application demonstrating this issue here: http://github.com/chkal/myfaces-tests/archives/vdl-insert-bug Start the app with: mvn jetty:run The page is then available here: http://localhost:9090/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2931) Regression: Template areas get lost when using ui:include
[ https://issues.apache.org/jira/browse/MYFACES-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916039#action_12916039 ] Christian Kaltepoth commented on MYFACES-2931: -- Hey Leonardo! I just had a look at MYFACES-2925 and the JSF 2.0 spec. I think you are right. ui:decorate is the way to go in a scenario like this. In my opinion the name of the tags are a bit misleading. I think most people will rather use ui:include if they want to include something in the page and they will expect ui:insert to work like in the main template. ui:decorate is more or less a include with templating that should be used in these cases. Nevertheless I have a bit of a bad feeling when MyFaces changes this behavior from previous version (and what Mojarra is doing) as it will possibly break existing applications. Regression: Template areas get lost when using ui:include Key: MYFACES-2931 URL: https://issues.apache.org/jira/browse/MYFACES-2931 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.2 Reporter: Christian Kaltepoth Template areas specified with ui:define are not visible in files that the template includes with ui:include. See the following example. The template: http://github.com/chkal/myfaces-tests/blob/vdl-insert-bug/src/main/webapp/template.xhtml The file included by the template: http://github.com/chkal/myfaces-tests/blob/vdl-insert-bug/src/main/webapp/header.xhtml The page using the template: http://github.com/chkal/myfaces-tests/blob/vdl-insert-bug/src/main/webapp/page.xhtml MyFaces 2.0.2 will show Wrong Title in the title div, which is the default value of the ui:insert. MyFaces 2.0.1 and Mojarra will instead display Correct Title, which is the value definied in page.xhtml via ui:define. You can download an example application demonstrating this issue here: http://github.com/chkal/myfaces-tests/archives/vdl-insert-bug Start the app with: mvn jetty:run The page is then available here: http://localhost:9090/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2930) ClassByteCodeAnnotationFilter doesn't read the constants pool correctly
[ https://issues.apache.org/jira/browse/MYFACES-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated MYFACES-2930: - Status: Patch Available (was: Open) ClassByteCodeAnnotationFilter doesn't read the constants pool correctly --- Key: MYFACES-2930 URL: https://issues.apache.org/jira/browse/MYFACES-2930 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.3-SNAPSHOT Reporter: Christian Kaltepoth Priority: Minor Attachments: MYFACES-2930.patch The ClassByteCodeAnnotationFilter used to check classes for annotations by reading their bytecode doesn't read the constants pool table correctly. The current code reads the number of entries from the class file and then reads each entry in the pool in a for loop. Unfortunately the code fails to process entries of the type CONSTANT_Long and CONSTANT_Double correctly. The Java VM spec says: All 8-byte constants take up two entries in the constant_pool table of the class file. If a CONSTANT_Long_info or CONSTANT_Double_info structure is the item in the constant_pool table at index n, then the next usable item in the pool is located at index n+2. The constant_pool index n+1 must be valid but is considered unusable. From: http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#1348 The ClassByteCodeAnnotationFilter doesn't increase the loop counter for these entry types. Thus the filter will read bytes outside of the constants pool as soon as it finds a double or long constant in the constants pool because it will try to read more entries than there actually are. Please note that this doesn't lead to faulty behavior of the class, because if the reader reaches the end of the constants pool, it didn't find any reference until then and therefore it is OK to abort scanning and return false. Find attached a patch containing a fix for this issue and a small unit test for the ClassByteCodeAnnotationFilter. I also added a log statement to default block of the switch statement. I guess this wasn't done because the current implementation often found bad tag values because of this bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2930) ClassByteCodeAnnotationFilter doesn't read the constants pool correctly
ClassByteCodeAnnotationFilter doesn't read the constants pool correctly --- Key: MYFACES-2930 URL: https://issues.apache.org/jira/browse/MYFACES-2930 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.3-SNAPSHOT Reporter: Christian Kaltepoth Priority: Minor Attachments: MYFACES-2930.patch The ClassByteCodeAnnotationFilter used to check classes for annotations by reading their bytecode doesn't read the constants pool table correctly. The current code reads the number of entries from the class file and then reads each entry in the pool in a for loop. Unfortunately the code fails to process entries of the type CONSTANT_Long and CONSTANT_Double correctly. The Java VM spec says: All 8-byte constants take up two entries in the constant_pool table of the class file. If a CONSTANT_Long_info or CONSTANT_Double_info structure is the item in the constant_pool table at index n, then the next usable item in the pool is located at index n+2. The constant_pool index n+1 must be valid but is considered unusable. From: http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#1348 The ClassByteCodeAnnotationFilter doesn't increase the loop counter for these entry types. Thus the filter will read bytes outside of the constants pool as soon as it finds a double or long constant in the constants pool because it will try to read more entries than there actually are. Please note that this doesn't lead to faulty behavior of the class, because if the reader reaches the end of the constants pool, it didn't find any reference until then and therefore it is OK to abort scanning and return false. Find attached a patch containing a fix for this issue and a small unit test for the ClassByteCodeAnnotationFilter. I also added a log statement to default block of the switch statement. I guess this wasn't done because the current implementation often found bad tag values because of this bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2927) Invalid handling of null values in listboxes and menus
[
https://issues.apache.org/jira/browse/MYFACES-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Kaltepoth updated MYFACES-2927:
-
Status: Patch Available (was: Open)
Invalid handling of null values in listboxes and menus
--
Key: MYFACES-2927
URL: https://issues.apache.org/jira/browse/MYFACES-2927
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.1
Reporter: Christian Kaltepoth
I discovered that MyFaces doesn't seem to handle null values correctly in
listboxes and menus.
See the following example showing a h:selectOneMenu used to select an enum
value:
@ManagedBean
@RequestScoped
public class TestBean {
public enum Level {
HIGH, MEDIUM, LOW
}
private Level level;
public String action() {
FacesContext.getCurrentInstance().addMessage(null,
new FacesMessage(Submitted level: + level));
return null;
}
}
And the following view:
h:selectOneMenu value=#{testBean.level} label=Level
f:selectItem itemValue=#{null} itemLabel=Unknown/
f:selectItem itemValue=HIGHitemLabel=High/
f:selectItem itemValue=MEDIUM itemLabel=Medium/
f:selectItem itemValue=LOW itemLabel=Level/
/h:selectOneMenu
h:commandButton action=#{testBean.action} value=Go/
Clicking the Go button will result in the validation error: Level:
'Unknown' must be convertible to an enum.
If the value of the select item is null, MyFaces won't render the value
attribute of the option and so the browser will submit the label as its value:
select id=levelForm:level name=levelForm:level size=1
option selected=selectedUnknown/option
option value=HIGHHigh/option
option value=MEDIUMMedium/option
option value=LOWLevel/option
/select
Mojarra instead renders an empty value attribute in this situation:
option value= selected=selectedUnknown/option
I've created a patch fixing this issue against the current trunk of
myfaces-shared and attached it to this ticket.
You can see the sample application reproducing this issue here:
http://github.com/chkal/myfaces-tests/tree/menu-null-value
And download it here:
http://github.com/chkal/myfaces-tests/archives/menu-null-value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2927) Invalid handling of null values in listboxes and menus
Invalid handling of null values in listboxes and menus
--
Key: MYFACES-2927
URL: https://issues.apache.org/jira/browse/MYFACES-2927
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.1
Reporter: Christian Kaltepoth
I discovered that MyFaces doesn't seem to handle null values correctly in
listboxes and menus.
See the following example showing a h:selectOneMenu used to select an enum
value:
@ManagedBean
@RequestScoped
public class TestBean {
public enum Level {
HIGH, MEDIUM, LOW
}
private Level level;
public String action() {
FacesContext.getCurrentInstance().addMessage(null,
new FacesMessage(Submitted level: + level));
return null;
}
}
And the following view:
h:selectOneMenu value=#{testBean.level} label=Level
f:selectItem itemValue=#{null} itemLabel=Unknown/
f:selectItem itemValue=HIGHitemLabel=High/
f:selectItem itemValue=MEDIUM itemLabel=Medium/
f:selectItem itemValue=LOW itemLabel=Level/
/h:selectOneMenu
h:commandButton action=#{testBean.action} value=Go/
Clicking the Go button will result in the validation error: Level: 'Unknown'
must be convertible to an enum.
If the value of the select item is null, MyFaces won't render the value
attribute of the option and so the browser will submit the label as its value:
select id=levelForm:level name=levelForm:level size=1
option selected=selectedUnknown/option
option value=HIGHHigh/option
option value=MEDIUMMedium/option
option value=LOWLevel/option
/select
Mojarra instead renders an empty value attribute in this situation:
option value= selected=selectedUnknown/option
I've created a patch fixing this issue against the current trunk of
myfaces-shared and attached it to this ticket.
You can see the sample application reproducing this issue here:
http://github.com/chkal/myfaces-tests/tree/menu-null-value
And download it here:
http://github.com/chkal/myfaces-tests/archives/menu-null-value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2865) ErrorPageWriter fails with NotSerializableException
[ https://issues.apache.org/jira/browse/MYFACES-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated MYFACES-2865: - Status: Patch Available (was: Open) ErrorPageWriter fails with NotSerializableException --- Key: MYFACES-2865 URL: https://issues.apache.org/jira/browse/MYFACES-2865 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Environment: Java 6u20, Tomcat 6.0.20 Reporter: Christian Kaltepoth Attachments: MYFACES-2865.patch My application is configured this way: * server-side state saving * disabled view state serialization * custom Spring scope for a view scope as described in Cagatay's blog (http://cagataycivici.wordpress.com/2010/02/17/port-jsf-2-0s-viewscope-to-spring-3-0/) If the ErrorPageWriter creates an error page and a non-serializable bean is in the view scope, the ErrorPageWriter fails with the following exception: java.io.NotSerializableException: one.of.my.beans at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at java.util.HashMap.writeObject(HashMap.java:1001) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1338) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1146) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.apache.myfaces.shared_impl.util.StateUtils.getAsByteArray(StateUtils.java:273) at org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:642) at org.apache.myfaces.renderkit.ErrorPageWriter.debugHtml(ErrorPageWriter.java:283) at org.apache.myfaces.renderkit.ErrorPageWriter.debugHtml(ErrorPageWriter.java:250) at org.apache.myfaces.renderkit.ErrorPageWriter.handleThrowable(ErrorPageWriter.java:417) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:274) [...] This exception completely masks the primary exception that caused the ErrorPageWriter to jump in. This makes it very difficult to find the root cause of the problem. The current workaround is to disable the MyFaces error handler by setting org.apache.myfaces.ERROR_HANDLING to 'false'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2865) ErrorPageWriter fails with NotSerializableException
ErrorPageWriter fails with NotSerializableException --- Key: MYFACES-2865 URL: https://issues.apache.org/jira/browse/MYFACES-2865 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Environment: Java 6u20, Tomcat 6.0.20 Reporter: Christian Kaltepoth My application is configured this way: * server-side state saving * disabled view state serialization * custom Spring scope for a view scope as described in Cagatay's blog (http://cagataycivici.wordpress.com/2010/02/17/port-jsf-2-0s-viewscope-to-spring-3-0/) If the ErrorPageWriter creates an error page and a non-serializable bean is in the view scope, the ErrorPageWriter fails with the following exception: java.io.NotSerializableException: one.of.my.beans at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at java.util.HashMap.writeObject(HashMap.java:1001) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1338) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1146) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.apache.myfaces.shared_impl.util.StateUtils.getAsByteArray(StateUtils.java:273) at org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:642) at org.apache.myfaces.renderkit.ErrorPageWriter.debugHtml(ErrorPageWriter.java:283) at org.apache.myfaces.renderkit.ErrorPageWriter.debugHtml(ErrorPageWriter.java:250) at org.apache.myfaces.renderkit.ErrorPageWriter.handleThrowable(ErrorPageWriter.java:417) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:274) [...] This exception completely masks the primary exception that caused the ErrorPageWriter to jump in. This makes it very difficult to find the root cause of the problem. The current workaround is to disable the MyFaces error handler by setting org.apache.myfaces.ERROR_HANDLING to 'false'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1438) t:selectOneRadio is broken when migrating from 1.1.8 to 1.1.9
[
https://issues.apache.org/jira/browse/TOMAHAWK-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12737855#action_12737855
]
Christian Kaltepoth commented on TOMAHAWK-1438:
---
I checked this issue but wasn't able to reproduce the problem with the
described environment (MyFaces Core 1.2.6 + Java6).
Tomahawk 1.1.8 and 1.1.9 both render the radio buttons correctly
even with an empty itemLabel.
There seems to be some other problem in your application that causes
this behavior. I'm very sorry, but I don't think we can help you
without a test case that can reproduce this issue.
t:selectOneRadio is broken when migrating from 1.1.8 to 1.1.9
---
Key: TOMAHAWK-1438
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1438
Project: MyFaces Tomahawk
Issue Type: Bug
Components: selectOneRadio / radio
Affects Versions: 1.1.9
Environment: windows xp, jsf 1.2.6, java 6
Reporter: reverttoconsole
I migrated from 1.1.8 to 1.1.9 to see if my application would be stable. On
one page, t:selectOneRadio buttons was not showing up at all. I researched
for a bit but couldn't find any solution. I don't think I can afford to test
every case for a migration so decided to drop the idea (we have our app in
production already).
I'm unable to give a test case but I can share the code used on the page:
t:selectOneRadio id=defaultPhoneType
value=${controller.preferedPhoneType} layout=spread
f:selectItem itemLabel= itemValue=HOME/
f:selectItem itemLabel= itemValue=WORK/
f:selectItem itemLabel= itemValue=CELL/
/t:selectOneRadio
!-- somewhere in the same page --
fieldset
legendspanxyz/span/legend
ul class=fieldRows phoneSet
li class=noteRow
Note: One preferred phone number is
required
/li
li class=phoneRow
t:outputLabel
value=#{dictionary.home} #{dictionary.phone}: styleClass=phonePrefLabel /
t:radio for=defaultPhoneType
index=0 / !-- this doesn't show up on 1.1.9 tomahawk but works in 1.1.8)
.
.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-41) NullPointerException in method findConversationContextId
[ https://issues.apache.org/jira/browse/ORCHESTRA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12732902#action_12732902 ] Christian Kaltepoth commented on ORCHESTRA-41: -- It seems like ORCHESTRA-34 wasn't fixed by adding a NPE check but by eliminating the cause of FrameworkAdapter.getCurrentInstance() returning null. See the SVN commit for ORCHESTRA-34: http://svn.apache.org/viewvc?view=revrevision=746706 Are you sure that this stack trace refers to Orchestra 1.3.1? An NPE seems possible with Orchestra 1.3 in line 140 of ConversationManager when FrameworkAdapter.getCurrentInstance() returns null: http://svn.apache.org/viewvc/myfaces/orchestra/tags/core-1_3/src/main/java/org/apache/myfaces/orchestra/conversation/ConversationManager.java?view=annotate But in 1.3.1 line 140 only contains a source code comment: http://svn.apache.org/viewvc/myfaces/orchestra/tags/core-1_3_1/src/main/java/org/apache/myfaces/orchestra/conversation/ConversationManager.java?view=annotate NullPointerException in method findConversationContextId Key: ORCHESTRA-41 URL: https://issues.apache.org/jira/browse/ORCHESTRA-41 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation, FrameworkAdapter Affects Versions: 1.3.1 Environment: Windows XP SP2, Tomcat 6.0.20 Reporter: Bozhidar Bozhanov Original Estimate: 0.08h Remaining Estimate: 0.08h After some time, (probably when a thread times-out) the following appears: Exception in thread org.apache.myfaces.orchestra.conversation.ConversationWiperThread java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.findConversationContextId(ConversationManager.java:140) at org.apache.myfaces.orchestra.conversation.ConversationManager.removeAndInvalidateConversationContext(ConversationManager.java:343) at org.apache.myfaces.orchestra.conversation.ConversationManager.checkTimeouts(ConversationManager.java:626) at org.apache.myfaces.orchestra.conversation.ConversationWiperThread._run(ConversationWiperThread.java:113) at org.apache.myfaces.orchestra.conversation.ConversationWiperThread.run(ConversationWiperThread.java:90) It doesn't bring any trouble to the front-end, but still, it is an exception :) The problem, I think is that the ThreadLocal variable (after the thread has timed-out) return null, so no conversationContext anymore. A little anti-NPE check in the findConversaionContextId would get rid of the exception. I'm not sure whether this happens in 1.3.1, I checked the source code in the repository and there was no NPE check, so I presume the issue is still there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-41) NullPointerException in method findConversationContextId
[ https://issues.apache.org/jira/browse/ORCHESTRA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12730059#action_12730059 ] Christian Kaltepoth commented on ORCHESTRA-41: -- Seems to be a duplicate of ORCHESTRA-34, which was fixed in 1.3.1. I would suggest that you try 1.3.1 and check if the issue still occurs. NullPointerException in method findConversationContextId Key: ORCHESTRA-41 URL: https://issues.apache.org/jira/browse/ORCHESTRA-41 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation, FrameworkAdapter Affects Versions: 1.3 Environment: Windows XP SP2, Tomcat 6.0.20 Reporter: Bozhidar Bozhanov Original Estimate: 0.08h Remaining Estimate: 0.08h After some time, (probably when a thread times-out) the following appears: Exception in thread org.apache.myfaces.orchestra.conversation.ConversationWiperThread java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.findConversationContextId(ConversationManager.java:140) at org.apache.myfaces.orchestra.conversation.ConversationManager.removeAndInvalidateConversationContext(ConversationManager.java:343) at org.apache.myfaces.orchestra.conversation.ConversationManager.checkTimeouts(ConversationManager.java:626) at org.apache.myfaces.orchestra.conversation.ConversationWiperThread._run(ConversationWiperThread.java:113) at org.apache.myfaces.orchestra.conversation.ConversationWiperThread.run(ConversationWiperThread.java:90) It doesn't bring any trouble to the front-end, but still, it is an exception :) The problem, I think is that the ThreadLocal variable (after the thread has timed-out) return null, so no conversationContext anymore. A little anti-NPE check in the findConversaionContextId would get rid of the exception. I'm not sure whether this happens in 1.3.1, I checked the source code in the repository and there was no NPE check, so I presume the issue is still there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1423) title:validateRegExpr with a4j:support does not display Summary message
[
https://issues.apache.org/jira/browse/TOMAHAWK-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712437#action_12712437
]
Christian Kaltepoth commented on TOMAHAWK-1423:
---
Which way do you use to declare you message bundle and which JSF version are
you using?
If you are on JSF 1.1 you must use a4j:loadBundle instead of f:loadBundle
to reference bundle messages during ajax re-rendering.
See:
http://www.jboss.org/file-access/default/members/jbossrichfaces/freezone/docs/devguide/en/html/a4j_loadBundle.html
title:validateRegExpr with a4j:support does not display Summary message
---
Key: TOMAHAWK-1423
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1423
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Validators
Affects Versions: 1.1.8
Reporter: Boryana Chavkova
When I am using validateRegExpr from version 1.1.8 and a4j tag library,
custom summary message and detail message don't display.
I debuged ValidationBase.class and found that getStringValue(FacesContext
context, ValueExpression vb) returns null when invoke onblur, but when
submit the form this returns correct value.
This is the code:
t:panelGroup id=fullNamePanel
t:inputText id=fullName forceId=true
value=#{mAdultSignUpBean.adult.bcard.fullName} required=true
t:validateRegExpr pattern=[a-zA-Z-\. ]{1,120}
summaryMessage=#{error['format.fullname']} /
a4j:support event=onblur reRender=fullNamePanel
ajaxSingle=true/
/t:inputText
t:message for=fullName styleClass=errormsg showDetail=true /
/t:panelGroup
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1902) Allow to use different ExpressionFactory implementation
[ https://issues.apache.org/jira/browse/MYFACES-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689197#action_12689197 ] Christian Kaltepoth commented on MYFACES-1902: -- Since I am very interested in this feature I have developed a fix for the issue. Find attached the patch against core12 trunk. The changes can be summarized as follows. The existing code for loading the custom ExpressionFactory has been moved from Jsp20FacesInitializer to AbstractFacesInitializer. Both AbstractFacesInitializer implementations now check for a custom ExpressionFactory by calling getUserDefinedExpressionFactory() before they proceed with their default behavior for finding the ExpressionFactory. I attached a small webapp for a proof of concept. The webapp can be started either in a JSP 2.1 or JSP 2.0 container by using different maven profiles. The demo shows basic features of JBossEL. See the webapp's source for details. Tomcat 6.0 (JSP 2.1) environment: # mvn -Ptomcat60 clean package cargo:start Tomcat 5.5 (JSP 2.0) environment: # mvn -Ptomcat55 clean package cargo:start The demo webapp can be accessed with this url: http://localhost:8080/eldemo/ Allow to use different ExpressionFactory implementation --- Key: MYFACES-1902 URL: https://issues.apache.org/jira/browse/MYFACES-1902 Project: MyFaces Core Issue Type: New Feature Components: Extension Feature Affects Versions: 1.2.4-SNAPSHOT Reporter: Christian Kaltepoth Assignee: Matthias Weßendorf Attachments: MYFACES-1902-webapp.zip, MYFACES-1902.patch It should be possible to use a different ExpressionFactory implementation. This feature is required to use 3rd party EL implementations like JBoss EL. Mojarra already supports this with the 'com.sun.faces.expressionFactory' context parameter. MyFaces Core 1.2.x already supports a context parameter 'org.apache.myfaces.EXPRESSION_FACTORY' but it is only evaluated in a JSP 2.0 environment (see MYFACES-1693 for details). It should be possible to use this parameter with JSP 2.1 as well. The corresponding code should be refactored from Jsp20FacesInitializer to AbstractFacesInitializer to be usable in both JSP 2.0 and 2.1. Discussion on myfaces-users: http://www.nabble.com/Replacing-expression-factory-td18867420.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1902) Allow to use different ExpressionFactory implementation
[ https://issues.apache.org/jira/browse/MYFACES-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated MYFACES-1902: - Status: Patch Available (was: Open) Allow to use different ExpressionFactory implementation --- Key: MYFACES-1902 URL: https://issues.apache.org/jira/browse/MYFACES-1902 Project: MyFaces Core Issue Type: New Feature Components: Extension Feature Affects Versions: 1.2.4-SNAPSHOT Reporter: Christian Kaltepoth Assignee: Matthias Weßendorf Attachments: MYFACES-1902-webapp.zip, MYFACES-1902.patch It should be possible to use a different ExpressionFactory implementation. This feature is required to use 3rd party EL implementations like JBoss EL. Mojarra already supports this with the 'com.sun.faces.expressionFactory' context parameter. MyFaces Core 1.2.x already supports a context parameter 'org.apache.myfaces.EXPRESSION_FACTORY' but it is only evaluated in a JSP 2.0 environment (see MYFACES-1693 for details). It should be possible to use this parameter with JSP 2.1 as well. The corresponding code should be refactored from Jsp20FacesInitializer to AbstractFacesInitializer to be usable in both JSP 2.0 and 2.1. Discussion on myfaces-users: http://www.nabble.com/Replacing-expression-factory-td18867420.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1902) Allow to use different ExpressionFactory implementation
Allow to use different ExpressionFactory implementation --- Key: MYFACES-1902 URL: https://issues.apache.org/jira/browse/MYFACES-1902 Project: MyFaces Core Issue Type: New Feature Components: Extension Feature Affects Versions: 1.2.4-SNAPSHOT Reporter: Christian Kaltepoth It should be possible to use a different ExpressionFactory implementation. This feature is required to use 3rd party EL implementations like JBoss EL. Mojarra already supports this with the 'com.sun.faces.expressionFactory' context parameter. MyFaces Core 1.2.x already supports a context parameter 'org.apache.myfaces.EXPRESSION_FACTORY' but it is only evaluated in a JSP 2.0 environment (see MYFACES-1693 for details). It should be possible to use this parameter with JSP 2.1 as well. The corresponding code should be refactored from Jsp20FacesInitializer to AbstractFacesInitializer to be usable in both JSP 2.0 and 2.1. Discussion on myfaces-users: http://www.nabble.com/Replacing-expression-factory-td18867420.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1891) ClassCastException in converter when Hiding / Showing unselected selectOneRadio
[
https://issues.apache.org/jira/browse/MYFACES-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12612418#action_12612418
]
Christian Kaltepoth commented on MYFACES-1891:
--
I have experienced similar problems dealing with the selectOneRadio component.
The root of these issues seems to be RendererUtils.NOTHING which is not handled
correctly in all cases. The stacktrace shows, that this special constant is
passed to the IntegerConverter for conversion.
See MYFACES-1567 for a similar issue with RendererUtils.NOTHING.
ClassCastException in converter when Hiding / Showing unselected
selectOneRadio
---
Key: MYFACES-1891
URL: https://issues.apache.org/jira/browse/MYFACES-1891
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Environment: MyFaces 1.2.3, Spring WebFlow 2.0.2, RichFaces 3.2.1,
Tomahawk 1.1.6, Facelets 1.1.15.B1, Tomcat 6.0.16
Reporter: Patrick Schmidt
Attachments: example.zip
See the attached example.
When the block with the selectOneRadio ist shown, then hidden and then shown
again a ClassCastException occurs in the Converter. The selectOneRadio has as
submittedValue org.apache.myfaces.shared_impl.renderkit.RendererUtils$1, for
which the conversion is done.
javax.faces.FacesException: Exception while calling encodeEnd on component :
{Component-Path : [Class: org.ajax4jsf.component.AjaxViewRoot,ViewId:
/WEB-INF/pages/schnellerfassung/dea/dea.xhtml][Class:
javax.faces.component.html.HtmlForm,Id: form][Class:
org.apache.myfaces.custom.div.Div,Id: hideableBlock][Class:
javax.faces.component.html.HtmlSelectOneRadio,Id: selectOneRadio]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:610)
at
org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:286)
at
org.ajax4jsf.renderkit.RendererBase.renderChildren(RendererBase.java:262)
at
org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:284)
at
org.ajax4jsf.renderkit.RendererBase.renderChildren(RendererBase.java:262)
at
org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:284)
at
org.ajax4jsf.renderkit.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:125)
at
org.ajax4jsf.renderkit.AjaxChildrenRenderer.encodeAjaxChildren(AjaxChildrenRenderer.java:68)
at
org.ajax4jsf.renderkit.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:116)
at
org.ajax4jsf.renderkit.AjaxContainerRenderer.encodeAjax(AjaxContainerRenderer.java:123)
at org.ajax4jsf.component.AjaxViewRoot.encodeAjax(AjaxViewRoot.java:673)
at
org.ajax4jsf.component.AjaxViewRoot.encodeChildren(AjaxViewRoot.java:544)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:239)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
at
org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at
org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:189)
at org.springframework.faces.webflow.JsfView.render(JsfView.java:92)
at
org.springframework.webflow.engine.ViewState.render(ViewState.java:240)
at
org.springframework.webflow.engine.ViewState.resume(ViewState.java:199)
at org.springframework.webflow.engine.Flow.resume(Flow.java:535)
at
org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:261)
at
org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:153)
at
org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:173)
at
org.springframework.webflow.mvc.servlet.FlowController.handleRequest(FlowController.java:172)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
[jira] Commented: (TOMAHAWK-64) Allow t:htmlTag to support an attributes string.
[ https://issues.apache.org/jira/browse/TOMAHAWK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611509#action_12611509 ] Christian Kaltepoth commented on TOMAHAWK-64: - This was necessary to access the f:param child components. I'm using HtmlComponentUtils.getParamterMap() that iterates over all child components. In my test setup (core-1.1 with JSP) this map only contained values when the component rendered its children. I thought this is expected behavior at least when using JSP. The javadocs of UIComponentBase say: When this is true [getRendersChildren()]: This component's encodeBegin method will only be called after all the child components have been created and added to this component. See: http://myfaces.apache.org/core12/myfaces-api/apidocs/javax/faces/component/UIComponentBase.html#getRendersChildren() Or do I misunderstand something here? Allow t:htmlTag to support an attributes string. Key: TOMAHAWK-64 URL: https://issues.apache.org/jira/browse/TOMAHAWK-64 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Tag Reporter: Michael Rimov Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.7-SNAPSHOT Attachments: htmltag_param_feature.patch I would really like to see t:htmlTag to allow html attributes to be passed into the html tag. A concrete example: td colspan=2 Hello World /td Would Ideally (to me) be converted to: t:htmlTag value=td attributes=colspan='2' h:outputText value=Hello World/ /t:htmlTag Thanks! :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-64) Allow t:htmlTag to support an attributes string.
[ https://issues.apache.org/jira/browse/TOMAHAWK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611521#action_12611521 ] Christian Kaltepoth commented on TOMAHAWK-64: - I agree that breaking backward-compatibility is a deal-breaker in this case. Unfortunately I did not realize the consequences of changing the rending behavior of the component when I wrote the patch. Allow t:htmlTag to support an attributes string. Key: TOMAHAWK-64 URL: https://issues.apache.org/jira/browse/TOMAHAWK-64 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Tag Reporter: Michael Rimov Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.7-SNAPSHOT Attachments: htmltag_param_feature.patch I would really like to see t:htmlTag to allow html attributes to be passed into the html tag. A concrete example: td colspan=2 Hello World /td Would Ideally (to me) be converted to: t:htmlTag value=td attributes=colspan='2' h:outputText value=Hello World/ /t:htmlTag Thanks! :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1295) t:radio should render 'id' html attribute
t:radio should render 'id' html attribute --- Key: TOMAHAWK-1295 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1295 Project: MyFaces Tomahawk Issue Type: New Feature Components: selectOneRadio / radio Affects Versions: 1.1.7-SNAPSHOT Reporter: Christian Kaltepoth Priority: Minor Attachments: t_radio_render_id.patch Currently t:radio does not render its id. This prevents usage of html label tags attached to the radio button. The feature is already present in HtmlRadioRendererBase.renderRadio() and can be activated with the boolean flag 'renderId'. This patch contains the required change for the extended HtmlRadioRenderer and an update for myfaces-example-simple webapp. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1295) t:radio should render 'id' html attribute
[ https://issues.apache.org/jira/browse/TOMAHAWK-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated TOMAHAWK-1295: -- Status: Patch Available (was: Open) t:radio should render 'id' html attribute --- Key: TOMAHAWK-1295 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1295 Project: MyFaces Tomahawk Issue Type: New Feature Components: selectOneRadio / radio Affects Versions: 1.1.7-SNAPSHOT Reporter: Christian Kaltepoth Priority: Minor Attachments: t_radio_render_id.patch Currently t:radio does not render its id. This prevents usage of html label tags attached to the radio button. The feature is already present in HtmlRadioRendererBase.renderRadio() and can be activated with the boolean flag 'renderId'. This patch contains the required change for the extended HtmlRadioRenderer and an update for myfaces-example-simple webapp. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-64) Allow t:htmlTag to support an attributes string.
[ https://issues.apache.org/jira/browse/TOMAHAWK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607496#action_12607496 ] Christian Kaltepoth commented on TOMAHAWK-64: - Thank you very much for looking into the patch and applying it to tomahawk12. I'm sorry I didn't notice the problem of the broken example in htmlTag.jsp with core11. One last question just to clear things up: I am aware of the problem with HTML code and f:verbatim tags in the 1.1 spec. So it seems to me, that the original code in htmlTag.jsp isn't correct: t:htmlTag value=h1bh1/b tag./t:htmlTag As HTML code has to be surrounded by a f:verbatim tag, this code should look like this: t:htmlTag value=h1f:verbatimbh1/b tag./f:verbatim/t:htmlTag In this case my code works without issues. The version without f:verbatim tags seems to break, because the component was modified to render the children itself. Unfortunately the patch would certainly break existing JSF 1.1 pages that were build according to the old example. Allow t:htmlTag to support an attributes string. Key: TOMAHAWK-64 URL: https://issues.apache.org/jira/browse/TOMAHAWK-64 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Tag Reporter: Michael Rimov Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.7-SNAPSHOT Attachments: htmltag_param_feature.patch I would really like to see t:htmlTag to allow html attributes to be passed into the html tag. A concrete example: td colspan=2 Hello World /td Would Ideally (to me) be converted to: t:htmlTag value=td attributes=colspan='2' h:outputText value=Hello World/ /t:htmlTag Thanks! :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-64) Allow t:htmlTag to support an attributes string.
[ https://issues.apache.org/jira/browse/TOMAHAWK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607301#action_12607301 ] Christian Kaltepoth commented on TOMAHAWK-64: - I think Vytauta's idea of nested f:param tags for t:htmlTag can be very useful for people working with legacy JSF 1.1 w/ JSP applications. And I also think, that the number of voters for this issue proves this. :-) I implemented this feature and attached a patch against current tomahawk trunk. The patch also includes updated documentation and a small example for myfaces-example-simple. Allow t:htmlTag to support an attributes string. Key: TOMAHAWK-64 URL: https://issues.apache.org/jira/browse/TOMAHAWK-64 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Tag Reporter: Michael Rimov Priority: Minor Attachments: htmltag_param_feature.patch I would really like to see t:htmlTag to allow html attributes to be passed into the html tag. A concrete example: td colspan=2 Hello World /td Would Ideally (to me) be converted to: t:htmlTag value=td attributes=colspan='2' h:outputText value=Hello World/ /t:htmlTag Thanks! :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1050) NullPointerException in s:ifMessage/
[ https://issues.apache.org/jira/browse/TOMAHAWK-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated TOMAHAWK-1050: -- Status: Patch Available (was: Open) NullPointerException in s:ifMessage/ -- Key: TOMAHAWK-1050 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1050 Project: MyFaces Tomahawk Issue Type: Bug Components: Message(s) Affects Versions: 1.1.6 Reporter: Christian Kaltepoth Fix For: 1.1.7-SNAPSHOT Omitting the 'for' attribute using s:ifMessage/ causes a NullPointerException although the attribute is declared as 'not required' in the TLD: Caused by: java.lang.NullPointerException at java.util.StringTokenizer.init(StringTokenizer.java:182) at java.util.StringTokenizer.init(StringTokenizer.java:204) at org.apache.myfaces.custom.ifmessage.IfMessage.encodeChildren(IfMessage.java:75) at org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:414) at org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:400) at org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:78) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:539) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:498) at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:366) at org.apache.myfaces.shared_impl.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:57) at org.apache.jsp.test_jsp._jspx_meth_h_panelGroup_0(org.apache.jsp.test_jsp:230) at org.apache.jsp.test_jsp._jspx_meth_h_form_0(org.apache.jsp.test_jsp:157) at org.apache.jsp.test_jsp._jspx_meth_f_view_0(org.apache.jsp.test_jsp:125) at org.apache.jsp.test_jsp._jspService(org.apache.jsp.test_jsp:89) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) ... 33 more The attached patch solves this problem. The component now considers messages for _all_ components if the for attribute is not used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1050) NullPointerException in s:ifMessage/
NullPointerException in s:ifMessage/ -- Key: TOMAHAWK-1050 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1050 Project: MyFaces Tomahawk Issue Type: Bug Components: Message(s) Affects Versions: 1.1.6 Reporter: Christian Kaltepoth Fix For: 1.1.7-SNAPSHOT Omitting the 'for' attribute using s:ifMessage/ causes a NullPointerException although the attribute is declared as 'not required' in the TLD: Caused by: java.lang.NullPointerException at java.util.StringTokenizer.init(StringTokenizer.java:182) at java.util.StringTokenizer.init(StringTokenizer.java:204) at org.apache.myfaces.custom.ifmessage.IfMessage.encodeChildren(IfMessage.java:75) at org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:414) at org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:400) at org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:78) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:539) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:498) at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:366) at org.apache.myfaces.shared_impl.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:57) at org.apache.jsp.test_jsp._jspx_meth_h_panelGroup_0(org.apache.jsp.test_jsp:230) at org.apache.jsp.test_jsp._jspx_meth_h_form_0(org.apache.jsp.test_jsp:157) at org.apache.jsp.test_jsp._jspx_meth_f_view_0(org.apache.jsp.test_jsp:125) at org.apache.jsp.test_jsp._jspService(org.apache.jsp.test_jsp:89) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) ... 33 more The attached patch solves this problem. The component now considers messages for _all_ components if the for attribute is not used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-934) Email validator allows whitespace
[ https://issues.apache.org/jira/browse/TOMAHAWK-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481941 ] Christian Kaltepoth commented on TOMAHAWK-934: -- This bug is caused by commons-validator prior to 1.3.0. See: http://issues.apache.org/jira/browse/VALIDATOR-50 Upgrading commons-validator will fix this problem. Email validator allows whitespace - Key: TOMAHAWK-934 URL: https://issues.apache.org/jira/browse/TOMAHAWK-934 Project: MyFaces Tomahawk Issue Type: Bug Components: Validators Affects Versions: 1.1.5-SNAPSHOT Environment: Windows XP JBoss 4.0.5 Reporter: Daniel Ray Email validator allows white space in an email address i.e. test(space)@email.com is considered valid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-935) Add 'decay' attribute to AutoUpdateDataTable
Add 'decay' attribute to AutoUpdateDataTable Key: TOMAHAWK-935 URL: https://issues.apache.org/jira/browse/TOMAHAWK-935 Project: MyFaces Tomahawk Issue Type: New Feature Components: AutoUpdateDataTable Affects Versions: 1.1.5-SNAPSHOT Reporter: Christian Kaltepoth Priority: Minor The attached patch adds support for the 'decay' attribute to AutoUpdateDataTable. It defines the rate at which the request interval grows when the response is unchanged. The decay feature was already part of Prototype's 'Ajax.PeriodicalUpdater' but was not accessible from the s:autoUpdateDataTable/ tag. I think access to this feature will be quite useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-145) Firefox fails to render autoUpdateDataTable styles specified by the rowClasses attribute
[ https://issues.apache.org/jira/browse/TOMAHAWK-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated TOMAHAWK-145: - Status: Patch Available (was: Reopened) Firefox fails to render autoUpdateDataTable styles specified by the rowClasses attribute Key: TOMAHAWK-145 URL: https://issues.apache.org/jira/browse/TOMAHAWK-145 Project: MyFaces Tomahawk Issue Type: Bug Components: AutoUpdateDataTable Environment: Tested on Windows XP, IE 6.0 - nightly build from Sep. 7, 2005 Reporter: Sh Ma Assigned To: Martin Marinschek Priority: Minor Attachments: sandbox.war CSS styles specified by using the rowClasses attribute are not displayed. For example, I have something like: x:autoUpdateDataTable rowClasses=oddRow,evenRow ... Although both oddRow and evenRow are specified in the rendered HTML - for example: tr class=oddRow... ...Firefox doesn't render the rows according to the specified CSS style. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
