[jira] [Commented] (TRINIDAD-1910) portal: common.js is included serveral times
[ https://issues.apache.org/jira/browse/TRINIDAD-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019236#comment-13019236 ] Daniel Niklas commented on TRINIDAD-1910: - TRINIDAD-53 - last activity 12/Jun/07 TRINIDAD-1705 - last activity 03/Feb/10 We are working in portal environment - we need a lot of patches and workarounds for Trinidad! Without this stop gap we are not able to use Trinidad for our productive applications! There seems to be no progress since years. portal: common.js is included serveral times Key: TRINIDAD-1910 URL: https://issues.apache.org/jira/browse/TRINIDAD-1910 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.10-core Reporter: Daniel Niklas Attachments: Page.js-trinidad-1910-patch.txt, XhtmlUtils-patch.txt The commons.js is included several times, when you have more than one trinidad-porlet on your portal-site. In XhtmlUtils#writeLibImport there is a mechanism to prevent including javascript libs more than one time (portal environment). This mechanism is not working, when you have more than one Trinidad-portlets within different web apps. The problem is, that the key contains the webapp context! Here _uixJSL for example contains: /webapp-one/adf/jsLibs/Common1_0_10.js -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3108) ResourceHandlerCache does not honor localePrefix
ResourceHandlerCache does not honor localePrefix Key: MYFACES-3108 URL: https://issues.apache.org/jira/browse/MYFACES-3108 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.5, 2.0.4, 2.0.3 Reporter: Jakob Korherr Assignee: Jakob Korherr Speaking with Michi Kurz, he told me that the MyFaces ResourceHandlerImpl's ResourceHandlerCache does not honor the localePrefix. The problem is that if you have e.g. an english version and a german version of a resource and you serve the english version first, it will be cached and the german version will never be served, even if the locale is german. I created a simple test case, which shows this problem - check it for details! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3108) ResourceHandlerCache does not honor localePrefix
[ https://issues.apache.org/jira/browse/MYFACES-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-3108. Resolution: Fixed Fix Version/s: 2.0.6-SNAPSHOT committed fix and test case ResourceHandlerCache does not honor localePrefix Key: MYFACES-3108 URL: https://issues.apache.org/jira/browse/MYFACES-3108 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.3, 2.0.4, 2.0.5 Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 2.0.6-SNAPSHOT Speaking with Michi Kurz, he told me that the MyFaces ResourceHandlerImpl's ResourceHandlerCache does not honor the localePrefix. The problem is that if you have e.g. an english version and a german version of a resource and you serve the english version first, it will be cached and the german version will never be served, even if the locale is german. I created a simple test case, which shows this problem - check it for details! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3109) UIInput SystemEvents are called with wrong sourceBaseTyp
UIInput SystemEvents are called with wrong sourceBaseTyp Key: MYFACES-3109 URL: https://issues.apache.org/jira/browse/MYFACES-3109 Project: MyFaces Core Issue Type: Bug Reporter: Marcus Büttner Function publishEvent is called with UIComponent.class instead of source.getClass according to spec java doc application.publishEvent. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3109) UIInput SystemEvents are called with wrong sourceBaseTyp
[ https://issues.apache.org/jira/browse/MYFACES-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019274#comment-13019274 ] Jakob Korherr commented on MYFACES-3109: This is a pretty big bug. Sadly no-one recognized it so far. Javadoc of Application.publishEvent() says: sourceBaseType - The Class of the source event that must be used to lookup the listener to which this event must be published. If this argument is null the return from source.getClass() must be used as the sourceBaseType. Marcus found out about it, because of the Primefaces guide to style invalid input fields with jsf (see http://cagataycivici.wordpress.com/2011/04/04/styling-invalid-input-fields-with-jsf/). So we have to change all references to UIComponent.class to source.getClass(). UIInput SystemEvents are called with wrong sourceBaseTyp Key: MYFACES-3109 URL: https://issues.apache.org/jira/browse/MYFACES-3109 Project: MyFaces Core Issue Type: Bug Reporter: Marcus Büttner Assignee: Jakob Korherr Function publishEvent is called with UIComponent.class instead of source.getClass according to spec java doc application.publishEvent. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3109) UIInput SystemEvents are called with wrong sourceBaseTyp
[ https://issues.apache.org/jira/browse/MYFACES-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-3109. Resolution: Fixed Fix Version/s: 2.0.6-SNAPSHOT fixed UIInput SystemEvents are called with wrong sourceBaseTyp Key: MYFACES-3109 URL: https://issues.apache.org/jira/browse/MYFACES-3109 Project: MyFaces Core Issue Type: Bug Reporter: Marcus Büttner Assignee: Jakob Korherr Fix For: 2.0.6-SNAPSHOT Function publishEvent is called with UIComponent.class instead of source.getClass according to spec java doc application.publishEvent. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Result (was: [RE-VOTE] release for myfaces archetypes 1.0.3)
Hi, Thanks to all people who voted. We have 6 +1 5 binding: - Mark Struberg - Werner Punz - Gerhard Petracek - Leonardo Uribe - Jakob Korherr 1 non-binding: - Hazem Saleh so we can continue with the necessary steps to release myfaces archetypes 1.0.3 Regards, Jakob -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Created] (EXTSCRIPT-148) Improve the poms remove external repositories
Improve the poms remove external repositories - Key: EXTSCRIPT-148 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-148 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz During the final build for the 1.0 site some pom problems were discovered, which should be fixed. a) External repositories need to be removed in the jar parts of the project only the war parts are allowed to have them. b) Upgrade the myfaces master pom to version 10 and also upgrade all dependencies in the checkstyle and other plugins to the versions required by the master pom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTSCRIPT-148) Improve the poms remove external repositories
[ https://issues.apache.org/jira/browse/EXTSCRIPT-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-148. --- Resolution: Fixed Fix Version/s: 1.0.1-SNAPSHOT Improve the poms remove external repositories - Key: EXTSCRIPT-148 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-148 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Fix For: 1.0.1-SNAPSHOT During the final build for the 1.0 site some pom problems were discovered, which should be fixed. a) External repositories need to be removed in the jar parts of the project only the war parts are allowed to have them. b) Upgrade the myfaces master pom to version 10 and also upgrade all dependencies in the checkstyle and other plugins to the versions required by the master pom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[ANNOUNCE] Apache MyFaces Extension Scripting 1.0
The Apache MyFaces team is pleased to announce the release of MyFaces Extension Scripting 1.0. Apache MyFaces Extension Scripting 1.0 is an extension project to Apache MyFaces which enables Groovy support and dynamic Java artifact reloading under JSF. Temporary download site and documentation site location: Extension-Scripting 1.0 can be downloaded under: http://people.apache.org/~werpu/ext-script-site/download.html And the documentation is currently hosted under: http://people.apache.org/~werpu/ext-script-site/index.html The artifacts also can be integrated via maven, please consult the documentation for further info. Release Notes - MyFaces Core - Version 2.0.5 The download pages and documentation for 1.0 currently are hosted in a temporary location until it is moved to the final location. Also the current version only runs under Apache MyFaces 2.0.0-2.0.2. A bugfix version 1.0.1 which enables the reloading up to MyFaces 2.0.5 will follow soon. Work on it has begun, and the release will follow asap.
[VOTE] Release myfaces-site-skin 3
Hello, i would like to release the myfaces-site-skin 3. Changes: Added ASF Branding requirements to the skin see: http://www.apache.org/foundation/marks/pmcs The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-089 The Vote is open for 24h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
Re: [VOTE] Release myfaces-site-skin 3
+1 On Wed, Apr 13, 2011 at 4:02 PM, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hello, i would like to release the myfaces-site-skin 3. Changes: Added ASF Branding requirements to the skin see: http://www.apache.org/foundation/marks/pmcs The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-089 The Vote is open for 24h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release myfaces-site-skin 3
+1 Regards, Udo Am 13.04.11 16:02, schrieb Bernd Bohmann: Hello, i would like to release the myfaces-site-skin 3. Changes: Added ASF Branding requirements to the skin see: http://www.apache.org/foundation/marks/pmcs The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-089 The Vote is open for 24h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
Re: [VOTE] Release myfaces-site-skin 3
Here is my +1 Bernd On Wed, Apr 13, 2011 at 4:06 PM, Matthias Wessendorf mat...@apache.org wrote: +1 On Wed, Apr 13, 2011 at 4:02 PM, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hello, i would like to release the myfaces-site-skin 3. Changes: Added ASF Branding requirements to the skin see: http://www.apache.org/foundation/marks/pmcs The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-089 The Vote is open for 24h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release myfaces-site-skin 3
+1 Werner Am 13.04.11 16:09, schrieb Bernd Bohmann: Here is my +1 Bernd On Wed, Apr 13, 2011 at 4:06 PM, Matthias Wessendorfmat...@apache.org wrote: +1 On Wed, Apr 13, 2011 at 4:02 PM, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hello, i would like to release the myfaces-site-skin 3. Changes: Added ASF Branding requirements to the skin see: http://www.apache.org/foundation/marks/pmcs The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-089 The Vote is open for 24h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release myfaces-site-skin 3
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/4/13 Bernd Bohmann bernd.bohm...@atanion.com Here is my +1 Bernd On Wed, Apr 13, 2011 at 4:06 PM, Matthias Wessendorf mat...@apache.org wrote: +1 On Wed, Apr 13, 2011 at 4:02 PM, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hello, i would like to release the myfaces-site-skin 3. Changes: Added ASF Branding requirements to the skin see: http://www.apache.org/foundation/marks/pmcs The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-089 The Vote is open for 24h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] [Commented] (MYFACES-2823) Request attribute names are not cached which causes performance degredation
[ https://issues.apache.org/jira/browse/MYFACES-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019409#comment-13019409 ] Bernd Bohmann commented on MYFACES-2823: The issue is solved in Tomcat 6.0.30 see: https://issues.apache.org/bugzilla/show_bug.cgi?id=49613 Request attribute names are not cached which causes performance degredation --- Key: MYFACES-2823 URL: https://issues.apache.org/jira/browse/MYFACES-2823 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.9 Environment: Tomcat 6.0.20 (with an SSL connector) MyFaces 1.2.9 RichFaces 3.3.2 Java 1.6.0_15 Reporter: Sampo Savolainen Attachments: stack.png Original Estimate: 24h Remaining Estimate: 24h When rendering a simple request, MyFaces ends up calling Request.getAttributeNames() 1000+ times. This causes performance degredation in cases when it is not trivial for the container to produce the names. This is the case for example with Tomcat when there is an SSL connector: reading the attribute names requires tomcat to check if there are peer certificates. I will attach a screenshot from a profiling session where a substantial portion of the server processing went into org.apache.myfaces.context.servlet.RequestMap.getAttributeNames(). This screenshot shows a backtrace from one JSSE accessor called by getAttributeNames() up to the faces components where the calls are initiated from. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-1910) portal: common.js is included serveral times
[ https://issues.apache.org/jira/browse/TRINIDAD-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019416#comment-13019416 ] Scott O'Bryan commented on TRINIDAD-1910: - Daniel, I'm well aware but I'm not too enthused about putting in an incorrect solution either. Would you be interested in trying to work on the other trinidad solutions? Scott portal: common.js is included serveral times Key: TRINIDAD-1910 URL: https://issues.apache.org/jira/browse/TRINIDAD-1910 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.10-core Reporter: Daniel Niklas Attachments: Page.js-trinidad-1910-patch.txt, XhtmlUtils-patch.txt The commons.js is included several times, when you have more than one trinidad-porlet on your portal-site. In XhtmlUtils#writeLibImport there is a mechanism to prevent including javascript libs more than one time (portal environment). This mechanism is not working, when you have more than one Trinidad-portlets within different web apps. The problem is, that the key contains the webapp context! Here _uixJSL for example contains: /webapp-one/adf/jsLibs/Common1_0_10.js -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-1985) High live memory usage from SkinStyleProvider
[ https://issues.apache.org/jira/browse/TRINIDAD-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019442#comment-13019442 ] Jeanne Waldman commented on TRINIDAD-1985: -- The LRUCache.patch should be for the related issue TRINIDAD-2026 memory leak in skinstyleprovider. This occurs if one application uses a bunch of different skins. High live memory usage from SkinStyleProvider - Key: TRINIDAD-1985 URL: https://issues.apache.org/jira/browse/TRINIDAD-1985 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 1.2.12-core Reporter: Stevan Malesevic Assignee: Jeanne Waldman Attachments: LRUCache.patch We were checking a live memory usage in one app and noticed that some 83MB of heap is pinned under SkinStyleProvider. This is under 14 instances of FileSystemStyleCache$Entry each with about 6MB of memory Heap shows these keys for styles LocaleVersion enMozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 koMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729) koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729) koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729) koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729) enMozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.15) Gecko/20101026 Firefox/3.5.15 ( .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729) koMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2) enMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729) koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Now beside the amount of memory pinned by single FileSystemStyleCache$Entry the issue is that we apparently create too many different versions and there is no restriction to the size of cache leaving open door for memory leak Two questions 1. Do we really have different styles for FF on 3.5 or 3.6 or so? If not why do we key by it? 2. Given different browsers and locales having cache as plain concurrent hash map is actually a source of leak as over time it can accumulate more and more. Do we have any restriction there? Should the entries by LRU or have exparation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2026) memory leak in skinstyleprovider
[ https://issues.apache.org/jira/browse/TRINIDAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019444#comment-13019444 ] Jeanne Waldman commented on TRINIDAD-2026: -- initial patch. Need to discuss the (1) default size and (2) the web.xml parameter name. Let's say one skin takes 1M of SkinStyleProvider. What should the default size (number of skins in the LRUCache) be? memory leak in skinstyleprovider Key: TRINIDAD-2026 URL: https://issues.apache.org/jira/browse/TRINIDAD-2026 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Attachments: LRUCache.patch There is no limit to the size of the providers cache in SkinStyleProvider.java. Every time we ask for a new skin, we add to the provider cache. A skin has StyleSheetDocument and StyleSheetDocument has StyleSheetNodes. If we remove a skin from the cache, we will need to clear out its _document, which in turn will clear out the StyleSheetNodes. StyleSheetNodes are the parsed representation of the skin css file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2087) memory leak skinfactories hold on to skin which holds on to stylesheetnodes
memory leak skinfactories hold on to skin which holds on to stylesheetnodes --- Key: TRINIDAD-2087 URL: https://issues.apache.org/jira/browse/TRINIDAD-2087 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Reporter: Jeanne Waldman related to TRINIDAD-2026. SkinFactory#_FACTORIES is holding on to StyleSheetNodes. We register all skins with the SkinFactory. Once a skin has been requested by the user, we parse the stylesheet and store the stylesheetnodes with the skin. To see in the memory profiler tool, first set the LRUCache for SkinStyleProvider to 1. This will only keep around one SkinStyleProvider at a time. Run the rich client app (or trinidad's panelPageSkinDemo). Change the skin to about 6 different skins. Stop the memory profiler. You will see that even though we limit the SkinStyleProvider to 1, we still see StyleSheetNodes growing. See attached image showing the profiler results. Think about using SoftReferences to the Skin -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2026) memory leak in skinstyleprovider
[ https://issues.apache.org/jira/browse/TRINIDAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019448#comment-13019448 ] Jeanne Waldman commented on TRINIDAD-2026: -- This patch does not clear out _document off the Skin. SkinFactory#_FACTORIES is holding on to StyleSheetNodes. We register all skins with the SkinFactory. Once a skin has been requested by the user, we parse the stylesheet and store the stylesheetnodes with the skin. This is TRINIDAD-2087 memory leak in skinstyleprovider Key: TRINIDAD-2026 URL: https://issues.apache.org/jira/browse/TRINIDAD-2026 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Attachments: LRUCache.patch There is no limit to the size of the providers cache in SkinStyleProvider.java. Every time we ask for a new skin, we add to the provider cache. A skin has StyleSheetDocument and StyleSheetDocument has StyleSheetNodes. If we remove a skin from the cache, we will need to clear out its _document, which in turn will clear out the StyleSheetNodes. StyleSheetNodes are the parsed representation of the skin css file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2026) memory leak in skinstyleprovider
[ https://issues.apache.org/jira/browse/TRINIDAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019526#comment-13019526 ] Jeanne Waldman commented on TRINIDAD-2026: -- I discussed this with our performance expert, and we decided to limit it to around 20M. A complex skin for many components (like adf faces's skins) will take about 1M per skin, so the default size will be 20. This leaves the decision for what should the web.xml parameter be called? ideas: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE memory leak in skinstyleprovider Key: TRINIDAD-2026 URL: https://issues.apache.org/jira/browse/TRINIDAD-2026 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Attachments: LRUCache.patch There is no limit to the size of the providers cache in SkinStyleProvider.java. Every time we ask for a new skin, we add to the provider cache. A skin has StyleSheetDocument and StyleSheetDocument has StyleSheetNodes. If we remove a skin from the cache, we will need to clear out its _document, which in turn will clear out the StyleSheetNodes. StyleSheetNodes are the parsed representation of the skin css file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Trinidad][API] web.xml context-param for skin cache size
Hi, For this issue, TRINIDAD-2026 memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne
Re: [Trinidad][API] web.xml context-param for skin cache size
On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 https://issues.apache.org/jira/browse/TRINIDAD-2026memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
[jira] [Commented] (TRINIDAD-2026) memory leak in skinstyleprovider
[ https://issues.apache.org/jira/browse/TRINIDAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019544#comment-13019544 ] Scott O'Bryan commented on TRINIDAD-2026: - I like SKIN_STYLE_PROVIDER_CACHE_SIZE memory leak in skinstyleprovider Key: TRINIDAD-2026 URL: https://issues.apache.org/jira/browse/TRINIDAD-2026 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Attachments: LRUCache.patch There is no limit to the size of the providers cache in SkinStyleProvider.java. Every time we ask for a new skin, we add to the provider cache. A skin has StyleSheetDocument and StyleSheetDocument has StyleSheetNodes. If we remove a skin from the cache, we will need to clear out its _document, which in turn will clear out the StyleSheetNodes. StyleSheetNodes are the parsed representation of the skin css file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2083) Trinidad doesn't work with the 3.0.0 Portlet Bridge
[ https://issues.apache.org/jira/browse/TRINIDAD-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019547#comment-13019547 ] Scott O'Bryan commented on TRINIDAD-2083: - Taking a look at this now Trinidad doesn't work with the 3.0.0 Portlet Bridge --- Key: TRINIDAD-2083 URL: https://issues.apache.org/jira/browse/TRINIDAD-2083 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 2.0.0-beta-2 Reporter: Michael Freedman Assignee: Scott O'Bryan I got 2.0.0-alpha2 working with a patch but once I upgraded to 2.0.0-beta-2 (which fixed the problem I needed to patch) the bridge completely breaks as long as the app includes the trinidad libs. There seems to be some incompatibilities between the Trinidad extensions and the bridge's. Did get a chance to track down the specific details but wanted to get the issue logged as its likely to be identified much faster by someone in the Trinidad team. To reproduce -- get the bridge-3.0.0-alpha and set up a project pointing to the 3.0.0 TCK. Follow the instructions in the TCK User Manual for building it, configuring it on Apache, and then running it. With the Trinidad jars in the deployment you will find that almost all the test fail (170) -- the few that pass don't actually execute Faces. If you remove the jars (and I think drop the other Trinidad refs in the web.xml) things run fine except for those few tests that depend on Trindiad (failed tests shoudl be something like 37). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Trinidad][API] web.xml context-param for skin cache size
That's a good one, too. SKIN_STYLE_PROVIDER_CACHE_SIZE is specific, but then SkinStyleProvider (and StyleProvider for that matter) are in the impl package. Blake Sullivan wrote, On 4/13/2011 1:52 PM PT: On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
Re: [Trinidad][API] web.xml context-param for skin cache size
I think configurators are less likely to understand what a 'STYLE PROVIDER' means. So I like the simpler name Blake proposed 'org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS'. Thanks, Prakash On 4/13/2011 3:52 PM, Blake Sullivan wrote: On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 https://issues.apache.org/jira/browse/TRINIDAD-2026memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
[jira] [Commented] (TRINIDAD-2026) memory leak in skinstyleprovider
[ https://issues.apache.org/jira/browse/TRINIDAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019566#comment-13019566 ] Prakash Udupa commented on TRINIDAD-2026: - I like what Blake proposed in his review email: 'org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS'. memory leak in skinstyleprovider Key: TRINIDAD-2026 URL: https://issues.apache.org/jira/browse/TRINIDAD-2026 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Attachments: LRUCache.patch There is no limit to the size of the providers cache in SkinStyleProvider.java. Every time we ask for a new skin, we add to the provider cache. A skin has StyleSheetDocument and StyleSheetDocument has StyleSheetNodes. If we remove a skin from the cache, we will need to clear out its _document, which in turn will clear out the StyleSheetNodes. StyleSheetNodes are the parsed representation of the skin css file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Trinidad][API] web.xml context-param for skin cache size
I like it too. It doesn't roll of the tongue, but I can't think of something simpler and better. Prakash Udupa wrote, On 4/13/2011 2:36 PM PT: I think configurators are less likely to understand what a 'STYLE PROVIDER' means. So I like the simpler name Blake proposed 'org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS'. Thanks, Prakash On 4/13/2011 3:52 PM, Blake Sullivan wrote: On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
Re: [Trinidad][API] web.xml context-param for skin cache size
On 4/13/2011 2:46 PM, Jeanne Waldman wrote: I like it too. It doesn't roll of the tongue, but I can't think of something simpler and better. You could try a slight variation MAX_SKINS_CACHED. Prakash Udupa wrote, On 4/13/2011 2:36 PM PT: I think configurators are less likely to understand what a 'STYLE PROVIDER' means. So I like the simpler name Blake proposed 'org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS'. Thanks, Prakash On 4/13/2011 3:52 PM, Blake Sullivan wrote: On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 https://issues.apache.org/jira/browse/TRINIDAD-2026memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
[jira] [Commented] (TRINIDAD-2083) Trinidad doesn't work with the 3.0.0 Portlet Bridge
[ https://issues.apache.org/jira/browse/TRINIDAD-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019631#comment-13019631 ] Scott O'Bryan commented on TRINIDAD-2083: - Okay. Well I ran the TCK with the 2.0.0-beta-3 jars in there and although there were some errors (the 37 you mentioned above) I didn't see the 170+. In my catalina logs, the failures seem to be associated with: java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpResourceResponse cannot be cast to javax.servlet.http.HttpServletResponse at com.sun.faces.util.OnOffResponseWrapper.init(OnOffResponseWrapper.java:58) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:94) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) I'm taking a look at this now, but it doesn't make sense to me why, what should be a portlet resource response, is trying to cast to an HttpServletResponse. Trinidad doesn't work with the 3.0.0 Portlet Bridge --- Key: TRINIDAD-2083 URL: https://issues.apache.org/jira/browse/TRINIDAD-2083 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 2.0.0-beta-2 Reporter: Michael Freedman Assignee: Scott O'Bryan I got 2.0.0-alpha2 working with a patch but once I upgraded to 2.0.0-beta-2 (which fixed the problem I needed to patch) the bridge completely breaks as long as the app includes the trinidad libs. There seems to be some incompatibilities between the Trinidad extensions and the bridge's. Did get a chance to track down the specific details but wanted to get the issue logged as its likely to be identified much faster by someone in the Trinidad team. To reproduce -- get the bridge-3.0.0-alpha and set up a project pointing to the 3.0.0 TCK. Follow the instructions in the TCK User Manual for building it, configuring it on Apache, and then running it. With the Trinidad jars in the deployment you will find that almost all the test fail (170) -- the few that pass don't actually execute Faces. If you remove the jars (and I think drop the other Trinidad refs in the web.xml) things run fine except for those few tests that depend on Trindiad (failed tests shoudl be something like 37). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release myfaces-site-skin 3
+1 On Wed, Apr 13, 2011 at 9:13 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/4/13 Bernd Bohmann bernd.bohm...@atanion.com Here is my +1 Bernd On Wed, Apr 13, 2011 at 4:06 PM, Matthias Wessendorf mat...@apache.org wrote: +1 On Wed, Apr 13, 2011 at 4:02 PM, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hello, i would like to release the myfaces-site-skin 3. Changes: Added ASF Branding requirements to the skin see: http://www.apache.org/foundation/marks/pmcs The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-089 The Vote is open for 24h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com
[jira] [Commented] (TRINIDAD-2083) Trinidad doesn't work with the 3.0.0 Portlet Bridge
[ https://issues.apache.org/jira/browse/TRINIDAD-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019633#comment-13019633 ] Scott O'Bryan commented on TRINIDAD-2083: - Yeah, I looked at this and this seems to be a problem with the R.I. or the bridge. I don't know why it didn't come up in other tests but the XmlHttpResourceResponse is a ResourceResponseWrapper which is appropriate for the PPR Portlet request. I'm going to log an issue with the Portlet Bridge over this issue and close this bug. Trinidad doesn't work with the 3.0.0 Portlet Bridge --- Key: TRINIDAD-2083 URL: https://issues.apache.org/jira/browse/TRINIDAD-2083 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 2.0.0-beta-2 Reporter: Michael Freedman Assignee: Scott O'Bryan I got 2.0.0-alpha2 working with a patch but once I upgraded to 2.0.0-beta-2 (which fixed the problem I needed to patch) the bridge completely breaks as long as the app includes the trinidad libs. There seems to be some incompatibilities between the Trinidad extensions and the bridge's. Did get a chance to track down the specific details but wanted to get the issue logged as its likely to be identified much faster by someone in the Trinidad team. To reproduce -- get the bridge-3.0.0-alpha and set up a project pointing to the 3.0.0 TCK. Follow the instructions in the TCK User Manual for building it, configuring it on Apache, and then running it. With the Trinidad jars in the deployment you will find that almost all the test fail (170) -- the few that pass don't actually execute Faces. If you remove the jars (and I think drop the other Trinidad refs in the web.xml) things run fine except for those few tests that depend on Trindiad (failed tests shoudl be something like 37). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-211) Trinidad doesn't work with the 3.0.0 Portlet Bridge
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019640#comment-13019640 ] Scott O'Bryan commented on PORTLETBRIDGE-211: - Cool. I found a way to move this. :) With the latest Trinidad 2.0.0-beta-3 (which will probably be release soon as Trinidad 2.0.0), I was able to run the TCK with the Trinidad jars included. The PPR tests are still failing for an unknown reason, but it looks like the Trinidad code is doing the right thing and the breakage is happening in the R.I. (Not sure how it's even getting there but it is). The full stack trace I'm seeing is as follows: Apr 13, 2011 6:14:57 PM org.apache.catalina.core.ApplicationContext log SEVERE: Exception thrown in doFacesRequest:resource javax.faces.FacesException: java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpResourceResponse cannot be cast to javax.servlet.http.HttpServletResponse at org.apache.myfaces.shared_portlet.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.shared_portlet.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:1068) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:1209) at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:700) at javax.portlet.faces.GenericFacesPortlet.serveResource(GenericFacesPortlet.java:291) at org.apache.pluto.driver.services.container.FilterChainImpl.doFilter(FilterChainImpl.java:186) at org.apache.pluto.driver.services.container.FilterChainImpl.processFilter(FilterChainImpl.java:77) at org.apache.pluto.driver.services.container.FilterManagerImpl.processFilter(FilterManagerImpl.java:98) at org.apache.pluto.container.driver.PortletServlet.dispatch(PortletServlet.java:350) at org.apache.pluto.container.driver.PortletServlet.doPost(PortletServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at org.apache.pluto.driver.container.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:229) at org.apache.pluto.driver.container.DefaultPortletInvokerService.serveResource(DefaultPortletInvokerService.java:149) at org.apache.pluto.container.impl.PortletContainerImpl.doServeResource(PortletContainerImpl.java:203) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:156) at org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:205) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:558) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:662) Caused by:
[TRINIDAD] Will be tagging Trinidad tomorrow morning
Hey everyone, Just FYI, I'd like to tag Trinidad 2.0 for a new release tomorrow if we can. I fixed the Bridge issue (or rather passed it one because it was already fixed :) ) and checked in many of the remaining patches. I'll do another pass of checking in patches tomorrow before I tag but I think we're looking pretty good. Scott
[jira] [Resolved] (TRINIDAD-2078) SKIP_ITERATION forces visit of non-rendered components
[ https://issues.apache.org/jira/browse/TRINIDAD-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Schwartz resolved TRINIDAD-2078. - Resolution: Fixed Fix Version/s: 2.0.0-beta-3 SKIP_ITERATION forces visit of non-rendered components -- Key: TRINIDAD-2078 URL: https://issues.apache.org/jira/browse/TRINIDAD-2078 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Blake Sullivan Fix For: 2.0.0-beta-3 Attachments: trin2078_trin2.diff, trinidad-2078.diff Certain tree visits, such as the PostRestoreStateEvent delivery visit, must avoid iteration in stamping components (eg. UIData). Before the fix for: TRINIDAD-2030 Honor SKIP_ITERATION FacesContext property This was handled in UIXComponent.visitChildren() by checking for the restore view phase. As of the fix for 2030, instead of checking the phase id we now check for the SKIP_ITERATION pseudo-hint. While this works correctly for the PostRestoreStateEvent visit, it fails in other cases. The problem: UIXComponent.visitChildren() falls back on a facets and children traversal when SKIP_ITERATION is set, which means that we will visit all children (both rendered and non-rendered) even when the SKIP_UNRENDERED hint is set. Thus, the combination of SKIP_ITERATION and SKIP_UNRENDERED is not correctly supported with our current solution. Since this is a valid combination of hints, we'll need an approach that correctly supports this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release myfaces-site-skin 3
+1 Sent from my iPhone On Apr 13, 2011, at 6:35 PM, Hazem Saleh haz...@apache.org wrote: +1 On Wed, Apr 13, 2011 at 9:13 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/4/13 Bernd Bohmann bernd.bohm...@atanion.com Here is my +1 Bernd On Wed, Apr 13, 2011 at 4:06 PM, Matthias Wessendorf mat...@apache.org wrote: +1 On Wed, Apr 13, 2011 at 4:02 PM, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hello, i would like to release the myfaces-site-skin 3. Changes: Added ASF Branding requirements to the skin see: http://www.apache.org/foundation/marks/pmcs The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-089 The Vote is open for 24h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com
