[jira] [Resolved] (TOBAGO-1089) Examples: Update to Jetty 7 and cleanup
[ https://issues.apache.org/jira/browse/TOBAGO-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1089. - Resolution: Fixed Fix Version/s: 1.5.3 I've updated Jetty to version 7.4.5.v20110725 Using higher versions has been failed, but I haven't checked it yet. Examples: Update to Jetty 7 and cleanup --- Key: TOBAGO-1089 URL: https://issues.apache.org/jira/browse/TOBAGO-1089 Project: MyFaces Tobago Issue Type: Task Components: Demo Affects Versions: 1.5.2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Trivial Fix For: 1.5.3 The Maven configuration can be simplified. Configuring jetty in the example parent pom, so every example can use SSL. Also removing the seam example. Its not properly maintained and CDI is used inside of the demo example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOBAGO-1091) Closing a Popup with defaultCommand=true will flush checkboxes on the page
Closing a Popup with defaultCommand=true will flush checkboxes on the page Key: TOBAGO-1091 URL: https://issues.apache.org/jira/browse/TOBAGO-1091 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.37 Reporter: Rainer Rohloff Closing a Popup with defaultCommand=true will flush checkboxes on the page -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[SECURITY] CVE-2011-4367 Apache MyFaces information disclosure vulnerability
-- CVE-2011-4367: Apache MyFaces information disclosure vulnerability Severity: Important Vendor: The Apache Software Foundation Versions Affected: MyFaces Core 2.0.1 to 2.0.11 MyFaces Core 2.1.0 to 2.1.5 Earlier versions are not affected Description: MyFaces JavaServer Faces (JSF) allows relative paths in the javax.faces.resource 'ln' parameter or writing the url so the resource name include '..' sequences . An attacker could use the security vulnerability to view files that they should not be able to. Mitigation: Users of affected versions should apply one of the following mitigations: MyFaces Core 2.0.x users should update to 2.0.12 MyFaces Core 2.1.x users should update to 2.1.6 Example: In linux or similar systems: http://hostname:port/context-root/faces/javax.faces.resource/web.xml?ln=../WEB-INF http://hostname:port/context-root/faces/javax.faces.resource/../WEB-INF/web.xml or in windows systems: http://hostname:port/context-root/faces/javax.faces.resource/web.xml?ln=..\\WEB-INF http://hostname:port/context-root/faces/javax.faces.resource/..\\WEB-INF/web.xml The 'ln' parameter should not allow a relative path. In the above example the contents of the web.xml are displayed in the response to the attacker. The part of the url that derive the resource name should not allow '..' as valid char sequence. Credit: Issue reported by Paul Nicolucci thanks to the security team at IBM References: -- regards, Leonardo Uribe
Re: PERF Discussion: Stateless JSF + HTML rendering
Hi Some days ago Thomas Andraschko told on users list that he already have a variant of this for MyFaces. Look the mail with subject: Weird PlexusContainer object in ViewRoot I think it is a good idea to put that code in myfaces commons or as an extension (extensions/stateless-jsf ?). Since the license of the code is ASL, it is possible to host it here. To make this possible I think we should vote about create a module. @Thomas: could you create an issue on myfaces issue tracker: https://issues.apache.org/jira/browse/MYFACES and attach the code you are working on, so the PMC can vote if it is worth to create the subproject? About performance of MyFaces code vs Mojarra: I think with the latest changes MyFaces code looks very good. Yes, there is a lot of room from improvement. I think it is possible to do things like trim spaces in facelets compiler, remove !-- -- on the scripts (it is there because very early versions of MyFaces do that), or optimize js rendering using some myfaces specific code instead call javax.faces js api. But note recent optimization in myfaces renderers has been improved its base speed. If you exclude the javascript rendering part, MyFaces renderers looks good. I think we should let those optimizations for 2.2. The only thing left to start working on that branch is reorganize shared modules (split shared in two, cleanup and maybe create myfaces-impl-api submodule to hold stuff like spi interfaces and other myfaces-impl api to be used for integration points). Right now, MyFaces 2.1.6 uses a lot less memory, and recent improvements into its PSS algorithm has reduced the required state size for views, making it very efficient. regards, Leonardo Uribe 2012/2/9 Werner Punz werner.p...@gmail.com: Hia just a general discussion, regarding performance. One of the big performance impacts is statefulness, now there has been a project http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ This however is only for Mojarra, shouldnt we target something similar, one day or the other it will be part of the spec, so targetting this early might give the mojarra guys a push for going there also. If you look at the numbers you can see there is a lot to gain by being able to render pages stateless one way or the other. I personally think in the typical extranet site, most pages are able to go stateless and about 5-10% should be stateful, that way we could cover both. Another performance issue I still have gripes with is the rendered code. For a small page we on the average still have way more code rendered than Mojarra, in some cases up to 40%. Which is a lot. While we already did some work regarding our onclick event javascript calls, there is still lots of room for optimization in our code. For instance we render !-- -- with all linebreaks and spaces between link and script tags intact. Mojarra basically strips all unneeded stuff and renders only the script and link tags without any blanks. Werner
Re: PERF Discussion: Stateless JSF + HTML rendering
Leonardo, does 2.0.6 share the same memory consumption improvements? ___ Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 * Listen to the latest headlines in the JSF and Java EE newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast * Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Thu, Feb 9, 2012 at 11:36 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi Some days ago Thomas Andraschko told on users list that he already have a variant of this for MyFaces. Look the mail with subject: Weird PlexusContainer object in ViewRoot I think it is a good idea to put that code in myfaces commons or as an extension (extensions/stateless-jsf ?). Since the license of the code is ASL, it is possible to host it here. To make this possible I think we should vote about create a module. @Thomas: could you create an issue on myfaces issue tracker: https://issues.apache.org/jira/browse/MYFACES and attach the code you are working on, so the PMC can vote if it is worth to create the subproject? About performance of MyFaces code vs Mojarra: I think with the latest changes MyFaces code looks very good. Yes, there is a lot of room from improvement. I think it is possible to do things like trim spaces in facelets compiler, remove !-- -- on the scripts (it is there because very early versions of MyFaces do that), or optimize js rendering using some myfaces specific code instead call javax.faces js api. But note recent optimization in myfaces renderers has been improved its base speed. If you exclude the javascript rendering part, MyFaces renderers looks good. I think we should let those optimizations for 2.2. The only thing left to start working on that branch is reorganize shared modules (split shared in two, cleanup and maybe create myfaces-impl-api submodule to hold stuff like spi interfaces and other myfaces-impl api to be used for integration points). Right now, MyFaces 2.1.6 uses a lot less memory, and recent improvements into its PSS algorithm has reduced the required state size for views, making it very efficient. regards, Leonardo Uribe 2012/2/9 Werner Punz werner.p...@gmail.com: Hia just a general discussion, regarding performance. One of the big performance impacts is statefulness, now there has been a project http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ This however is only for Mojarra, shouldnt we target something similar, one day or the other it will be part of the spec, so targetting this early might give the mojarra guys a push for going there also. If you look at the numbers you can see there is a lot to gain by being able to render pages stateless one way or the other. I personally think in the typical extranet site, most pages are able to go stateless and about 5-10% should be stateful, that way we could cover both. Another performance issue I still have gripes with is the rendered code. For a small page we on the average still have way more code rendered than Mojarra, in some cases up to 40%. Which is a lot. While we already did some work regarding our onclick event javascript calls, there is still lots of room for optimization in our code. For instance we render !-- -- with all linebreaks and spaces between link and script tags intact. Mojarra basically strips all unneeded stuff and renders only the script and link tags without any blanks. Werner
Re: PERF Discussion: Stateless JSF + HTML rendering
Hi Kito MyFaces Core 2.0.12 has the same improvements. All improvements done has been applied on both branches, even if that means some overhead associated. Compared with 2.0.11/2.1.5, the diference is significant. regards, Leonardo Uribe 2012/2/9 Kito Mann kito.m...@virtua.com: Leonardo, does 2.0.6 share the same memory consumption improvements? ___ Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 * Listen to the latest headlines in the JSF and Java EE newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast * Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Thu, Feb 9, 2012 at 11:36 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi Some days ago Thomas Andraschko told on users list that he already have a variant of this for MyFaces. Look the mail with subject: Weird PlexusContainer object in ViewRoot I think it is a good idea to put that code in myfaces commons or as an extension (extensions/stateless-jsf ?). Since the license of the code is ASL, it is possible to host it here. To make this possible I think we should vote about create a module. @Thomas: could you create an issue on myfaces issue tracker: https://issues.apache.org/jira/browse/MYFACES and attach the code you are working on, so the PMC can vote if it is worth to create the subproject? About performance of MyFaces code vs Mojarra: I think with the latest changes MyFaces code looks very good. Yes, there is a lot of room from improvement. I think it is possible to do things like trim spaces in facelets compiler, remove !-- -- on the scripts (it is there because very early versions of MyFaces do that), or optimize js rendering using some myfaces specific code instead call javax.faces js api. But note recent optimization in myfaces renderers has been improved its base speed. If you exclude the javascript rendering part, MyFaces renderers looks good. I think we should let those optimizations for 2.2. The only thing left to start working on that branch is reorganize shared modules (split shared in two, cleanup and maybe create myfaces-impl-api submodule to hold stuff like spi interfaces and other myfaces-impl api to be used for integration points). Right now, MyFaces 2.1.6 uses a lot less memory, and recent improvements into its PSS algorithm has reduced the required state size for views, making it very efficient. regards, Leonardo Uribe 2012/2/9 Werner Punz werner.p...@gmail.com: Hia just a general discussion, regarding performance. One of the big performance impacts is statefulness, now there has been a project http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ This however is only for Mojarra, shouldnt we target something similar, one day or the other it will be part of the spec, so targetting this early might give the mojarra guys a push for going there also. If you look at the numbers you can see there is a lot to gain by being able to render pages stateless one way or the other. I personally think in the typical extranet site, most pages are able to go stateless and about 5-10% should be stateful, that way we could cover both. Another performance issue I still have gripes with is the rendered code. For a small page we on the average still have way more code rendered than Mojarra, in some cases up to 40%. Which is a lot. While we already did some work regarding our onclick event javascript calls, there is still lots of room for optimization in our code. For instance we render !-- -- with all linebreaks and spaces between link and script tags intact. Mojarra basically strips all unneeded stuff and renders only the script and link tags without any blanks. Werner
Re: PERF Discussion: Stateless JSF + HTML rendering
Hello Leonardo, That's great to hear. I'll have to try out the new release :-). ___ Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 * Listen to the latest headlines in the JSF and Java EE newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast * Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Thu, Feb 9, 2012 at 11:56 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi Kito MyFaces Core 2.0.12 has the same improvements. All improvements done has been applied on both branches, even if that means some overhead associated. Compared with 2.0.11/2.1.5, the diference is significant. regards, Leonardo Uribe 2012/2/9 Kito Mann kito.m...@virtua.com: Leonardo, does 2.0.6 share the same memory consumption improvements? ___ Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 * Listen to the latest headlines in the JSF and Java EE newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast * Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Thu, Feb 9, 2012 at 11:36 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi Some days ago Thomas Andraschko told on users list that he already have a variant of this for MyFaces. Look the mail with subject: Weird PlexusContainer object in ViewRoot I think it is a good idea to put that code in myfaces commons or as an extension (extensions/stateless-jsf ?). Since the license of the code is ASL, it is possible to host it here. To make this possible I think we should vote about create a module. @Thomas: could you create an issue on myfaces issue tracker: https://issues.apache.org/jira/browse/MYFACES and attach the code you are working on, so the PMC can vote if it is worth to create the subproject? About performance of MyFaces code vs Mojarra: I think with the latest changes MyFaces code looks very good. Yes, there is a lot of room from improvement. I think it is possible to do things like trim spaces in facelets compiler, remove !-- -- on the scripts (it is there because very early versions of MyFaces do that), or optimize js rendering using some myfaces specific code instead call javax.faces js api. But note recent optimization in myfaces renderers has been improved its base speed. If you exclude the javascript rendering part, MyFaces renderers looks good. I think we should let those optimizations for 2.2. The only thing left to start working on that branch is reorganize shared modules (split shared in two, cleanup and maybe create myfaces-impl-api submodule to hold stuff like spi interfaces and other myfaces-impl api to be used for integration points). Right now, MyFaces 2.1.6 uses a lot less memory, and recent improvements into its PSS algorithm has reduced the required state size for views, making it very efficient. regards, Leonardo Uribe 2012/2/9 Werner Punz werner.p...@gmail.com: Hia just a general discussion, regarding performance. One of the big performance impacts is statefulness, now there has been a project http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ This however is only for Mojarra, shouldnt we target something similar, one day or the other it will be part of the spec, so targetting this early might give the mojarra guys a push for going there also. If you look at the numbers you can see there is a lot to gain by being able to render pages stateless one way or the other. I personally think in the typical extranet site, most pages are able to go stateless and about 5-10% should be stateful, that way we could cover both. Another performance issue I still have gripes with is the rendered code. For a small page we on the average still have way more code rendered than Mojarra, in some cases up to 40%. Which is a lot. While we already did some work regarding our onclick event javascript calls, there is still lots of room for optimization in our code. For instance we render !-- -- with all linebreaks and spaces between link and script tags intact. Mojarra basically strips all unneeded stuff and renders only the script and link tags without any blanks. Werner
Re: PERF Discussion: Stateless JSF + HTML rendering
+1 Stateless definitely should be part of the codebase, I would not opt for an extension more for an integrated feature here. Extensions are so so, because they always are a little bit behind the core. As for !-- -- Martin Koci told me, that removal code already is in, it is just not enabled per default due to legacy browser support. (you can turn it on via context-param param-nameorg.apache.myfaces.WRAP_SCRIPT_CONTENT_WITH_XML_COMMENT_TAG/param-name param-valuefalse/param-value /context-param ) We probably should rethink if we already safely can make this our default since some legacy browsers no can be considered safe not to be supported anymore (ie 5.5 for instance and ie6 is slowly on its way out except for Asia) Werner Am 09.02.12 17:36, schrieb Leonardo Uribe: Hi Some days ago Thomas Andraschko told on users list that he already have a variant of this for MyFaces. Look the mail with subject: Weird PlexusContainer object in ViewRoot I think it is a good idea to put that code in myfaces commons or as an extension (extensions/stateless-jsf ?). Since the license of the code is ASL, it is possible to host it here. To make this possible I think we should vote about create a module. @Thomas: could you create an issue on myfaces issue tracker: https://issues.apache.org/jira/browse/MYFACES and attach the code you are working on, so the PMC can vote if it is worth to create the subproject? About performance of MyFaces code vs Mojarra: I think with the latest changes MyFaces code looks very good. Yes, there is a lot of room from improvement. I think it is possible to do things like trim spaces in facelets compiler, remove!-- -- on the scripts (it is there because very early versions of MyFaces do that), or optimize js rendering using some myfaces specific code instead call javax.faces js api. But note recent optimization in myfaces renderers has been improved its base speed. If you exclude the javascript rendering part, MyFaces renderers looks good. I think we should let those optimizations for 2.2. The only thing left to start working on that branch is reorganize shared modules (split shared in two, cleanup and maybe create myfaces-impl-api submodule to hold stuff like spi interfaces and other myfaces-impl api to be used for integration points). Right now, MyFaces 2.1.6 uses a lot less memory, and recent improvements into its PSS algorithm has reduced the required state size for views, making it very efficient. regards, Leonardo Uribe 2012/2/9 Werner Punzwerner.p...@gmail.com: Hia just a general discussion, regarding performance. One of the big performance impacts is statefulness, now there has been a project http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ This however is only for Mojarra, shouldnt we target something similar, one day or the other it will be part of the spec, so targetting this early might give the mojarra guys a push for going there also. If you look at the numbers you can see there is a lot to gain by being able to render pages stateless one way or the other. I personally think in the typical extranet site, most pages are able to go stateless and about 5-10% should be stateful, that way we could cover both. Another performance issue I still have gripes with is the rendered code. For a small page we on the average still have way more code rendered than Mojarra, in some cases up to 40%. Which is a lot. While we already did some work regarding our onclick event javascript calls, there is still lots of room for optimization in our code. For instance we render!-- -- with all linebreaks and spaces between link and script tags intact. Mojarra basically strips all unneeded stuff and renders only the script and link tags without any blanks. Werner
