Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
sure! On Thu, May 28, 2009 at 6:34 AM, Leonardo Uribe lu4...@gmail.com wrote: +1, but just a small suggestion. Right now I'm running the necessary steps for release myfaces core 1.2.7, core 1.1.7, so I would like if it is possible to delay this change after the release. regards Leonardo Uribe 2009/5/27 Cagatay Civici cagatay.civ...@gmail.com +1 for sure On Wed, May 27, 2009 at 8:53 AM, Bruno Aranda brunoara...@gmail.com wrote: +1 sounds good to me 2009/5/27 Matthias Wessendorf mat...@apache.org: so, there are no objections in making the MyFaces 2.0 efforts become trunk ? -Matthias On Fri, May 22, 2009 at 9:10 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, +1 I would prefer /trunk - 2.0 /branches/myfaces-1.1.x /branches/myfaces-1.2.x because we are not using cvs anymore and the path already contains http://svn.apache.org/repos/asf/myfaces/core/ maybe we can omit the 'myfaces' in the branch name. Regards Bernd On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf mat...@apache.org wrote: actually, I agree with Bernd. For the following layout: /trunk - 2.0 /branches/myfaces_1_1_x /branches/myfaces_1_2_x Two reasons for way making 2.0 trunk: -most current development is on-going in 2.0 (new spec) -most commits are going to the 2.0 branch (so, let's make it trunk) So, I am +1 on the above svn layout -Matthias On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf mat...@apache.org wrote: from Bernd, on a different thread: Hello, I would suggest following layout 1.1.x branch/1.1.x 1.2.x branch/1.2.x 2.0.x trunk because the 2.0.x version is in development the other branches are only in bugfix state. On Fri, May 15, 2009 at 1:13 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hi, ... Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) what do people think if the 1.2 stuff becomes trunk And the following efforts are on a branch: -2.0.x -1.1.x +1 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1027) returnFromDialog doesn't work for JSF1.2 when useWindow=false
[
https://issues.apache.org/jira/browse/TRINIDAD-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12713903#action_12713903
]
Valentinas Gylys commented on TRINIDAD-1027:
Any plans on solving it?
returnFromDialog doesn't work for JSF1.2 when useWindow=false
---
Key: TRINIDAD-1027
URL: https://issues.apache.org/jira/browse/TRINIDAD-1027
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.1-core, 1.2.2-core, 1.2.3-core, 1.2.4-core,
1.2.5-core, 1.2.6-core, 1.2.7-core
Reporter: Giedrius Kasparas
Priority: Blocker
This can be reproduced in demo application:
change useWindow from true to false in
trinidad-demo-1.2.7/demos/launchDialog.jspx
tr:commandButton text=... action=dialog:chooseInteger
windowWidth=300 windowHeight=150
useWindow=false
returnListener=#{launchDialog.tableReturned}/
After such change neither 'Submit' nor 'Cancel' button in chooseInteger.jspx
page return back to launchDialog.jspx page.
I've tried and it doesn't return to opening page in every trinidad-demo-1.2.x
release
but it works as expected in every trinidad-demo-1.0.x release.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
J4Fry dojoFacelets
Hi, We are having a meeting on the dojo facelets with the J4Fry people tonight in munich. As this might come to MyFaces you are invited to join us. If you aren't in located munich, don't panic: I'll outline our results tomorrow. Best regards, Ganesh So, here's the results from the J4Fry dojoFacelets meeting last night: Developer interest is huge, the technology hits the nerve. The J4Fry members expressed their wish to continue the development of dojoFacelets within the J4Fry CVS at Sourceforge. There shouldn't be any difference because it's open source and the license is identical. The MyFaces people are very welcome to join in with the development. This is the list of components contained in the latest dojoFacelets release: dojo:form dojo:button dojo:dataGrid dojo:tabContainer dojo:comboBox dojo:filteringSelect dojo:tree And here is the list of dijit widgets we want to integrate next: MenuBar Editor DateTextBox Drap and Drop / Shuttle Progressbar CheckBox ValidationInput RadioButton Slider enhance dojo:comboBox for an autocomplete example Finally all dijit Widgets that need server communication shall be wrapped with tags. Best regards, Ganesh
Re: J4Fry dojoFacelets
Awesome On Thu, May 28, 2009 at 10:36 AM, Ganesh gan...@j4fry.org wrote: Hi, We are having a meeting on the dojo facelets with the J4Fry people tonight in munich. As this might come to MyFaces you are invited to join us. If you aren't in located munich, don't panic: I'll outline our results tomorrow. Best regards, Ganesh So, here's the results from the J4Fry dojoFacelets meeting last night: Developer interest is huge, the technology hits the nerve. The J4Fry members expressed their wish to continue the development of dojoFacelets within the J4Fry CVS at Sourceforge. There shouldn't be any difference because it's open source and the license is identical. The MyFaces people are very welcome to join in with the development. This is the list of components contained in the latest dojoFacelets release: dojo:form dojo:button dojo:dataGrid dojo:tabContainer dojo:comboBox dojo:filteringSelect dojo:tree And here is the list of dijit widgets we want to integrate next: MenuBar Editor DateTextBox Drap and Drop / Shuttle Progressbar CheckBox ValidationInput RadioButton Slider enhance dojo:comboBox for an autocomplete example Finally all dijit Widgets that need server communication shall be wrapped with tags. Best regards, Ganesh
Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
+1 On Thu, May 28, 2009 at 2:23 AM, Matthias Wessendorf mat...@apache.orgwrote: sure! On Thu, May 28, 2009 at 6:34 AM, Leonardo Uribe lu4...@gmail.com wrote: +1, but just a small suggestion. Right now I'm running the necessary steps for release myfaces core 1.2.7, core 1.1.7, so I would like if it is possible to delay this change after the release. regards Leonardo Uribe 2009/5/27 Cagatay Civici cagatay.civ...@gmail.com +1 for sure On Wed, May 27, 2009 at 8:53 AM, Bruno Aranda brunoara...@gmail.com wrote: +1 sounds good to me 2009/5/27 Matthias Wessendorf mat...@apache.org: so, there are no objections in making the MyFaces 2.0 efforts become trunk ? -Matthias On Fri, May 22, 2009 at 9:10 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, +1 I would prefer /trunk - 2.0 /branches/myfaces-1.1.x /branches/myfaces-1.2.x because we are not using cvs anymore and the path already contains http://svn.apache.org/repos/asf/myfaces/core/ maybe we can omit the 'myfaces' in the branch name. Regards Bernd On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf mat...@apache.org wrote: actually, I agree with Bernd. For the following layout: /trunk - 2.0 /branches/myfaces_1_1_x /branches/myfaces_1_2_x Two reasons for way making 2.0 trunk: -most current development is on-going in 2.0 (new spec) -most commits are going to the 2.0 branch (so, let's make it trunk) So, I am +1 on the above svn layout -Matthias On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf mat...@apache.org wrote: from Bernd, on a different thread: Hello, I would suggest following layout 1.1.x branch/1.1.x 1.2.x branch/1.2.x 2.0.x trunk because the 2.0.x version is in development the other branches are only in bugfix state. On Fri, May 15, 2009 at 1:13 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hi, ... Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) what do people think if the 1.2 stuff becomes trunk And the following efforts are on a branch: -2.0.x -1.1.x +1 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-1491) Initially sorted table column
Initially sorted table column - Key: TRINIDAD-1491 URL: https://issues.apache.org/jira/browse/TRINIDAD-1491 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.2.11-core, 1.0.11-core Reporter: Tomas Havelka It would be nice if the table component should define any of its columns as initially sorted when table is rendered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1491) Initially sorted table column
[ https://issues.apache.org/jira/browse/TRINIDAD-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Havelka updated TRINIDAD-1491: Status: Patch Available (was: Open) Initially sorted table column - Key: TRINIDAD-1491 URL: https://issues.apache.org/jira/browse/TRINIDAD-1491 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.0.11-core, 1.2.11-core Reporter: Tomas Havelka It would be nice if the table component should define any of its columns as initially sorted when table is rendered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2139) h:messages don't use styleClass attribute when rendering
[ https://issues.apache.org/jira/browse/MYFACES-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12713985#action_12713985 ] Frank-Michael Jaeschke commented on MYFACES-2139: - I think the fix is not complete yet. Rendering styleClass and style attributes to the component is missing. According to sun jsf 1.1 tld doc (http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/tlddocs/index.html), for example we have errorClass - CSS style class to apply to any message with a severity class of ERROR fatalClass - CSS style class to apply to any message with a severity class of FATAL and so on. A single message is rendered to li class=errorClassmessage/li this is perfect now. But tld contains also styleClass - Space-separated list of CSS style class(es) to be applied when this element is rendered. This value must be passed through as the class attribute on generated markup. So I would assume h:messages styleClass=styleClass errorClass=errorClass/ would be rendered to ul class=styleClass li class=errorClassmessage/li /ul h:messages don't use styleClass attribute when rendering Key: MYFACES-2139 URL: https://issues.apache.org/jira/browse/MYFACES-2139 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.6, 1.2.6 Reporter: Frank-Michael Jaeschke Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT, 1.2.7-SNAPSHOT Attachments: HtmlRendererBase.patch MyFaces breaks compatibility with Sun RI as the styleClass attribute is not rendered for h:messages. The styleClass attribute should be applied to the ul element (or the table element if in table layout). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-760) target attribute in tc:menuitem should be paired with link attribute
target attribute in tc:menuitem should be paired with link attribute -- Key: TOBAGO-760 URL: https://issues.apache.org/jira/browse/TOBAGO-760 Project: MyFaces Tobago Issue Type: Improvement Environment: N/A for feature enhancement. For the curious: Ubuntu 9.04, Tomcat 5.5 and Tobago 1.0.20, similarly openSuSE 11.1, Tomcat 6 and Tobago 1.0.20 Reporter: D. W. The target attribute for the tc:menuitem only works in connection with the action attribute. This has been resolved in issue: https://issues.apache.org/jira/browse/TOBAGO-286 . However, for better usability and also consistency it should be possible to make it also work when specifying the link attribute instead of the action attribute. Thank you very much for your time and consideration. Best regards, D.W. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-983) Sortable model for localized texts
[ https://issues.apache.org/jira/browse/TRINIDAD-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Havelka updated TRINIDAD-983: --- Status: Patch Available (was: Open) Sortable model for localized texts -- Key: TRINIDAD-983 URL: https://issues.apache.org/jira/browse/TRINIDAD-983 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.0.6-core Reporter: Tomas Havelka Attachments: locale-sensitive-sortable-model.patch Sortable model should support sorting for current locale. Solution: Extend inner class Comp of SortableModel to support sorting of String values using Collator.compare method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: J4Fry dojoFacelets
On Thu, May 28, 2009 at 4:48 PM, Matthias Wessendorf mat...@apache.org wrote: sounds good! Perhaps you can link from the myfaces project to the dojoFacelets ? myfaces wiki :-) -M On Thu, May 28, 2009 at 11:36 AM, Ganesh gan...@j4fry.org wrote: Hi, We are having a meeting on the dojo facelets with the J4Fry people tonight in munich. As this might come to MyFaces you are invited to join us. If you aren't in located munich, don't panic: I'll outline our results tomorrow. Best regards, Ganesh So, here's the results from the J4Fry dojoFacelets meeting last night: Developer interest is huge, the technology hits the nerve. The J4Fry members expressed their wish to continue the development of dojoFacelets within the J4Fry CVS at Sourceforge. There shouldn't be any difference because it's open source and the license is identical. The MyFaces people are very welcome to join in with the development. This is the list of components contained in the latest dojoFacelets release: dojo:form dojo:button dojo:dataGrid dojo:tabContainer dojo:comboBox dojo:filteringSelect dojo:tree And here is the list of dijit widgets we want to integrate next: MenuBar Editor DateTextBox Drap and Drop / Shuttle Progressbar CheckBox ValidationInput RadioButton Slider enhance dojo:comboBox for an autocomplete example Finally all dijit Widgets that need server communication shall be wrapped with tags. Best regards, Ganesh -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [MyFaces 2.0] an experiment ?
Hi, the dojo license have to be appropriate because it is already in tomahawk ;-) I don't like the concept of the plugins from JQuery as mentioned above (from ganesh). I wouldn't use ExtJS as well (it has got the smack of commercial software ;-)) Alex 2009/5/27 Jan-Kees van Andel jankeesvanan...@gmail.com IMHO, Dojo, Prototype.js, JQuery and most other big JS libraries are more or less the same. Dojo was very bloated in the past, but the Dojo team have cleaned a lot, which makes it a quite lean and mean library atm. I've always been a Prototype.js fan because the programming model looks the most like Java (objects vs. functions). I'm using JQuery on my current project and I must say, I like it. It offers a really productive API, but it's a quite difficult library for beginners, because it relies heavily on function chaining, closures, etc. Prototye.js code is often longer, but also more readable. But because Prototype.js is also moving towards a more oneliner API and Dojo is getting leaner, I would say, let the license decide. JQuery: MIT + GPL. Don't know if MIT can be used? Prototype.js: Also MIT Dojo: BSD + Academic Free License I've checked out some other libraries (YUI, Sajax...) and it looks like BSD is a much used licensing model amongst JS libraries... I wouldn't use ExtJS because of the reasons stated by Ganesh. If MIT is compatible with Apache, I would use JQuery, otherwise, if BSD or Academic Free License is compatible with Apache, use Dojo, otherwise we need to look for another JS library which has a good license... My 2 cents, /JK 2009/5/27 Mike Kienenberger mkien...@gmail.com: Yes, I looked at this library for GWT work a couple weeks ago. It's compatible in theory, but not in practice. On Wed, May 27, 2009 at 6:23 AM, Ganesh gan...@j4fry.org wrote: AFAIK ExtJS may not be altered and resold commercially - they have a 2nd commercial license. The whole thing is developed commercially. IMHO they use OS just to get their excellent product into the market, but they don't have the OS spirit. -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml
[jira] Commented: (MYFACES-2139) h:messages don't use styleClass attribute when rendering
[ https://issues.apache.org/jira/browse/MYFACES-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12714106#action_12714106 ] Leonardo Uribe commented on MYFACES-2139: - Yes, you're right. Changed to proposed behavior on both branches and modified junit test to detect this condition. Thanks to Frank-Michael Jaeschke for the attention in the details. h:messages don't use styleClass attribute when rendering Key: MYFACES-2139 URL: https://issues.apache.org/jira/browse/MYFACES-2139 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.6, 1.2.6 Reporter: Frank-Michael Jaeschke Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT, 1.2.7-SNAPSHOT Attachments: HtmlRendererBase.patch MyFaces breaks compatibility with Sun RI as the styleClass attribute is not rendered for h:messages. The styleClass attribute should be applied to the ul element (or the table element if in table layout). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2156) Performance improvement in HtmlRenderKitImpl
[ https://issues.apache.org/jira/browse/MYFACES-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12714120#action_12714120 ] Martin Marinschek commented on MYFACES-2156: Hi Leonardo, are you sure a flat3map will not cause any problems with multiple threads accessing the configuration? regards, Martin Performance improvement in HtmlRenderKitImpl Key: MYFACES-2156 URL: https://issues.apache.org/jira/browse/MYFACES-2156 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.1.6 Reporter: Philipp Schoepf Assignee: Leonardo Uribe Priority: Minor Fix For: 1.2.7-SNAPSHOT Attachments: MYFACES-2156.patch we did some profiling in our project and found out that HtmlRenderKitImpl creates some amount of transient object garbage when getRenderer is called: Self 8005 0,00 7,92 0 2894448 J:org/apache/myfaces/renderkit/html/HtmlRenderKitImpl.getRenderer(Ljava/lang/String;Ljava/lang/String;)Ljavax/faces/render/Renderer; Child 24015 0,00 4,69 0 1714064 J:java/lang/StringBuffer.append(Ljava/lang/String;)Ljava/lang/StringBuffer; The above values were recorded with just 2 request to a page with many components - 2.8MB of transient objects were created by 8005 calls to getRenderer. I assume that this is due to the keying currenlty implemented which always creates a concatinated string. I guess using a MapString, MapString, Renderer doubleMap could improve the performance here since string creation for keying would not be nessary. Might also touch 1.2 and 2.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2156) Performance improvement in HtmlRenderKitImpl
[
https://issues.apache.org/jira/browse/MYFACES-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12714129#action_12714129
]
Leonardo Uribe commented on MYFACES-2156:
-
Hi Martin
Originally the default structure that holds renderers was a simple HashMap.
Right now, one point that need concurrency management is when you add a
renderer to the structure:
synchronized private void _put(String componentFamily, String rendererType,
Renderer renderer)
{
Map String,Renderer familyRendererMap =
_renderers.get(componentFamily);
if (familyRendererMap == null)
{
familyRendererMap = (MapString,Renderer) new Flat3Map();
_renderers.put(componentFamily, familyRendererMap);
}
else
{
//Log override
}
familyRendererMap.put(rendererType, renderer);
}
The reason to do that here is prevent create a familyRendererMap twice and lost
one renderer configuration.
The default RenderKit is loaded (or addRenderer is called) in two situations:
- On application init.
- On update conditions occur (change on some faces-config related file on
/WEB-INF/ path). Note that when update occur the current RenderKit instance is
not reused, a new one is created.
In any case, all renderers are loaded once by a single thread.
Now, in comparison with trinidad RenderKitBase, the reason why trinidad
counterpart uses a ConcurrentHashMapString,ConcurrentHashMapString, Object
is because trinidad load renderers on demand (concurrent read and write occur).
RenderKitImpl has never experienced concurrent read and write because by design
load all renderers at once and never during the app lifecycle is added or
overridden.
The scenario that requires an inner concurrent HashMap is when there are
multiple read a write, but since all write calls are synchronized, and Renderer
instances does not have any inner state, everything is ok.
At this point we have several options:
1. Keep using a simple Flat3Map
2. Use a ConcurrentHashMapString, Object(8, 0.75f, 1) like RenderKitBase
3. Wrap Flat3Map with a Collections.synchronizedMap(Map)
The evidence at this time suggest option 1 is enough, but if some user by some
reason add or override renderers on different moments than current ones use
option 2 or 3 is preferred. Anyway, I think use a ConcurrentHashMap like
RenderKitBase could prevent concurrency problems in any hypothetical case case.
regards
Leonardo
Performance improvement in HtmlRenderKitImpl
Key: MYFACES-2156
URL: https://issues.apache.org/jira/browse/MYFACES-2156
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 1.1.6
Reporter: Philipp Schoepf
Assignee: Leonardo Uribe
Priority: Minor
Fix For: 1.2.7-SNAPSHOT
Attachments: MYFACES-2156.patch
we did some profiling in our project and found out that HtmlRenderKitImpl
creates some amount of transient object garbage when getRenderer is called:
Self 8005 0,00 7,92 0 2894448
J:org/apache/myfaces/renderkit/html/HtmlRenderKitImpl.getRenderer(Ljava/lang/String;Ljava/lang/String;)Ljavax/faces/render/Renderer;
Child 24015 0,00 4,69 0 1714064
J:java/lang/StringBuffer.append(Ljava/lang/String;)Ljava/lang/StringBuffer;
The above values were recorded with just 2 request to a page with many
components - 2.8MB of transient objects were created by 8005 calls to
getRenderer.
I assume that this is due to the keying currenlty implemented which always
creates a concatinated string. I guess using a MapString, MapString,
Renderer doubleMap could improve the performance here since string creation
for keying would not be nessary.
Might also touch 1.2 and 2.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2156) Performance improvement in HtmlRenderKitImpl
[ https://issues.apache.org/jira/browse/MYFACES-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12714150#action_12714150 ] Leonardo Uribe commented on MYFACES-2156: - Committed option 2 use ConcurrentHashMapString, Renderer(8, 0.75f, 1) like RenderKitBase, just for prevention. Performance improvement in HtmlRenderKitImpl Key: MYFACES-2156 URL: https://issues.apache.org/jira/browse/MYFACES-2156 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.1.6 Reporter: Philipp Schoepf Assignee: Leonardo Uribe Priority: Minor Fix For: 1.2.7-SNAPSHOT Attachments: MYFACES-2156.patch we did some profiling in our project and found out that HtmlRenderKitImpl creates some amount of transient object garbage when getRenderer is called: Self 8005 0,00 7,92 0 2894448 J:org/apache/myfaces/renderkit/html/HtmlRenderKitImpl.getRenderer(Ljava/lang/String;Ljava/lang/String;)Ljavax/faces/render/Renderer; Child 24015 0,00 4,69 0 1714064 J:java/lang/StringBuffer.append(Ljava/lang/String;)Ljava/lang/StringBuffer; The above values were recorded with just 2 request to a page with many components - 2.8MB of transient objects were created by 8005 calls to getRenderer. I assume that this is due to the keying currenlty implemented which always creates a concatinated string. I guess using a MapString, MapString, Renderer doubleMap could improve the performance here since string creation for keying would not be nessary. Might also touch 1.2 and 2.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTVAL-43) typesafe constraint parameter mechanism
typesafe constraint parameter mechanism
---
Key: EXTVAL-43
URL: https://issues.apache.org/jira/browse/EXTVAL-43
Project: MyFaces Extensions Validator
Issue Type: New Feature
Components: Core
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
mechanism which allows generic and typesafe parameters for annotations
example:
public @interface MyAnnotation
{
Class? extends ValidationParameter[] parameters();
}
usage:
@MyAnnotation(parameters = MyValue.class)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTVAL-44) constraint severity for the validation process
constraint severity for the validation process -- Key: EXTVAL-44 URL: https://issues.apache.org/jira/browse/EXTVAL-44 Project: MyFaces Extensions Validator Issue Type: New Feature Components: Core, Property Validation Reporter: Gerhard Petracek Assignee: Gerhard Petracek via the parameter-type ViolationSeverity it is possible to switch the severity. severity warn and info don't lead to a ValidatorException - in such a case just a faces-message is queued with the given severity. @Required(parameters = ViolationSeverity.Warn.class) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
