[core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?
Hi Some time ago, this proposal was submitted to the consideration of this list. [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode) http://markmail.org/message/54rb3aphc6txwzbr I have been thinking about the advantages and disadvantages of this technique. Advantages: - Build view time is cut off, giving a speed improvement per each requests. Test done shows around 8% improvement in page rendering and in ajax case the improvement is even better, because in that case the build view time has more weight. - A lot less objects are allocated. Disadvantages: - Detection technique to enable this optimization is not 100% fail-safe. - It could create memory fragmentation, making garbage collection slower. - Higher memory footprint. - It is difficult to keep the code synchronized between versions of JSF, because each concept related to view handling affects how the view pool works. - The use ui:param uses EL VariableResolver, makes the view non poolable, because the ValueExpression instances are not stateless in this case. Do the advantages justify the introduction of this concept? Will users find the improvement useful or applicable in real projects? or does not worth the complexity involved and in this case keep thing simple is better? regards, Leonardo Uribe -- [image: http://download.irian.at/2013/CONFESS_2013_email_signature.png]
[jira] [Created] (EXTVAL-150) Extval does not work with new placeholder component of Richfaces
Martin Maier created EXTVAL-150:
---
Summary: Extval does not work with new placeholder component of
Richfaces
Key: EXTVAL-150
URL: https://issues.apache.org/jira/browse/EXTVAL-150
Project: MyFaces Extensions Validator
Issue Type: Bug
Affects Versions: 2.0.6
Environment: Java 7, Tomcat 7, Richfaces 4.3.0.Final, MyFaces 2.1.10
Reporter: Martin Maier
The class ExtValGenericRendererWrapper intercepts several methods of Render
classes based on reflection. This can cause problems if a Render class has a
method with an equal name but different parameter count.
For instance: Richfaces 4.3 introduces a new class PlaceholderRendererBase with
a method 'getConvertedValue' that takes 2 parameters. This method is not
related to 'getConvertedValue' of javax.faces.render.Render with 3 parameters.
However, this method gets also intercepted because the parameter count is not
checked.
The relavant code part of ExtValGenericRendererWrapper is this (line 56):
{code}
if (method.getName().equals(getConvertedValue) args[1] instanceof
UIComponent) {
return getConvertedValue((FacesContext) args[0], (UIComponent)
args[1], args[2]);
{code}
which should be fixed with something like
{code}
if (method.getName().equals(getConvertedValue) args[1] instanceof
UIComponent
method.getParameterTypes().length == 3) {
return getConvertedValue((FacesContext) args[0], (UIComponent)
args[1], args[2]);
{code}
I can provide a stacktrace for this problem with the Richfaces placeholder
component:
{code}
java.lang.IllegalStateException: Rendering of placeholder before its parent has
failed
at
org.richfaces.component.AbstractPlaceholder$PlaceholderParentPreRenderListener.preRenderParent(AbstractPlaceholder.java:138)
at
org.richfaces.component.event.PreRenderParentListener.processEvent(PreRenderParentListener.java:70)
at
javax.faces.component.UIComponent$EventListenerWrapper.processEvent(UIComponent.java:1565)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:43)
at
org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2410)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:577)
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:580)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:517)
at
org.apache.myfaces.shared.renderkit.RendererUtils.renderChildren(RendererUtils.java:693)
at
org.apache.myfaces.shared.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:115)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:77)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:359)
at
org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRendererWrapper.intercept(ExtValGenericRendererWrapper.java:66)
at
org.apache.myfaces.renderkit.html.HtmlGroupRenderer$$EnhancerByCGLIB$$e84eb129.encodeEnd(generated)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
at
org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer.encodeEnd(HtmlCompositeComponentRenderer.java:71)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:77)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:359)
at
org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRendererWrapper.intercept(ExtValGenericRendererWrapper.java:66)
at
org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer$$EnhancerByCGLIB$$86055b2c.encodeEnd(generated)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545)
at
org.richfaces.renderkit.RendererBase.renderChildren(RendererBase.java:276)
at
org.richfaces.renderkit.AbstractTableBaseRenderer.encodeColumn(AbstractTableBaseRenderer.java:82)
at
org.richfaces.renderkit.ColumnGroupRenderer.encodeRow(ColumnGroupRenderer.java:55)
at
org.richfaces.renderkit.AbstractRowsRenderer.process(AbstractRowsRenderer.java:80)
at
org.richfaces.component.AbstractColumnGroup.walk(AbstractColumnGroup.java:64)
at
org.richfaces.renderkit.AbstractRowsRenderer.encodeRows(AbstractRowsRenderer.java:90)
[jira] [Updated] (EXTVAL-150) Extval does not work with new placeholder component of Richfaces
[
https://issues.apache.org/jira/browse/EXTVAL-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Maier updated EXTVAL-150:
Status: Patch Available (was: Open)
Extval does not work with new placeholder component of Richfaces
Key: EXTVAL-150
URL: https://issues.apache.org/jira/browse/EXTVAL-150
Project: MyFaces Extensions Validator
Issue Type: Bug
Affects Versions: 2.0.6
Environment: Java 7, Tomcat 7, Richfaces 4.3.0.Final, MyFaces 2.1.10
Reporter: Martin Maier
The class ExtValGenericRendererWrapper intercepts several methods of Render
classes based on reflection. This can cause problems if a Render class has a
method with an equal name but different parameter count.
For instance: Richfaces 4.3 introduces a new class PlaceholderRendererBase
with a method 'getConvertedValue' that takes 2 parameters. This method is not
related to 'getConvertedValue' of javax.faces.render.Render with 3
parameters. However, this method gets also intercepted because the parameter
count is not checked.
The relavant code part of ExtValGenericRendererWrapper is this (line 56):
{code}
if (method.getName().equals(getConvertedValue) args[1]
instanceof UIComponent) {
return getConvertedValue((FacesContext) args[0], (UIComponent)
args[1], args[2]);
{code}
which should be fixed with something like
{code}
if (method.getName().equals(getConvertedValue) args[1]
instanceof UIComponent
method.getParameterTypes().length == 3) {
return getConvertedValue((FacesContext) args[0], (UIComponent)
args[1], args[2]);
{code}
I can provide a stacktrace for this problem with the Richfaces placeholder
component:
{code}
java.lang.IllegalStateException: Rendering of placeholder before its parent
has failed
at
org.richfaces.component.AbstractPlaceholder$PlaceholderParentPreRenderListener.preRenderParent(AbstractPlaceholder.java:138)
at
org.richfaces.component.event.PreRenderParentListener.processEvent(PreRenderParentListener.java:70)
at
javax.faces.component.UIComponent$EventListenerWrapper.processEvent(UIComponent.java:1565)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:43)
at
org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2410)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:577)
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:580)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:517)
at
org.apache.myfaces.shared.renderkit.RendererUtils.renderChildren(RendererUtils.java:693)
at
org.apache.myfaces.shared.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:115)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:77)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:359)
at
org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRendererWrapper.intercept(ExtValGenericRendererWrapper.java:66)
at
org.apache.myfaces.renderkit.html.HtmlGroupRenderer$$EnhancerByCGLIB$$e84eb129.encodeEnd(generated)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
at
org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer.encodeEnd(HtmlCompositeComponentRenderer.java:71)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:77)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:359)
at
org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRendererWrapper.intercept(ExtValGenericRendererWrapper.java:66)
at
org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer$$EnhancerByCGLIB$$86055b2c.encodeEnd(generated)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545)
at
org.richfaces.renderkit.RendererBase.renderChildren(RendererBase.java:276)
at
org.richfaces.renderkit.AbstractTableBaseRenderer.encodeColumn(AbstractTableBaseRenderer.java:82)
at
org.richfaces.renderkit.ColumnGroupRenderer.encodeRow(ColumnGroupRenderer.java:55)
at
[jira] [Updated] (EXTVAL-150) Extval does not work with new placeholder component of Richfaces
[
https://issues.apache.org/jira/browse/EXTVAL-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Maier updated EXTVAL-150:
Status: Open (was: Patch Available)
Extval does not work with new placeholder component of Richfaces
Key: EXTVAL-150
URL: https://issues.apache.org/jira/browse/EXTVAL-150
Project: MyFaces Extensions Validator
Issue Type: Bug
Affects Versions: 2.0.6
Environment: Java 7, Tomcat 7, Richfaces 4.3.0.Final, MyFaces 2.1.10
Reporter: Martin Maier
The class ExtValGenericRendererWrapper intercepts several methods of Render
classes based on reflection. This can cause problems if a Render class has a
method with an equal name but different parameter count.
For instance: Richfaces 4.3 introduces a new class PlaceholderRendererBase
with a method 'getConvertedValue' that takes 2 parameters. This method is not
related to 'getConvertedValue' of javax.faces.render.Render with 3
parameters. However, this method gets also intercepted because the parameter
count is not checked.
The relavant code part of ExtValGenericRendererWrapper is this (line 56):
{code}
if (method.getName().equals(getConvertedValue) args[1]
instanceof UIComponent) {
return getConvertedValue((FacesContext) args[0], (UIComponent)
args[1], args[2]);
{code}
which should be fixed with something like
{code}
if (method.getName().equals(getConvertedValue) args[1]
instanceof UIComponent
method.getParameterTypes().length == 3) {
return getConvertedValue((FacesContext) args[0], (UIComponent)
args[1], args[2]);
{code}
I can provide a stacktrace for this problem with the Richfaces placeholder
component:
{code}
java.lang.IllegalStateException: Rendering of placeholder before its parent
has failed
at
org.richfaces.component.AbstractPlaceholder$PlaceholderParentPreRenderListener.preRenderParent(AbstractPlaceholder.java:138)
at
org.richfaces.component.event.PreRenderParentListener.processEvent(PreRenderParentListener.java:70)
at
javax.faces.component.UIComponent$EventListenerWrapper.processEvent(UIComponent.java:1565)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:43)
at
org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2410)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:577)
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:580)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:517)
at
org.apache.myfaces.shared.renderkit.RendererUtils.renderChildren(RendererUtils.java:693)
at
org.apache.myfaces.shared.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:115)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:77)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:359)
at
org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRendererWrapper.intercept(ExtValGenericRendererWrapper.java:66)
at
org.apache.myfaces.renderkit.html.HtmlGroupRenderer$$EnhancerByCGLIB$$e84eb129.encodeEnd(generated)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
at
org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer.encodeEnd(HtmlCompositeComponentRenderer.java:71)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:77)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:359)
at
org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRendererWrapper.intercept(ExtValGenericRendererWrapper.java:66)
at
org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer$$EnhancerByCGLIB$$86055b2c.encodeEnd(generated)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545)
at
org.richfaces.renderkit.RendererBase.renderChildren(RendererBase.java:276)
at
org.richfaces.renderkit.AbstractTableBaseRenderer.encodeColumn(AbstractTableBaseRenderer.java:82)
at
org.richfaces.renderkit.ColumnGroupRenderer.encodeRow(ColumnGroupRenderer.java:55)
at
[jira] [Created] (TRINIDAD-2358) add features support in the trinidad-skins to the skin-addition node
Gary VanMatre created TRINIDAD-2358: --- Summary: add features support in the trinidad-skins to the skin-addition node Key: TRINIDAD-2358 URL: https://issues.apache.org/jira/browse/TRINIDAD-2358 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1-core Environment: generic Reporter: Gary VanMatre JIRA TRINIDAD-2270 added an enhancement to the trinidad-skins.xml to add features to a skin definition that could be used at runtime to conditionally enable rendering behavior. The proposed improvement is to extend the features support to skin-addtion so that custom components that add to an existing skin can also use the runtime features metadata. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2358) add features support in the trinidad-skins to the skin-addition node
[ https://issues.apache.org/jira/browse/TRINIDAD-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary VanMatre updated TRINIDAD-2358: Status: Patch Available (was: Open) add features support in the trinidad-skins to the skin-addition node Key: TRINIDAD-2358 URL: https://issues.apache.org/jira/browse/TRINIDAD-2358 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1-core Environment: generic Reporter: Gary VanMatre JIRA TRINIDAD-2270 added an enhancement to the trinidad-skins.xml to add features to a skin definition that could be used at runtime to conditionally enable rendering behavior. The proposed improvement is to extend the features support to skin-addtion so that custom components that add to an existing skin can also use the runtime features metadata. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TRINIDAD-2358) add features support in the trinidad-skins to the skin-addition node
[ https://issues.apache.org/jira/browse/TRINIDAD-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570583#comment-13570583 ] Gary VanMatre edited comment on TRINIDAD-2358 at 2/4/13 8:01 PM: - Proposed patch that extends features support to skin-addition. was (Author: gvanma...@comcast.net): Proposed patch that extends features support to skin-addion. add features support in the trinidad-skins to the skin-addition node Key: TRINIDAD-2358 URL: https://issues.apache.org/jira/browse/TRINIDAD-2358 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1-core Environment: generic Reporter: Gary VanMatre Attachments: features-in-skin-additions.patch JIRA TRINIDAD-2270 added an enhancement to the trinidad-skins.xml to add features to a skin definition that could be used at runtime to conditionally enable rendering behavior. The proposed improvement is to extend the features support to skin-addtion so that custom components that add to an existing skin can also use the runtime features metadata. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2359) ClearRequestExternalContext wrapper applied unnecessarily
Andy Schwartz created TRINIDAD-2359: --- Summary: ClearRequestExternalContext wrapper applied unnecessarily Key: TRINIDAD-2359 URL: https://issues.apache.org/jira/browse/TRINIDAD-2359 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1-core Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor GlobalConfiguratorImpl wraps the ExternalContext with a ClearRequestExternalContext if it detects that Mojarra issue 493 (fixed back in Mojarra 1.2.04) is present. The Mojarra issue is described here: http://java.net/jira/browse/JAVASERVERFACES-493 setRequest does not reset request maps Two problems with this: 1. This issue was fixed in 2007, so it is unclear whether we should ever bother applying this workaround. 2. The code which detects the presence of this Mojarra issue is buggy. As a result of #2, GlobalConfiguratorImpl always adds a ClearRequestExternalContext wrapper, regardless of whether the old Mojarra issue is present or not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2359) ClearRequestExternalContext wrapper applied unnecessarily
[
https://issues.apache.org/jira/browse/TRINIDAD-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570626#comment-13570626
]
Andy Schwartz commented on TRINIDAD-2359:
-
More details on #2 above...
GlobalConfiguratorImpl._isSetRequestBugPresent() performs the following test:
// Call getInitParameterMap() up front
ec.getInitParameterMap();
ec.setRequest(new TestRequest(orig));
_sHasSetRequestBug = !TestRequest.isTestParamPresent(ec);
Where TestRequest looks like this:
static private class TestRequest
extends ServletRequestWrapper
{
public TestRequest(ServletRequest request)
{
super(request);
}
@Override
public String getParameter(String string)
{
if (_TEST_PARAM.equals(string))
{
return passed;
}
return super.getParameter(string);
}
static public final boolean isTestParamPresent(ExternalContext ec)
{
return RequestStateMap.getInstance(ec).get(_TEST_PARAM) != null;
}
static private String _TEST_PARAM = TestRequest.class.getName() +
.TEST_PARAM;
}
TestRequest.isTestParamPresent() is checking for the presence of this
_TEST_PARAM in the RequestStateMap. However, the _TEST_PARAM lives in the
ServletRequest's parameter map. As far as I can tell, these are different
things - ie. the RequestStateMap does not actually delegate through to the
ServletRequest's parameter map. Thus isTestParamPresent() will always return
false, even when the _TEST_PARAM is accessible via the request parameter map.
ClearRequestExternalContext wrapper applied unnecessarily
-
Key: TRINIDAD-2359
URL: https://issues.apache.org/jira/browse/TRINIDAD-2359
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
GlobalConfiguratorImpl wraps the ExternalContext with a
ClearRequestExternalContext if it detects that Mojarra issue 493 (fixed back
in Mojarra 1.2.04) is present.
The Mojarra issue is described here:
http://java.net/jira/browse/JAVASERVERFACES-493 setRequest does not reset
request maps
Two problems with this:
1. This issue was fixed in 2007, so it is unclear whether we should ever
bother applying this workaround.
2. The code which detects the presence of this Mojarra issue is buggy.
As a result of #2, GlobalConfiguratorImpl always adds a
ClearRequestExternalContext wrapper, regardless of whether the old Mojarra
issue is present or not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2359) ClearRequestExternalContext wrapper applied unnecessarily
[ https://issues.apache.org/jira/browse/TRINIDAD-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570630#comment-13570630 ] Andy Schwartz commented on TRINIDAD-2359: - This patch: https://issues.apache.org/jira/secure/attachment/12567885/trinidad-2359.patch Fixes the isTestParamPresent() present by looking for the test parameter in the ExternalContext's request parameter map instead of in the RequestStateMap. I suppose we could rip this code out altogether, though perhaps this test could be useful for catching future regressions? ClearRequestExternalContext wrapper applied unnecessarily - Key: TRINIDAD-2359 URL: https://issues.apache.org/jira/browse/TRINIDAD-2359 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1-core Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Attachments: trinidad-2359.patch GlobalConfiguratorImpl wraps the ExternalContext with a ClearRequestExternalContext if it detects that Mojarra issue 493 (fixed back in Mojarra 1.2.04) is present. The Mojarra issue is described here: http://java.net/jira/browse/JAVASERVERFACES-493 setRequest does not reset request maps Two problems with this: 1. This issue was fixed in 2007, so it is unclear whether we should ever bother applying this workaround. 2. The code which detects the presence of this Mojarra issue is buggy. As a result of #2, GlobalConfiguratorImpl always adds a ClearRequestExternalContext wrapper, regardless of whether the old Mojarra issue is present or not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?
Can it be optional, with a context param ? On Mon, Feb 4, 2013 at 9:36 AM, Leonardo Uribe lu4...@apache.org wrote: Hi Some time ago, this proposal was submitted to the consideration of this list. [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode) http://markmail.org/message/54rb3aphc6txwzbr I have been thinking about the advantages and disadvantages of this technique. Advantages: - Build view time is cut off, giving a speed improvement per each requests. Test done shows around 8% improvement in page rendering and in ajax case the improvement is even better, because in that case the build view time has more weight. - A lot less objects are allocated. Disadvantages: - Detection technique to enable this optimization is not 100% fail-safe. - It could create memory fragmentation, making garbage collection slower. - Higher memory footprint. - It is difficult to keep the code synchronized between versions of JSF, because each concept related to view handling affects how the view pool works. - The use ui:param uses EL VariableResolver, makes the view non poolable, because the ValueExpression instances are not stateless in this case. Do the advantages justify the introduction of this concept? Will users find the improvement useful or applicable in real projects? or does not worth the complexity involved and in this case keep thing simple is better? regards, Leonardo Uribe -- [image: http://download.irian.at/2013/CONFESS_2013_email_signature.png] -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?
2013/2/4 Grant Smith gr...@marathonpm.com Can it be optional, with a context param ? Yes, it can be optional, that's the idea. In this point we are in a situation where we need to be sure that the idea is good enough to be included in MyFaces or not (not all possible ideas of improvement can necessary qualify to be inside MyFaces Core). On Mon, Feb 4, 2013 at 9:36 AM, Leonardo Uribe lu4...@apache.org wrote: Hi Some time ago, this proposal was submitted to the consideration of this list. [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode) http://markmail.org/message/54rb3aphc6txwzbr I have been thinking about the advantages and disadvantages of this technique. Advantages: - Build view time is cut off, giving a speed improvement per each requests. Test done shows around 8% improvement in page rendering and in ajax case the improvement is even better, because in that case the build view time has more weight. - A lot less objects are allocated. Disadvantages: - Detection technique to enable this optimization is not 100% fail-safe. - It could create memory fragmentation, making garbage collection slower. - Higher memory footprint. - It is difficult to keep the code synchronized between versions of JSF, because each concept related to view handling affects how the view pool works. - The use ui:param uses EL VariableResolver, makes the view non poolable, because the ValueExpression instances are not stateless in this case. Do the advantages justify the introduction of this concept? Will users find the improvement useful or applicable in real projects? or does not worth the complexity involved and in this case keep thing simple is better? regards, Leonardo Uribe -- [image: http://download.irian.at/2013/CONFESS_2013_email_signature.png] -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] [Created] (TRINIDAD-2360) Size of the pop-up window does not honor the width and height parameters provided in IE
Anshu Jain created TRINIDAD-2360: Summary: Size of the pop-up window does not honor the width and height parameters provided in IE Key: TRINIDAD-2360 URL: https://issues.apache.org/jira/browse/TRINIDAD-2360 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core, 2.0.0-core, 2.1.0-core Environment: The issue occurs only in Internet Explorer. Reporter: Anshu Jain Priority: Minor If the width and height of a pop-up window is passed on as parameters, the pop-up on opening is not of the provided size. The width is slightly more and the height is reduced from the provided parameters. This behaviors occurs only in IE. For other browsers like Chrome and Firefox, the popup is of correct size as passed through the parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2360) Size of the pop-up window does not honor the width and height parameters provided in IE
[ https://issues.apache.org/jira/browse/TRINIDAD-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshu Jain updated TRINIDAD-2360: - Status: Patch Available (was: Open) Size of the pop-up window does not honor the width and height parameters provided in IE --- Key: TRINIDAD-2360 URL: https://issues.apache.org/jira/browse/TRINIDAD-2360 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-core, 2.0.1-core, 2.1.0-core Environment: The issue occurs only in Internet Explorer. Reporter: Anshu Jain Priority: Minor Attachments: TRINIDAD-2360.patch If the width and height of a pop-up window is passed on as parameters, the pop-up on opening is not of the provided size. The width is slightly more and the height is reduced from the provided parameters. This behaviors occurs only in IE. For other browsers like Chrome and Firefox, the popup is of correct size as passed through the parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EXTVAL-150) Extval does not work with new placeholder component of Richfaces
[
https://issues.apache.org/jira/browse/EXTVAL-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Maier updated EXTVAL-150:
Status: Patch Available (was: Open)
Extval does not work with new placeholder component of Richfaces
Key: EXTVAL-150
URL: https://issues.apache.org/jira/browse/EXTVAL-150
Project: MyFaces Extensions Validator
Issue Type: Bug
Affects Versions: 2.0.6
Environment: Java 7, Tomcat 7, Richfaces 4.3.0.Final, MyFaces 2.1.10
Reporter: Martin Maier
Attachments: ExtValGenericRendererWrapper.diff
The class ExtValGenericRendererWrapper intercepts several methods of Render
classes based on reflection. This can cause problems if a Render class has a
method with an equal name but different parameter count.
For instance: Richfaces 4.3 introduces a new class PlaceholderRendererBase
with a method 'getConvertedValue' that takes 2 parameters. This method is not
related to 'getConvertedValue' of javax.faces.render.Render with 3
parameters. However, this method gets also intercepted because the parameter
count is not checked.
The relavant code part of ExtValGenericRendererWrapper is this (line 56):
{code}
if (method.getName().equals(getConvertedValue) args[1]
instanceof UIComponent) {
return getConvertedValue((FacesContext) args[0], (UIComponent)
args[1], args[2]);
{code}
which should be fixed with something like
{code}
if (method.getName().equals(getConvertedValue) args[1]
instanceof UIComponent
method.getParameterTypes().length == 3) {
return getConvertedValue((FacesContext) args[0], (UIComponent)
args[1], args[2]);
{code}
I can provide a stacktrace for this problem with the Richfaces placeholder
component:
{code}
java.lang.IllegalStateException: Rendering of placeholder before its parent
has failed
at
org.richfaces.component.AbstractPlaceholder$PlaceholderParentPreRenderListener.preRenderParent(AbstractPlaceholder.java:138)
at
org.richfaces.component.event.PreRenderParentListener.processEvent(PreRenderParentListener.java:70)
at
javax.faces.component.UIComponent$EventListenerWrapper.processEvent(UIComponent.java:1565)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:43)
at
org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2410)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:577)
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:580)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:517)
at
org.apache.myfaces.shared.renderkit.RendererUtils.renderChildren(RendererUtils.java:693)
at
org.apache.myfaces.shared.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:115)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:77)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:359)
at
org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRendererWrapper.intercept(ExtValGenericRendererWrapper.java:66)
at
org.apache.myfaces.renderkit.html.HtmlGroupRenderer$$EnhancerByCGLIB$$e84eb129.encodeEnd(generated)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
at
org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer.encodeEnd(HtmlCompositeComponentRenderer.java:71)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:77)
at
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:359)
at
org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRendererWrapper.intercept(ExtValGenericRendererWrapper.java:66)
at
org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer$$EnhancerByCGLIB$$86055b2c.encodeEnd(generated)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665)
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545)
at
org.richfaces.renderkit.RendererBase.renderChildren(RendererBase.java:276)
at
org.richfaces.renderkit.AbstractTableBaseRenderer.encodeColumn(AbstractTableBaseRenderer.java:82)
at
