[
https://issues.apache.org/jira/browse/MYFACES-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe reopened MYFACES-4003:
-------------------------------------
There is a small problem with the location of testClassAttribute.xhtml . It
should be on the same folder in src/test/resources as the package name of the
Test class.
It looks like the related issue in Mojarra is:
https://java.net/jira/browse/JAVASERVERFACES-3025
Since facelets 1.1.x, this rule was in
org.apache.myfaces.view.facelets.tag.jsf.html.HtmlComponentHandler. The old
rule is still there, but the new case is justified and I can't imagine a case
where this change could cause a problem. After all, you can always override the
metadata ruleset.
> Allow the "class" Attribute To Be Set For Custom Tags
> -----------------------------------------------------
>
> Key: MYFACES-4003
> URL: https://issues.apache.org/jira/browse/MYFACES-4003
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.2.8
> Environment: Tomcat 8.0.21, MyFaces 2.2.8
> Reporter: Bill Lucy
> Assignee: Bill Lucy
> Priority: Minor
> Fix For: 2.2.9-SNAPSHOT
>
> Attachments: JSFClassTagTest.war, myfaces-4003.patch
>
>
> For native JSF tags, setting the "class" attribute performs as you'd expect;
> however, in user-defined tags, setting the "class" attribute results in the
> following exception:
> java.lang.IllegalArgumentException: Component property class is not writable
> Which is how we've behaved traditionally. Using the "styleClass" attribute
> instead does work as expected.
> Mojarra supports setting the "class" attribute as of 2.2.9. Additionally,
> the same issue was fixed in MYFACES-3874 for jsf:class.
> Changing the behavior of MyFaces here - to allow for custom components to
> accept the "class" attribute without Exceptions - should be fairly trivial,
> along the lines of MYFACES-3874.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
