Re: [VOTE] Release Tobago 1.0.36
Here is my +1 Regards Bernd On Thu, May 12, 2011 at 1:36 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote: +1 Am 09.05.11 22:52, schrieb Bernd Bohmann: Hello, I would like to release Tobago 1.0.36. Changes: ** Bug * [TOBAGO-980] - tc:attribute mode=valueIfSet not working in some cases * [TOBAGO-981] - Infinite loop in tobago-menu.js * [TOBAGO-983] - ComponentUtils.findDescendant returns the wrong component * [TOBAGO-995] - TextArea applies always style class tobago-TextArea-required, if length validator is present * [TOBAGO-996] - NonFacesRequestServlet doesn't work proper with JSF 1.2 * [TOBAGO-998] - Partially update while popup close drops User input ** Improvement * [TOBAGO-986] - Sheet can only sort UIOutput - Nothing happend with UILinkCommand and UIButtonCommand * [TOBAGO-997] - Extend DebugPhaseListener: log RequestURI, RequestHeaders, ResponseCharset, ... For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12316297 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-034/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
Re: [VOTE] Release Tobago 1.0.36
The vote has passed with the following results: +1 werpu (binding) weber(binding) struberg (binding) lofwyr (binding) bommel (binding) I will proceed with the next steps. Regards Bernd On Fri, May 13, 2011 at 9:32 AM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Here is my +1 Regards Bernd On Thu, May 12, 2011 at 1:36 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote: +1 Am 09.05.11 22:52, schrieb Bernd Bohmann: Hello, I would like to release Tobago 1.0.36. Changes: ** Bug * [TOBAGO-980] - tc:attribute mode=valueIfSet not working in some cases * [TOBAGO-981] - Infinite loop in tobago-menu.js * [TOBAGO-983] - ComponentUtils.findDescendant returns the wrong component * [TOBAGO-995] - TextArea applies always style class tobago-TextArea-required, if length validator is present * [TOBAGO-996] - NonFacesRequestServlet doesn't work proper with JSF 1.2 * [TOBAGO-998] - Partially update while popup close drops User input ** Improvement * [TOBAGO-986] - Sheet can only sort UIOutput - Nothing happend with UILinkCommand and UIButtonCommand * [TOBAGO-997] - Extend DebugPhaseListener: log RequestURI, RequestHeaders, ResponseCharset, ... For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12316297 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-034/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
[RESULT] [VOTE] Release Tobago 1.0.36
Ok now with changed subject. The vote has passed with the following results: +1 werpu (binding) weber(binding) struberg (binding) lofwyr (binding) bommel (binding) I will proceed with the next steps. Regards Bernd On Fri, May 13, 2011 at 9:37 AM, Bernd Bohmann bernd.bohm...@atanion.com wrote: The vote has passed with the following results: +1 werpu (binding) weber(binding) struberg (binding) lofwyr (binding) bommel (binding) I will proceed with the next steps. Regards Bernd On Fri, May 13, 2011 at 9:32 AM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Here is my +1 Regards Bernd On Thu, May 12, 2011 at 1:36 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote: +1 Am 09.05.11 22:52, schrieb Bernd Bohmann: Hello, I would like to release Tobago 1.0.36. Changes: ** Bug * [TOBAGO-980] - tc:attribute mode=valueIfSet not working in some cases * [TOBAGO-981] - Infinite loop in tobago-menu.js * [TOBAGO-983] - ComponentUtils.findDescendant returns the wrong component * [TOBAGO-995] - TextArea applies always style class tobago-TextArea-required, if length validator is present * [TOBAGO-996] - NonFacesRequestServlet doesn't work proper with JSF 1.2 * [TOBAGO-998] - Partially update while popup close drops User input ** Improvement * [TOBAGO-986] - Sheet can only sort UIOutput - Nothing happend with UILinkCommand and UIButtonCommand * [TOBAGO-997] - Extend DebugPhaseListener: log RequestURI, RequestHeaders, ResponseCharset, ... For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12316297 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-034/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
[jira] [Updated] (TRINIDAD-2097) tr:selectOneListBox - item not selected - wrong item of selected item returned by SimpleSelectOneRenderer.resolveIndex
[ https://issues.apache.org/jira/browse/TRINIDAD-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Padera updated TRINIDAD-2097: Status: Patch Available (was: Open) tr:selectOneListBox - item not selected - wrong item of selected item returned by SimpleSelectOneRenderer.resolveIndex -- Key: TRINIDAD-2097 URL: https://issues.apache.org/jira/browse/TRINIDAD-2097 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.14-core Reporter: Michal Padera Priority: Blocker Attachments: TRINIDAD-2097.patch I am setting value in selectOneListBox programmatically - CoreSelectOneListbox.setValue(...) but the item is not rendered as selected. Equals() method finds the object in combo that should be selected but method SimpleSelectOneRenderer._findIndex() returns wrong index. I have SelectItemGroups with SelectItems and the structure is following: Group 1 - empty Group 2 - item 2.1 - item 2.2 - should be selected Group 3 - empty Group 4 - empty Group 5 - empty Method _findIndex() returns 2. When option item 2.2 is rendered its index is 1 and it is rendered as an option that is not selected. Even when I do not set value of combo programmatically and leave it up to component (setting value attribute), wrong item is preselected. When I use h:selectOneListBox, everything works fine - correct item is selected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-176) JSF Page with a WindowScoped Bean cannot be accessed directly
[
https://issues.apache.org/jira/browse/EXTCDI-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved EXTCDI-176.
-
Resolution: Won't Fix
that isn't a codi bug. the context is active as soon as there is a session. it
looks like mojarra accesses the bean before the session is active. it works
with myfaces-core2 (+ owb)
JSF Page with a WindowScoped Bean cannot be accessed directly
-
Key: EXTCDI-176
URL: https://issues.apache.org/jira/browse/EXTCDI-176
Project: MyFaces CODI
Issue Type: Bug
Components: Core
Affects Versions: 0.9.4
Environment: Tested on Ubuntu Linux and Mac OSX, JBoss 6 Final, JEE6
Reporter: Daniel Sachse
I have a Facelets-page with a WIndow-Scoped Bean and I just want to access a
list.
The List gets loaded via :
f:metadata
f:event type=javax.faces.event.PreRenderViewEvent
listener=#{listBean.preRenderView} /
/f:metadata
This just reloads the List every time the page gets rendered. The problem
with using this approach is, if I access the page directly, I get the
following error:
WELD-001303 No active contexts for scope type
org.apache.myfaces.extensions.cdi.core.api.scope.conversation.WindowScoped.
If I do navigate to the page i.e using a commandLink, everything works fine.
If you do need more information, please just ask.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (EXTCDI-176) JSF Page with a WindowScoped Bean cannot be accessed directly
[
https://issues.apache.org/jira/browse/EXTCDI-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032934#comment-13032934
]
Gerhard Petracek edited comment on EXTCDI-176 at 5/13/11 9:57 AM:
--
that isn't a codi bug. the context is active as soon as there is a session. it
looks like mojarra accesses the bean before the session is active. it works
with myfaces-core2 (+ owb).
as an alternative you can use the view-controller concept of codi which allows
the usage of @PreRenderView
was (Author: gpetracek):
that isn't a codi bug. the context is active as soon as there is a session.
it looks like mojarra accesses the bean before the session is active. it
works with myfaces-core2 (+ owb)
JSF Page with a WindowScoped Bean cannot be accessed directly
-
Key: EXTCDI-176
URL: https://issues.apache.org/jira/browse/EXTCDI-176
Project: MyFaces CODI
Issue Type: Bug
Components: Core
Affects Versions: 0.9.4
Environment: Tested on Ubuntu Linux and Mac OSX, JBoss 6 Final, JEE6
Reporter: Daniel Sachse
I have a Facelets-page with a WIndow-Scoped Bean and I just want to access a
list.
The List gets loaded via :
f:metadata
f:event type=javax.faces.event.PreRenderViewEvent
listener=#{listBean.preRenderView} /
/f:metadata
This just reloads the List every time the page gets rendered. The problem
with using this approach is, if I access the page directly, I get the
following error:
WELD-001303 No active contexts for scope type
org.apache.myfaces.extensions.cdi.core.api.scope.conversation.WindowScoped.
If I do navigate to the page i.e using a commandLink, everything works fine.
If you do need more information, please just ask.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-177) workaround for the @Alternative issue of weld
workaround for the @Alternative issue of weld - Key: EXTCDI-177 URL: https://issues.apache.org/jira/browse/EXTCDI-177 Project: MyFaces CODI Issue Type: Task Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek test a module of alternative implementations which aren't activated by default. those implementations are only proxies which lookup the final implementation from the environment to bypass a spec. issue of cdi 1.0. we need this module only for new weld versions which implement cdi 1.0. it's planned to fix this spec. issue in cdi 1.1. we have to provide special dist jars which bundle this module out-of-the-box. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-169) re-visit ClientConfig
[ https://issues.apache.org/jira/browse/EXTCDI-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-169. - Resolution: Fixed re-visit ClientConfig - Key: EXTCDI-169 URL: https://issues.apache.org/jira/browse/EXTCDI-169 Project: MyFaces CODI Issue Type: Task Affects Versions: 0.9.4 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.9.5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-178) archetype is broken for mojarra
archetype is broken for mojarra --- Key: EXTCDI-178 URL: https://issues.apache.org/jira/browse/EXTCDI-178 Project: MyFaces CODI Issue Type: Bug Reporter: Imre Osswald Assignee: Jakob Korherr Priority: Trivial mvn clean jetty:run-exploded -PjettyConfig -Djsf=mojarra leads to an exception because the bean-validation impl. is missing and mojarra behaves differently. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-179) GAE support
GAE support --- Key: EXTCDI-179 URL: https://issues.apache.org/jira/browse/EXTCDI-179 Project: MyFaces CODI Issue Type: Task Affects Versions: 1.0.0 Reporter: Gerhard Petracek if some classes aren't allowed by GAE we have to catch NoClassDefFoundError and log the unsupported feature. we might have to do the same for owb. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hi, two questions : 1) can UIComponent.rendererType be ValueExpression? If yes, in which situation is useful to use it? 2) should be rendereType saved during state saving? Each component has setRendererType(com.foo.renderer) in constructor and/or VDL calls setRendererType() after calling Application.createComponent() Please see MYFACES-3136 for details Thanks, Kočičák
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hi Martin, Have you checked the JSF 2.1 and 2.0 specs yet? Regards, Jakob 2011/5/13 Martin Koci martin.kocicak.k...@gmail.com: Hi, two questions : 1) can UIComponent.rendererType be ValueExpression? If yes, in which situation is useful to use it? 2) should be rendereType saved during state saving? Each component has setRendererType(com.foo.renderer) in constructor and/or VDL calls setRendererType() after calling Application.createComponent() Please see MYFACES-3136 for details Thanks, Kočičák -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Commented] (EXTCDI-178) archetype is broken for mojarra
[ https://issues.apache.org/jira/browse/EXTCDI-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033054#comment-13033054 ] Jakob Korherr commented on EXTCDI-178: -- thx, Imre. I'll take a look at it soon! archetype is broken for mojarra --- Key: EXTCDI-178 URL: https://issues.apache.org/jira/browse/EXTCDI-178 Project: MyFaces CODI Issue Type: Bug Reporter: Imre Osswald Assignee: Jakob Korherr Priority: Trivial Attachments: pom.xml.zip mvn clean jetty:run-exploded -PjettyConfig -Djsf=mojarra leads to an exception because the bean-validation impl. is missing and mojarra behaves differently. To reproduce: * Use the archetype (currently) #11 * mvn clean jetty:run-exploded -PjettyConfig -Djsf=mojarra * Enter something into the input-field and submit the form. I've attached a pom that depends on org.apache.bval.bval-core and bval-jsr303 in the mojarra profile (not sure if both are needed?) As it will obviously also break for myfaces, if you add a bval-constraint on for example setName(), we should maybe also add a commented section, that has the dependencies for using bval/extval. Imre -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hi,
from spec:
.. Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?
2) should be rendereType saved during state saving? Each component has
setRendererType(com.foo.renderer) in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()
Please see MYFACES-3136 for details
Thanks,
Kočičák
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hmm, ok.
I also can't think of a scenario where you would use something like
this right now. But I'll think of it and do some research..
Martin, could you take a look at some of the prominent JSF component
libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
IceFaces) and search in their code for something like this? If you
don't find anything there, then it should be pretty safe to remove the
ValueExpression support from rendererType!
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
from spec:
.. Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?
2) should be rendereType saved during state saving? Each component has
setRendererType(com.foo.renderer) in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()
Please see MYFACES-3136 for details
Thanks,
Kočičák
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
[jira] [Commented] (EXTCDI-179) GAE support
[ https://issues.apache.org/jira/browse/EXTCDI-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033081#comment-13033081 ] Mark Struberg commented on EXTCDI-179: -- Do you have an example class for it? GAE support --- Key: EXTCDI-179 URL: https://issues.apache.org/jira/browse/EXTCDI-179 Project: MyFaces CODI Issue Type: Improvement Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Jakob Korherr if some classes aren't allowed by GAE we have to catch NoClassDefFoundError and log the unsupported feature. we might have to do the same for owb. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-179) GAE support
[ https://issues.apache.org/jira/browse/EXTCDI-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033087#comment-13033087 ] Gerhard Petracek commented on EXTCDI-179: - see: http://code.google.com/appengine/docs/java/jrewhitelist.html e.g. InitialContext (btw. javax.naming.* as a whole) isn't on the list. GAE support --- Key: EXTCDI-179 URL: https://issues.apache.org/jira/browse/EXTCDI-179 Project: MyFaces CODI Issue Type: Improvement Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Jakob Korherr if some classes aren't allowed by GAE we have to catch NoClassDefFoundError and log the unsupported feature. we might have to do the same for owb. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3143) f:viewParam in templates
f:viewParam in templates Key: MYFACES-3143 URL: https://issues.apache.org/jira/browse/MYFACES-3143 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.5 Reporter: Gerhard Petracek if f:metadata and f:viewParam are in a template instead of a template-client, it gets parsed incorrectly. so there is no TagUnit instance for it and no UIPanel for f:metadata. - ViewMetadata#createMetadataView doesn't work correctly (in ViewMetadata#getViewParameters the call root.getFacet (UIViewRoot.METADATA_FACET_NAME) returns a UIViewParameter directly instead of a Metadata node with UIViewParameter as a child). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3143) f:viewParam in templates
[ https://issues.apache.org/jira/browse/MYFACES-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033156#comment-13033156 ] Leonardo Uribe commented on MYFACES-3143: - Could you provide an example so I can check it. According to the spec javadoc (Facelets Tag Documentation) of f:metadata, it says: ... Declare the metadata facet for this view. This must be a child of the f:view. This tag must reside within the top level XHTML file for the given viewId, or in a template client, but not in a template ... The page author is not required to use templating, but if they do, it must be done as shown above, (or with ui:include in a similar manner). Based on the information provided, My conclusion is this is not a bug on MyFaces, but maybe a test case could help to understand what's going on. f:viewParam in templates Key: MYFACES-3143 URL: https://issues.apache.org/jira/browse/MYFACES-3143 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.5 Reporter: Gerhard Petracek if f:metadata and f:viewParam are in a template instead of a template-client, it gets parsed incorrectly. so there is no TagUnit instance for it and no UIPanel for f:metadata. - ViewMetadata#createMetadataView doesn't work correctly (in ViewMetadata#getViewParameters the call root.getFacet (UIViewRoot.METADATA_FACET_NAME) returns a UIViewParameter directly instead of a Metadata node with UIViewParameter as a child). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3143) f:viewParam in templates
[ https://issues.apache.org/jira/browse/MYFACES-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033201#comment-13033201 ] Gerhard Petracek commented on MYFACES-3143: --- it was a child of f:view. just move the usual ui:define content to the template. use-cases: templateX should ensure that all pages always use the same view-param. ... that isn't a frequent use-case. however, besides valid use-cases there should be at least a warning or msg. in dev. mode or exception instead of just doing nothing. f:viewParam in templates Key: MYFACES-3143 URL: https://issues.apache.org/jira/browse/MYFACES-3143 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.5 Reporter: Gerhard Petracek if f:metadata and f:viewParam are in a template instead of a template-client, it gets parsed incorrectly. so there is no TagUnit instance for it and no UIPanel for f:metadata. - ViewMetadata#createMetadataView doesn't work correctly (in ViewMetadata#getViewParameters the call root.getFacet (UIViewRoot.METADATA_FACET_NAME) returns a UIViewParameter directly instead of a Metadata node with UIViewParameter as a child). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3144) [PERF] Cache renderer in UIComponentBase
[PERF] Cache renderer in UIComponentBase Key: MYFACES-3144 URL: https://issues.apache.org/jira/browse/MYFACES-3144 Project: MyFaces Core Issue Type: New Feature Components: General Affects Versions: 2.1.0-SNAPSHOT Environment: myfaces core trunk Reporter: Martin Kočí Assignee: Martin Kočí UIComponentBase uses getRenderer(): Renderer in five methods: 1) decode 2) encodeBegin 3) encodeChildren 4) encodeEnd 50 getClientId getting the renderer is not cheap if you have thousands component in view. Cache renderer instance in UIComponentBase (Trinidad UIXComponentBase does it already) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3145) Myfaces h:commandButton errors on Mozilla 3.6 when using Javascript form.submit()
Myfaces h:commandButton errors on Mozilla 3.6 when using Javascript
form.submit()
--
Key: MYFACES-3145
URL: https://issues.apache.org/jira/browse/MYFACES-3145
Project: MyFaces Core
Issue Type: Bug
Components: website
Affects Versions: 1.1.10-SNAPSHOT
Environment: Myfaces 1.1.10 on Tomcat 6.0.x
Reporter: suresh t
submitting commandButton buttons using javascript code
document.getElementById('jsfsearch').submit() doesn't send all values in the
form to the tomcat when using Mozilla. whereas the same code works on IE.
===
h:form id=jsfsearch
h:commandButton id=abutton style=font:
bold 100% 'trebuchet ms',helvetica; font-size: 18px;background-color:rgb(201,200
,202); border-color:rgb(234,40,57); border-style:thin; immediate=true onclick
=return submitSearch(); action=#{searchController.simple} value=#{searchmes
sages['simplesearch']}/
h:inputText id=
search_Srch1 value=#{searchController.vSrch1} rendered=#{searchContr
oller.searchparameter1} /
/h:form
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hi,
trinidad caches Renderer instance in UIXComponentBase so they at least
suppose that rendererType cannot change during one render/response and
no need for evaluate it in every getRendererType() call - see
MYFACES-3144.
Other libs I'll check.
Regards,
Kočičák
Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
Hmm, ok.
I also can't think of a scenario where you would use something like
this right now. But I'll think of it and do some research..
Martin, could you take a look at some of the prominent JSF component
libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
IceFaces) and search in their code for something like this? If you
don't find anything there, then it should be pretty safe to remove the
ValueExpression support from rendererType!
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
from spec:
.. Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?
2) should be rendereType saved during state saving? Each component has
setRendererType(com.foo.renderer) in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()
Please see MYFACES-3136 for details
Thanks,
Kočičák
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hi
+1 to both changes. I agree with you about rendererType is always an
String, there is not any mention on the spec saying rendererType could
receive EL expressions. If someone wants to change a renderer, it uses
a RenderKit wrapper or just define another RenderKitId to be used for
the current application.
Please note this description of UIViewRoot.getRenderKitId :
... Return the render kit identifier of the RenderKit associated with
this view. Unless explicitly set, as in
ViewHandler.createView(javax.faces.context.FacesContext,
java.lang.String), the returned value will be null. ...
and setRenderKitId:
... Set the render kit identifier of the RenderKit associated with
this view. This method may be called at any time between the end of
Apply Request Values phase of the request processing lifecycle (i.e.
when events are being broadcast) and the beginning of the Render
Response phase. ...
So any caching must preserve this behavior.
regards,
Leonardo
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
trinidad caches Renderer instance in UIXComponentBase so they at least
suppose that rendererType cannot change during one render/response and
no need for evaluate it in every getRendererType() call - see
MYFACES-3144.
Other libs I'll check.
Regards,
Kočičák
Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
Hmm, ok.
I also can't think of a scenario where you would use something like
this right now. But I'll think of it and do some research..
Martin, could you take a look at some of the prominent JSF component
libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
IceFaces) and search in their code for something like this? If you
don't find anything there, then it should be pretty safe to remove the
ValueExpression support from rendererType!
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
from spec:
.. Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?
2) should be rendereType saved during state saving? Each component has
setRendererType(com.foo.renderer) in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()
Please see MYFACES-3136 for details
Thanks,
Kočičák
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500:
Hi
+1 to both changes.
That means: replace StateHelper with attribute as MYFACES-3136 suggests,
right?
I agree with you about rendererType is always an
String, there is not any mention on the spec saying rendererType could
receive EL expressions. If someone wants to change a renderer, it uses
a RenderKit wrapper or just define another RenderKitId to be used for
the current application.
Please note this description of UIViewRoot.getRenderKitId :
... Return the render kit identifier of the RenderKit associated with
this view. Unless explicitly set, as in
ViewHandler.createView(javax.faces.context.FacesContext,
java.lang.String), the returned value will be null. ...
and setRenderKitId:
... Set the render kit identifier of the RenderKit associated with
this view. This method may be called at any time between the end of
Apply Request Values phase of the request processing lifecycle (i.e.
when events are being broadcast) and the beginning of the Render
Response phase. ...
So any caching must preserve this behavior.
Thats very interesting, with this behaviour it is possible to change
renderkit in actionListener for example. But it also means that renderer
cannot be be cached UIComponentBase:
1) UIComponent.decode - caches renderer
2) INVOKE_APPLICATION - changes renderKit
3) UIComponent.encodeBegin - uses old cached renderer
but caching is valid for all encode* method then. Any ideas how to
detect this component will be rendered in this lifecycle and cache
renderer even for getClientId? stateManagement calls getClientId
(checkIds) before component.encodeBegin. Can we use visitTree method for
that?
Kočičák
regards,
Leonardo
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
trinidad caches Renderer instance in UIXComponentBase so they at least
suppose that rendererType cannot change during one render/response and
no need for evaluate it in every getRendererType() call - see
MYFACES-3144.
Other libs I'll check.
Regards,
Kočičák
Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
Hmm, ok.
I also can't think of a scenario where you would use something like
this right now. But I'll think of it and do some research..
Martin, could you take a look at some of the prominent JSF component
libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
IceFaces) and search in their code for something like this? If you
don't find anything there, then it should be pretty safe to remove the
ValueExpression support from rendererType!
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
from spec:
.. Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?
2) should be rendereType saved during state saving? Each component has
setRendererType(com.foo.renderer) in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()
Please see MYFACES-3136 for details
Thanks,
Kočičák
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
OK great, thanks Leo!
but caching is valid for all encode* method then. Any ideas how to
detect this component will be rendered in this lifecycle and cache
renderer even for getClientId? stateManagement calls getClientId
(checkIds) before component.encodeBegin. Can we use visitTree method for
that?
we could use visitTree(), but note that this could be very expensive ;)
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500:
Hi
+1 to both changes.
That means: replace StateHelper with attribute as MYFACES-3136 suggests,
right?
I agree with you about rendererType is always an
String, there is not any mention on the spec saying rendererType could
receive EL expressions. If someone wants to change a renderer, it uses
a RenderKit wrapper or just define another RenderKitId to be used for
the current application.
Please note this description of UIViewRoot.getRenderKitId :
... Return the render kit identifier of the RenderKit associated with
this view. Unless explicitly set, as in
ViewHandler.createView(javax.faces.context.FacesContext,
java.lang.String), the returned value will be null. ...
and setRenderKitId:
... Set the render kit identifier of the RenderKit associated with
this view. This method may be called at any time between the end of
Apply Request Values phase of the request processing lifecycle (i.e.
when events are being broadcast) and the beginning of the Render
Response phase. ...
So any caching must preserve this behavior.
Thats very interesting, with this behaviour it is possible to change
renderkit in actionListener for example. But it also means that renderer
cannot be be cached UIComponentBase:
1) UIComponent.decode - caches renderer
2) INVOKE_APPLICATION - changes renderKit
3) UIComponent.encodeBegin - uses old cached renderer
but caching is valid for all encode* method then. Any ideas how to
detect this component will be rendered in this lifecycle and cache
renderer even for getClientId? stateManagement calls getClientId
(checkIds) before component.encodeBegin. Can we use visitTree method for
that?
Kočičák
regards,
Leonardo
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
trinidad caches Renderer instance in UIXComponentBase so they at least
suppose that rendererType cannot change during one render/response and
no need for evaluate it in every getRendererType() call - see
MYFACES-3144.
Other libs I'll check.
Regards,
Kočičák
Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
Hmm, ok.
I also can't think of a scenario where you would use something like
this right now. But I'll think of it and do some research..
Martin, could you take a look at some of the prominent JSF component
libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
IceFaces) and search in their code for something like this? If you
don't find anything there, then it should be pretty safe to remove the
ValueExpression support from rendererType!
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
from spec:
.. Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?
2) should be rendereType saved during state saving? Each component
has
setRendererType(com.foo.renderer) in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()
Please see MYFACES-3136 for details
Thanks,
Kočičák
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
[jira] [Commented] (MYFACES-3145) Myfaces h:commandButton errors on Mozilla 3.6 when using Javascript form.submit()
[
https://issues.apache.org/jira/browse/MYFACES-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033274#comment-13033274
]
Jakob Korherr commented on MYFACES-3145:
Is this an official Mozilla bug?
Myfaces h:commandButton errors on Mozilla 3.6 when using Javascript
form.submit()
--
Key: MYFACES-3145
URL: https://issues.apache.org/jira/browse/MYFACES-3145
Project: MyFaces Core
Issue Type: Bug
Components: website
Affects Versions: 1.1.10-SNAPSHOT
Environment: Myfaces 1.1.10 on Tomcat 6.0.x
Reporter: suresh t
submitting commandButton buttons using javascript code
document.getElementById('jsfsearch').submit() doesn't send all values in
the form to the tomcat when using Mozilla. whereas the same code works on IE.
===
h:form id=jsfsearch
h:commandButton id=abutton style=font:
bold 100% 'trebuchet ms',helvetica; font-size:
18px;background-color:rgb(201,200
,202); border-color:rgb(234,40,57); border-style:thin; immediate=true
onclick
=return submitSearch(); action=#{searchController.simple}
value=#{searchmes
sages['simplesearch']}/
h:inputText id=
search_Srch1 value=#{searchController.vSrch1} rendered=#{searchContr
oller.searchparameter1} /
/h:form
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
True, but it should only be invoked when the renderer(kit) changes, right?
That shouldn't happen in most cases. And in the case when it does, we pay a
penalty and the page is a bit slower. Doesn't sound like a big deal to
me...?
Regards,
Jan-Kees
2011/5/13 Jakob Korherr jakob.korh...@gmail.com
OK great, thanks Leo!
but caching is valid for all encode* method then. Any ideas how to
detect this component will be rendered in this lifecycle and cache
renderer even for getClientId? stateManagement calls getClientId
(checkIds) before component.encodeBegin. Can we use visitTree method for
that?
we could use visitTree(), but note that this could be very expensive ;)
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500:
Hi
+1 to both changes.
That means: replace StateHelper with attribute as MYFACES-3136 suggests,
right?
I agree with you about rendererType is always an
String, there is not any mention on the spec saying rendererType could
receive EL expressions. If someone wants to change a renderer, it uses
a RenderKit wrapper or just define another RenderKitId to be used for
the current application.
Please note this description of UIViewRoot.getRenderKitId :
... Return the render kit identifier of the RenderKit associated with
this view. Unless explicitly set, as in
ViewHandler.createView(javax.faces.context.FacesContext,
java.lang.String), the returned value will be null. ...
and setRenderKitId:
... Set the render kit identifier of the RenderKit associated with
this view. This method may be called at any time between the end of
Apply Request Values phase of the request processing lifecycle (i.e.
when events are being broadcast) and the beginning of the Render
Response phase. ...
So any caching must preserve this behavior.
Thats very interesting, with this behaviour it is possible to change
renderkit in actionListener for example. But it also means that renderer
cannot be be cached UIComponentBase:
1) UIComponent.decode - caches renderer
2) INVOKE_APPLICATION - changes renderKit
3) UIComponent.encodeBegin - uses old cached renderer
but caching is valid for all encode* method then. Any ideas how to
detect this component will be rendered in this lifecycle and cache
renderer even for getClientId? stateManagement calls getClientId
(checkIds) before component.encodeBegin. Can we use visitTree method for
that?
Kočičák
regards,
Leonardo
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
trinidad caches Renderer instance in UIXComponentBase so they at least
suppose that rendererType cannot change during one render/response and
no need for evaluate it in every getRendererType() call - see
MYFACES-3144.
Other libs I'll check.
Regards,
Kočičák
Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
Hmm, ok.
I also can't think of a scenario where you would use something like
this right now. But I'll think of it and do some research..
Martin, could you take a look at some of the prominent JSF component
libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
IceFaces) and search in their code for something like this? If you
don't find anything there, then it should be pretty safe to remove
the
ValueExpression support from rendererType!
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
from spec:
.. Because the components themselves store only a rendererType
property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set
of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the
type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not
ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not
possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in
which
situation is useful to use it?
2) should be rendereType saved
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hi 2011/5/13 Martin Koci martin.kocicak.k...@gmail.com: Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500: Hi +1 to both changes. That means: replace StateHelper with attribute as MYFACES-3136 suggests, right? That means change StateHelper.eval to StateHelper.get in UIComponentBase.getRendererType() The point 3 it is not really necessary, because this property is part of the full state, not the delta, which is the one that consume space on server side state saving. I prefer keep using StateHelper but get instead eval. I agree with you about rendererType is always an String, there is not any mention on the spec saying rendererType could receive EL expressions. If someone wants to change a renderer, it uses a RenderKit wrapper or just define another RenderKitId to be used for the current application. Please note this description of UIViewRoot.getRenderKitId : ... Return the render kit identifier of the RenderKit associated with this view. Unless explicitly set, as in ViewHandler.createView(javax.faces.context.FacesContext, java.lang.String), the returned value will be null. ... and setRenderKitId: ... Set the render kit identifier of the RenderKit associated with this view. This method may be called at any time between the end of Apply Request Values phase of the request processing lifecycle (i.e. when events are being broadcast) and the beginning of the Render Response phase. ... So any caching must preserve this behavior. Thats very interesting, with this behaviour it is possible to change renderkit in actionListener for example. But it also means that renderer cannot be be cached UIComponentBase: 1) UIComponent.decode - caches renderer 2) INVOKE_APPLICATION - changes renderKit 3) UIComponent.encodeBegin - uses old cached renderer but caching is valid for all encode* method then. Any ideas how to detect this component will be rendered in this lifecycle and cache renderer even for getClientId? stateManagement calls getClientId (checkIds) before component.encodeBegin. Can we use visitTree method for that? Cache as soon as you do the lookup, but clean it inside encodeAll call. Note some code is necessary here if encodeAll is called multiple times over the same instance (datatable or datalist case). Use a simple variable to do the trick. Leonardo
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
One more question: UIComponent.getClientId() uses Renderer.convertClientId 1) INVOKE_APPLICATION - action listener calls component.getClient() - component generates client id with renderer1 + as next step actionListener changes renderKitId 2) RENDER_RESPOSE: renderer2 from new renderkit renders component with clientId from renderer1! Is that ok? Leonardo Uribe píše v Pá 13. 05. 2011 v 15:45 -0500: Hi 2011/5/13 Martin Koci martin.kocicak.k...@gmail.com: Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500: Hi +1 to both changes. That means: replace StateHelper with attribute as MYFACES-3136 suggests, right? That means change StateHelper.eval to StateHelper.get in UIComponentBase.getRendererType() The point 3 it is not really necessary, because this property is part of the full state, not the delta, which is the one that consume space on server side state saving. I prefer keep using StateHelper but get instead eval. I agree with you about rendererType is always an String, there is not any mention on the spec saying rendererType could receive EL expressions. If someone wants to change a renderer, it uses a RenderKit wrapper or just define another RenderKitId to be used for the current application. Please note this description of UIViewRoot.getRenderKitId : ... Return the render kit identifier of the RenderKit associated with this view. Unless explicitly set, as in ViewHandler.createView(javax.faces.context.FacesContext, java.lang.String), the returned value will be null. ... and setRenderKitId: ... Set the render kit identifier of the RenderKit associated with this view. This method may be called at any time between the end of Apply Request Values phase of the request processing lifecycle (i.e. when events are being broadcast) and the beginning of the Render Response phase. ... So any caching must preserve this behavior. Thats very interesting, with this behaviour it is possible to change renderkit in actionListener for example. But it also means that renderer cannot be be cached UIComponentBase: 1) UIComponent.decode - caches renderer 2) INVOKE_APPLICATION - changes renderKit 3) UIComponent.encodeBegin - uses old cached renderer but caching is valid for all encode* method then. Any ideas how to detect this component will be rendered in this lifecycle and cache renderer even for getClientId? stateManagement calls getClientId (checkIds) before component.encodeBegin. Can we use visitTree method for that? Cache as soon as you do the lookup, but clean it inside encodeAll call. Note some code is necessary here if encodeAll is called multiple times over the same instance (datatable or datalist case). Use a simple variable to do the trick. Leonardo
Re: [core] Enhancements to State Saving Caching Algorithm
Hi I finally committed a solution for this issue, and other cool optimizations in MYFACES-3117. I'll going to explain below which changes were done. Now there exists a class called org.apache.myfaces.application.StateCacheK, V, to delegate all logic related to state storing/retrieving in a cleaner way. Additionally a factory class org.apache.myfaces.application.StateCacheFactory is available, to provide alternate implementations in the future. Two new params were added for server side stuff: /** * Only applicable if state saving method is server (= default). * Indicates the amount of views (default is not active) that should be stored in session between sequential * POST or POST-REDIRECT-GET if org.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION is true. * pFor example, if this param has value = 2 and in your custom webapp there is a form that is clicked 3 times, only 2 views * will be stored and the third one (the one stored the first time) will be removed from session, even if the view can * store more sessions org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION. This feature becomes useful for multi-window applications. * where without this feature a window can swallow all view slots so the other ones will throw ViewExpiredException./p */ @JSFWebConfigParam(since=2.0.6) private static final String NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION_PARAM = org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION; /** * Only applicable if state saving method is server (= default). * Allow use flash scope to keep track of the views used in session and the previous ones, * so server side state saving can delete old views even if POST-REDIRECT-GET pattern is used. * The default value is false. */ @JSFWebConfigParam(since=2.0.6, defaultValue=false, expectedValues=true, false) private static final String USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION = org.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION; Finally I founded a way to support POST-Redirect-GET pattern using flash scope. By default, these two params are disabled. Other optimizations that will reduce memory usage were done: - Don't trigger session creation if state is not written on facelets. - Don't use a buffer to write the state token when server side state saving is used, because after all it is not necessary. I think with these changes we can solve MYFACES-3117. With this code, we have a solid foundation to continue investigating how to solve the window-id problem. Suggestions are welcome. Leonardo Uribe
[jira] [Resolved] (MYFACES-3117) Current server state saving implementation prevents multi-window usage
[ https://issues.apache.org/jira/browse/MYFACES-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3117. - Resolution: Fixed Fix Version/s: 2.1.0 2.0.6 See the discussion here: http://markmail.org/message/7yrh7267lr5jauua?q=[core]+Enhancements+to+State+Saving+Caching+Algorithm Current server state saving implementation prevents multi-window usage -- Key: MYFACES-3117 URL: https://issues.apache.org/jira/browse/MYFACES-3117 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.6-SNAPSHOT Environment: myfaces core trunk Reporter: Martin Kočí Assignee: Leonardo Uribe Priority: Critical Fix For: 2.0.6, 2.1.0 Attachments: MYFACES-3117-1.patch, MYFACES-3117.patch Problem: open two tabs (or windows) in browser with view: h:body h:form id=formId h:commandButton value=Click me 20x! / /h:form /h:body then click the button on the first tab 20x or more - then click the button on the second tab - you will get the most beloved ViewExpiredException. Reason: oam.SerializedViewCollection drops the saved state for 2. tab from map. Suggestion: remove the successfully restored view state from map. This can be done, because each SerializedViewKey is unique over *all requests* for one HttpSession - see DefaultFaceletsStateManagementHelper.nextViewSequence(FacesContext). Because each request has unique sequence number, we can the just restored one remove from the map, because it can never come from client again. Open question: the previous statement is true except the double submit problem: JAVASERVERFACES_SPEC_PUBLIC-559. In this case, server can process same request (with the same sequence number) twice. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
