[jira] [Created] (TRINIDAD-2379) Trinidad does not work properly with h:form
Tomas Havelka created TRINIDAD-2379: --- Summary: Trinidad does not work properly with h:form Key: TRINIDAD-2379 URL: https://issues.apache.org/jira/browse/TRINIDAD-2379 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core, 2.1.0-core Environment: Glassfish 3, Mojarra Reporter: Tomas Havelka Trinidad does not support the JSF's standard h:form component. 1) When this form is used, the Ajax functionality of some components is crashed. It's because FormData object is not initialized at all when using the component. This object is initialized with code in UIXComponent during render phase by the method visitTree, but the is not instance of that Trinidad specific component. So the FormData object is not created and the component behavior is crashed. 2) Trinidad does not support functionality. In this case, the null prefix for the component is rendered. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOBAGO-1256) No default markups for tc:file available
Udo Schnurpfeil created TOBAGO-1256: --- Summary: No default markups for tc:file available Key: TOBAGO-1256 URL: https://issues.apache.org/jira/browse/TOBAGO-1256 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.5.9 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Trivial -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TOBAGO-1256) No default markups for tc:file available
[ https://issues.apache.org/jira/browse/TOBAGO-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1256. - Resolution: Fixed Fix Version/s: 1.5.10 > No default markups for tc:file available > > > Key: TOBAGO-1256 > URL: https://issues.apache.org/jira/browse/TOBAGO-1256 > Project: MyFaces Tobago > Issue Type: Bug >Affects Versions: 1.5.9 >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Trivial > Fix For: 1.5.10 > > > There is missing this entry in the tobago-config.xml of the standard theme: > > File > > disabled > readonly > required > fatal > error > warn > info > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Wiki Spam
I don't have time to do much testing of this right now, but Gavin has reconfigured our wiki. I've added Leonardo as an administrator as his is the only other wiki id that I know. I searched my mailbox for recent wiki contributors and added them to the ContributorsGroup. If you send me your wiki id, I'll add you as either a contributor or administrator as desired when I get back later today. It'd be nice to have a few more administrators listed just in case. On Tue, Apr 23, 2013 at 11:22 AM, Matt Cooper wrote: > Thank you Mike for getting this going! > > > On Tue, Apr 23, 2013 at 8:32 AM, Mike Kienenberger > wrote: >> >> I've requested Infra to help us make this happen. >> >> https://issues.apache.org/jira/browse/INFRA-6191 >> >> On Mon, Apr 22, 2013 at 10:04 AM, Mike Kienenberger >> wrote: >> > So I've been poking around for a while to try to set up >> > AdminGroup/ContributorsGroup, and I know what the pages should look >> > like. >> > >> > But I don't currently have the permissions to make the changes myself. >> > >> > http://wiki.apache.org/general/HowToBeWikiAdministrator >> > >> > Does anyone here already have Wiki Administrator permissions? >> > >> > Or apsite permission on minotaur? >> > >> > If not, I'll need to contact infrastructure. >> > >> > On Fri, Apr 19, 2013 at 4:19 PM, Mike Kienenberger >> > wrote: >> >> My recommendation is that we set up an AdminGroup, probably with all >> >> committers in it. >> >> >> >> Then we add additional people to the ContributorsGroup as desired. >> >> >> >> >> >> http://wiki.apache.org/general/WikiFrequentlyAskedQuestions >> >> >> >> http://wiki.apache.org/general/OurWikiFarm >> >> = >> >> per wiki access control - tighten your wiki just a little, benefit just >> >> a lot >> >> >> >> Long sub-title for a fairly long subject. >> >> >> >> The MoinMoin wiki is very configurable, more so than some might think. >> >> Of course, wikis are meant to be open, for complete and utter open >> >> collaboration. That is appreciated. However, there are some that would >> >> like a balance between open wiki and having to spend time cleaning up >> >> spam each week. Times change, and the reality is, spammers are here >> >> and in greater numbers than before. What can we do? Well, here is a >> >> suggestion - and one that can be easily implemented and takes but 2 >> >> minutes (for infra) to set up. >> >> >> >> Have your project wiki editable only by a custom trusted group - that >> >> need not be committers only - it can in fact still be anybody who >> >> wants to edit your wiki, they just need to ask one time for edit >> >> access and thats it. Is this an incovenience? To ask once for access, >> >> I don't think so. After all as a potential contributor to your wiki >> >> you (project) will already be conversing with the potential >> >> contributor via the mailing lists right? How much pain is it to add >> >> someone to the custom trusted group once it has been set up? , no pain >> >> at all, a member of the projects AdminGroup edits one wiki page, adds >> >> the users WikiuserName to the bottom of the list and save the page! 10 >> >> seconds maybe and your done. For the amount of times you will have to >> >> do that as opposed to the amount of times you spend cleaning up spam - >> >> you work out which is better. >> >> >> >> The spamassassin wiki is a good example - those in the project wikis >> >> AdminGroup can add folks to the projects ContributorsGroup and that's >> >> it. How much spam has spamassassin received since this was setup ? >> >> Zero, Zilch, Nil, Nada. >> >> >> >> Remember also, any page can have its own access control which >> >> overrides and per wiki and per farm defaults - This page does just >> >> that, as does LocalBadContent and BadContent pages. >> >> = >> >> >> >> >> >> >> >> On Fri, Apr 19, 2013 at 3:47 PM, Mike Kienenberger >> >> wrote: >> >>> Probably it's time to enable some kind of protection for the wiki. >> >>> >> >>> I've been hoping to avoid that, but the amount of spam the past two >> >>> weeks has finally exceeded my willingness to continue fixing by hand. >> >>> >> >>> Is anyone who is subscribed to infrastructure willing to look into >> >>> this? If no takers, I guess I'll sign up and see what can be done. >> >>> >> >>> >> >>> On Fri, Apr 19, 2013 at 3:41 PM, Cagatay Civici >> >>> wrote: >> Hi, >> >> Does anyone know how can I unsubscribe from wiki as it is full of >> spam >> everyday. >> >> Thanks, >> >> Cagatay Civici >> PrimeFaces Lead >> www.primefaces.org >> > >
[jira] [Created] (TOBAGO-1257) The ObjectRenderer should produce HTML5 conform code
Udo Schnurpfeil created TOBAGO-1257: --- Summary: The ObjectRenderer should produce HTML5 conform code Key: TOBAGO-1257 URL: https://issues.apache.org/jira/browse/TOBAGO-1257 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.5.9, 1.6.0-beta-2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Trivial The tag may no longer contain HTML tags. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TOBAGO-1257) The ObjectRenderer should produce HTML5 conform code
[ https://issues.apache.org/jira/browse/TOBAGO-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1257. - Resolution: Fixed Fix Version/s: 2.0.0 2.0.0-alpha-1 1.5.10 > The ObjectRenderer should produce HTML5 conform code > > > Key: TOBAGO-1257 > URL: https://issues.apache.org/jira/browse/TOBAGO-1257 > Project: MyFaces Tobago > Issue Type: Bug > Components: Themes >Affects Versions: 1.6.0-beta-2, 1.5.9 >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Trivial > Fix For: 1.5.10, 2.0.0-alpha-1, 2.0.0 > > > The tag may no longer contain HTML tags. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions
[ https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640441#comment-13640441 ] Dora Rajappan commented on MYFACES-1892: Can I commit this code? I have no developer access to svn > validator element in faces-config should support nested attribute and > property definitions > -- > > Key: MYFACES-1892 > URL: https://issues.apache.org/jira/browse/MYFACES-1892 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.2.3 >Reporter: Simon Kitching > Attachments: MYFACES-1892.patch, MYFACES-1892.patch > > > As shown in this dtd: > http://java.sun.com/dtd/web-facesconfig_1_1.dtd > the validator element in a faces-config.xml file should support nested > attribute and property elements: > >xyValidtor >com.xy.XyValidator > > length > java.lang.Integer > 40 > > > However this appears to never have been implemented in either 1.1.x or 1.2.x > of core; only validator-id and validator-class are supported. Note that the > equivalent feature exists for converters, and does appear to have been > implemented. > See the digester rules registered in the constructor for class > org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl > Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Wiki Spam
Mike, as far as I know I have been the other guy deleting spam pages. You can add me as an administrator if you like, id MattBenson. Matt On Wed, Apr 24, 2013 at 7:45 AM, Mike Kienenberger wrote: > I don't have time to do much testing of this right now, but Gavin has > reconfigured our wiki. > > I've added Leonardo as an administrator as his is the only other wiki > id that I know. > > I searched my mailbox for recent wiki contributors and added them to > the ContributorsGroup. > > If you send me your wiki id, I'll add you as either a contributor or > administrator as desired when I get back later today. > It'd be nice to have a few more administrators listed just in case. > > > > > On Tue, Apr 23, 2013 at 11:22 AM, Matt Cooper wrote: > > Thank you Mike for getting this going! > > > > > > On Tue, Apr 23, 2013 at 8:32 AM, Mike Kienenberger > > wrote: > >> > >> I've requested Infra to help us make this happen. > >> > >> https://issues.apache.org/jira/browse/INFRA-6191 > >> > >> On Mon, Apr 22, 2013 at 10:04 AM, Mike Kienenberger > > >> wrote: > >> > So I've been poking around for a while to try to set up > >> > AdminGroup/ContributorsGroup, and I know what the pages should look > >> > like. > >> > > >> > But I don't currently have the permissions to make the changes myself. > >> > > >> > http://wiki.apache.org/general/HowToBeWikiAdministrator > >> > > >> > Does anyone here already have Wiki Administrator permissions? > >> > > >> > Or apsite permission on minotaur? > >> > > >> > If not, I'll need to contact infrastructure. > >> > > >> > On Fri, Apr 19, 2013 at 4:19 PM, Mike Kienenberger < > mkien...@gmail.com> > >> > wrote: > >> >> My recommendation is that we set up an AdminGroup, probably with all > >> >> committers in it. > >> >> > >> >> Then we add additional people to the ContributorsGroup as desired. > >> >> > >> >> > >> >> http://wiki.apache.org/general/WikiFrequentlyAskedQuestions > >> >> > >> >> http://wiki.apache.org/general/OurWikiFarm > >> >> = > >> >> per wiki access control - tighten your wiki just a little, benefit > just > >> >> a lot > >> >> > >> >> Long sub-title for a fairly long subject. > >> >> > >> >> The MoinMoin wiki is very configurable, more so than some might > think. > >> >> Of course, wikis are meant to be open, for complete and utter open > >> >> collaboration. That is appreciated. However, there are some that > would > >> >> like a balance between open wiki and having to spend time cleaning up > >> >> spam each week. Times change, and the reality is, spammers are here > >> >> and in greater numbers than before. What can we do? Well, here is a > >> >> suggestion - and one that can be easily implemented and takes but 2 > >> >> minutes (for infra) to set up. > >> >> > >> >> Have your project wiki editable only by a custom trusted group - that > >> >> need not be committers only - it can in fact still be anybody who > >> >> wants to edit your wiki, they just need to ask one time for edit > >> >> access and thats it. Is this an incovenience? To ask once for access, > >> >> I don't think so. After all as a potential contributor to your wiki > >> >> you (project) will already be conversing with the potential > >> >> contributor via the mailing lists right? How much pain is it to add > >> >> someone to the custom trusted group once it has been set up? , no > pain > >> >> at all, a member of the projects AdminGroup edits one wiki page, adds > >> >> the users WikiuserName to the bottom of the list and save the page! > 10 > >> >> seconds maybe and your done. For the amount of times you will have to > >> >> do that as opposed to the amount of times you spend cleaning up spam > - > >> >> you work out which is better. > >> >> > >> >> The spamassassin wiki is a good example - those in the project wikis > >> >> AdminGroup can add folks to the projects ContributorsGroup and that's > >> >> it. How much spam has spamassassin received since this was setup ? > >> >> Zero, Zilch, Nil, Nada. > >> >> > >> >> Remember also, any page can have its own access control which > >> >> overrides and per wiki and per farm defaults - This page does just > >> >> that, as does LocalBadContent and BadContent pages. > >> >> = > >> >> > >> >> > >> >> > >> >> On Fri, Apr 19, 2013 at 3:47 PM, Mike Kienenberger < > mkien...@gmail.com> > >> >> wrote: > >> >>> Probably it's time to enable some kind of protection for the wiki. > >> >>> > >> >>> I've been hoping to avoid that, but the amount of spam the past two > >> >>> weeks has finally exceeded my willingness to continue fixing by > hand. > >> >>> > >> >>> Is anyone who is subscribed to infrastructure willing to look into > >> >>> this? If no takers, I guess I'll sign up and see what can be done. > >> >>> > >> >>> > >> >>> On Fri, Apr 19, 2013 at 3:41 PM, Cagatay Civici > >> >>> wrote: > >> Hi, > >> > >> Does anyone know how can I unsubscribe from wiki as it is full of > >> spam > >> everyday. > >> > >>
Re: Wiki Spam
Thanks, Matt. I've added your as an administrator. On Wed, Apr 24, 2013 at 10:19 AM, Matt Benson wrote: > Mike, as far as I know I have been the other guy deleting spam pages. You > can add me as an administrator if you like, id MattBenson. > > Matt > > > On Wed, Apr 24, 2013 at 7:45 AM, Mike Kienenberger > wrote: >> >> I don't have time to do much testing of this right now, but Gavin has >> reconfigured our wiki. >> >> I've added Leonardo as an administrator as his is the only other wiki >> id that I know. >> >> I searched my mailbox for recent wiki contributors and added them to >> the ContributorsGroup. >> >> If you send me your wiki id, I'll add you as either a contributor or >> administrator as desired when I get back later today. >> It'd be nice to have a few more administrators listed just in case. >> >> >> >> >> On Tue, Apr 23, 2013 at 11:22 AM, Matt Cooper wrote: >> > Thank you Mike for getting this going! >> > >> > >> > On Tue, Apr 23, 2013 at 8:32 AM, Mike Kienenberger >> > wrote: >> >> >> >> I've requested Infra to help us make this happen. >> >> >> >> https://issues.apache.org/jira/browse/INFRA-6191 >> >> >> >> On Mon, Apr 22, 2013 at 10:04 AM, Mike Kienenberger >> >> >> >> wrote: >> >> > So I've been poking around for a while to try to set up >> >> > AdminGroup/ContributorsGroup, and I know what the pages should look >> >> > like. >> >> > >> >> > But I don't currently have the permissions to make the changes >> >> > myself. >> >> > >> >> > http://wiki.apache.org/general/HowToBeWikiAdministrator >> >> > >> >> > Does anyone here already have Wiki Administrator permissions? >> >> > >> >> > Or apsite permission on minotaur? >> >> > >> >> > If not, I'll need to contact infrastructure. >> >> > >> >> > On Fri, Apr 19, 2013 at 4:19 PM, Mike Kienenberger >> >> > >> >> > wrote: >> >> >> My recommendation is that we set up an AdminGroup, probably with all >> >> >> committers in it. >> >> >> >> >> >> Then we add additional people to the ContributorsGroup as desired. >> >> >> >> >> >> >> >> >> http://wiki.apache.org/general/WikiFrequentlyAskedQuestions >> >> >> >> >> >> http://wiki.apache.org/general/OurWikiFarm >> >> >> = >> >> >> per wiki access control - tighten your wiki just a little, benefit >> >> >> just >> >> >> a lot >> >> >> >> >> >> Long sub-title for a fairly long subject. >> >> >> >> >> >> The MoinMoin wiki is very configurable, more so than some might >> >> >> think. >> >> >> Of course, wikis are meant to be open, for complete and utter open >> >> >> collaboration. That is appreciated. However, there are some that >> >> >> would >> >> >> like a balance between open wiki and having to spend time cleaning >> >> >> up >> >> >> spam each week. Times change, and the reality is, spammers are here >> >> >> and in greater numbers than before. What can we do? Well, here is a >> >> >> suggestion - and one that can be easily implemented and takes but 2 >> >> >> minutes (for infra) to set up. >> >> >> >> >> >> Have your project wiki editable only by a custom trusted group - >> >> >> that >> >> >> need not be committers only - it can in fact still be anybody who >> >> >> wants to edit your wiki, they just need to ask one time for edit >> >> >> access and thats it. Is this an incovenience? To ask once for >> >> >> access, >> >> >> I don't think so. After all as a potential contributor to your wiki >> >> >> you (project) will already be conversing with the potential >> >> >> contributor via the mailing lists right? How much pain is it to add >> >> >> someone to the custom trusted group once it has been set up? , no >> >> >> pain >> >> >> at all, a member of the projects AdminGroup edits one wiki page, >> >> >> adds >> >> >> the users WikiuserName to the bottom of the list and save the page! >> >> >> 10 >> >> >> seconds maybe and your done. For the amount of times you will have >> >> >> to >> >> >> do that as opposed to the amount of times you spend cleaning up spam >> >> >> - >> >> >> you work out which is better. >> >> >> >> >> >> The spamassassin wiki is a good example - those in the project wikis >> >> >> AdminGroup can add folks to the projects ContributorsGroup and >> >> >> that's >> >> >> it. How much spam has spamassassin received since this was setup ? >> >> >> Zero, Zilch, Nil, Nada. >> >> >> >> >> >> Remember also, any page can have its own access control which >> >> >> overrides and per wiki and per farm defaults - This page does just >> >> >> that, as does LocalBadContent and BadContent pages. >> >> >> = >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Apr 19, 2013 at 3:47 PM, Mike Kienenberger >> >> >> >> >> >> wrote: >> >> >>> Probably it's time to enable some kind of protection for the wiki. >> >> >>> >> >> >>> I've been hoping to avoid that, but the amount of spam the past two >> >> >>> weeks has finally exceeded my willingness to continue fixing by >> >> >>> hand. >> >> >>> >> >> >>> Is anyone who is subscribed to infrastructure willing to look into >> >> >>> t
[jira] [Commented] (TOBAGO-1257) The ObjectRenderer should produce HTML5 conform code
[ https://issues.apache.org/jira/browse/TOBAGO-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640595#comment-13640595 ] Hudson commented on TOBAGO-1257: Integrated in tobago-1.5.x #157 (See [https://builds.apache.org/job/tobago-1.5.x/157/]) TOBAGO-1257: The ObjectRenderer should produce HTML5 conform code (Revision 1471398) Result = FAILURE lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471398 Files : * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/ObjectRenderer.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago-message.properties.xml * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago-message_es.properties.xml * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago.properties.xml * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago_de.properties.xml * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago_es.properties.xml > The ObjectRenderer should produce HTML5 conform code > > > Key: TOBAGO-1257 > URL: https://issues.apache.org/jira/browse/TOBAGO-1257 > Project: MyFaces Tobago > Issue Type: Bug > Components: Themes >Affects Versions: 1.6.0-beta-2, 1.5.9 >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Trivial > Fix For: 1.5.10, 2.0.0-alpha-1, 2.0.0 > > > The tag may no longer contain HTML tags. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1256) No default markups for tc:file available
[ https://issues.apache.org/jira/browse/TOBAGO-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640596#comment-13640596 ] Hudson commented on TOBAGO-1256: Integrated in tobago-1.5.x #157 (See [https://builds.apache.org/job/tobago-1.5.x/157/]) TOBAGO-1256: No default markups for tc:file available (Revision 1471373) Result = FAILURE lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471373 Files : * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/webapp/tc/file/file-markup.xhtml * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-standard/src/main/resources/META-INF/tobago-config.xml > No default markups for tc:file available > > > Key: TOBAGO-1256 > URL: https://issues.apache.org/jira/browse/TOBAGO-1256 > Project: MyFaces Tobago > Issue Type: Bug >Affects Versions: 1.5.9 >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Trivial > Fix For: 1.5.10 > > > There is missing this entry in the tobago-config.xml of the standard theme: > > File > > disabled > readonly > required > fatal > error > warn > info > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1254) Improve logging
[ https://issues.apache.org/jira/browse/TOBAGO-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640594#comment-13640594 ] Hudson commented on TOBAGO-1254: Integrated in tobago-1.5.x #157 (See [https://builds.apache.org/job/tobago-1.5.x/157/]) TOBAGO-1254: Improve logging (Revision 1471374) TOBAGO-1254: Improve logging - only replace contentType when it's needed: "text/html; charset=UTF-8" should be handle as same as "text/html;charset=UTF-8" (without space) (Revision 1471369) TOBAGO-1254: Improve logging - Servlet 2.3 is not supported since Tobago 1.5 (Revision 1471265) Result = FAILURE lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471374 Files : * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/lifecycle/TobagoLifecycleFactory.java lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471369 Files : * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/util/ResponseUtils.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/util/StringUtils.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/webapp/TobagoResponseWriter.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/test/java/org/apache/myfaces/tobago/internal/util * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/test/java/org/apache/myfaces/tobago/internal/util/StringUtilsUnitTest.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/NavigationTree.java lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471265 Files : * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/util/ResponseUtils.java > Improve logging > --- > > Key: TOBAGO-1254 > URL: https://issues.apache.org/jira/browse/TOBAGO-1254 > Project: MyFaces Tobago > Issue Type: Task >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Minor > Fix For: 1.0.41, 1.5.10, 2.0.0-alpha-1, 2.0.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Wiki Spam
Something is still not set up right for wiki editing. While anyone in the AdminGroup can edit pages, someone in the ContributorsGroup still cannot. I suspect we might need the $projectwiki.py updated as per [1] in order to allow ContributorsGroup to edit pages by default. [1] http://wiki.apache.org/general/OurWikiFarm#Enabling_per_wiki_override_of_ACLs I am attempting to subscribe to infrastructure@ to ask about this. In the short term, add people to AdminGroup if they need to edit the wiki. Also, there's very little indication of what has to be done in order to get permissions to edit the wiki. I think I'll add a line on the folowing FrontPage "Community and Context / With a little help of our friends" section stating: * To Edit This wiki -- request wiki contributor status from the MyFaces Development mailing list. It'd be great to make this more obvious, but I'm not certain how. On Wed, Apr 24, 2013 at 11:20 AM, Mike Kienenberger wrote: > Thanks, Matt. > > I've added your as an administrator. > > On Wed, Apr 24, 2013 at 10:19 AM, Matt Benson wrote: >> Mike, as far as I know I have been the other guy deleting spam pages. You >> can add me as an administrator if you like, id MattBenson. >> >> Matt >> >> >> On Wed, Apr 24, 2013 at 7:45 AM, Mike Kienenberger >> wrote: >>> >>> I don't have time to do much testing of this right now, but Gavin has >>> reconfigured our wiki. >>> >>> I've added Leonardo as an administrator as his is the only other wiki >>> id that I know. >>> >>> I searched my mailbox for recent wiki contributors and added them to >>> the ContributorsGroup. >>> >>> If you send me your wiki id, I'll add you as either a contributor or >>> administrator as desired when I get back later today. >>> It'd be nice to have a few more administrators listed just in case. >>> >>> >>> >>> >>> On Tue, Apr 23, 2013 at 11:22 AM, Matt Cooper wrote: >>> > Thank you Mike for getting this going! >>> > >>> > >>> > On Tue, Apr 23, 2013 at 8:32 AM, Mike Kienenberger >>> > wrote: >>> >> >>> >> I've requested Infra to help us make this happen. >>> >> >>> >> https://issues.apache.org/jira/browse/INFRA-6191 >>> >> >>> >> On Mon, Apr 22, 2013 at 10:04 AM, Mike Kienenberger >>> >> >>> >> wrote: >>> >> > So I've been poking around for a while to try to set up >>> >> > AdminGroup/ContributorsGroup, and I know what the pages should look >>> >> > like. >>> >> > >>> >> > But I don't currently have the permissions to make the changes >>> >> > myself. >>> >> > >>> >> > http://wiki.apache.org/general/HowToBeWikiAdministrator >>> >> > >>> >> > Does anyone here already have Wiki Administrator permissions? >>> >> > >>> >> > Or apsite permission on minotaur? >>> >> > >>> >> > If not, I'll need to contact infrastructure. >>> >> > >>> >> > On Fri, Apr 19, 2013 at 4:19 PM, Mike Kienenberger >>> >> > >>> >> > wrote: >>> >> >> My recommendation is that we set up an AdminGroup, probably with all >>> >> >> committers in it. >>> >> >> >>> >> >> Then we add additional people to the ContributorsGroup as desired. >>> >> >> >>> >> >> >>> >> >> http://wiki.apache.org/general/WikiFrequentlyAskedQuestions >>> >> >> >>> >> >> http://wiki.apache.org/general/OurWikiFarm >>> >> >> = >>> >> >> per wiki access control - tighten your wiki just a little, benefit >>> >> >> just >>> >> >> a lot >>> >> >> >>> >> >> Long sub-title for a fairly long subject. >>> >> >> >>> >> >> The MoinMoin wiki is very configurable, more so than some might >>> >> >> think. >>> >> >> Of course, wikis are meant to be open, for complete and utter open >>> >> >> collaboration. That is appreciated. However, there are some that >>> >> >> would >>> >> >> like a balance between open wiki and having to spend time cleaning >>> >> >> up >>> >> >> spam each week. Times change, and the reality is, spammers are here >>> >> >> and in greater numbers than before. What can we do? Well, here is a >>> >> >> suggestion - and one that can be easily implemented and takes but 2 >>> >> >> minutes (for infra) to set up. >>> >> >> >>> >> >> Have your project wiki editable only by a custom trusted group - >>> >> >> that >>> >> >> need not be committers only - it can in fact still be anybody who >>> >> >> wants to edit your wiki, they just need to ask one time for edit >>> >> >> access and thats it. Is this an incovenience? To ask once for >>> >> >> access, >>> >> >> I don't think so. After all as a potential contributor to your wiki >>> >> >> you (project) will already be conversing with the potential >>> >> >> contributor via the mailing lists right? How much pain is it to add >>> >> >> someone to the custom trusted group once it has been set up? , no >>> >> >> pain >>> >> >> at all, a member of the projects AdminGroup edits one wiki page, >>> >> >> adds >>> >> >> the users WikiuserName to the bottom of the list and save the page! >>> >> >> 10 >>> >> >> seconds maybe and your done. For the amount of times you will have >>> >> >> to >>> >> >> do that as opposed to the amount
[jira] [Commented] (TOBAGO-1254) Improve logging
[ https://issues.apache.org/jira/browse/TOBAGO-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640613#comment-13640613 ] Hudson commented on TOBAGO-1254: Integrated in tobago-trunk #1000 (See [https://builds.apache.org/job/tobago-trunk/1000/]) TOBAGO-1254: Improve logging (Revision 1471375) TOBAGO-1254: Improve logging - only replace contentType when it's needed: "text/html; charset=UTF-8" should be handle as same as "text/html;charset=UTF-8" (without space) (Revision 1471370) TOBAGO-1254: Improve logging - Servlet 2.3 is not supported since Tobago 1.5 (Revision 1471263) Result = SUCCESS lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471375 Files : * /myfaces/tobago/trunk/tobago-extension/tobago-deprecation/src/main/java/org/apache/myfaces/tobago/internal/lifecycle/TobagoLifecycleFactory.java lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471370 Files : * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/util/ResponseUtils.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/util/StringUtils.java * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/webapp/TobagoResponseWriter.java * /myfaces/tobago/trunk/tobago-core/src/test/java/org/apache/myfaces/tobago/internal/util * /myfaces/tobago/trunk/tobago-core/src/test/java/org/apache/myfaces/tobago/internal/util/StringUtilsUnitTest.java * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/NavigationTree.java lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471263 Files : * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/util/ResponseUtils.java > Improve logging > --- > > Key: TOBAGO-1254 > URL: https://issues.apache.org/jira/browse/TOBAGO-1254 > Project: MyFaces Tobago > Issue Type: Task >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Minor > Fix For: 1.0.41, 1.5.10, 2.0.0-alpha-1, 2.0.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1257) The ObjectRenderer should produce HTML5 conform code
[ https://issues.apache.org/jira/browse/TOBAGO-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640614#comment-13640614 ] Hudson commented on TOBAGO-1257: Integrated in tobago-trunk #1000 (See [https://builds.apache.org/job/tobago-trunk/1000/]) TOBAGO-1257: The ObjectRenderer should produce HTML5 conform code (Revision 1471399) Result = SUCCESS lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471399 Files : * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/ObjectRenderer.java * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago-message.properties.xml * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago-message_es.properties.xml * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago.properties.xml * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago_de.properties.xml * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/property/tobago_es.properties.xml > The ObjectRenderer should produce HTML5 conform code > > > Key: TOBAGO-1257 > URL: https://issues.apache.org/jira/browse/TOBAGO-1257 > Project: MyFaces Tobago > Issue Type: Bug > Components: Themes >Affects Versions: 1.6.0-beta-2, 1.5.9 >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Trivial > Fix For: 1.5.10, 2.0.0-alpha-1, 2.0.0 > > > The tag may no longer contain HTML tags. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Wiki Spam
The problem was user error. 1) I put the FirstLast name in as "First Last" with a space 2) I put a comment after the name, effectively making the name different. Putting the correct login id, and only the login id, on the line works fine :-) On Wed, Apr 24, 2013 at 12:29 PM, Mike Kienenberger wrote: > Something is still not set up right for wiki editing. > > While anyone in the AdminGroup can edit pages, someone in the > ContributorsGroup still cannot. > > I suspect we might need the $projectwiki.py updated as per [1] in > order to allow ContributorsGroup to edit pages by default. > > [1] > http://wiki.apache.org/general/OurWikiFarm#Enabling_per_wiki_override_of_ACLs > > I am attempting to subscribe to infrastructure@ to ask about this. > > In the short term, add people to AdminGroup if they need to edit the wiki. > > Also, there's very little indication of what has to be done in order > to get permissions to edit the wiki. > I think I'll add a line on the folowing FrontPage "Community and > Context / With a little help of our friends" section stating: > > * To Edit This wiki -- request wiki contributor status from the > MyFaces Development mailing list. > > It'd be great to make this more obvious, but I'm not certain how. > > > On Wed, Apr 24, 2013 at 11:20 AM, Mike Kienenberger > wrote: >> Thanks, Matt. >> >> I've added your as an administrator. >> >> On Wed, Apr 24, 2013 at 10:19 AM, Matt Benson wrote: >>> Mike, as far as I know I have been the other guy deleting spam pages. You >>> can add me as an administrator if you like, id MattBenson. >>> >>> Matt >>> >>> >>> On Wed, Apr 24, 2013 at 7:45 AM, Mike Kienenberger >>> wrote: I don't have time to do much testing of this right now, but Gavin has reconfigured our wiki. I've added Leonardo as an administrator as his is the only other wiki id that I know. I searched my mailbox for recent wiki contributors and added them to the ContributorsGroup. If you send me your wiki id, I'll add you as either a contributor or administrator as desired when I get back later today. It'd be nice to have a few more administrators listed just in case. On Tue, Apr 23, 2013 at 11:22 AM, Matt Cooper wrote: > Thank you Mike for getting this going! > > > On Tue, Apr 23, 2013 at 8:32 AM, Mike Kienenberger > wrote: >> >> I've requested Infra to help us make this happen. >> >> https://issues.apache.org/jira/browse/INFRA-6191 >> >> On Mon, Apr 22, 2013 at 10:04 AM, Mike Kienenberger >> >> wrote: >> > So I've been poking around for a while to try to set up >> > AdminGroup/ContributorsGroup, and I know what the pages should look >> > like. >> > >> > But I don't currently have the permissions to make the changes >> > myself. >> > >> > http://wiki.apache.org/general/HowToBeWikiAdministrator >> > >> > Does anyone here already have Wiki Administrator permissions? >> > >> > Or apsite permission on minotaur? >> > >> > If not, I'll need to contact infrastructure. >> > >> > On Fri, Apr 19, 2013 at 4:19 PM, Mike Kienenberger >> > >> > wrote: >> >> My recommendation is that we set up an AdminGroup, probably with all >> >> committers in it. >> >> >> >> Then we add additional people to the ContributorsGroup as desired. >> >> >> >> >> >> http://wiki.apache.org/general/WikiFrequentlyAskedQuestions >> >> >> >> http://wiki.apache.org/general/OurWikiFarm >> >> = >> >> per wiki access control - tighten your wiki just a little, benefit >> >> just >> >> a lot >> >> >> >> Long sub-title for a fairly long subject. >> >> >> >> The MoinMoin wiki is very configurable, more so than some might >> >> think. >> >> Of course, wikis are meant to be open, for complete and utter open >> >> collaboration. That is appreciated. However, there are some that >> >> would >> >> like a balance between open wiki and having to spend time cleaning >> >> up >> >> spam each week. Times change, and the reality is, spammers are here >> >> and in greater numbers than before. What can we do? Well, here is a >> >> suggestion - and one that can be easily implemented and takes but 2 >> >> minutes (for infra) to set up. >> >> >> >> Have your project wiki editable only by a custom trusted group - >> >> that >> >> need not be committers only - it can in fact still be anybody who >> >> wants to edit your wiki, they just need to ask one time for edit >> >> access and thats it. Is this an incovenience? To ask once for >> >> access, >> >> I don't think so. After all as a potential contributor to your wiki >> >> you (project) will already be conversing with the potential >> >> contributor via the
[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions
[ https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641285#comment-13641285 ] Leonardo Uribe commented on MYFACES-1892: - Does this work with Mojarra? We need to know first if the reference implementation has this behavior, before commit it inside myfaces code. > validator element in faces-config should support nested attribute and > property definitions > -- > > Key: MYFACES-1892 > URL: https://issues.apache.org/jira/browse/MYFACES-1892 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.2.3 >Reporter: Simon Kitching > Attachments: MYFACES-1892-New.patch > > > As shown in this dtd: > http://java.sun.com/dtd/web-facesconfig_1_1.dtd > the validator element in a faces-config.xml file should support nested > attribute and property elements: > >xyValidtor >com.xy.XyValidator > > length > java.lang.Integer > 40 > > > However this appears to never have been implemented in either 1.1.x or 1.2.x > of core; only validator-id and validator-class are supported. Note that the > equivalent feature exists for converters, and does appear to have been > implemented. > See the digester rules registered in the constructor for class > org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl > Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1219) Evaluate jQuery UI Widget Factory
[ https://issues.apache.org/jira/browse/TOBAGO-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641343#comment-13641343 ] Hudson commented on TOBAGO-1219: Integrated in tobago-trunk #1001 (See [https://builds.apache.org/job/tobago-trunk/1001/]) TOBAGO-1171: Support for the Content Security Policy (CSP) TOBAGO-1219: Evaluate jQuery UI Widget Factory (Revision 1471604) TOBAGO-1171: Support for the Content Security Policy (CSP) TOBAGO-1219: Evaluate jQuery UI Widget Factory (Revision 1471510) Result = SUCCESS lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471604 Files : * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/70-dataAttribute/dataAttribute.xhtml lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471510 Files : * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/30-object/object.js * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/30-object/object.xhtml * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/70-dataAttribute/dataAttribute.js > Evaluate jQuery UI Widget Factory > - > > Key: TOBAGO-1219 > URL: https://issues.apache.org/jira/browse/TOBAGO-1219 > Project: MyFaces Tobago > Issue Type: Task > Components: Themes >Reporter: Udo Schnurpfeil >Assignee: Bernd Bohmann > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1171) Support for the Content Security Policy (CSP)
[ https://issues.apache.org/jira/browse/TOBAGO-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641342#comment-13641342 ] Hudson commented on TOBAGO-1171: Integrated in tobago-trunk #1001 (See [https://builds.apache.org/job/tobago-trunk/1001/]) TOBAGO-1171: Support for the Content Security Policy (CSP) TOBAGO-1219: Evaluate jQuery UI Widget Factory (Revision 1471604) TOBAGO-1171: Support for the Content Security Policy (CSP) TOBAGO-1219: Evaluate jQuery UI Widget Factory (Revision 1471510) Result = SUCCESS lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471604 Files : * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/70-dataAttribute/dataAttribute.xhtml lofwyr : http://svn.apache.org/viewvc/?view=rev&rev=1471510 Files : * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/30-object/object.js * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/30-object/object.xhtml * /myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/content/70-dataAttribute/dataAttribute.js > Support for the Content Security Policy (CSP) > - > > Key: TOBAGO-1171 > URL: https://issues.apache.org/jira/browse/TOBAGO-1171 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Themes >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil > > This security feature is currently under development in the W3. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3714) Implement stateless mode using f:view "transient" attribute
Leonardo Uribe created MYFACES-3714: --- Summary: Implement stateless mode using f:view "transient" attribute Key: MYFACES-3714 URL: https://issues.apache.org/jira/browse/MYFACES-3714 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Implement stateless mode using f:view "transient" attribute The big problem with this stuff is what happen when view protection is considered and the resulting relationship between the state mode used (client or server) and mixing everything together. For example, view protection relies on what's inside javax.faces.ViewState hidden field and how it is encoded. Theorically javax.faces.ViewState protects against CSRF attacks, but with a special stateless token it could be possible to use that token into non stateless views. We should prevent that adding proper checks into the StateManagementStrategy and the Restore View phase. In theory, it is necessary to extend org.apache.myfaces.application.StateCache abstract class to reflect the necessary logic to ensure protected views are always secured, even if they are declared as stateless. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3715) Remove unnecessary parameters or features from earlier versions in MyFaces 2.2
Leonardo Uribe created MYFACES-3715: --- Summary: Remove unnecessary parameters or features from earlier versions in MyFaces 2.2 Key: MYFACES-3715 URL: https://issues.apache.org/jira/browse/MYFACES-3715 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Priority: Blocker Before any release, it is necessary to remove unnecessary parameters or features from earlier versions One example is org.apache.myfaces.HANDLE_STATE_CACHING_MECHANICS web config param. It was added in 2.0.x/2.1.x to deal with StateManager implementations that relies on previous behavior, but in 2.2.x, we should unify that part (ri behavior). Other example is org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE web config param. With the standard javascript api (jsf.js), this behavior was included in the javascript file by default. The param was included only for backward compatibility with previous versions (JSF 1.2). There are other examples of config params like org.apache.myfaces.PRETTY_HTML that are only things left from 1.1.x versions. It is necessary to do this part before any official release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
