PMC chair of Apache MyFaces changed
Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: PMC chair of Apache MyFaces changed
Matthias, Thx for the work and effort you have put into the Myfaces project. Gerhard, Congratulations. Regards Rudy On 17 March 2011 08:20, Matthias Wessendorf mat...@apache.org wrote: Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: PMC chair of Apache MyFaces changed
Thank you Mathias. Congratulations Gerhard, and good luck! :-) Walter Mourão http://waltermourao.com.br http://arcadian.com.br http://oriens.com.br On Thu, Mar 17, 2011 at 4:20 AM, Matthias Wessendorf mat...@apache.orgwrote: Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-2065) render javascript focus() instead of plain href-anker in links of tr:messages box.
render javascript focus() instead of plain href-anker in links of tr:messages
box.
--
Key: TRINIDAD-2065
URL: https://issues.apache.org/jira/browse/TRINIDAD-2065
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.2.14-core
Environment: Browser with enabled javascript
Reporter: Markus Reichert
The tr:messages-Tag-Renderer MessageBoxRenderer._renderMessageAnchor(...)
renders an anker like that:
a href=#_msgAnc_ComponentId class=OraLinkLabelOfComponent/a
The Anker isn't very handy for the user because when the link above is clicked
the only thing happens is that the browser scrolls to the label of the
input-field affected.
In cases of enabled javascript on the browser it would there a better solution
instead which focuses the affected input-field directly:
a href=javascript:document.getElementById('ComponentId').focus();
class=OraLinkLabelOfComponent/a
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3076) Improve error reporting and logging: report duplicate converters, validators, etc.
Improve error reporting and logging: report duplicate converters, validators,
etc.
--
Key: MYFACES-3076
URL: https://issues.apache.org/jira/browse/MYFACES-3076
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Reporter: Martin Kočí
Priority: Minor
One of the problems from category:
http://www.mail-archive.com/dev@myfaces.apache.org/msg50721.html
Situation: if user creates (mostly by mistake) two converters for same type:
@FacesConverter(forClass=AEntity.class)
public class ConverterOne {}
@FacesConverter(forClass=AEntity.class)
public class ConverterTwo {}
myfaces don't say nothing, moreover random behaviour occurs, because
HashMapString,Converter and together with classloading in ConverterOne or
ConverterTwo is used randomly.
This obviously can afftect @FacesValidator etc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-980) tc:attribute mode=valueIfSet not working in some cases
tc:attribute mode=valueIfSet not working in some cases Key: TOBAGO-980 URL: https://issues.apache.org/jira/browse/TOBAGO-980 Project: MyFaces Tobago Issue Type: Bug Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor Especially in the case of setting an id attribute in a facelets template, the attribute doesn't work like expected. I've added some use cases in the tobago-example-test application in file: tc/attribute/mode-valueIfSet.xhtml -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2065) render javascript focus() instead of plain href-anker in links of tr:messages box.
[
https://issues.apache.org/jira/browse/TRINIDAD-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007924#comment-13007924
]
Scott O'Bryan commented on TRINIDAD-2065:
-
Very cool idea Markus. It's a little more complex then this because the
componentId does not always map to the actual component itself, but it's a
great suggestion.
render javascript focus() instead of plain href-anker in links of tr:messages
box.
--
Key: TRINIDAD-2065
URL: https://issues.apache.org/jira/browse/TRINIDAD-2065
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.2.14-core
Environment: Browser with enabled javascript
Reporter: Markus Reichert
The tr:messages-Tag-Renderer MessageBoxRenderer._renderMessageAnchor(...)
renders an anker like that:
a href=#_msgAnc_ComponentId class=OraLinkLabelOfComponent/a
The Anker isn't very handy for the user because when the link above is
clicked the only thing happens is that the browser scrolls to the label of
the input-field affected.
In cases of enabled javascript on the browser it would there a better
solution instead which focuses the affected input-field directly:
a href=javascript:document.getElementById('ComponentId').focus();
class=OraLinkLabelOfComponent/a
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-980) tc:attribute mode=valueIfSet not working in some cases
[ https://issues.apache.org/jira/browse/TOBAGO-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-980. Resolution: Fixed tc:attribute mode=valueIfSet not working in some cases Key: TOBAGO-980 URL: https://issues.apache.org/jira/browse/TOBAGO-980 Project: MyFaces Tobago Issue Type: Bug Components: Facelets Affects Versions: 1.5.0-alpha-2, 1.0.35 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor Fix For: 1.0.36, 1.5.0-alpha-3 Especially in the case of setting an id attribute in a facelets template, the attribute doesn't work like expected. I've added some use cases in the tobago-example-test application in file: tc/attribute/mode-valueIfSet.xhtml -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2066) do not cache url connections for trinidad-skins.xml or for skinning's css files in design time mode
do not cache url connections for trinidad-skins.xml or for skinning's css files
in design time mode
---
Key: TRINIDAD-2066
URL: https://issues.apache.org/jira/browse/TRINIDAD-2066
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Our skinning editor deploys a jar with the user's custom skin. The user adds
this jar to the classpath, and the user views the page in design time mode. The
user goes back to the skinning editor, changes the custom skin, redeploys the
jar, but does not see the changes in the design time mode without restarting
the server.
The fix is to call setUseCaches(false) when in design time mode:
// prevent caching during DT where the source may change...
if (Beans.isDesignTime())
{
connection.setUseCaches(false);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2066) do not cache url connections for trinidad-skins.xml or for skinning's css files in design time mode
[
https://issues.apache.org/jira/browse/TRINIDAD-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman resolved TRINIDAD-2066.
--
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
do not cache url connections for trinidad-skins.xml or for skinning's css
files in design time mode
---
Key: TRINIDAD-2066
URL: https://issues.apache.org/jira/browse/TRINIDAD-2066
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Fix For: 2.0.0-beta-3
Our skinning editor deploys a jar with the user's custom skin. The user adds
this jar to the classpath, and the user views the page in design time mode.
The user goes back to the skinning editor, changes the custom skin, redeploys
the jar, but does not see the changes in the design time mode without
restarting the server.
The fix is to call setUseCaches(false) when in design time mode:
// prevent caching during DT where the source may change...
if (Beans.isDesignTime())
{
connection.setUseCaches(false);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release MyFaces Portlet Bridge 3.0.0
Reminder -- if you are intending to vote please do so by mid-day Friday (PST) as I want to close the vote before the weekend. -Mike- On 3/16/2011 1:12 PM, Michael Freedman wrote: +1 FYI ... I plan to close the vote on Friday. Hopefully I will have some more votes to record by then. -Mike- On 3/15/2011 9:30 AM, Michael Freedman wrote: Here is the information you want -- however I don't really want to hold this release until MyFaces/Trinidad are released -- rather can't we use this release as pressure to wrap up releases in these other projects so they follow shortly? Have folks been waiting to vote because of Scott's e-mail -- if so I would appreciate your vote so I can close/release this. Trinidad JIRA: TRINIDAD-1996 https://issues.apache.org/jira/browse/TRINIDAD-1996 (Status Fixed 1/26/11) I believe this fix is in Beta-2 but I haven't tried it yet and another member of the team reports other problems with using beta-2. I need to investigate more MyFaces JIRA: MYFACES-3064 https://issues.apache.org/jira/browse/MYFACES-3064: Fixed 3/1/11 Fix Version: 2.0.5-SNAPSHOT MYFACES-3045 https://issues.apache.org/jira/browse/MYFACES-3045: Fixed 3/1/11 Fix Version: 2.0.5-SNAPSHOT MYFACES-3042 https://issues.apache.org/jira/browse/MYFACES-3042: Fixed 2/15/11 Fix Version: Unresolved -- patch available MYFACES-3039 https://issues.apache.org/jira/browse/MYFACES-3039: Fixed 2/18/11 Fix Version: 2.0.5-SNAPSHOT MYFACES-3038 https://issues.apache.org/jira/browse/MYFACES-3038: Fixed 2/18/11 Fix Version: 2.0.4 MYFACES-3017 https://issues.apache.org/jira/browse/MYFACES-3017: Fixed 2/9/11 Fix Version: 2.0.4 MyFacesJIRA: On 3/10/2011 5:50 AM, Scott O'Bryan wrote: Hey Mike, do we have JIRA tickets for the Trinidad patches needed? Also, what are the challenges with the MyFaces core? I, for one, would like to see this fixed ASAP.. On Mar 9, 2011, at 4:53 PM, Michael Freedman michael.freed...@oracle.com wrote: Please vote on the proposed release of MyFaces Portlet Bridge 3.0.0-alpha. This is the alpha version of the Portlet Bridge for JSF 2.0. It includes all the base function of JSR329 updated to run in a JSF 2.0 environment. Some, though not all JSF 2.0 features are expressed/utilized. Most significant is Ajax support and Composite Component suppport. Note: this version of the bridge will not work with any currently released versions of MyFaces (try Trunk) and only mostly runs on released version of Mojarra (patches available). Likewise a patched version of Trinidad is needed to run the TCK (for those tests that depend on Trinidad). Distributable components can be inspected in http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha Repository artifacts are at: https://repository.apache.org/content/repositories/orgapachemyfaces-006/ I have verified that the distributable jars run and pass the updated version of the JSR 329 TCK. In addition I have verified that the distributable examples run (on apache tomcat/pluto). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, -Mike-
Re: PMC chair of Apache MyFaces changed
Matthias, Thanks for all of your hard work. Gerhard, congratulations and I look forward to working with you. -- Blake On 3/17/11 12:20 AM, Matthias Wessendorf wrote: Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias
Re: PMC chair of Apache MyFaces changed
Congrats Gerard. I hope we'll see you around Matthias. Greetings, Ali On Thu, Mar 17, 2011 at 7:43 PM, Blake Sullivan blake.sulli...@oracle.comwrote: Matthias, Thanks for all of your hard work. Gerhard, congratulations and I look forward to working with you. -- Blake On 3/17/11 12:20 AM, Matthias Wessendorf wrote: Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: PMC chair of Apache MyFaces changed
Hi, Thanks for all your work from me too, Matthias. You have been a very great PMC chair :) And of course congratulations to Gerhard! Regards, Jakob 2011/3/17 Ali Ok al...@aliok.com.tr: Congrats Gerard. I hope we'll see you around Matthias. Greetings, Ali On Thu, Mar 17, 2011 at 7:43 PM, Blake Sullivan blake.sulli...@oracle.com wrote: Matthias, Thanks for all of your hard work. Gerhard, congratulations and I look forward to working with you. -- Blake On 3/17/11 12:20 AM, Matthias Wessendorf wrote: Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release for myfaces core 1.1.9
+1 Regards, Jakob 2011/3/16 Werner Punz werner.p...@gmail.com: +1 Am 16.03.11 20:14, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 1.1.9 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v2.0.12 [1] 2. Maven artifact group org.apache.myfaces.core v1.1.9 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 1.1.9 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-013/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces119binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316154 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: PMC chair of Apache MyFaces changed
Thanks for all of your hard work, Matthias! We'll miss you. Welcome, Gerhard! Sent from my iPhone http://www.jsfcentral.com http://www.Virtua.com On Mar 17, 2011, at 3:20 AM, Matthias Wessendorf mat...@apache.org wrote: Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: PMC chair of Apache MyFaces changed
Congrats Gerhard!! And its sad to see you leave Matthias! I agree with Kito and will definitely miss you! Bruno On 17 March 2011 18:56, Kito Mann kito.m...@virtua.com wrote: Thanks for all of your hard work, Matthias! We'll miss you. Welcome, Gerhard! Sent from my iPhone http://www.jsfcentral.com http://www.Virtua.com On Mar 17, 2011, at 3:20 AM, Matthias Wessendorf mat...@apache.org wrote: Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (TOMAHAWK-1562) tomahawk20-1.1.10 for JSF 2 does not work: aliasBean
[
https://issues.apache.org/jira/browse/TOMAHAWK-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved TOMAHAWK-1562.
--
Resolution: Fixed
Fix Version/s: 1.1.11-SNAPSHOT
Assignee: Leonardo Uribe
I did a full review of the component to find the problem and I was able to
reproduce it. I found that the template used to generate tomahawk jsp tld file
was changed in JSF 2.0. The problem was caused by this line on Alias bean
@JSFProperty
public String getValue()
It is true the method returns String but it is expected the value expression
returns Object. The solution is do this:
@JSFProperty(deferredValueType=java.lang.Object)
public String getValue()
I did some other small changes to take into consideration JSP usage (cache
facesContext again, add invokeOnComponent code.
tomahawk20-1.1.10 for JSF 2 does not work: aliasBean
Key: TOMAHAWK-1562
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1562
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Alias Bean
Environment: Windows, tomahawk20-1.1.10, JSF 2.0 (Mojarra 2.0) on
JBoss AS 6, Richfaces 3.3.1
Reporter: Dave
Assignee: Leonardo Uribe
Fix For: 1.1.11-SNAPSHOT
I tried tomahawk20-1.1.10 with jsf 2.0 (Mojarra 2.0) on JBoss AS 6, and got
the following exception. The bean is alias, and it works for JSF 1.2.
t:aliasBean alias=#{bean} value=#{fooBean}
f:subview id=foo
jsp:include page=/include/foo.jsp /
/f:subview
/t:aliasBean
org.apache.jasper.el.JspPropertyNotFoundException: /include/foo.jsp(47,2)
'#{bean.result}' The class 'java.lang.String' does not have the property
'result'
.
at
org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:104)
[:6.0.0.Final]
at
org.apache.myfaces.custom.aliasbean.Alias.computeEvaluatedExpression(Alias.java:112)
[:1.1.10]
at org.apache.myfaces.custom.aliasbean.Alias.make(Alias.java:136)
[:1.1.10]
at
org.apache.myfaces.custom.aliasbean.AliasBean.makeAlias(AliasBean.java:349)
[:1.1.10]
at
org.apache.myfaces.custom.aliasbean.AliasBean.makeAlias(AliasBean.java:334)
[:1.1.10]
at
org.apache.myfaces.custom.aliasbean.AliasBeanTag.doStartTag(AliasBeanTag.java:52)
[:1.1.10]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3077) CLONE - Support SKIP_ITERATION FacesContext property
CLONE - Support SKIP_ITERATION FacesContext property Key: MYFACES-3077 URL: https://issues.apache.org/jira/browse/MYFACES-3077 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.3 Reporter: Andy Schwartz Assignee: Leonardo Uribe Priority: Minor Fix For: 2.0.4 In the following jsr-314-open thread: http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-June/000200.html Members of the Mojarra team, MyFaces team and EG discussed a temporary workaround for the lack of a proper VisitHint.SKIP_ITERATION API in JSF 2.0.x. We agreed to use a FacesContext property to address this case until a new VisitHint enum value could be added in 2.1. Logging this issue to request that we add support for the FacesContext property (javax.faces.visit.SKIP_ITERATION) in MyFaces 2.0.x to allow tree visits to be performed without forcing iterating components (like UIData/UIRepeat) to iterate over all rows. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOMAHAWK-1570) CLONE - Support SKIP_ITERATION FacesContext property
[ https://issues.apache.org/jira/browse/TOMAHAWK-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved TOMAHAWK-1570. -- Resolution: Fixed Fix Version/s: 1.1.11-SNAPSHOT CLONE - Support SKIP_ITERATION FacesContext property Key: TOMAHAWK-1570 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1570 Project: MyFaces Tomahawk Issue Type: Improvement Components: JSF2 Affects Versions: 1.1.10 Reporter: Andy Schwartz Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.11-SNAPSHOT In the following jsr-314-open thread: http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-June/000200.html Members of the Mojarra team, MyFaces team and EG discussed a temporary workaround for the lack of a proper VisitHint.SKIP_ITERATION API in JSF 2.0.x. We agreed to use a FacesContext property to address this case until a new VisitHint enum value could be added in 2.1. Logging this issue to request that we add support for the FacesContext property (javax.faces.visit.SKIP_ITERATION) in MyFaces 2.0.x to allow tree visits to be performed without forcing iterating components (like UIData/UIRepeat) to iterate over all rows. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core] performance: ELResolvers filtering
This approach cannot filter two resolvers: 1. org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver 2. org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver 1) the first one is instance of CompositeELResolver and serves as container for sorted/filtered list of others ELResolvers. Currently does something for JSP, so I suggest to introduce: o.a.m.SUPPORT_JSP = true|false content-param as mentioned in original mail thread performance: disabling old technologies and if this false, myfaces will not install FacesCompositeELResolver, but plain javax.el.CompositeELResolver as parent. 2) org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver is the last one in chain and always calls setPropertyResolved(true); (JSF 2.1: 5.6.2.9 ScopedAttribute ELResolver) and pick up anything stored in the request, viewScope, session, or application scopes by name. In strictly CDI-based application with no direct modification of servlet scopes or view scope this resolver will never resolve a property. What to do with this one I don't know. Possibly we can use ELResolver transforming :) org.apache.commons.collections.Transformer and allow replace one resolver with another, for example: o.a.m.el.unified.resolver.ScopedAttributeResolver - MyNotResovingResolverWhichCallsSetPropertyResolvedTrue el.ResourceBundleELResolver - SpringMessageSourceResolver (we don't use ResourceBundle) el.BeanELResolver - MemoryLeakFreeBeanELResolver Of course this functionality can be achieved by filtering out the unwanted resolver with predicate and adding own in faces-config (and sort it to proper position in chain) Regards, Kočičák Martin Koci píše v St 16. 03. 2011 v 11:29 +0100: Hi, after few months I have time to do some performance optimalization for myfaces. This one is related to topic http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html Problem: how to disable ELResolver smartly? Adding a context-param for each is an overkill. But we have https://cwiki.apache.org/MYFACES/elresolver-ordering.html in codebase already. I propose to add new feature ELResolver filtering and new context-param: context-param param-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name param-valueorg.foo.bazz.ELResolverPredicate/param-value /context-param Filter is simple instance of org.apache.commons.collections.Predicate. For application where no ManagedBean(Resolver) is used or no Flash, user can simply return false from Predicate.evaluate and ELResolver won't be installed. WDYT? Regards, Kočičák
[jira] Created: (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOMAHAWK-96) Data table Scroller not working the dataTable which was actually contained in other DataTable
[
https://issues.apache.org/jira/browse/TOMAHAWK-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved TOMAHAWK-96.
Resolution: Fixed
Fix Version/s: 1.1.11-SNAPSHOT
This is another one related to TOMAHAWK-961. To make it work, now it is
possible to use t:dataTable preserveRowComponentState=true. Additionally, a
fix was done on t:dataScroller to take into account this case. Note this only
works on tomahawk for JSF 2.0 in facelets mode.
Data table Scroller not working the dataTable which was actually contained in
other DataTable
-
Key: TOMAHAWK-96
URL: https://issues.apache.org/jira/browse/TOMAHAWK-96
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Data Scroller
Environment: Window 2000 ( servicepack4 ) , JBuilderX , Tomcat 4.0 ,
using src ( myfaces-20051216-src )
Reporter: Sharvan Bhatt
Assignee: Thomas Spiegl
Fix For: 1.1.11-SNAPSHOT
I want to use the t:dataScroller ... / for Navigation in t:dataTable ...
/
It works fine but I in my case navigable t:dataScroller ... / is actually
contained in t:dataScroller ... /
Actual code
JSP
/***/
%@ taglib uri=/taglib/h.tld prefix=h%
%@ taglib uri=/taglib/f.tld prefix=f%
%@ taglib uri=/taglib/t.tld prefix=t%
%--
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
--%
html
head
title
componentCreationTest
/title
/head
body bgcolor=#ff
f:view
h:messages
/h:messages
h:message for=userGroup
/h:message
t:dataTable id=userGroup value=#{list.userGroup} var=userGroup
t:column
t:dataTable id=user value=#{list.users} var=data rows=5
preserveDataModel=true
h:column
f:facet name=header
h:outputLabel value=UserName
/h:outputLabel
/f:facet
h:outputLabel value=#{data}
/h:outputLabel
/h:column
f:facet name=footer
t:dataScroller fastStep=5 styleClass=scrollerTable
pageCountVar=pageCount
pageIndexVar=pageIndex
paginator=true
paginatorMaxPages=12
paginatorTableClass=paginator
paginatorActiveColumnStyle=font-weight:bold;
immediate=false
for=user
f:facet name=first
t:graphicImage url=/images/arrow-first.gif border=1
styleClass=objectList_GraphicImage /
/f:facet
f:facet name=last
t:graphicImage url=/images/arrow-last.gif border=1
styleClass=objectList_GraphicImage /
/f:facet
f:facet name=previous
t:graphicImage url=/images/arrow-previous.gif border=1
styleClass=objectList_GraphicImage/
/f:facet
f:facet name=next
t:graphicImage url=/images/arrow-next.gif border=1
styleClass=objectList_GraphicImage /
/f:facet
f:facet name=fastforward
t:graphicImage url=/images/arrow-ff.gif border=1
styleClass=objectList_GraphicImage/
/f:facet
f:facet name=fastrewind
t:graphicImage url=/images/arrow-fr.gif border=1
styleClass=objectList_GraphicImage/
/f:facet
/t:dataScroller
/f:facet
/t:dataTable
/t:column
/t:dataTable
/f:view
/body
/html
/***/
/***/
/***/
Corresponding Managed Bean Java Class code
/***/
/***/
package com.daffodilwoods.framework.tester;
import javax.faces.model.*;
import java.util.*;
import com.daffodilwoods.framework.test.User;
import javax.faces.model.DataModel;
public class SimpleUserList {
private DataModel users;
private DataModel userGroup;
public SimpleUserList() {
}
public DataModel getUsers(){
System.out.println(SimpleUserList.getUsers());
List list = new ArrayList();
for (int i = 0; i 100; i++) {
list.add(test ::
[jira] Created: (TOMAHAWK-1571) t:collapsiblePanel does not render its id when behaviors are used or it is indicated by user
t:collapsiblePanel does not render its id when behaviors are used or it is indicated by user Key: TOMAHAWK-1571 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1571 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.10 Reporter: Leonardo Uribe Assignee: Leonardo Uribe t:collapsiblePanel does not render its id when behaviors are used or it is indicated by user. This causes some operations fails, like use client behavior or f:ajax tag to refresh it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOMAHAWK-1571) t:collapsiblePanel does not render its id when behaviors are used or it is indicated by user
[ https://issues.apache.org/jira/browse/TOMAHAWK-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved TOMAHAWK-1571. -- Resolution: Fixed Fix Version/s: 1.1.11-SNAPSHOT t:collapsiblePanel does not render its id when behaviors are used or it is indicated by user Key: TOMAHAWK-1571 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1571 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.10 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 1.1.11-SNAPSHOT t:collapsiblePanel does not render its id when behaviors are used or it is indicated by user. This causes some operations fails, like use client behavior or f:ajax tag to refresh it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[trinidad][api] (TRINIDAD-2067) setUpEncodingContext called twice on all partial page rendered roots during optimized PPR
The below api is a little gross, but I don't see a better solution to the problem. -- Blake Sullivan Original Message Subject: [jira] Created: (TRINIDAD-2067) setUpEncodingContext called twice on all partial page rendered roots during optimized PPR Date: Fri, 18 Mar 2011 01:32:29 + (UTC) From: Blake Sullivan (JIRA) dev@myfaces.apache.org Reply-To: MyFaces Development dev@myfaces.apache.org To: dev@myfaces.apache.org setUpEncodingContext called twice on all partial page rendered roots during optimized PPR - Key: TRINIDAD-2067 URL: https://issues.apache.org/jira/browse/TRINIDAD-2067 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 2.0.0-beta-3 Reporter: Blake Sullivan Assignee: Blake Sullivan setUpEncodingContext is called on all of the partial page roots during optimized partial page rendering. This is because optimizedPPR uses a tree visit to visit the partial page roots to render and the tree visiting code calls setUpEncodingContext before calling the visit callback. The optimized PPR code then calls encodeAll() on the partial target, which calls beforeEncode(), which calls setupEncodingContext again. This breaks code that can't have its setupEncodingContext (and tearDownEncodingContext) called twice in a row. A good example is a form renderer that uses setupEncodingContext to catch cases where forms have been nested. The fix is to add an api to UIXComponent: /** * Calls the VisitCallback after popping the encoding or visiting context of the * current component and then restores that context, returning the VisitCallbacks's * response. This handles the rare cases where a VisitCallback should not be * called inside the target component's callback. * @param visitContext thecodeVisitContext/code for this visit * @param component thecodeUIComponent/code to pop the context of * @param callback thecodeVisitCallback/code instance to call in the popped context * @return the result of the VisitCallback */ public static VisitResult visitOutsideOfContext( VisitContext visitContext, UIComponent component, VisitCallback callback) The optimized PPR code can then wrap its current VisitCallback in one that calls visitOutsideOfContext, passing in the original VisitCallback. Other solutions would attempt to change the optimized PPR code to attempt to avoid calling encodeAll when the target was a UIXComponent, however doing so would require making assumptions about how different components have implemented encodeAll(), violating its abstraction. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
