[jira] [Commented] (MYFACES-3528) CLONE - Performance Improvements
[ https://issues.apache.org/jira/browse/MYFACES-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257632#comment-13257632 ] Leonardo Uribe commented on MYFACES-3528: - A lot of improvements has been already done in 2.1.x / 2.0.x, but they are not ported yet to 1.2.x / 1.1.x because since these two versions are in maintenance stage, care must be taken to ensure do not break existing applications, and most of the interest is in JSF 2.0/2.1/2.2. If you provide a patch, I'll check it and commit it for you. Note for most of the changes, it s a backport, which means just take the improvement from 2.0.x or 1.2.x and apply it in 1.1.x. CLONE - Performance Improvements Key: MYFACES-3528 URL: https://issues.apache.org/jira/browse/MYFACES-3528 Project: MyFaces Core Issue Type: Improvement Reporter: Krashan Brahmanjara Assignee: Martin Marinschek Fix For: 1.2.2 Last week I did some JMeter testing, profiling and code checking on MyFaces to try increase the overall performance. Here are my suggestions for improvement: *) _ComponentAttributesMap I introduced a cache for maps with component attributes. This cache avoids rebuilding the map for every instance of the same component class. It is implemented using a WeakHashMap to allow the GC to remove entries that are not referenced in any instance. *) UIComponentBase Made a few changes in isIdValid as it is called quite often. The new id is now checked against the old id and if it is the same it is assumed as valid (avoids checking chars). Additionally I use isLetterOrDigit() and access string chars directly insted of fetching an array first. *) ImplicitObjectResolver I replaced List with Map to avoid iteration over lists. *) HtmlResponseWriterImpl Use new method of HTMLEncoder for char[] *) HTMLEncoder Improved performance of encode mthod and added a new one that takes a char[] und directly writes to a writer. *) UnicodeEncoder Replaced StringBuffer with StringBuilder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1605) ValueExpressions for SelectItems are evaluated too often for checboxes or radios with spread layout
[ https://issues.apache.org/jira/browse/TOMAHAWK-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256139#comment-13256139 ] Leonardo Uribe commented on TOMAHAWK-1605: -- I checked the code and it seems the implementation changed completely in tomahawk20, so the duplicate call is not there anymore in a new version of shared. I know it is not optimal from perf perspective, but I think we should let it as is in 1.2 branch. If there is a problem with caching at application scope and change it later, that stuff should be handled by app itself, taking the data from app scope and storing it in request scope for example. This is a common bug, but the framework cannot help, because if the data is stored in app scope, in that location is the only place where thread safety can be warranted. I'll close this one as not a problem, because the latest code does not have the related lines anymore. Thanks for the report. ValueExpressions for SelectItems are evaluated too often for checboxes or radios with spread layout --- Key: TOMAHAWK-1605 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1605 Project: MyFaces Tomahawk Issue Type: Bug Components: selectOneRadio / radio Affects Versions: 1.1.9, 1.1.10 Environment: Myfaces 1.2.9/ 1.2.10, Richfaces 3.3.3, Facelets, Tomcat 6.0.32 Reporter: Michael Heinen The method HtmlCheckboxRenderer.renderSingleCheckbox (or HtmlRadioRenderer.renderRadio) calls for each checkbox RendererUtils.getSelectItemList(uiSelectMany) two times. RendererUtils creates a new SelectItemsIterator which evaluates the value expression again for each checkbox that should be rendered and creates each time a new List with SelectItems. It is caused by - method call getConverter(facesContext, uiSelectMany) which calls RendererUtils.getSelectItemList(uiSelectMany) - and few lines later by direct call of RendererUtils.getSelectItemList(uiSelectMany) From a performance point of view this is not optimal. It would be better to create the list once during response rendering and cache it somewhere (maybe in request scope). But even worse (and therefore from my pov a bug) is that this repeated evaluation could result in synchronization problems during the rendering of the response if the bound SelectItems array or collection is changed. This could easily happen if the SelectItems are cached in an application scoped bean. An IndexOutOfBoundsException will occur during response rendering if an item is removed by another thread. This does not happen with list or page layout because the expression to get the SelectItems is evaluated once and then stored as a local var. RendererUtils.internalGetSelectItemList contains already a comment for this: TODO: Shall we cache the list in a component attribute? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3522) collectionType attribute of selectManyCheckbox not processed correctly
[ https://issues.apache.org/jira/browse/MYFACES-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252891#comment-13252891 ] Leonardo Uribe commented on MYFACES-3522: - Once is fixed in shared, it is fixed in tomahawk too. It seems I forgot to synch javax.faces.component._SharedRendererUtils, but for the issue mentioned it is not necessary. Anyway, I updated the code in trunk. Thanks for remember me that. collectionType attribute of selectManyCheckbox not processed correctly -- Key: MYFACES-3522 URL: https://issues.apache.org/jira/browse/MYFACES-3522 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.6 Environment: Tomcat 6.0.35 myFaces 2.1.6 Reporter: Michael Heinen Assignee: Leonardo Uribe Priority: Critical Fix For: 2.0.13, 2.1.7 Attachments: z.war The collectionType attribute of h:selectManyCheckbox is not processed correctly. The value attribute of selectManyCheckbox points to a Map with an ArrayList containing Strings as values, representing the selected values. The checkboxes are initially correctly checked, but after ajax submission the model (MapSting,Object) contains StringArrays instead of ArrayLists. This worked well since JSF 1.0, but it does not work with 2.1 anymore. It can be easily reproduced with MyFaces only. I see this as critical because ClassCastException are thrown as a result in application code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-1904) Exception encoding selectOneMenu when value has an intermediate node null
[
https://issues.apache.org/jira/browse/MYFACES-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253026#comment-13253026
]
Leonardo Uribe commented on MYFACES-1904:
-
I think it is because the description of the issue is incomplete. Note the
description of this issue does not have the logic inside the bean.
By that reason, it is not possible to see what's wrong, and fix it.
Additionally, it is not a common scenario. If you can provide a patch, or if
you can provide a test case, I'll check it and fix it.
Exception encoding selectOneMenu when value has an intermediate node null
-
Key: MYFACES-1904
URL: https://issues.apache.org/jira/browse/MYFACES-1904
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Environment: geronimo 2.1.2
Reporter: Antoni Reus
I have a managed bean called treeManager, with a selectedNode property
that is null the first time.
I have three input components: 2 inputText, and a selectOneMenu, the JSP code
is this:
...
h:outputLabel for=nodeName value=Nom/
h:inputText id=nodeName value=#{treeManager.selectedNode.name} /
h:outputLabel for=nodeDescription value=Descripció/
h:inputText id=nodeDescription
value=#{treeManager.selectedNode.description} /
h:outputLabel for=ambitType value=Àmbit/
h:selectOneMenu id=ambitType value=#{treeManager.selectedNode.ambit}
f:selectItem itemLabel=Global itemValue=global/
f:selectItem itemLabel=Organisme itemValue=organisme/
f:selectItem itemLabel=Procediment itemValue=procediment/
/h:selectOneMenu
When I try the JSF I get this error.
|javax.faces.FacesException: Exception while calling encodeEnd on component :
{Component-Path : [Class: org.ajax4jsf.component.AjaxViewRoot,ViewId:
/dissenyador/estructures.jsp][Class:
javax.faces.component.html.HtmlPanelGrid,Id: j_id_jsp_305935947_1]}|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:610)|
Caused by: ...
|Caused by: org.apache.jasper.el.JspPropertyNotFoundException:
/dissenyador/estructures.jsp(60,8) '#{treeManager.selectedNode.ambit}' Target
Unreachable, 'selectedNode' returned null|
| at
org.apache.jasper.el.JspValueExpression.getType(JspValueExpression.java:61)|
| at
org.apache.myfaces.shared_impl.renderkit._SharedRendererUtils.findUIOutputConverter(_SharedRendererUtils.java:58)|
| at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.findUIOutputConverter(RendererUtils.java:391)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.findUIOutputConverterFailSafe(HtmlRendererUtils.java:393)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:316)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderMenu(HtmlRendererUtils.java:288)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlMenuRendererBase.encodeEnd(HtmlMenuRendererBase.java:57)|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:607)|
Comments from Simon Kitching on the mailing list:
Interesting. From the stacktrace it look like the problem is when trying
to determine the *type* that this expression returns.
When actually asking for the value, null is simply returned if the
intermediate object is not there.
But when asking what static type of object would be returned from the
bound property, of course there is a real problem if the intermediate
node is not there.
Here's the code from SharedRendererUtils.findUIOutputConverter; the
getType call is the problem:
Class valueType = vb.getType(facesContext); // boom when an
intermediate node in the EL is null
if (valueType == null) return null;
if (String.class.equals(valueType)) return null;//No
converter needed for String type
if (Object.class.equals(valueType)) return null;//There is
no converter for Object class
The HtmlRendererUtils.internalRenderSelect uses
converter = findUIOutputConverterFailSafe
-- which obviously is not quite so fail safe :-)
I'm not quite sure what the converter is being used for during rendering
of the select component, but I do know that the rules about converters
and select-components are quite complex. The HTML select component must
always render strings for its options, but JSF requires typed objects to
be passed between the select *component* and the backing beans. So
conversions are required to be invoked at various times.
I think a JIRA issues should definitely be filed for this. If a
converter is optional here, then the code should catch this exception
and not use a converter. Even if a converter is mandatory (ie an error
should be reported if the value-type cannot be
[jira] [Commented] (MYFACES-3524) MyFaces returns a blank page whenever there's some error. Nothing on the log, either.
[ https://issues.apache.org/jira/browse/MYFACES-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253032#comment-13253032 ] Leonardo Uribe commented on MYFACES-3524: - Probably there is an error in render response phase. The response was already started and cannot be reset, so the default error handler cannot reset the response and render the error page. You should attach a debugger into your tomcat to see what's wrong. I don't think the solution is in MyFaces in this case. MyFaces returns a blank page whenever there's some error. Nothing on the log, either. - Key: MYFACES-3524 URL: https://issues.apache.org/jira/browse/MYFACES-3524 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.6 Environment: JDK 1.6.0_31 Tomcat 7.0.26 tomahawk20-1.1.11 Reporter: Haroldo de Oliveira Pinheiro We were migrating from MyFaces 1.1.8 to MyFaces 2.1.6, when we ran into a really crippling problem: Whenever an uncaught error happens, MyFaces 2.1.6 just returns a blank page, and doesn't show anything on the log, either. Naturally, this error makes it almost impossible to even find out what error is ocurring. Couldn't the error at least be shown in the log? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3520) False evaluation of variables/params with the same name
[
https://issues.apache.org/jira/browse/MYFACES-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253047#comment-13253047
]
Leonardo Uribe commented on MYFACES-3520:
-
The problem with this one is c:forEach relies on VariableResolver, and that is
a bad idea by some reasons:
- It can pass across everything, including other templates and composite
components and breaks encapsulation principle.
- The value is statically stored into the inner value expressions, and that
means they can't be cached and reused across pages.
My advice is replace c:forEach with t:dataTable or t:dataList with
rowStatePreserved=true. They are more flexible as described in:
http://lu4242.blogspot.com/2011/06/jsf-component-state-per-row-for.html
Additionally, avoiding c:forEach eliminates the effect over state size.
Unfortunately, after a lot of changes done in myfaces core, the conclusion is
previous c:forEach behavior is not fixable. It is possible to use the template
context map to store the var and disable EL expression caching, but anyway
c:forEach is too inconvenient.
Change the order of VariableResolver stuff is reasonable but is also not
wanted. In fact, remove any local VariableResolver usage inside facelets
algorithm is preferred, so it is just there for backward compatibility. Note
myfaces changed the way c:set and ui:param works to match better the spec.
So, the question is if we change c:forEach to use template context scope
instead. Sounds reasonable. c:forEach var should not pass through ui:include or
composite components. In this case, ui:include creates another template
context, so with that the problem is fixed, and since the expression is still
resolved through VariableResolver, the change will not break anything.
False evaluation of variables/params with the same name
---
Key: MYFACES-3520
URL: https://issues.apache.org/jira/browse/MYFACES-3520
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.6
Reporter: dennis hoersch
I have an scenario where an xhml is included. The included file has a
parameter with the same name as some outer variable. In the included file the
parameter is ignored and the outer variable is used.
Some xhtml:
c:forEach var=item begin=1 end=3
div
ui:include src=templateContextTestInclude.xhtml
ui:param name=item value=#{item + 10} /
/ui:include
/div
/c:forEach
templateContextTestInclude.xhtml:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:c=http://java.sun.com/jsp/jstl/core;
xmlns:t=http://myfaces.apache.org/tomahawk;
body
ui:composition
Item: h:outputText value=#{item} /br/
/ui:composition
/body
/html
I found out that the hierarchy of VariableMappers is asked for a value
before the 'DefaultVariableMapper' tests the current template/page context.
That was not what I expected. Is that how it should be?
In JSF1 it works that way.
(If I change the VariableMapperWrapper locally to test the template/page
context first the behaviour is as I would have expected (don't know if it is
the right place ;-)):
public ValueExpression resolveVariable(String variable)
{
AbstractFaceletContext faceletContext = (AbstractFaceletContext)
FacesContext.getCurrentInstance().getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);
//Check on page and template context
PageContext pageContext = faceletContext.getPageContext();
if (pageContext != null pageContext.getAttributeCount() 0)
{
if (pageContext.getAttributes().containsKey(variable))
{
ValueExpression returnValue =
pageContext.getAttributes().get(variable);
if (_trackResolveVariables)
{
_variableResolved = true;
}
return returnValue;
}
}
TemplateContext templateContext = faceletContext.getTemplateContext();
if (templateContext != null !templateContext.isParameterEmpty())
{
if (templateContext.getParameterMap().containsKey(variable))
{
ValueExpression returnValue =
templateContext.getParameter(variable);
if (_trackResolveVariables)
{
_variableResolved = true;
}
return returnValue;
}
}
[jira] [Commented] (MYFACES-3519) Could not load Javascript-Sources in 'Package' org.apache.myfaces.core.impl.xhrCore.engine
[
https://issues.apache.org/jira/browse/MYFACES-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242504#comment-13242504
]
Leonardo Uribe commented on MYFACES-3519:
-
I checked and there are some small bugs there, due to some important changes.
This bug only can be seen when this param is set:
context-param
param-nameorg.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS/param-name
param-valuetrue/param-value
/context-param
Fortunately, the solution is simple, just fix the paths to:
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/XhrConst.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/FormData.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/BaseRequest.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/Xhr1.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/IFrame.js']},
null, null, UTF-8, false);
And add two js files (_DomExperimental.js and _ExtTransport.js) that are
included on the normal version.
Could not load Javascript-Sources in 'Package'
org.apache.myfaces.core.impl.xhrCore.engine
--
Key: MYFACES-3519
URL: https://issues.apache.org/jira/browse/MYFACES-3519
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: dennis hoersch
Assignee: Leonardo Uribe
Hi,
I am testing MyFaces 2.1.6 with ProjectStage=Development. And I have an
Javascript-error: Firefox showes me that 'myfaces.core.impl.xhrCore.engine'
is undefined. After looking around I found that the jsf-uncompressed.js loads
some libraries, i.e.:
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:XhrConst.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:FormData.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:Xhr1.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:IFrame.js']},
null, null, UTF-8, false);
The replaced JS in Firefox for these entries looks like the following:
_ls(, null, null, UTF-8, false);
The resources are packaged under:
META-INF/internal-resources/org.apache.myfaces.core.impl.xhrCore/engine
The ResourceLoader expects them to be in:
META-INF/internal-resources/org.apache.myfaces.core.impl.xhrCore.engine
After changing it in my local myfaces-jar all libraries could be loaded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3514) cc:insertChildren must relocate user tag handlers other tags that contains markup too
[ https://issues.apache.org/jira/browse/MYFACES-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241200#comment-13241200 ] Leonardo Uribe commented on MYFACES-3514: - Yes, you're right. I was supposing the junit test would catch any bug. I committed the fix. Thanks for your attention in the details. It helps a lot. cc:insertChildren must relocate user tag handlers other tags that contains markup too - Key: MYFACES-3514 URL: https://issues.apache.org/jira/browse/MYFACES-3514 Project: MyFaces Core Issue Type: Bug Environment: MyFaces 2.1.6, Tomahawk20 1.1.11 Reporter: dennis hoersch Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Hello, I just copied the emails of the problem that not all children of composite components will be rendered out of the dev-list in here. -- Hi Leonardo, that was my first attempt too. But as I mentioned earlier, we have also own TagHandlers (no UserTagHandlers, they extends TagHandler) - that ones will be still ignored... Maybe there can be a special marker interface? So that the 'list' is more dynamically? (But I am not very glad with this solution if anyone having own tag handlers must do a special thing to get them work with composite components (?)...) Greetings, dennis Hi Dennis I have checked the code and I think we can consider all UserTagHandler instances as containers of components (just like DecorateHandler and IncludeHandler). That means if cc:insertChildren is used, all instances of UserTagHandler should be executed in the place when cc:insertChildren is called. So we just need to increase the list to: - javax.faces.view.facelets.ComponentHandler.class - InsertChildrenHandler.class - InsertHandler.class - DecorateHandler.class - IncludeHandler.class - TextHandler.class - UserHagHandler.class After looking carefully this issue, it seems we need to include c:if and c:choose too. Could you please create an issue for this one in https://issues.apache.org/jira/browse/MYFACES so I can fix it? regards, Leonardo 2012/3/27 Dennis Hörsch hoer...@his.de: Hi, I was expecting that composite components behave like any other. I am currently updating a big project from JSF1 to 2. We have many usages of JSTL as 'child'-components. And our 'old-fashioned' facelets components now are UserTagHandlers in the end. This ones will also be ignored... I had a look an at CompositeComponentResourceTagHandler and changed it in the way that 'newly' added childs are stored and will later be added to the right component. My simple test scenario works, but I have no clue about Partial State Saving and if there are any other cases that may be affected. I attached it, can you have a look? Thank you, dennis hoersch Am 26.03.2012 22:42, schrieb Leonardo Uribe: Hi Difficult question. You should avoid that trick, or at least use c:if inside you custom tag to make it work properly. Really there are some details that will not work as expected. First of all, c:if code has changed since the original code inside facelets, to ensure proper operation with JSF 2.0 Partial State Saving. It is very complex to explain, but in resume, no component like c:if can be created without rely in some implementation details. The second part is composite component algorithm cannot recognize the tag as a tag containing component instances, so if the composite component uses cc:insertChildren, the part related to the tag will not be applied correctly. The solution in this case is use a composite component or a normal component instead a facelets user tag. Anyway, maybe we can do something better in this part ( org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler), and try to detect better cases like the one described here. regards, Leonardo Uribe 2012/3/26 Dennis Hörsch hoer...@his.de: Hey, I have a problem with composite components. The scenario is as follows: his:someCompositeComponent id=outer h:inputText id=first ... / his:someTagHandlerTag condition=bla h:inputText is=second ... / /his:someTagHandlerTag /his:someCompositeComponent The problem is, only the first input field is rendered. The second is not. After building the component tree, the first is a child of the 'composite component'-facet of the surrounding UINamingContainer (outer), the second ends as child of the UINamingContainer. The 'HtmlCompositeComponentRenderer' renders only the children of the facet. The 'someTagHandlerTag' is handled by a subclass of TagHandler. If the condition is true, it calls the nextHandler (second-input field)
[jira] [Commented] (MYFACES-3518) Datatable (h:dataTable) is not populated with data despite getAll() method returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 + mysql-connector-java-5.1.1
[
https://issues.apache.org/jira/browse/MYFACES-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241985#comment-13241985
]
Leonardo Uribe commented on MYFACES-3518:
-
I checked the code and I finally found the problem. Since 1.1, myfaces
DataModel classes assume rowCount is always defined. Recently, in MYFACES-3270,
I found on the spec that rowCount can be -1, but that only means the model
doesn't know how many rows are. ResultSetDataModel returns in getRowCount() by
default -1.
In MyFaces 1.1.3, a change was done in h:dataTable renderer to include
newspaper mode in tomahawk. For such mode, get the rowCount is critical,
because otherwise there is no way to calculate the newspaper rows and newspaper
columns.
The solution is add some code to iterate when getRowCount() returns -1.
This issue will be fixed on 1.1.x, 1.2.x, 2.0.x and 2.1.x branches.
Datatable (h:dataTable) is not populated with data despite getAll() method
returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 +
mysql-connector-java-5.1.18 )
-
Key: MYFACES-3518
URL: https://issues.apache.org/jira/browse/MYFACES-3518
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.6
Environment: Windows 7 64bit
Tomcat 7.0.26
myfaces-2.1.6
JRE 6
MySQL 5.5
mysql-connector-java-5.1.18
Reporter: Sagi Kovaliov
Hello, when I use the following BeanClass and xhtml page, Datatable is not
populated with data, despite the method getAll() returns ResultSet that
contains customer names.
Code line System.out.println(crs.getString(Name)) iterates through the
ResultSet and prints customer names from customer table before the ResultSet
is being returned to h:dataTable component. This is what I get in Tomcat log:
..
***
*** WARNING: Apache MyFaces-2 is running in DEVELOPMENT mode. ***
*** ^^^ ***
*** Do NOT deploy to your live server(s) without changing this. ***
*** See Application#getProjectStage() for more information. ***
***
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8080]
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-bio-8009]
29/03/2012 22:19:57 org.apache.catalina.startup.Catalina start
INFO: Server startup in 4706 ms
29/03/2012 22:19:58 org.apache.myfaces.util.ExternalSpecifications
isUnifiedELAvailable
INFO: MyFaces Unified EL support enabled
Start of Debug
William Dupont
William Dupont
End of Debug
This is the ManagedBean:
package com.corejsf;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.annotation.Resource;
import javax.faces.bean.*;
import javax.sql.DataSource;
import javax.sql.rowset.CachedRowSet;
@ManagedBean
@RequestScoped
public class CustomerBean {
@Resource(name=jdbc/Sufa) private DataSource ds;
public ResultSet getAll() throws SQLException {
Connection conn = ds.getConnection();
try {
Statement stmt = conn.createStatement();
ResultSet result = stmt.executeQuery(SELECT * FROM customers);
CachedRowSet crs = new com.sun.rowset.CachedRowSetImpl();
crs.populate(result);
System.out.println(Start of Debug);
while(crs.next()) {
System.out.println(crs.getString(Name));
}
System.out.println(End of Debug);
return crs;
} finally {
conn.close();
}
}
}
This is xhtml page:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:body
h:form
h:dataTable value=#{customerBean.all} var=customer
h:column
f:facet name=header#{msgs.nameHeader}/f:facet
#{customer.Name}
/h:column
/h:dataTable
/h:form
/h:body
/html
It's important to mention that the same code works perfect when I change JSF
implementation to mojarra-2.1.7.
It's seems like a bug.
Thanks a lot
Sagi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly,
[jira] [Commented] (TOMAHAWK-1618) ui:fragment ignores rendered attribute if nested in t:div
[ https://issues.apache.org/jira/browse/TOMAHAWK-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241990#comment-13241990 ] Leonardo Uribe commented on TOMAHAWK-1618: -- Thanks for the sample. It is a bug in tomahawk, and will be fixed updating shared module. ui:fragment ignores rendered attribute if nested in t:div - Key: TOMAHAWK-1618 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1618 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.11 Environment: MyFaces 2.1.6, Tomahawk 1.1.11, Tomcat 6.0.32 Reporter: Patrick Schmidt Attachments: myfaces-blank.zip When nested inside a t:div, the rendered attribute of ui:fragment ist ignored. This seems to be similar to MYFACES-3239, which was fixed in 2.1.2. Example: t:div ui:fragment rendered=false h:outputText value=This text should not appear / /ui:fragment /t:div -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3518) Datatable (h:dataTable) is not populated with data despite getAll() method returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 + mysql-connector-java-5.1.1
[
https://issues.apache.org/jira/browse/MYFACES-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241993#comment-13241993
]
Leonardo Uribe commented on MYFACES-3518:
-
Thanks to Sagi Kovaliov for the example, it helps a lot solving this issue
quickly.
Datatable (h:dataTable) is not populated with data despite getAll() method
returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 +
mysql-connector-java-5.1.18 )
-
Key: MYFACES-3518
URL: https://issues.apache.org/jira/browse/MYFACES-3518
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.6
Environment: Windows 7 64bit
Tomcat 7.0.26
myfaces-2.1.6
JRE 6
MySQL 5.5
mysql-connector-java-5.1.18
Reporter: Sagi Kovaliov
Assignee: Leonardo Uribe
Fix For: 1.1.10, 1.2.12, 2.0.13, 2.1.7
Hello, when I use the following BeanClass and xhtml page, Datatable is not
populated with data, despite the method getAll() returns ResultSet that
contains customer names.
Code line System.out.println(crs.getString(Name)) iterates through the
ResultSet and prints customer names from customer table before the ResultSet
is being returned to h:dataTable component. This is what I get in Tomcat log:
..
***
*** WARNING: Apache MyFaces-2 is running in DEVELOPMENT mode. ***
*** ^^^ ***
*** Do NOT deploy to your live server(s) without changing this. ***
*** See Application#getProjectStage() for more information. ***
***
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8080]
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-bio-8009]
29/03/2012 22:19:57 org.apache.catalina.startup.Catalina start
INFO: Server startup in 4706 ms
29/03/2012 22:19:58 org.apache.myfaces.util.ExternalSpecifications
isUnifiedELAvailable
INFO: MyFaces Unified EL support enabled
Start of Debug
William Dupont
William Dupont
End of Debug
This is the ManagedBean:
package com.corejsf;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.annotation.Resource;
import javax.faces.bean.*;
import javax.sql.DataSource;
import javax.sql.rowset.CachedRowSet;
@ManagedBean
@RequestScoped
public class CustomerBean {
@Resource(name=jdbc/Sufa) private DataSource ds;
public ResultSet getAll() throws SQLException {
Connection conn = ds.getConnection();
try {
Statement stmt = conn.createStatement();
ResultSet result = stmt.executeQuery(SELECT * FROM customers);
CachedRowSet crs = new com.sun.rowset.CachedRowSetImpl();
crs.populate(result);
System.out.println(Start of Debug);
while(crs.next()) {
System.out.println(crs.getString(Name));
}
System.out.println(End of Debug);
return crs;
} finally {
conn.close();
}
}
}
This is xhtml page:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:body
h:form
h:dataTable value=#{customerBean.all} var=customer
h:column
f:facet name=header#{msgs.nameHeader}/f:facet
#{customer.Name}
/h:column
/h:dataTable
/h:form
/h:body
/html
It's important to mention that the same code works perfect when I change JSF
implementation to mojarra-2.1.7.
It's seems like a bug.
Thanks a lot
Sagi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3515) Duplicate id using a facet in a composite component
[
https://issues.apache.org/jira/browse/MYFACES-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240372#comment-13240372
]
Leonardo Uribe commented on MYFACES-3515:
-
Could you provide an example to be able to reproduce this issue?
Duplicate id using a facet in a composite component
---
Key: MYFACES-3515
URL: https://issues.apache.org/jira/browse/MYFACES-3515
Project: MyFaces Core
Issue Type: Bug
Environment: MyFaces 2.1.6, Tomahawk20 1.1.11
Reporter: dennis hoersch
Hello,
I get an IllegalStateException using a facet in a composite component. The
facet gets the same id as the internal 'composite component'-facet. The facet
is created using CumponentSupport.addFacet(). Here the id of the facet is
generated using the view root instead of the UniqueIdVendor of the parent to
whom the facet is added.
In other places the id is retrieved with something like
FaceletCompositionContext mctx =
FaceletCompositionContext.getCurrentInstance(facesContext);
UniqueIdVendor uniqueIdVendor = mctx.getUniqueIdVendorFromStack();
if (uniqueIdVendor == null)
{
uniqueIdVendor = facesContext.getViewRoot();
}
String uid = uniqueIdVendor.createUniqueId(facesContext, null);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3514) cc:insertChildren must relocate user tag handlers other tags that contains markup too
[ https://issues.apache.org/jira/browse/MYFACES-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240945#comment-13240945 ] Leonardo Uribe commented on MYFACES-3514: - After thinking about it, I consider use c:if and any user tag (tag that is created adding a source entry pointing to a .xhtml file into taglib.xml) should be just relocated like ui:decorate. It is clear a new interface called org.apache.myfaces.view.facelets.tag.ComponentContainerHandler is necessary to identify such tags and include them in a pluggable way into cc:insertChildren special logic. cc:insertChildren must relocate user tag handlers other tags that contains markup too - Key: MYFACES-3514 URL: https://issues.apache.org/jira/browse/MYFACES-3514 Project: MyFaces Core Issue Type: Bug Environment: MyFaces 2.1.6, Tomahawk20 1.1.11 Reporter: dennis hoersch Hello, I just copied the emails of the problem that not all children of composite components will be rendered out of the dev-list in here. -- Hi Leonardo, that was my first attempt too. But as I mentioned earlier, we have also own TagHandlers (no UserTagHandlers, they extends TagHandler) - that ones will be still ignored... Maybe there can be a special marker interface? So that the 'list' is more dynamically? (But I am not very glad with this solution if anyone having own tag handlers must do a special thing to get them work with composite components (?)...) Greetings, dennis Hi Dennis I have checked the code and I think we can consider all UserTagHandler instances as containers of components (just like DecorateHandler and IncludeHandler). That means if cc:insertChildren is used, all instances of UserTagHandler should be executed in the place when cc:insertChildren is called. So we just need to increase the list to: - javax.faces.view.facelets.ComponentHandler.class - InsertChildrenHandler.class - InsertHandler.class - DecorateHandler.class - IncludeHandler.class - TextHandler.class - UserHagHandler.class After looking carefully this issue, it seems we need to include c:if and c:choose too. Could you please create an issue for this one in https://issues.apache.org/jira/browse/MYFACES so I can fix it? regards, Leonardo 2012/3/27 Dennis Hörsch hoer...@his.de: Hi, I was expecting that composite components behave like any other. I am currently updating a big project from JSF1 to 2. We have many usages of JSTL as 'child'-components. And our 'old-fashioned' facelets components now are UserTagHandlers in the end. This ones will also be ignored... I had a look an at CompositeComponentResourceTagHandler and changed it in the way that 'newly' added childs are stored and will later be added to the right component. My simple test scenario works, but I have no clue about Partial State Saving and if there are any other cases that may be affected. I attached it, can you have a look? Thank you, dennis hoersch Am 26.03.2012 22:42, schrieb Leonardo Uribe: Hi Difficult question. You should avoid that trick, or at least use c:if inside you custom tag to make it work properly. Really there are some details that will not work as expected. First of all, c:if code has changed since the original code inside facelets, to ensure proper operation with JSF 2.0 Partial State Saving. It is very complex to explain, but in resume, no component like c:if can be created without rely in some implementation details. The second part is composite component algorithm cannot recognize the tag as a tag containing component instances, so if the composite component uses cc:insertChildren, the part related to the tag will not be applied correctly. The solution in this case is use a composite component or a normal component instead a facelets user tag. Anyway, maybe we can do something better in this part ( org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler), and try to detect better cases like the one described here. regards, Leonardo Uribe 2012/3/26 Dennis Hörsch hoer...@his.de: Hey, I have a problem with composite components. The scenario is as follows: his:someCompositeComponent id=outer h:inputText id=first ... / his:someTagHandlerTag condition=bla h:inputText is=second ... / /his:someTagHandlerTag /his:someCompositeComponent The problem is, only the first input field is rendered. The second is not. After building the component tree, the first is a child of the 'composite component'-facet of the surrounding UINamingContainer (outer), the second ends as child of the UINamingContainer. The 'HtmlCompositeComponentRenderer'
[jira] [Commented] (MYFACES-3515) Duplicate id using a facet in a composite component
[
https://issues.apache.org/jira/browse/MYFACES-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240949#comment-13240949
]
Leonardo Uribe commented on MYFACES-3515:
-
I was not able to reproduce the bug, but I can see the problem. The reason why
we haven't seen it is any call to UIViewRoot.createUniqueId() increase the
unique counter, so as soon as the view gets bigger and bigger, the different
between the unique counter in UIViewRoot and other counters in composite
components gets bigger too. In few words, the probability to see the problem is
very small, but I'm glad someone has been able to see it.
The panel created by ComponentSupport.createFacetUIPanel is special. To be
restored properly and do not create duplicate ids or any other unwanted
conflicts, it requires an unique id. This code is usually called when more than
one component is added to a facet and it is necessary to create a shared
container. Use FaceletCompositionContext.generateUniqueComponentId() is not
possible, because c:if blocks inside a facet will make component ids
unstable. Use UniqueIdVendor is feasible but also will be affected by c:if
blocks inside a facet. The only solution that will generate real unique ids is
use the parent id and the facet name and derive an unique id that cannot be
generated by SectionUniqueIdCounter, doing the same trick as with metadata: use
a double __ and add a prefix (f). Note this id will never be printed into the
response, because this is just a container.
Note in facelets 1.1.x facets requires a container component, but in JSF 2.0 /
2.1, the behavior to handle facets was changed in order to make f:metadata
component work (requires facets can contain more than one component
automatically).
I also have notice a small performance improvement: our calls to
UniqueIdVendor.createUniqueId() increase the unique counter in 1, but when a
seed is passed this is not necessary. That will save one HashMap.get() call per
component create by facelets.
Duplicate id using a facet in a composite component
---
Key: MYFACES-3515
URL: https://issues.apache.org/jira/browse/MYFACES-3515
Project: MyFaces Core
Issue Type: Bug
Environment: MyFaces 2.1.6, Tomahawk20 1.1.11
Reporter: dennis hoersch
Attachments: duplicateIdTest.zip
Hello,
I get an IllegalStateException using a facet in a composite component. The
facet gets the same id as the internal 'composite component'-facet. The facet
is created using CumponentSupport.addFacet(). Here the id of the facet is
generated using the view root instead of the UniqueIdVendor of the parent to
whom the facet is added.
In other places the id is retrieved with something like
FaceletCompositionContext mctx =
FaceletCompositionContext.getCurrentInstance(facesContext);
UniqueIdVendor uniqueIdVendor = mctx.getUniqueIdVendorFromStack();
if (uniqueIdVendor == null)
{
uniqueIdVendor = facesContext.getViewRoot();
}
String uid = uniqueIdVendor.createUniqueId(facesContext, null);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ORCHESTRA-60) Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL()
[ https://issues.apache.org/jira/browse/ORCHESTRA-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238099#comment-13238099 ] Leonardo Uribe commented on ORCHESTRA-60: - Hi Cristian O, now I get it. sendRedirect() is used for internal and external URLs, but all internal URLs pass first through encodeRedirectURL(), so it is valid to add conversationContext param into that call. The rules for add conversationContext are already in orchestra and applies to encodeURL() too, so the change is valid. Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL() -- Key: ORCHESTRA-60 URL: https://issues.apache.org/jira/browse/ORCHESTRA-60 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.5 Reporter: Christian Kaltepoth Orchestra currently doesn't implement RequestParameterResponseWrapper.encodeRedirectURL(). The API docs of HttpServletResponse clearly state that encodeRedirectURL() should be called before sending a redirect using sendRedirect(). Therefore the conversationContext parameter is currently lost in these situations. Corresponding PrettyFaces issue: http://code.google.com/p/prettyfaces/issues/detail?id=125 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236707#comment-13236707 ] Leonardo Uribe commented on MYFACES-3510: - No, it is not a bug. There is no other way to detect tomcat different to check if such class exists on the classpath. Instead, what do you need is implement a LifecycleProvider2 for glassfish or a custom LifecycleProviderFactory, to skip TomcatAnnotationLifecycleProvider.isAvailable. Unfortunately, since glassfish is CDDL/GPL licensed, we can't include that integration code in MyFaces. See: https://cwiki.apache.org/confluence/display/MYFACES/Integration+with+application+and+web+servers for more details. It could be good to share your findings later in a blog, other users have reported problems setting up myfaces with glassfish, and maybe that could help Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235769#comment-13235769 ] Leonardo Uribe commented on MYFACES-3510: - I have attached another patch that uses this structure: private static MapClassLoader, SoftReferenceMapClass?, MapString, _PropertyDescriptorHolder propertyDescriptorCacheMap = new WeakHashMapClassLoader, SoftReferenceMapClass?, MapString, _PropertyDescriptorHolder(); The idea is use a SoftReference to prevent the direct strong reference over propertyDescriptorCache, but use a new key over current classloader to make possible when the application is undeployed to clean the cache. Using yourkit profiler I was not able to see any problem with metadata field, because a cleanup method is called when the application is destroyed on AbstractFacesInitializer. I also tried to check if the SoftReference solves the problem without the cleanup code and it does. I also checked if the solution makes the code slower, but the effect is minimal. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235894#comment-13235894 ] Leonardo Uribe commented on MYFACES-3510: - The stack trace provided looks normal. A webapp is deployed, so it takes some time to initialize the environment. That is necessary because it is required to parse some files, scan for annotations and merge all that information. Please do not reopen this issue and instead, create another one if necessary, because the stack trace is another different behavior to the one solved in the patch. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235968#comment-13235968 ] Leonardo Uribe commented on MYFACES-3510: - Garbage collection takes time. The code committed (patch-2) try to cleanup the cache as soon as the app is undeployed. The soft reference is only cleaned up when memory is really necessary, and an OutOfMemoryError is only thrown after clean all soft references. I suppose the GC is responsible of the slowdown, but with the code committed, this effect dissapear. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236126#comment-13236126 ] Leonardo Uribe commented on MYFACES-3510: - Well, do you have a better explanation? You could try replace SoftReference with WeakReference. If that change improves the situation, let me know and I'll change the code. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235068#comment-13235068 ] Leonardo Uribe commented on MYFACES-3510: - I checked the code and it works as it was designed. There is a WeakHashMap in _ComponentAttributesMap: // Cache for component property descriptors private static MapClass?, MapString, _PropertyDescriptorHolder propertyDescriptorCache = new WeakHashMapClass?, MapString, _PropertyDescriptorHolder(); and _PropertyDescriptorHolder holds PropertyDescriptor and Method instances. It is not necessary to use WeakReference inside _PropertyDescriptorHolder, because the Classloader is already weakly reachable. I took an application using tomcat 7.0.23 and then try to start/stop multiple times. If there is a memory leak, an OutOfMemoryException can be seen. It never happened. What could happen is the classloader is not discarded by the gc immediately. But as soons as the jvm as for memory and the gc do its cleanup job, it will found the classloader is weakly reachable and can be discarded from memory. Unfortunately, the screenshot is not enough proof that a memory leak exist. We need to check if an OutOfMemoryException could be caused by this code. Anyway, use a WeakReference is only reasonable if you can gain something, but I don't think it apply in this case. Suggestions are welcome. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235304#comment-13235304 ] Leonardo Uribe commented on MYFACES-3510: - What I mean with weakly reachable is since the map in propertyDescriptorCache is a WeakHashMap, once the keys are collected, the values are discarded and the Classloader can be discarded from memory too. So, strictly speaking there is no leak. What could happen is in one moment of the time the Classloader cannot be discarded since the weak keys needs to be discarded first. Could you see if there is a leak over org.apache.myfaces.view.facelets.tag.MetaRulesetImpl (used in facelets)?, specifically with: private volatile static WeakHashMapClassLoader, MapString, MetadataTarget metadata = new WeakHashMapClassLoader, MapString, MetadataTarget(); This is a similar case. If this is not a problem, maybe the leak is caused by cache Method instances. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235308#comment-13235308 ] Leonardo Uribe commented on MYFACES-3510: - I have attached a patch with a possible solution. The idea is change propertyDescriptorCache, adding a soft reference. private static MapClass?, SoftReferenceMapString, _PropertyDescriptorHolder propertyDescriptorCache = new WeakHashMapClass?, SoftReferenceMapString, _PropertyDescriptorHolder(); In this way, we can avoid the strong reference through the static var, and since the garbage collector needs to clean all soft references before throw an OutOfMemoryError, we ensure that cache is cleaned up if memory is required. @Ruben: Could you please try if this patch can solve the problem? Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: MYFACES-3510-1.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ORCHESTRA-60) Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL()
[ https://issues.apache.org/jira/browse/ORCHESTRA-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234023#comment-13234023 ] Leonardo Uribe commented on ORCHESTRA-60: - I have checked this one and there is a problem with override RequestParameterResponseWrapper.encodeRedirectURL() . In few words, there is no warrant the same conversationContext should be used for a redirect. This is the javadoc: ... Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged. The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL. Because the rules for making this determination can differ from those used to decide whether to encode a normal link, this method is separated from the encodeURL method. All URLs sent to the HttpServletResponse.sendRedirect method should be run through this method. Otherwise, URL rewriting cannot be used with browsers which do not support cookies. ... What happen if the redirect url is not for the same app? conversationContext query param should not be added. Note encodeURL is used always for URL that are served for the webapp. In PrettyFaces case, since it is a layer to generate pretty URLs, in my opinion it sounds better to use encodeURL. Suggestions are welcome. Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL() -- Key: ORCHESTRA-60 URL: https://issues.apache.org/jira/browse/ORCHESTRA-60 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.5 Reporter: Christian Kaltepoth Orchestra currently doesn't implement RequestParameterResponseWrapper.encodeRedirectURL(). The API docs of HttpServletResponse clearly state that encodeRedirectURL() should be called before sending a redirect using sendRedirect(). Therefore the conversationContext parameter is currently lost in these situations. Corresponding PrettyFaces issue: http://code.google.com/p/prettyfaces/issues/detail?id=125 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ORCHESTRA-59) Orchestra does not work with JSF RI
[ https://issues.apache.org/jira/browse/ORCHESTRA-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234025#comment-13234025 ] Leonardo Uribe commented on ORCHESTRA-59: - In this case, it sounds reasonable to override ExternalContext.encodeRedirectURL() and add the conversationContext query param. It is different from ORCHESTRA-60, because the encoded URL is supposed to be used in the JSF application. Anyway, I think a check to ensure the link is local is necessary in this place. Suggestions are welcome. Orchestra does not work with JSF RI --- Key: ORCHESTRA-59 URL: https://issues.apache.org/jira/browse/ORCHESTRA-59 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.4 Environment: - Glassfish 3.3.1 - JSF RI 2.1.3 (FCS b02) - MyFaces Orchestra 1.4 (JSF 2) Reporter: Tomas Havelka ConversationContext request parameter is missing (it's not appended) in the url. If it's passed manually in the request url, it works. It's because the Mojarra 2.1.3 does not call the HttpServletResponse.encodeURL() in the ExternalContext.encodeRedirectURL() so the conversationContext is not append to the url. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1613) HtmlCalendarRenderer Throws ClassCastException - not fixed
[
https://issues.apache.org/jira/browse/TOMAHAWK-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230609#comment-13230609
]
Leonardo Uribe commented on TOMAHAWK-1613:
--
Some time ago I studied in deep the problem. Really the problem to deal with
different date types was solved in TOMAHAWK-1508. I'll take some extracts from
that issue to explain it to you:
... I reviewed both components and the problem for use Converter interface
reside in its design vs t:inputCalendar and t:inputDate requeriments. It has
two problems:
- It assume submittedValue is always a String, but for t:inputDate that is not
true. For this case as suggested, we need a property to give the chance to
convert the java.util.Date instance used by the component to other type and
viceversa.
- t:inputCalendar and t:inputDate requires a base date type to manipulate. In
both cases is java.util.Date, but the boundaries between the base date type and
the business type are not clear. For example, in jdk 1.6 java.sql.Date that
extends from java.util.Date override some methods and makes t:inputCalendar and
t:inputDate fail.
In few words, t:inputDate and t:inputCalendar cannot know all different date
types and manipulate them correctly. But we needed some flexibility on the
model to use different date types (plain String, Calendar or use joda library
for date/time).
Unfortunately the Converter interface is not good enough, because it does not
isolate correctly the value in the model and the one used by
t:inputDate/t:inputCalendar to render itself. There are some corner cases
that make it fail.
The right way to do it is introduce a proper converter interface to deal with
the conversion between the value stored in the bean and the value used by
t:inputCalendar / t:inputDate. That is
org.apache.myfaces.custom.calendar.DateBusinessConverter
... Provide a bridge between the java.util.Date instance used by a component
that receive date/time values and
the business value used to represent the value. ...
So, instead use a custom converter, try adding this class:
package myproject.myconverter;
public class CalendarDateBusinessConverter implements DateBusinessConverter
{
public Object getBusinessValue(FacesContext context,
UIComponent component,
java.util.Date value)
{
// ... convert from java.util.Date to Calendar
return calendarValue;
}
public java.util.Date getDateValue(FacesContext context,
UIComponent component,
Object value)
{
// ... convert from Calendar to java.util.Date
return dateValueToUseByDateComponent;
}
}
And register the class
t:inputCalendar
dateBusinessConverter=myproject.myconverter.CalendarDateBusinessConverter
It also receive EL expressions. Anyway, I'll remove the cast for the next
version.
HtmlCalendarRenderer Throws ClassCastException - not fixed
--
Key: TOMAHAWK-1613
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1613
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.11
Reporter: Klaus Schuster
The problem mentioned TOMAHAWK-1599 is not fixed.
I could locally fix the problem with changing line 169 in File:
org.apache.myfaces.custom.calendar.HtmlCalendarRenderer.java
from:
value = (Date) inputCalendar.getValue();
to:
if(converter instanceof DateConverter) {
value = ((DateConverter) converter).getAsDate(facesContext,
inputCalendar);
} else {
value = (Date) inputCalendar.getValue();
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3191) Handing exception (in exception handler) from render response phase with forward/redirect is inconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229362#comment-13229362
]
Leonardo Uribe commented on MYFACES-3191:
-
The problem here is to do that we need to buffer the response before send it to
the client, so if an error occur, be able to reset the response and render the
error page. This has a significant impact in performance, specially in memory
usage. In client side state saving a part of the response is buffered to render
the state token, but in server side it does not.
The question is simple: it is really wanted to buffer all requests into memory
before sent it to the server?
I think it is possible to use StreamCharBuffer to do that and handle memory
usage in a efficient way. There exists a method called
ServletResponse.resetBuffer() but it is not useable because the buffer size
should be bigger than the response size otherwise, the buffer is flushed
automatically. Unfortunately there is no ExternalContext.responseResetBuffer()
but there is ExternalContext.responseReset().
Maybe this should be considered a flaw of servlet spec. It is possible to set
the buffer in FaceletsViewDeclarationLanguage.renderView and change
ExternalContext.responseReset() to reset that buffer too if it is called. Note
that is something outside the spec, but is reasonable behavior, because if the
user set the buffer size (with javax.faces.FACELETS_BUFFER_SIZE) to a enough
big value, it will work anyway. I think the buffer stuff could be handled
better by the servlet container, but in this case we don't have choice.
Handing exception (in exception handler) from render response phase with
forward/redirect is inconsistent
-
Key: MYFACES-3191
URL: https://issues.apache.org/jira/browse/MYFACES-3191
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Affects Versions: 2.1.2-SNAPSHOT
Environment: myfaces trunk
Reporter: Martin Kočí
View.xhtml snippet:
h:commandButton value=Submit
f:setPropertyActionListener value=#{true}
target=#{bean.rendered} /
f:ajax render=outputText /
/h:commandButton
h:outputText rendered=#{bean.rendered} id=outputText
value=#{bean.value} /
Bean.java snippet:
public Object getValue() {
throw new NullPointerException();
}
Custom exception handler code:
if (PhaseId.RENDER_RESPONSE.equals(currentPhaseId)) {
try {
nav.handleNavigation(facesContext,
null, /ErrorPage.xhtml?faces-redirect=true);
} finally {
i.remove();
}
}
Modify view and exception handler to achieve following combinations (HTML
request = comment out f:ajax, forward = remove ?faces-redirect=true)
1) HTML request + forward: nothing in log, and malformed output is produced
(no closing tags for /body etc.)
2) HTML request + redirect: OK , redirect to ErrorPage.xhtml is done
3) AJAX request + forward: exception in log, bud no forward to ErrorPage
performed
4) AJAX request + redirect: exception in log, malformed XML produced (?xml
and partial-response 2x in output) , no redirect performed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3191) Handing exception (in exception handler) from render response phase with forward/redirect is inconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229364#comment-13229364
]
Leonardo Uribe commented on MYFACES-3191:
-
MyFaces org.apache.myfaces.renderkit.ErrorHandler has this line:
if (!facesContext.getExternalContext().isResponseCommitted())
{
facesContext.getExternalContext().responseReset();
}
Handing exception (in exception handler) from render response phase with
forward/redirect is inconsistent
-
Key: MYFACES-3191
URL: https://issues.apache.org/jira/browse/MYFACES-3191
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Affects Versions: 2.1.2-SNAPSHOT
Environment: myfaces trunk
Reporter: Martin Kočí
View.xhtml snippet:
h:commandButton value=Submit
f:setPropertyActionListener value=#{true}
target=#{bean.rendered} /
f:ajax render=outputText /
/h:commandButton
h:outputText rendered=#{bean.rendered} id=outputText
value=#{bean.value} /
Bean.java snippet:
public Object getValue() {
throw new NullPointerException();
}
Custom exception handler code:
if (PhaseId.RENDER_RESPONSE.equals(currentPhaseId)) {
try {
nav.handleNavigation(facesContext,
null, /ErrorPage.xhtml?faces-redirect=true);
} finally {
i.remove();
}
}
Modify view and exception handler to achieve following combinations (HTML
request = comment out f:ajax, forward = remove ?faces-redirect=true)
1) HTML request + forward: nothing in log, and malformed output is produced
(no closing tags for /body etc.)
2) HTML request + redirect: OK , redirect to ErrorPage.xhtml is done
3) AJAX request + forward: exception in log, bud no forward to ErrorPage
performed
4) AJAX request + redirect: exception in log, malformed XML produced (?xml
and partial-response 2x in output) , no redirect performed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3199) Handling AbortProcessingException is unconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228542#comment-13228542
]
Leonardo Uribe commented on MYFACES-3199:
-
I see. I can't remember one example, but I suppose a custom implementation of
javax.faces.view.facelets.MetaRule can inject that. So there is justification
for that check.
Handling AbortProcessingException is unconsistent
-
Key: MYFACES-3199
URL: https://issues.apache.org/jira/browse/MYFACES-3199
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Environment: myface core trunk
Reporter: Martin Kočí
Assignee: Leonardo Uribe
Fix For: 2.0.9, 2.1.3
Attachments: MYFACES-3199-v2.patch, UIViewRoot.patch
UIViewRoot:
try {
source.broadcast(event);
}
catch (AbortProcessingException e)
{
ExceptionQueuedEventContext exceptionContext
= new ExceptionQueuedEventContext(context, e, source,
context.getCurrentPhaseId());
context.getApplication().publishEvent(context,
ExceptionQueuedEvent.class, exceptionContext);
// Abortion
return false;
}
Problem 1:
h:inputText valueChangeListener=#{bean.processValueChange}
MethodExpressionValueChangeListener wraps all exceptions to
AbortProcessingException and therefore exception is queued
Problem 2:
h:inputText
f:valueChangeListener binding=#{bean} /
/h:inputText
ValueChangeListenerHandler does not wrap exception to
AbortProcessingException and therefore exception is not queued in this block
(but it is queued from phase executor but without component info)
Problem 3: JSF spec 2.1 :
Clarification made: throwing an AbortProcessingException tells an
implementation that no further broadcast of the
current event occurs. Does not affect future events.
But I think that code in UIViewRoot makes opposite: // Abortion return
false;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3497) [perf] Improve EventHandler
[ https://issues.apache.org/jira/browse/MYFACES-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228577#comment-13228577 ] Leonardo Uribe commented on MYFACES-3497: - * created methodExpressions are already cached at TagAttributeImpl. No need to do something additional in this part * it is reasonable to cache that result, because once calculated it will not change. * Suggestions are welcome. Note the same trick is used in other places like javax.faces.event.MethodExpressionActionListener. Checking this one, I notice in EL 2.2 there exists a new method called boolean isParmetersProvided() (the spell bug is intentional). [perf] Improve EventHandler --- Key: MYFACES-3497 URL: https://issues.apache.org/jira/browse/MYFACES-3497 Project: MyFaces Core Issue Type: Improvement Reporter: Martin Kočí Priority: Minor org.apache.myfaces.view.facelets.tag.jsf.core.EventHandler * cache created MethodExpressions (same as in MYFACES-3160) * if f:event type= is literal, cache resulting class * review implementation of EventHandler.Listener.processEvent(ComponentSystemEvent): uses void El method invocation to detect if method exists - spec requires this but maybe better solution exists * -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3199) Handling AbortProcessingException is unconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228640#comment-13228640
]
Leonardo Uribe commented on MYFACES-3199:
-
Yes, sounds reasonable unify in this part, so all APE cases can be handled as
expected in custom ExceptionHandler implementations. I updated the code to
include the changes proposed on the second patch. Thanks for the fix.
Handling AbortProcessingException is unconsistent
-
Key: MYFACES-3199
URL: https://issues.apache.org/jira/browse/MYFACES-3199
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Environment: myface core trunk
Reporter: Martin Kočí
Assignee: Leonardo Uribe
Fix For: 2.0.9, 2.0.13, 2.1.3, 2.1.7
Attachments: MYFACES-3199-v2.patch, UIViewRoot.patch
UIViewRoot:
try {
source.broadcast(event);
}
catch (AbortProcessingException e)
{
ExceptionQueuedEventContext exceptionContext
= new ExceptionQueuedEventContext(context, e, source,
context.getCurrentPhaseId());
context.getApplication().publishEvent(context,
ExceptionQueuedEvent.class, exceptionContext);
// Abortion
return false;
}
Problem 1:
h:inputText valueChangeListener=#{bean.processValueChange}
MethodExpressionValueChangeListener wraps all exceptions to
AbortProcessingException and therefore exception is queued
Problem 2:
h:inputText
f:valueChangeListener binding=#{bean} /
/h:inputText
ValueChangeListenerHandler does not wrap exception to
AbortProcessingException and therefore exception is not queued in this block
(but it is queued from phase executor but without component info)
Problem 3: JSF spec 2.1 :
Clarification made: throwing an AbortProcessingException tells an
implementation that no further broadcast of the
current event occurs. Does not affect future events.
But I think that code in UIViewRoot makes opposite: // Abortion return
false;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3493) Cache info about non-existant resources in org.apache.myfaces.application.ResourceHandlerImpl.createResource()
[ https://issues.apache.org/jira/browse/MYFACES-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228069#comment-13228069 ] Leonardo Uribe commented on MYFACES-3493: - Interesting. One question, are you using f:validateBean in wrap mode?: f:validateBean ... . /f:validateBean I think in this case the cache should be added in TagLibraryConfig, instead add it on ResourceHandler. Cache info about non-existant resources in org.apache.myfaces.application.ResourceHandlerImpl.createResource() -- Key: MYFACES-3493 URL: https://issues.apache.org/jira/browse/MYFACES-3493 Project: MyFaces Core Issue Type: Improvement Components: Extension Feature Affects Versions: 2.1.6 Environment: Linux FC15 Reporter: Dmitry Kukushkin The existent resources are cached in the public Resource createResource(String resourceName, String libraryName, String contentType) method, which is good, but the information about resources, which are not existent ( deriveResourceMeta(loader, resourceName, libraryName, localePrefix) returned null ) is not cached. Thus at the next requests for the same resource the same resource lookup operations will happen, which may be expensive. In my case, for example (Tomcat + Spring + MyFaces + Tomahawk), for every html tag, lookup on the file system and in all classpaths (including ~30 jars) is performed (and failing), which de-gradates response time by factor of 25! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3493) Cache info about non-existant resources in org.apache.myfaces.application.ResourceHandlerImpl.createResource()
[ https://issues.apache.org/jira/browse/MYFACES-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228150#comment-13228150 ] Leonardo Uribe commented on MYFACES-3493: - I found the source of the problem in MYFACES-3208, which was fixed in 2.1.2 / 2.0.8. Please update your myfaces version to 2.1.6 or 2.0.12. I checked and a cache in that location is not necessary. I think we can close this issue as won't fix, because the problem was MYFACES-3208, which was already fixed. Cache info about non-existant resources in org.apache.myfaces.application.ResourceHandlerImpl.createResource() -- Key: MYFACES-3493 URL: https://issues.apache.org/jira/browse/MYFACES-3493 Project: MyFaces Core Issue Type: Improvement Components: Extension Feature Affects Versions: 2.1.6 Environment: Linux FC15 Reporter: Dmitry Kukushkin The existent resources are cached in the public Resource createResource(String resourceName, String libraryName, String contentType) method, which is good, but the information about resources, which are not existent ( deriveResourceMeta(loader, resourceName, libraryName, localePrefix) returned null ) is not cached. Thus at the next requests for the same resource the same resource lookup operations will happen, which may be expensive. In my case, for example (Tomcat + Spring + MyFaces + Tomahawk), for every html tag, lookup on the file system and in all classpaths (including ~30 jars) is performed (and failing), which de-gradates response time by factor of 25! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3493) Cache info about non-existant resources in org.apache.myfaces.application.ResourceHandlerImpl.createResource()
[ https://issues.apache.org/jira/browse/MYFACES-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226189#comment-13226189 ] Leonardo Uribe commented on MYFACES-3493: - This modification is questionable. In theory, the components will always register resources that exists. Use the same cache used to save information related to Resource classes doesn't sound good, because asking for non existent resources it is possible to clean that cache, and that is not the idea. Instead, it is responsibility of the ResourceLoader implementation to minimize the associated overhead. In this case, the cache should be implemented in org.apache.myfaces.shared.resource.ClassLoaderResourceLoader. Anyway, it seems something more related to your particular environment, and not something to solve from MyFaces side. I suggest to create a custom ResourceHandler implementation, reusing the api provided by MyFaces into its shared package. Suggestions are welcome. Cache info about non-existant resources in org.apache.myfaces.application.ResourceHandlerImpl.createResource() -- Key: MYFACES-3493 URL: https://issues.apache.org/jira/browse/MYFACES-3493 Project: MyFaces Core Issue Type: Improvement Components: Extension Feature Affects Versions: 2.1.6 Environment: Linux FC15 Reporter: Dmitry Kukushkin The existent resources are cached in the public Resource createResource(String resourceName, String libraryName, String contentType) method, which is good, but the information about resources, which are not existent ( deriveResourceMeta(loader, resourceName, libraryName, localePrefix) returned null ) is not cached. Thus at the next requests for the same resource the same resource lookup operations will happen, which may be expensive. In my case, for example (Tomcat + Spring + MyFaces + Tomahawk), for every html tag, lookup on the file system and in all classpaths (including ~30 jars) is performed (and failing), which de-gradates response time by factor of 25! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3199) Handling AbortProcessingException is unconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226234#comment-13226234
]
Leonardo Uribe commented on MYFACES-3199:
-
Ok, now I get it.
MK Problem1 : UIViewRoot._broadcastAll queues APE into ExceptionQueuedEvent
and
MK check for any of the causes of the exception are an APE is missing in
code
The check is done in the wrappers. See
javax.faces.event.MethodExpressionActionListener,
javax.faces.event.MethodExpressionValueChangeListener. I think an additional
check on UIViewRoot is not necessary.
MK ad Problem 2) queuing the source component is required to solve the mail
goal
MK of MYFACES-3053: any time there is an error in *any* part of the
MK lifecycle, the user should see not just a cryptic stack trace, but also the
MK **component** - including file and line number - that triggered the
problem
The patch has some side effects. UIViewRoot._process(FacesContext context,
PhaseId phaseId, PhaseProcessor processor) as a try {} catch block for
RuntimeExceptions, to execute afterPhase listeners and then rethrow the
exception. Later, on LifecycleImpl the exception is catched and finally
published as an EventQueuedException.
In few words, the change proposed here is just publish EventQueuedException for
non APE exceptions in UIViewRoot._broadcastAll too, but preserve the effect of
stop broadcasting when a non APE exception is received.
If you provide a patch removing the check for nested APE, and if no objections
I'll review it and commit it.
Handling AbortProcessingException is unconsistent
-
Key: MYFACES-3199
URL: https://issues.apache.org/jira/browse/MYFACES-3199
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Environment: myface core trunk
Reporter: Martin Kočí
Assignee: Leonardo Uribe
Fix For: 2.0.9, 2.1.3
Attachments: UIViewRoot.patch
UIViewRoot:
try {
source.broadcast(event);
}
catch (AbortProcessingException e)
{
ExceptionQueuedEventContext exceptionContext
= new ExceptionQueuedEventContext(context, e, source,
context.getCurrentPhaseId());
context.getApplication().publishEvent(context,
ExceptionQueuedEvent.class, exceptionContext);
// Abortion
return false;
}
Problem 1:
h:inputText valueChangeListener=#{bean.processValueChange}
MethodExpressionValueChangeListener wraps all exceptions to
AbortProcessingException and therefore exception is queued
Problem 2:
h:inputText
f:valueChangeListener binding=#{bean} /
/h:inputText
ValueChangeListenerHandler does not wrap exception to
AbortProcessingException and therefore exception is not queued in this block
(but it is queued from phase executor but without component info)
Problem 3: JSF spec 2.1 :
Clarification made: throwing an AbortProcessingException tells an
implementation that no further broadcast of the
current event occurs. Does not affect future events.
But I think that code in UIViewRoot makes opposite: // Abortion return
false;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3496) Unify myfaces archetypes and update to use jetty 8
[ https://issues.apache.org/jira/browse/MYFACES-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226500#comment-13226500 ] Leonardo Uribe commented on MYFACES-3496: - Changes committed on: myfaces-archetype-codi-jsf20 myfaces-archetype-helloworld20 myfaces-archetype-helloworld20-debug myfaces-archetype-helloworld20-owb myfaces-archetype-jsfcomponents20 myfaces-archetype-trinidad20 (update to 2.0.1) Suggestions are welcome. Unify myfaces archetypes and update to use jetty 8 -- Key: MYFACES-3496 URL: https://issues.apache.org/jira/browse/MYFACES-3496 Project: MyFaces Core Issue Type: Improvement Components: Archetype Reporter: Leonardo Uribe Assignee: Leonardo Uribe Jetty 8 maven plugin is out and since people is using JSF2 / EL 2.2 / Servlet 3.0 , it could be good to use that plugin for all our JSF 2 archetypes. Also, I would like to contribute with a maven archetype I use frequently to debug myfaces stuff. It has some profile configurations that makes easier test myfaces in some situations, and also use some utilities used to create junit tests inside myfaces core. For example, it has a test case that checks if a xhtml can be recognized by facelets compiler. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3491) Unable to use direct char[] access of java.lang.String error on appengine
[ https://issues.apache.org/jira/browse/MYFACES-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225225#comment-13225225 ] Leonardo Uribe commented on MYFACES-3491: - Changed default to false. That code comes from grails StreamCharBuffer, that was adapted to use into MyFaces Unable to use direct char[] access of java.lang.String error on appengine - Key: MYFACES-3491 URL: https://issues.apache.org/jira/browse/MYFACES-3491 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: appengine Reporter: lucio piccoli Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 hi all i am getting the following error when running on appengine. Unable to use direct char[] access of java.lang.String i found some src code that alowed for onfiguration of the the chararray access. http://svn.apache.org/repos/asf/myfaces/core/trunk/shared/src/main/java/org/apache/myfaces/shared/util/StringCharArrayAccessor.java it uses a poperty to disable using the char access. static volatile boolean enabled = !Boolean .getBoolean(oam.stringchararrayaccessor.disabled); where is this property set? it is not documented anywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3199) Handling AbortProcessingException is unconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224938#comment-13224938
]
Leonardo Uribe commented on MYFACES-3199:
-
I think this should be discussed on the Expert Group. The changes done in
myfaces is just an interpretation of the spec, in order to preserve
consistency. For example, if an ActionListener is added using f:actionListener
or using h:commandXXX actionListener=.../, the same behavior should be seen
by the user and so on.
It is very difficult to analyze this problem without concrete examples
demostrating why the code should be changed. I know there are parts that can be
improved but the changes we can do are limited with the current descriptions on
the spec. If no objections I'll close again this issue, because no further
advance can be done from MyFaces side.
Handling AbortProcessingException is unconsistent
-
Key: MYFACES-3199
URL: https://issues.apache.org/jira/browse/MYFACES-3199
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Environment: myface core trunk
Reporter: Martin Kočí
Assignee: Leonardo Uribe
Fix For: 2.0.9, 2.1.3
UIViewRoot:
try {
source.broadcast(event);
}
catch (AbortProcessingException e)
{
ExceptionQueuedEventContext exceptionContext
= new ExceptionQueuedEventContext(context, e, source,
context.getCurrentPhaseId());
context.getApplication().publishEvent(context,
ExceptionQueuedEvent.class, exceptionContext);
// Abortion
return false;
}
Problem 1:
h:inputText valueChangeListener=#{bean.processValueChange}
MethodExpressionValueChangeListener wraps all exceptions to
AbortProcessingException and therefore exception is queued
Problem 2:
h:inputText
f:valueChangeListener binding=#{bean} /
/h:inputText
ValueChangeListenerHandler does not wrap exception to
AbortProcessingException and therefore exception is not queued in this block
(but it is queued from phase executor but without component info)
Problem 3: JSF spec 2.1 :
Clarification made: throwing an AbortProcessingException tells an
implementation that no further broadcast of the
current event occurs. Does not affect future events.
But I think that code in UIViewRoot makes opposite: // Abortion return
false;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3488) [perf] store facelets MARK_CREATED and rendererType at UIComponentBase level
[ https://issues.apache.org/jira/browse/MYFACES-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223376#comment-13223376 ] Leonardo Uribe commented on MYFACES-3488: - The idea with that check lenght first is prevent an unnecessary cast. The number comparison is cheaper compared with the cast, so it is ok to let it as is. [perf] store facelets MARK_CREATED and rendererType at UIComponentBase level Key: MYFACES-3488 URL: https://issues.apache.org/jira/browse/MYFACES-3488 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Inspired on the suggestions done in MYFACES-3470 and MYFACES-3471, I have found a solution for both cases. MARK_CREATED and rendererType are special properties. Both are more related to the real UIComponent instance, which means those properties does not change for components inside a table (h:dataTable rowStatePreserved=true). In the case of MARK_CREATED, almost all components created by facelets uses it, and this is assigned when the view is built. It has only sense to save this value when the component needs to be restored fully, but since this is a property that does not change once created, it does not have sense to store it on the delta. In the case of rendererType, the same as MARK_CREATED happens, but by the spec, it could be valid to set a ValueExpression for it and it is feasible to create a component, call markInitialState() and then call setRendererType(...), so this value could be saved on the delta. Components that are created without properties (for example h:panelGroup) only require these two properties, so storing these values at UIComponentBase it is possible to prevent create unnecessary Map.Entry instances. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent
[ https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223439#comment-13223439 ] Leonardo Uribe commented on MYFACES-3435: - I have checked again the patch and I founded some inconsistencies in FacetHashMap that were fixed in _ComponentFacetMap some time ago (implement fully Set interface for entrySet(), keySet() and valuesSet() ). Here is when delegation pattern shines. It is possible to use ArrayMap instead HashMap and improve performance in one step. If we use inheritance, I don't want to imagine the work required to fix this. I'm still thinking we can do other improvements (adjust structures sizes, cache some variables in some parts, ... ) and get bigger improvements without sacrify the code structure. In other words, there are other parts of the code that generate a lot more objects that this place. Anyway, I splitted the patch in two and I applied it partially, adjusting the structure's size and replacing HashMap with ArrayMap for facets. The other part of the patch (MYFACES-3435-7.patch) was attached here if in the future we came back to this point again. I'll let this issue open, but for now that's all I'm going to do for the next release cycle. [perf] _DeltaList: use ArrayList as parent -- Key: MYFACES-3435 URL: https://issues.apache.org/jira/browse/MYFACES-3435 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3435-2.patch, MYFACES-3435-7.patch, MYFACES-3435.patch, _ComponentChildrenList2.java Two internal classes _DeltaList in API: 1) now use delegation pattern, but are always initialized with an ArrayList instance - use inheritance and ArrayList as parent - improvement in memory area, reduces number of GCed object in one request/response of (_DeltaList instances/2) 2) initialize expected size of _DeltaList (for example, number of validators per one component is perhaps never 10, use: new _DeltaList(5)) 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) - improvement in performance -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3136) [perf] review UIComponentBase.getRendererType
[ https://issues.apache.org/jira/browse/MYFACES-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223452#comment-13223452 ] Leonardo Uribe commented on MYFACES-3136: - fixed as part of MYFACES-3488 [perf] review UIComponentBase.getRendererType -- Key: MYFACES-3136 URL: https://issues.apache.org/jira/browse/MYFACES-3136 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.1.0-SNAPSHOT Environment: myfaces core trunk Reporter: Martin Kočí Assignee: Leonardo Uribe Priority: Minor Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3136.patch 1) method UIComponentBase.getRendererType is the most frequent, because all encodeBegin, getRendersChildren and encodeAll l try to locate renderer 2) getRendererType uses StateHelper.eval - but can be renderType ValueExpression? If not, change StateHelper.eval to StateHelper.get 3) should rendererType even be part of state saving? Each component I've ever seen has setRendererType(com.foo.renderer) in constructor and/or VDL calls setRendererType() after calling Application.createComponent(): If rendererType is not part of state saving, replace StateHelper with attribute 4) Cache getRenderer(FacesContext context) result anyway (I'll create separate issue for this) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3144) [PERF] Cache renderer in UIComponentBase
[ https://issues.apache.org/jira/browse/MYFACES-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223467#comment-13223467 ] Leonardo Uribe commented on MYFACES-3144: - Thinking about it, I found an alternative solution for this problem. The idea is create two vars in UIComponentBase: private transient Boolean _cachedIsRendered; private transient Renderer _cachedRenderer; copy the code from UIComponent.encodeAll() to UIComponentBase. Then, do the same trick for cache FacesContext, but on encodeAll(). The idea is set _cachedRendered and _cachedIsRendered at the beginning and then clear this variables before end the method. Then, some code is added in isRendered() and getRenderer() to check for the cached var and if is set, return that value. In this way we have control about the cached var. If by some reason encodeXXX() is called instead encodeAll(), the code will work as expected. The same thing can be done in decode() method, but in this case only for _cachedRendered, preventing a second call when getClientId() is called. In this way we can save between 6 and 8 lookups to a map. isRendered() is called only once per component, which is valid because this value does not change while encoding of the same component occur. Also, it preserves getRenderer() plugability, because it is possible to change the renderKit before render response time and reflect the change. [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čí Attachments: MYFACES-3144.patch 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3150) [perf] buildView: review usage of facelets.FACET_NAME
[ https://issues.apache.org/jira/browse/MYFACES-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223942#comment-13223942 ] Leonardo Uribe commented on MYFACES-3150: - Unfortunately the patch will not work, because there is an association between the parent component and the facet name, and then a check for a facet name is used to decide if the component is added as a child or as a facet child. With a stack, that connection get lost and at the end the tree will not be built correctly. [perf] buildView: review usage of facelets.FACET_NAME --- Key: MYFACES-3150 URL: https://issues.apache.org/jira/browse/MYFACES-3150 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.1.0-SNAPSHOT Environment: myfaces core trunk Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3150-v1.patch Consider 1000 components in view without any f:facet. During VDL.buildView Facelets call for each component ComponentHandler.getFacetName(FaceletContext, UIComponent) and that creates 3 calls of Map.get(): 1) _ComponentAttributesMap.getPropertyDescriptor(String) 2) _ComponentAttributesMap.getUnderlyingMap().get() 3) UIComponent.getValueExpression(String) 3000 empty invocations in buildView withnout match. Suggestions: * do not use Component.attribute for that marker (comes from FacetHandler) * replace map.get calls with property for performance reasons * use a stack or property on AbstractFaceletContext if possible -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3481) [perf] f:validateBean re-creates facelets handlers (MetaRulesetImpl,DelegatingMetaTagHandler ...) for children every time
[ https://issues.apache.org/jira/browse/MYFACES-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217564#comment-13217564 ] Leonardo Uribe commented on MYFACES-3481: - I see. This is different to the previous one fixed, and is caused by this call. _delegate.getValidatorConfig().getNextHandler().apply(ctx, parent); Tracking down this problem, it came from MYFACES-2512. In that time, we tried to implement the disabled logic into ValidatorTagHandlerDelegate, but after some tests cycles, we found that the right thing to do is move that logic into ComponentTagHandlerDelegate. Later, to solve validationGroups problem, another strategy was implemented, so we commented the old code, but this line was let without change. The solution is just use: _delegate.applyNextHandler(ctx, parent); Instead. The problem described on MYFACES-2512 will not happen, because all that code was changed in MYFACES-3259 with a better alternative. [perf] f:validateBean re-creates facelets handlers (MetaRulesetImpl,DelegatingMetaTagHandler ...) for children every time - Key: MYFACES-3481 URL: https://issues.apache.org/jira/browse/MYFACES-3481 Project: MyFaces Core Issue Type: Improvement Reporter: Martin Kočí Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 myfaces in Production stage: f:validateBean h:outputLabelmyfaces/h:outputLabel /f:validateBean (or book.xhtml in myfaces-jpa test app) In every request/response, this invocation appears: MetaRulesetImpl.init(Tag, Class?) line: 118 ComponentTagHandlerDelegate.createMetaRuleset(Class) line: 459 HtmlComponentHandler(DelegatingMetaTagHandler).createMetaRuleset(Class) line: 102 HtmlComponentHandler.createMetaRuleset(Class) line: 42 HtmlComponentHandler(MetaTagHandler).setAttributes(FaceletContext, Object) line: 63 HtmlComponentHandler(DelegatingMetaTagHandler).setAttributes(FaceletContext, Object) line: 93 ComponentTagHandlerDelegate.apply(FaceletContext, UIComponent) line: 235 HtmlComponentHandler(DelegatingMetaTagHandler).apply(FaceletContext, UIComponent) line: 53 ValidatorTagHandlerDelegate.apply(FaceletContext, UIComponent) line: 152 ValidatorHandler(DelegatingMetaTagHandler).apply(FaceletContext, UIComponent) line: 53 this applies for all children of f:validateBean Without f:validateBean Metatag rules are created only once in production stage during initial request to facelet. (Not sure if it is a bug - maybe something special needs to be done for f:beanValidator ) It also leads to stack bellow - but _getFactory method is synchronized and slow down response times to the same facelet: FactoryFinder._getFactory(String) line: 259 FactoryFinder.getFactory(String) line: 206 ConvertNumberHandler(DelegatingMetaTagHandler).init(TagConfig) line: 42 ConvertNumberHandler(FaceletsAttachedObjectHandler).init(TagConfig) line: 42 ConvertNumberHandler(ConverterHandler).init(ConverterConfig) line: 44 ConvertNumberHandler.init(ConverterConfig) line: 57 NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not available [native method] NativeConstructorAccessorImpl.newInstance(Object[]) line: 39 DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 ConstructorT.newInstance(Object...) line: 513 AbstractTagLibrary$UserConverterHandlerFactory.createHandler(TagConfig) line: 593 CoreLibrary(AbstractTagLibrary).createTagHandler(String, String, TagConfig) line: 98 CompositeTagLibrary.createTagHandler(String, String, TagConfig) line: 93 TagUnit.createFaceletHandler() line: 56 TextUnit.createFaceletHandler() line: 104 TagUnit(CompilationUnit).getNextFaceletHandler() line: 82 TagUnit.getNextHandler() line: 61 AbstractTagLibrary$ComponentConfigWrapper.getNextHandler() line: 431 HtmlComponentHandler(TagHandler).init(TagConfig) line: 39 HtmlComponentHandler(MetaTagHandler).init(TagConfig) line: 35 HtmlComponentHandler(DelegatingMetaTagHandler).init(TagConfig) line: 40 HtmlComponentHandler(ComponentHandler).init(ComponentConfig) line: 37 HtmlComponentHandler.init(ComponentConfig) line: 37 GeneratedConstructorAccessor17.newInstance(Object[]) line: not available DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 ConstructorT.newInstance(Object...) line: 513 AbstractTagLibrary$UserComponentHandlerFactory.createHandler(TagConfig) line: 519 HtmlLibrary(AbstractTagLibrary).createTagHandler(String, String, TagConfig) line: 98 CompositeTagLibrary.createTagHandler(String,
[jira] [Commented] (MYFACES-3459) RegexValidator does not provide label and pattern for first usage of RegexValidator.NOT_MATCHED
[
https://issues.apache.org/jira/browse/MYFACES-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217568#comment-13217568
]
Leonardo Uribe commented on MYFACES-3459:
-
Of course, I have already committed it. Thanks for your help and for remind me
that.
RegexValidator does not provide label and pattern for first usage of
RegexValidator.NOT_MATCHED
---
Key: MYFACES-3459
URL: https://issues.apache.org/jira/browse/MYFACES-3459
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.5
Environment: myfaces trunk
Reporter: Martin Kočí
Assignee: Martin Kočí
Priority: Trivial
Attachments: MYFACES-3459.patch, myfaces-1244836.patch
RegexValidator uses javax.faces.validator.RegexValidator.NOT_MATCHED 2x:
javax.faces.validator.RegexValidator.NOT_MATCHED= the passed value is not a
String, or when the pattern does not match the passed value.
the first usage for if (value instanceof String) check does not provide
args for {0} {1} in message.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3481) [perf] f:validateBean re-creates facelets handlers (MetaRulesetImpl,DelegatingMetaTagHandler ...) for children every time
[ https://issues.apache.org/jira/browse/MYFACES-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217017#comment-13217017 ] Leonardo Uribe commented on MYFACES-3481: - It is not a but, instead it is an improvement. In theory, base tag handler classes should cache TagHandlerDelegate instance, but it seems we forgot to do the same for javax.faces.view.facelets.ValidatorHandler, ConverterHandler and BehaviorHandler. Since f:validateBean has wrap mode, the effect is visible. The fix is very simple. Thanks for notice it. [perf] f:validateBean re-creates facelets handlers (MetaRulesetImpl,DelegatingMetaTagHandler ...) for children every time - Key: MYFACES-3481 URL: https://issues.apache.org/jira/browse/MYFACES-3481 Project: MyFaces Core Issue Type: Improvement Reporter: Martin Kočí Fix For: 2.0.13, 2.1.7 myfaces in Production stage: f:validateBean h:outputLabelmyfaces/h:outputLabel /f:validateBean (or book.xhtml in myfaces-jpa test app) In every request/response, this invocation appears: MetaRulesetImpl.init(Tag, Class?) line: 118 ComponentTagHandlerDelegate.createMetaRuleset(Class) line: 459 HtmlComponentHandler(DelegatingMetaTagHandler).createMetaRuleset(Class) line: 102 HtmlComponentHandler.createMetaRuleset(Class) line: 42 HtmlComponentHandler(MetaTagHandler).setAttributes(FaceletContext, Object) line: 63 HtmlComponentHandler(DelegatingMetaTagHandler).setAttributes(FaceletContext, Object) line: 93 ComponentTagHandlerDelegate.apply(FaceletContext, UIComponent) line: 235 HtmlComponentHandler(DelegatingMetaTagHandler).apply(FaceletContext, UIComponent) line: 53 ValidatorTagHandlerDelegate.apply(FaceletContext, UIComponent) line: 152 ValidatorHandler(DelegatingMetaTagHandler).apply(FaceletContext, UIComponent) line: 53 this applies for all children of f:validateBean Without f:validateBean Metatag rules are created only once in production stage during initial request to facelet. (Not sure if it is a bug - maybe something special needs to be done for f:beanValidator ) It also leads to stack bellow - but _getFactory method is synchronized and slow down response times to the same facelet: FactoryFinder._getFactory(String) line: 259 FactoryFinder.getFactory(String) line: 206 ConvertNumberHandler(DelegatingMetaTagHandler).init(TagConfig) line: 42 ConvertNumberHandler(FaceletsAttachedObjectHandler).init(TagConfig) line: 42 ConvertNumberHandler(ConverterHandler).init(ConverterConfig) line: 44 ConvertNumberHandler.init(ConverterConfig) line: 57 NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not available [native method] NativeConstructorAccessorImpl.newInstance(Object[]) line: 39 DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 ConstructorT.newInstance(Object...) line: 513 AbstractTagLibrary$UserConverterHandlerFactory.createHandler(TagConfig) line: 593 CoreLibrary(AbstractTagLibrary).createTagHandler(String, String, TagConfig) line: 98 CompositeTagLibrary.createTagHandler(String, String, TagConfig) line: 93 TagUnit.createFaceletHandler() line: 56 TextUnit.createFaceletHandler() line: 104 TagUnit(CompilationUnit).getNextFaceletHandler() line: 82 TagUnit.getNextHandler() line: 61 AbstractTagLibrary$ComponentConfigWrapper.getNextHandler() line: 431 HtmlComponentHandler(TagHandler).init(TagConfig) line: 39 HtmlComponentHandler(MetaTagHandler).init(TagConfig) line: 35 HtmlComponentHandler(DelegatingMetaTagHandler).init(TagConfig) line: 40 HtmlComponentHandler(ComponentHandler).init(ComponentConfig) line: 37 HtmlComponentHandler.init(ComponentConfig) line: 37 GeneratedConstructorAccessor17.newInstance(Object[]) line: not available DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 ConstructorT.newInstance(Object...) line: 513 AbstractTagLibrary$UserComponentHandlerFactory.createHandler(TagConfig) line: 519 HtmlLibrary(AbstractTagLibrary).createTagHandler(String, String, TagConfig) line: 98 CompositeTagLibrary.createTagHandler(String, String, TagConfig) line: 93 TagUnit.createFaceletHandler() line: 56 TextUnit.createFaceletHandler() line: 104 TagUnit(CompilationUnit).getNextFaceletHandler() line: 82 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see:
[jira] [Commented] (MYFACES-3474) [perf] LifecycleProviderFactory does not cache created Factory
[ https://issues.apache.org/jira/browse/MYFACES-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216488#comment-13216488 ] Leonardo Uribe commented on MYFACES-3474: - I have to say it: Martin, you have found a very, very, very insteresting thing. I tried it and you are right. This few lines has a huge impact on performance. I reviewed all other SPI interfaces and does not have the problem, so it was just this class. Some months ago I detected a problem in this area, but instead check this class I optimize LifecycleProvider related interfaces, so I skipped this part. This finding is just great!. I agree maybe this issue has something to do with the slow response time. Thanks a lot for the patch. This is a very valuable contribution. [perf] LifecycleProviderFactory does not cache created Factory -- Key: MYFACES-3474 URL: https://issues.apache.org/jira/browse/MYFACES-3474 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.12, 2.1.6 Reporter: Martin Kočí Assignee: Martin Kočí Fix For: 1.2.12, 2.0.13, 2.1.7 Attachments: MYFACES-3474.patch It seems that org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(FacesContext, ManagedBean) tries to locale implementation of a interface, but the instance found is never stored in application map: see code in org.apache.myfaces.config.annotation.LifecycleProviderFactory.getLifecycleProviderFactory(ExternalContext) this lead to Webappclassloader.loadClass invocation, which is sychronized and accesses disk. Can significantly affect perfomance of myfaces app with managed-bean in multithreaded environment. maybe reason for http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/ ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3463) Refactor UIRepeat code to implement PSS algorithm like UIData and fix state behavior
[ https://issues.apache.org/jira/browse/MYFACES-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211632#comment-13211632 ] Leonardo Uribe commented on MYFACES-3463: - I reviewed the code and created a patch, taking what's necessary from UIData. At the end the code has two differences: - State for rows (rowState) was saved into the state. This is not necessary because the information for EditableValueHolder is usually send to the client and then go back to the server. UIData do that and there is no reason why UIRepeat cannot do it. - The condition for reset model if a validation occur is based only on the messages related to components in UIRepeat. In UIData, the condition is different. To solve MYFACES-3415 it is preferred to do the same as UIData does. Anyway, this should be discussed on the EG, because the condition is not very clear and there is other issue (MYFACES-3326) that suggest this condition should be enhanced. If no objections I'll commit the code soon (on 2.0.x and 2.1.x branches) Refactor UIRepeat code to implement PSS algorithm like UIData and fix state behavior Key: MYFACES-3463 URL: https://issues.apache.org/jira/browse/MYFACES-3463 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.12, 2.1.6 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-3463-1.patch Right now, the code in org.apache.myfaces.view.facelets.component.UIRepeat has not been reviewed more than to fix issues related to JSF 2 spec. It works, but it can be done better. The code has the following opportunities: - Implement PSS algorithm, to prevent store data in the state. - The algorithm used in UIData to handle state is better. - Fix MYFACES-3415 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3459) RegexValidator does not provide label and pattern for first usage of RegexValidator.NOT_MATCHED
[
https://issues.apache.org/jira/browse/MYFACES-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13208578#comment-13208578
]
Leonardo Uribe commented on MYFACES-3459:
-
Added messages for en, es and de languages. I'm not sure about change how this
validator works, because any change in behavior must be done at spec level.
RegexValidator does not provide label and pattern for first usage of
RegexValidator.NOT_MATCHED
---
Key: MYFACES-3459
URL: https://issues.apache.org/jira/browse/MYFACES-3459
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.5
Environment: myfaces trunk
Reporter: Martin Kočí
Assignee: Martin Kočí
Priority: Trivial
RegexValidator uses javax.faces.validator.RegexValidator.NOT_MATCHED 2x:
javax.faces.validator.RegexValidator.NOT_MATCHED= the passed value is not a
String, or when the pattern does not match the passed value.
the first usage for if (value instanceof String) check does not provide
args for {0} {1} in message.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3383) Self nested Composite Component leads to EL Stack Overflow
[ https://issues.apache.org/jira/browse/MYFACES-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13207956#comment-13207956 ] Leonardo Uribe commented on MYFACES-3383: - I reviewed this issue again, trying to do something over LocationValueExpression. The idea was store the current nesting level where the ValueExpression was created related to the current composite component. It works, but it has some side effects like make EL expressions context dependant which evidence the initial problem. In few words, once the component tree is created by facelets engine, the page context get lost. What we really need is some way to preserve the page context, not tweak LocationValueExpression. Anyway, do that seems to be very difficult and inconvenient, because you need to store such relationship in the EL expression and the resulting design can be broken easily if the component is relocated or manipulated in some way. Self nested Composite Component leads to EL Stack Overflow -- Key: MYFACES-3383 URL: https://issues.apache.org/jira/browse/MYFACES-3383 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2 Environment: Windows Reporter: Michael Dietrich Attachments: TestStackOverflow.war If the same Composite Component is used inside itself, e.g. as child of an ui:include that is included in the Composite Component, an StackOverflow happens, if an EL Expression is refering CC interface attributes. The use case is a CC to include a facelet, given by name. If the included facelet uses the same CC to include another facelet, CompositeComponentELUtils.getCompositeComponentBasedOnLocation(..) does always find the same CC, which leads to an endless loop. Please see the attached file for an example of the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3464) Using Myfaces 2.1.6 does not allow to using a user provided EL (e.g. jBoss-el) other than what is provided by container when used with Webesphere 7 .
[
https://issues.apache.org/jira/browse/MYFACES-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13208158#comment-13208158
]
Leonardo Uribe commented on MYFACES-3464:
-
The problem is simple. The check just do a Class.forName:
try
{
// Check if the UEL classes are available.
// If the JSP EL classes are loaded first, UEL will not work
// properly, hence it will be disabled.
unifiedELAvailable = (
Class.forName(javax.el.ValueReference) != null
Class.forName(javax.el.ValueExpression)
.getMethod(getValueReference,
ELContext.class) != null
);
}
catch (Throwable t)
{
log.log(Level.FINE, Error loading class (could be normal), t);
unifiedELAvailable = false;
}
log.info(MyFaces Unified EL support + (unifiedELAvailable ?
enabled : disabled));
If the check fails UEL will not work, no matter how it looks (how to enable it
if javax.el.ValueReference is not on the classpath?) . The only way to fix it
is remove JSP EL classes from the classpath. Add a param to put MyFaces in a
state that could be illegal sounds bad. The problem is in Websphere, MyFaces is
not doing anything wrong in this part.
Using Myfaces 2.1.6 does not allow to using a user provided EL (e.g.
jBoss-el) other than what is provided by container when used with Webesphere
7 .
-
Key: MYFACES-3464
URL: https://issues.apache.org/jira/browse/MYFACES-3464
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.6
Environment: Websphere 7.0.0.17
JSF 2
Reporter: Shahzeb Khan
Assignee: Leonardo Uribe
There seems to be no way to use an EL other than what is provided by
Websphere (have not checked with any other server).
We are using JSF 2 via isolated shared library with Websphere version
7.0.0.17. Trying to use jBoss-el by adding it to the isolated shared
libraries or to lib directory and setting
context-param
param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
param-valueorg.jboss.el.ExpressionFactoryImpl/param-value
/context-param
in web.xml does not make myfaces pickup the supplied EL.
In the logs this line is written [13/02/12 15:19:06:113 EST] 0029
ExternalSpeci I MyFaces Unified EL support disabled.
tracked it down to this method
org.apache.myfaces.util.ExternalSpecifications#isUnifiedELAvailable() . The
try block throws a error as can not find class ( and method but exception is
thrown at the first check i.e class) and catch block sets the return value to
false. This stopping it to use an externally supplied EL .
I have also asked this question on SO
http://stackoverflow.com/questions/9091354/how-can-i-update-websphere-7-to-use-el2-2
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3462) REGRESSION - Detect when to wpdate head or body target when content has been updated dynamically
[
https://issues.apache.org/jira/browse/MYFACES-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206534#comment-13206534
]
Leonardo Uribe commented on MYFACES-3462:
-
The problem is caused because javax.faces.IS_BUILDING_INITIAL_STATE was used as
a marker to detect if a resource was put on head and if that so, trigger a
head update. But in MYFACES-3451, the activation conditions for that flag were
changed, with the intention to get a significant reduction of the state size.
The solution is just update the condition, so
javax.faces.IS_BUILDING_INITIAL_STATE is set and is refreshing transient build,
activate the flag.
REGRESSION - Detect when to wpdate head or body target when content has been
updated dynamically
Key: MYFACES-3462
URL: https://issues.apache.org/jira/browse/MYFACES-3462
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions: 2.0.12, 2.1.6
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Related to topic sent on jsr344-experts list:
[jsr344-experts] Facelet page with dynamic content and update ajax content
does not work as user expects
Now take a look at this example:
include.xhtml
h:commandLink ...
f:ajax render=content/
/h:commandLink
...
f:subview id=content
ui:include src=#{testManagedBean.page}/
/f:subview
page1.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputText id=component1 value=Page 1/
!-- ... more components ... --
/ui:composition
page2.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputStylesheet ... /
h:outputText id=component2 value=Page 2/
!-- ... more components ... --
/ui:composition
Here the problem is if the dynamic content changes and add a resource under
head target (h:outputStylesheet does that), shouldn't be added a section
on the ajax payload to update the head section? In theory yes, because
this breaks encapsulation principle. If the user says render all inside
content if the head section changes it is responsability of the framework
(in this case PartialViewContext) to detect that an send the correct
payload, right?. Here we have two options:
a. Keep track of the resources rendered and save that on the state, then use
that information to check if the head should be rendered.
b. Use PostAddToViewEvent to check when a change on the component tree has
triggered a change on the head.
Option b. save some bytes on the state but it could cause render head
section more than necessary (for example a dynamic change but the head
has already rendered the resource, so it is not necessary). Option a.
impose that you need a way to check if the head was changed, and
require changes on the spec.
I'll solve this problem adding a web config param:
org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX
on MyFaces and doing some
changes on the algorithm, adding a flag to indicate if a view is being built
by first time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3367) Detect when to wpdate head or body target when content has been updated dynamically
[
https://issues.apache.org/jira/browse/MYFACES-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206263#comment-13206263
]
Leonardo Uribe commented on MYFACES-3367:
-
Hi
Checking this part, it works on 2.0.11 but stopped working on 2.0.12. I don't
know yet the reason, it should work, I'll take a look at it.
Leonardo
Detect when to wpdate head or body target when content has been updated
dynamically
---
Key: MYFACES-3367
URL: https://issues.apache.org/jira/browse/MYFACES-3367
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Fix For: 2.0.10, 2.1.4
Attachments: MYFACES-3367-1.patch
Related to topic sent on jsr344-experts list:
[jsr344-experts] Facelet page with dynamic content and update ajax content
does not work as user expects
Now take a look at this example:
include.xhtml
h:commandLink ...
f:ajax render=content/
/h:commandLink
...
f:subview id=content
ui:include src=#{testManagedBean.page}/
/f:subview
page1.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputText id=component1 value=Page 1/
!-- ... more components ... --
/ui:composition
page2.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputStylesheet ... /
h:outputText id=component2 value=Page 2/
!-- ... more components ... --
/ui:composition
Here the problem is if the dynamic content changes and add a resource under
head target (h:outputStylesheet does that), shouldn't be added a section
on the ajax payload to update the head section? In theory yes, because
this breaks encapsulation principle. If the user says render all inside
content if the head section changes it is responsability of the framework
(in this case PartialViewContext) to detect that an send the correct
payload, right?. Here we have two options:
a. Keep track of the resources rendered and save that on the state, then use
that information to check if the head should be rendered.
b. Use PostAddToViewEvent to check when a change on the component tree has
triggered a change on the head.
Option b. save some bytes on the state but it could cause render head
section more than necessary (for example a dynamic change but the head
has already rendered the resource, so it is not necessary). Option a.
impose that you need a way to check if the head was changed, and
require changes on the spec.
I'll solve this problem adding a web config param:
org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX
on MyFaces and doing some
changes on the algorithm, adding a flag to indicate if a view is being built
by first time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3455) [myfaces-2.1.6-SNAPSHOT] Using f:ajax within h:commandButton to dynamic switch ui:include works not correct anymore
[ https://issues.apache.org/jira/browse/MYFACES-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197914#comment-13197914 ] Leonardo Uribe commented on MYFACES-3455: - I checked the problem and it is caused because when f:facet contains more than one child, facelets algorithm create a panel that is not backed by any facelet tag, but it has ComponentSupport.FACET_CREATED_UIPANEL_MARKER to recognize it. Since it does not have ComponentSupport.MARK_CREATED associated, that panel is marked to remove, but it should note. The fix is just check that case on PostAddPreRemoveFromViewListener. It took me some time to figure it out, but now it should work. Thanks a lot for the test and the interest to check these cases, it is a very valuable contribution. [myfaces-2.1.6-SNAPSHOT] Using f:ajax within h:commandButton to dynamic switch ui:include works not correct anymore --- Key: MYFACES-3455 URL: https://issues.apache.org/jira/browse/MYFACES-3455 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.6-SNAPSHOT Reporter: Rene O Assignee: Leonardo Uribe Priority: Blocker Fix For: 2.0.12, 2.1.6 Attachments: jsftest.war, jsftest2.war If you click the ajaxified commandButton the ui:include switches. After a few clicks, the switch doesn't work correct anymore. You must click twice to switch the include, which is a bug. A testcase to reproduce this issue is attached. Note, that this issue doesn't appear within myfaces 2.1.5 http://localhost:8080/jsftest/navtest.jsf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3454) composite component is not rendered anymore with 2.1.6-SNAPSHOT
[ https://issues.apache.org/jira/browse/MYFACES-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194846#comment-13194846 ] Leonardo Uribe commented on MYFACES-3454: - You can add a file under your WEB-INF folder ending with .taglib.xml (for example mycomp.taglib.xml) with this content: facelet-taglib xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd; version=2.0 namespacehttp://java.sun.com/jsf/composite/components/mycomp/namespace composite-library-namecomponents.mycomp/composite-library-name /facelet-taglib and create a folder called components.mycomp and add your files there. composite component is not rendered anymore with 2.1.6-SNAPSHOT --- Key: MYFACES-3454 URL: https://issues.apache.org/jira/browse/MYFACES-3454 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.6-SNAPSHOT Reporter: Rene O Assignee: Leonardo Uribe Priority: Blocker Attachments: jsftest.war If you use myfaces 2.1.6-SNAPSHOT, a composite component is not rendered correctly anymore. With myfaces-2.1.5 everything is ok. A testcase to reproduce this issue is attached. http://localhost:8080/jsftest/componenttest.jsf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent
[ https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193903#comment-13193903 ] Leonardo Uribe commented on MYFACES-3435: - After study this issue, the problem about extend from ArrayList is it force us to implement all methods, because we can't assume the parent is implemented in some specific way. Things are different for classes extending AbstractList, because the contract specify that it is just required to implementing some methods. I did a draft for _ComponentChildrenList but I would like to think this change more carefully. My first impression is sometimes performance improvements can ruin you code and make it difficult to read. Is it worth to do it? suggestions are welcome. [perf] _DeltaList: use ArrayList as parent -- Key: MYFACES-3435 URL: https://issues.apache.org/jira/browse/MYFACES-3435 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3435.patch, _ComponentChildrenList2.java Two internal classes _DeltaList in API: 1) now use delegation pattern, but are always initialized with an ArrayList instance - use inheritance and ArrayList as parent - improvement in memory area, reduces number of GCed object in one request/response of (_DeltaList instances/2) 2) initialize expected size of _DeltaList (for example, number of validators per one component is perhaps never 10, use: new _DeltaList(5)) 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) - improvement in performance -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent
[ https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194003#comment-13194003 ] Leonardo Uribe commented on MYFACES-3435: - Ok, let's let this change for the next release cycle. Note a change in that part needs to be checked fully to prevent introduce bugs. [perf] _DeltaList: use ArrayList as parent -- Key: MYFACES-3435 URL: https://issues.apache.org/jira/browse/MYFACES-3435 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3435.patch, _ComponentChildrenList2.java Two internal classes _DeltaList in API: 1) now use delegation pattern, but are always initialized with an ArrayList instance - use inheritance and ArrayList as parent - improvement in memory area, reduces number of GCed object in one request/response of (_DeltaList instances/2) 2) initialize expected size of _DeltaList (for example, number of validators per one component is perhaps never 10, use: new _DeltaList(5)) 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) - improvement in performance -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3438) jsf.js: error handling output improvement
[ https://issues.apache.org/jira/browse/MYFACES-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194123#comment-13194123 ] Leonardo Uribe commented on MYFACES-3438: - Translation committed on 2.1.x and 2.0.x branches jsf.js: error handling output improvement - Key: MYFACES-3438 URL: https://issues.apache.org/jira/browse/MYFACES-3438 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Fix For: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Attachments: myfaces-1229093.patch While we already have improved the error reporting a lot. We still have room for improvement. For instance the error alert could need some room for improvement, we should also report the faulty http codes in case of a http error etc... Also we should discuss whether we really should use the alert if there is a console present. (would make more sense to push error reports into the console on newer browsers if present) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3447) Invalid Id check in the UIViewRoot.addComponentResource method
[
https://issues.apache.org/jira/browse/MYFACES-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187068#comment-13187068
]
Leonardo Uribe commented on MYFACES-3447:
-
Unfortunately it is not possible, because the parent component will always be
UIViewRoot, so the clientId will be the the same id. In practice you never set
id for resources, because it has no use at all.
Invalid Id check in the UIViewRoot.addComponentResource method
--
Key: MYFACES-3447
URL: https://issues.apache.org/jira/browse/MYFACES-3447
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.3, 2.1.4, 2.1.5
Environment: Glassfish 3.1 y jdk1.6
Reporter: Juan Fernandez Corugedo
Assignee: Leonardo Uribe
Original Estimate: 24h
Remaining Estimate: 24h
The method addComponentResource of the class UIViewRoot makes a check over
the Id attribute of each component that will be inserted into the
componentResources list:
code
// If the component ID of componentResource matches the ID of a
resource that has already been added, remove the old resource.
String componentId = componentResource.getId();
...
else if (componentId != null)
{
for(IteratorUIComponent it = componentResources.iterator();
it.hasNext();)
{
UIComponent component = it.next();
if(componentId.equals(component.getId())
componentResource != component)
{
it.remove();
}
else if (componentResource == component)
{
alreadyAdded = true;
}
}
}
/code
As you can see, if there are two components with the same Id but different
clientId, only one of them will be included in the header:
bks:outputStylesheet id=testStyle library=css1 name=test1.css/ !--
Its clientId is testStyle --
form id=form
...
bks:outputStylesheet id=testStyle library=css2 name=test2.css/ !--
Its clientId is form:testStyle --
...
/form
This situtation can be solved using the clientId instead of the id attribute:
code
// If the component CLIENT_ID of componentResource matches the
CLIENT_ID of a resource that has already been added, remove the old resource.
String componentId = componentResource.getClientId();
/code
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3442) Infinite loop when calling ApplicationImpl._handleListenerForAnnotations under heavy load
[ https://issues.apache.org/jira/browse/MYFACES-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187070#comment-13187070 ] Leonardo Uribe commented on MYFACES-3442: - Hi Michael The branch on the svn will be rollback this week (it belongs to a release procedure done in december that does not passed), so you have to check trunk. or 2.0.x branch. A release of 2.0.12/2.1.6 will take some time while I include some cool performance enhancements, so stay tuned. best regards, Leonardo Infinite loop when calling ApplicationImpl._handleListenerForAnnotations under heavy load - Key: MYFACES-3442 URL: https://issues.apache.org/jira/browse/MYFACES-3442 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.3 Reporter: Michael Dietrich Assignee: Leonardo Uribe Fix For: 2.0.12, 2.1.6 Hi, when doing Load Tests, we recognize that we sometimes got stuck in an infinite loop, when calling the _handleListenerForAnnotations method of the ApplicationImpl class. According to our analysis, this is related to the _classToListenerForMap attribute that is is defined as plain HashMap, so no synchronisation takes place when it is accessed from several threads. Our suggestion would be, to define it as a ConcurrentHashMap instead, because according to our experience, such kind of infinite loops due to concurrency don't occur with ConcurrentHashMaps. Kind regards, Michael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3441) [perf] use shared StringBuilder instance
[ https://issues.apache.org/jira/browse/MYFACES-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187319#comment-13187319 ] Leonardo Uribe commented on MYFACES-3441: - Attached alternate patch. The idea is create a class called SharedStringBuilder with these methods: public static StringBuilder get(FacesContext facesContext, String stringBuilderKey) public static StringBuilder get(FacesContext facesContext, String stringBuilderKey, int initialSize) public static StringBuilder get(String stringBuilderKey) and provide a param that allows to provide a key. In this way, we can reuse the same buffer, but do not mix it in different locations and cause problems that later become very difficult to solve. The idea is use it per renderer or per class. Additionally, I propose some places where this technique becomes useful, like in ajax renderer or link calculations. I don't think we should use this everywhere, just in some selected locations and that's it. There is no appreciable difference in code speed but the memory gets some benefit, because less object instances means less gc. [perf] use shared StringBuilder instance Key: MYFACES-3441 URL: https://issues.apache.org/jira/browse/MYFACES-3441 Project: MyFaces Core Issue Type: Improvement Environment: myfaces core trunk Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3441-1.patch, RendererUtils.path method javax.faces.component.UIComponentBase._getSharedStringBuilder(FacesContext) already provide this. Add same method to public API and use request-shared StringBuilder instance in renderers too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3441) [perf] use shared StringBuilder instance
[ https://issues.apache.org/jira/browse/MYFACES-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187321#comment-13187321 ] Leonardo Uribe commented on MYFACES-3441: - If no objections, I'll commit the proposed code soon. [perf] use shared StringBuilder instance Key: MYFACES-3441 URL: https://issues.apache.org/jira/browse/MYFACES-3441 Project: MyFaces Core Issue Type: Improvement Environment: myfaces core trunk Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3441-1.patch, RendererUtils.path method javax.faces.component.UIComponentBase._getSharedStringBuilder(FacesContext) already provide this. Add same method to public API and use request-shared StringBuilder instance in renderers too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3418) [perf] do not check for duplicate ids when saving view on production stage
[ https://issues.apache.org/jira/browse/MYFACES-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185013#comment-13185013 ] Leonardo Uribe commented on MYFACES-3418: - Attached final patch. Changed param name to org.apache.myfaces.CHECK_ID_PRODUCTION_MODE with this description: /** * Define how duplicate ids are checked when ProjectStage is Production, by default (auto) it only check ids of * components that does not encapsulate markup (like facelets UILeaf). * * ul * litrue: check all ids, including ids for components that are transient and encapsulate markup./li * liauto: (default) check ids of components that does not encapsulate markup (like facelets UILeaf). * Note ids of UILeaf instances are generated by facelets vdl, start with j_id, are never rendered * into the response and UILeaf instances are never used as a target for listeners, so in practice * there is no need to check such ids. This reduce the overhead associated with generate client ids./li * lifalse: do not do any check when ProjectStage is Production/li * /ul * p According to specification, identifiers must be unique within the scope of the nearest ancestor to * the component that is a naming container./p */ [perf] do not check for duplicate ids when saving view on production stage -- Key: MYFACES-3418 URL: https://issues.apache.org/jira/browse/MYFACES-3418 Project: MyFaces Core Issue Type: New Feature Environment: myfaces trunk Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3418-alternative-1.patch, MYFACES-3418-final-1.patch, MYFACES-3418.patch see discussion here: http://www.mail-archive.com/dev@myfaces.apache.org/msg52995.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3442) Infinite loop when calling ApplicationImpl._handleListenerForAnnotations under heavy load
[ https://issues.apache.org/jira/browse/MYFACES-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184200#comment-13184200 ] Leonardo Uribe commented on MYFACES-3442: - Hi Michael Really it should be similar to javax.faces.component._ComponentAttributesMap.getPropertyDescriptor() . Note the synchronized block is only to wrap the code that adds a value on the map, and the map is application scope, so once the first requests has been processed, the map will be full and no contention will occur anymore. Anyway, it sounds good to use a Singleton object like a empty list (Collections.emptyList()). I have already committed the solution. I hope this change will solve the problem. Thanks for the suggestion. Infinite loop when calling ApplicationImpl._handleListenerForAnnotations under heavy load - Key: MYFACES-3442 URL: https://issues.apache.org/jira/browse/MYFACES-3442 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.3 Reporter: Michael Dietrich Assignee: Leonardo Uribe Fix For: 2.0.12, 2.1.6 Hi, when doing Load Tests, we recognize that we sometimes got stuck in an infinite loop, when calling the _handleListenerForAnnotations method of the ApplicationImpl class. According to our analysis, this is related to the _classToListenerForMap attribute that is is defined as plain HashMap, so no synchronisation takes place when it is accessed from several threads. Our suggestion would be, to define it as a ConcurrentHashMap instead, because according to our experience, such kind of infinite loops due to concurrency don't occur with ConcurrentHashMaps. Kind regards, Michael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3418) [perf] do not check for duplicate ids when saving view on production stage
[ https://issues.apache.org/jira/browse/MYFACES-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184653#comment-13184653 ] Leonardo Uribe commented on MYFACES-3418: - I did another alternative for this one. The idea is do not take into account ids from components descending UILeaf (html markup) in production by default and do not use the parameter. Maybe we can combine both strategies, allowing org.apache.myfaces.CHECK_ID_IN_PRODUCTION with these values: true : Check all client ids, including UILeaf components auto : Check only client ids of components that does not extends from UILeaf. false : Do not check for duplicate ids in production. I think the advantage of the auto mode is that improve performance and reduce memory usage, and catch all duplicate id relevant cases (remember that facelets generates ids always starting with j_id_ , which is a reserved prefix for generated ids). If no objections I'll combine both patches and commit the resulting code soon. [perf] do not check for duplicate ids when saving view on production stage -- Key: MYFACES-3418 URL: https://issues.apache.org/jira/browse/MYFACES-3418 Project: MyFaces Core Issue Type: New Feature Environment: myfaces trunk Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3418-alternative-1.patch, MYFACES-3418.patch see discussion here: http://www.mail-archive.com/dev@myfaces.apache.org/msg52995.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3266) [perf] [concurrency] check correct logger creation
[ https://issues.apache.org/jira/browse/MYFACES-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184685#comment-13184685 ] Leonardo Uribe commented on MYFACES-3266: - Attached patch with proposed solution. The idea is call it only when it is necessary. If no objections I'll commit this code soon. [perf] [concurrency] check correct logger creation -- Key: MYFACES-3266 URL: https://issues.apache.org/jira/browse/MYFACES-3266 Project: MyFaces Core Issue Type: Improvement Reporter: Martin Kočí Assignee: Martin Kočí Priority: Trivial Attachments: MYFACES-3266-1.patch BLOCKEDjava.util.logging.Logger.getLogger(String) javax.faces.component.UIViewRoot.init() problem is that has non-static logger and logger is requested in every view init. For a class (static) method, the monitor associated with the Class object for the method's class is used. Check myfaces code base for this usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3439) [perf] ApplicationImpl: use cached info about ResourceDependecies for behaviors, converters and validators
[ https://issues.apache.org/jira/browse/MYFACES-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182944#comment-13182944 ] Leonardo Uribe commented on MYFACES-3439: - We can't apply the patch proposed because there are some subtle details between _handleAttachedResourceDependency and _handleResourceDependency that makes not possible to use one variant. It is better copy the code from private void _handleResourceDependencyAnnotations(FacesContext context, Class? inspectedClass, UIComponent component, boolean isProduction) to private void _handleAttachedResourceDependencyAnnotations(FacesContext context, Object inspected) and adjust the code to call the right code. Thanks for the patch proposed and for notice this improvement. [perf] ApplicationImpl: use cached info about ResourceDependecies for behaviors, converters and validators -- Key: MYFACES-3439 URL: https://issues.apache.org/jira/browse/MYFACES-3439 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Environment: myfaces core trunk Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3439-1.patch, MYFACES-3439.patch Solution is simple: ApplicationImpl has already method _handleResourceDependencyAnnotations for renderers and components. This method caches infos about ResourceDependecies annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3412) updated AJAX values sometimes delete other elements
[ https://issues.apache.org/jira/browse/MYFACES-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159477#comment-13159477 ] Leonardo Uribe commented on MYFACES-3412: - It worked before because PartialResponseWriter had two lines that removed all CDATA sections: //we now first remove pending javascript CDATA blocks //the reason is if we leave them the ppr chokes on them //the syntax from the auto generated CDATA usually is //\s+![CDATA[ -resultString = resultString.replaceAll(//\\s*((!\\[CDATA\\[)|(\\]\\]\\)), ); In 2.1.4, in MYFACES-3339 this was replaced with: +// -= Leonardo Uribe =- Do this cause a bug on the client side, because +// scripts containing '' will be considered invalid xml. +//resultString = resultString.replaceAll(//\\s*((!\\[CDATA\\[)|(\\]\\]\\)), ); If no CDATA, primefaces javascript works but with the fix, now there are 2 different CDATA blocks per component and primefaces only handle one of them, trimming the other one. updated AJAX values sometimes delete other elements --- Key: MYFACES-3412 URL: https://issues.apache.org/jira/browse/MYFACES-3412 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.10, 2.1.4 Reporter: Mark Struberg Assignee: Werner Punz Attachments: ajaxbug.zip The attached examples shows a problem I face after updating to the latest 2.0.10/11 and 2.1.4/5 MyFaces versions. I have 2 primefaces date pickers inside a h:panelGroup. Both date pickers create ajax requests and refresh their values. If you click one of them (both update the whole panelGroup), the 2nd date picker disapears. This might have something to do with the AJAX js rework? I can easily work around this issue, but I'm not sure which other problems might arise as well, thus we better fix this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3412) updated AJAX values sometimes delete other elements
[ https://issues.apache.org/jira/browse/MYFACES-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159697#comment-13159697 ] Leonardo Uribe commented on MYFACES-3412: - The problem is to render the markup for an ajax request two ResponseWriters comes into play: org.apache.myfaces.shared.renderkit.html.HtmlResponseWriterImpl org.apache.myfaces.context.PartialResponseWriterImpl PartialResponseWriter wraps HtmlResponseWriterImpl. JSF 2.0 spec section 13.4.4.1 says this: ... JavaServer Faces provides javax.faces.context.PartialResponseWriter to ensure the Ajax response that is written follows the standard format as specified in Section 1.3 “XML Schema Definition for Partial Responses”. Implementations must take care to properly handle nested CDATA sections when writing the response. PartialResponseWriter decorates an existing ResponseWriter implementation by extending javax.faces.context.ResponseWriterWrapper ... Which seems obvious, now take a look at section 13.4.4 ... The response should be in a common format so JavaScript clients can interpret the markup in a consistent way - an important requirement for component compatability. The agreed upon format and content type for the partial response is XML. This means there should be a ResponseWriter suitable for writing the response in XML ... With this two descriptions we can conclude that MYFACES-3339 is a bug and needs to be fixed. Historically, there was some issues on both ResponseWriter implementations, and the old code was a workaround. But later after solve issues we found the right combination. Now take a look at section 8.1, in the part that talks about createResponseWriter: ... The contentTypeList parameter is an Accept header style list of content types for this response, or null if the RenderKit should choose the best fit. [P1-start-contentTypeList]The RenderKit must support a value for the contentTypeList argument that comes straight from the Accept HTTP header, and therefore requires parsing according to the specification of the Accept header.[P1-end] Please see Section 14.1 of RFC 2616 (the HTTP 1.1 RFC) for the specification of the Accept header. ... The same description is on the javadoc and basically it means if no contentTypeList the RenderKit should choose the best fit but later says derive it from Accept HTTP heade. Since the header sent by primefaces is: Accept application/xml, text/xml, */*; q=0.01 And HtmlRenderKit has two modes xhtml and html, the best match is xml. In theory the client side is the one responsible to send the proper header, because in that place it is possible to know which contentType when the page was rendered at first. Since this behavior is specified by the spec, we can't change that part. Since there is a valid workaround adding a RenderKit wrapper, create a config param doesn't sound good. It is true send !-- -- is valid, but according to the spec text/html should be sent into accept header so HtmlResponseWriterImpl could choose the right match. Looking more carefully, maybe the problem is we are using xhtml mode for application/xml, text/xml, but it should be only used if Accept header is application/xhtml+xml. I'll check it with more care to see if we have a problem here. updated AJAX values sometimes delete other elements --- Key: MYFACES-3412 URL: https://issues.apache.org/jira/browse/MYFACES-3412 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.10, 2.1.4 Reporter: Mark Struberg Assignee: Werner Punz Attachments: ajaxbug.zip The attached examples shows a problem I face after updating to the latest 2.0.10/11 and 2.1.4/5 MyFaces versions. I have 2 primefaces date pickers inside a h:panelGroup. Both date pickers create ajax requests and refresh their values. If you click one of them (both update the whole panelGroup), the 2nd date picker disapears. This might have something to do with the AJAX js rework? I can easily work around this issue, but I'm not sure which other problems might arise as well, thus we better fix this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3412) updated AJAX values sometimes delete other elements
[ https://issues.apache.org/jira/browse/MYFACES-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159775#comment-13159775 ] Leonardo Uribe commented on MYFACES-3412: - Definitively there is a hole in the spec. In few words, it is not specified how to extract the contentType from Accept HTTP header. But the request has a header that clearly identifies it as an ajax request. We can use that. I think HtmlResponseWriterImpl should have a param to define if the content to render is html or xhtml and that condition should be calculated on HtmlRenderKit, based on the content type and if the request is an ajax request. Additionally, it is necessary to define a web config param to set the default mode (html or xhtml), and fix the algorithm that calculates contentType to set that default if no Accept header is set or there is no derived content type. updated AJAX values sometimes delete other elements --- Key: MYFACES-3412 URL: https://issues.apache.org/jira/browse/MYFACES-3412 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.10, 2.1.4 Reporter: Mark Struberg Assignee: Werner Punz Attachments: ajaxbug.zip The attached examples shows a problem I face after updating to the latest 2.0.10/11 and 2.1.4/5 MyFaces versions. I have 2 primefaces date pickers inside a h:panelGroup. Both date pickers create ajax requests and refresh their values. If you click one of them (both update the whole panelGroup), the 2nd date picker disapears. This might have something to do with the AJAX js rework? I can easily work around this issue, but I'm not sure which other problems might arise as well, thus we better fix this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3412) updated AJAX values sometimes delete other elements
[ https://issues.apache.org/jira/browse/MYFACES-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159816#comment-13159816 ] Leonardo Uribe commented on MYFACES-3412: - Attached proposed patch for this issue. It considers ajax request and resolve contentType correctly in such cases. Adds a web config param: org.apache.myfaces.DEFAULT_RESPONSE_WRITER_CONTENT_TYPE_MODE to define the default writer content type mode. I tried with the example provided and it works well. If no objections I'll commit this patch very soon. updated AJAX values sometimes delete other elements --- Key: MYFACES-3412 URL: https://issues.apache.org/jira/browse/MYFACES-3412 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.10, 2.1.4 Reporter: Mark Struberg Assignee: Werner Punz Attachments: MYFACES-3412-1.patch, ajaxbug.zip The attached examples shows a problem I face after updating to the latest 2.0.10/11 and 2.1.4/5 MyFaces versions. I have 2 primefaces date pickers inside a h:panelGroup. Both date pickers create ajax requests and refresh their values. If you click one of them (both update the whole panelGroup), the 2nd date picker disapears. This might have something to do with the AJAX js rework? I can easily work around this issue, but I'm not sure which other problems might arise as well, thus we better fix this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3412) updated AJAX values sometimes delete other elements
[ https://issues.apache.org/jira/browse/MYFACES-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159071#comment-13159071 ] Leonardo Uribe commented on MYFACES-3412: - I checked the response and it is correct. To escape CDATA endings the way to do it is replace ]] occurrences with: ]]![CDATA[![CDATA[ to the ending marker. Later on the client side (javascript) all CDATA blocks are joined together, restoring the markup as it was generated by the server (or renderers). See MYFACES-3339 for details. Note this change was introduced on 2.1.4. We should check the javascript side. updated AJAX values sometimes delete other elements --- Key: MYFACES-3412 URL: https://issues.apache.org/jira/browse/MYFACES-3412 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.10, 2.1.4 Reporter: Mark Struberg Assignee: Werner Punz Attachments: ajaxbug.zip The attached examples shows a problem I face after updating to the latest 2.0.10/11 and 2.1.4/5 MyFaces versions. I have 2 primefaces date pickers inside a h:panelGroup. Both date pickers create ajax requests and refresh their values. If you click one of them (both update the whole panelGroup), the 2nd date picker disapears. This might have something to do with the AJAX js rework? I can easily work around this issue, but I'm not sure which other problems might arise as well, thus we better fix this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3411) archetype myfaces-archetype-helloworld20 is broken
[ https://issues.apache.org/jira/browse/MYFACES-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159073#comment-13159073 ] Leonardo Uribe commented on MYFACES-3411: - The solution I had in mind for this problem is change jetty version to 7.x, so when you call mvn jetty:run, it will work as expected. archetype myfaces-archetype-helloworld20 is broken -- Key: MYFACES-3411 URL: https://issues.apache.org/jira/browse/MYFACES-3411 Project: MyFaces Core Issue Type: Bug Components: Archetype Affects Versions: 2.1.4 Reporter: Mark Struberg This archetype creates a webapp which does not work. The start page appears but the JSF ManagedBean helloWorld cannot be found in the postback. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3405) includeViewParameters re-evaluates param/model values as EL expressions
[ https://issues.apache.org/jira/browse/MYFACES-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155471#comment-13155471 ] Leonardo Uribe commented on MYFACES-3405: - Attached patch that fix the issue. Just create an utility class for evaluation (NavigationUtils) and use it on the right spots where we need it. In this way, we prevent EL evaluation for params received from UIViewParameter instances. includeViewParameters re-evaluates param/model values as EL expressions --- Key: MYFACES-3405 URL: https://issues.apache.org/jira/browse/MYFACES-3405 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.3 Environment: MyFaces 2.1.3 Reporter: Frederick Kämpfer Attachments: MYFACES-3405-1.patch I just wanted to make you aware of the following security issue in conjunction with the includeViewParameters navigation parameter. It seems it is also reproducible with MyFaces: http://java.net/jira/browse/JAVASERVERFACES-2247 I'm not sure which workaround would be best in accordance with the Spec, but at least a quick fix might be worth considering to improve the security of the default behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3405) includeViewParameters re-evaluates param/model values as EL expressions
[ https://issues.apache.org/jira/browse/MYFACES-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155517#comment-13155517 ] Leonardo Uribe commented on MYFACES-3405: - I tried it and the patch is ok. includeViewParameters re-evaluates param/model values as EL expressions --- Key: MYFACES-3405 URL: https://issues.apache.org/jira/browse/MYFACES-3405 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.3 Environment: MyFaces 2.1.3 Reporter: Frederick Kämpfer Attachments: MYFACES-3405-1.patch I just wanted to make you aware of the following security issue in conjunction with the includeViewParameters navigation parameter. It seems it is also reproducible with MyFaces: http://java.net/jira/browse/JAVASERVERFACES-2247 I'm not sure which workaround would be best in accordance with the Spec, but at least a quick fix might be worth considering to improve the security of the default behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3396) Make an helper class to configure Myfaces validator
[ https://issues.apache.org/jira/browse/MYFACES-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13150726#comment-13150726 ] Leonardo Uribe commented on MYFACES-3396: - added this entry as import-package on MANIFEST.MF: javax.validation.*;version=[1.0.0, 2.0.0);resolution:=optional Make an helper class to configure Myfaces validator --- Key: MYFACES-3396 URL: https://issues.apache.org/jira/browse/MYFACES-3396 Project: MyFaces Core Issue Type: New Feature Environment: equinox/Felix Reporter: Charlie Mordant Hi, I made bean validation working well in an osgi environment. The problem is that it need to export the validator 'by hand'. As myfaces detects Hibernate validator automatically detected Hibernate implementation, I'm not able to wire these two framework. It would be cool to make and helper class allowing to manually wire jsr 303 implementation and Myfaces. I made an example of a running bean validation implementation in an osgi environment: http://hudson.osgiliath.net/job/orthank-sample%20Tag/ws/ In order to compile, you juste need to have maven 3 and run: mvn clean install -DskipTests=true (integration tests are not stable for now). then, in order to launch run: mvn pax:provision -Dframework=equinox (or -Dframework=felix) and point your browser to http://localhost:8080/net.osgiliath.orthank-sample.java.web.simple_1.0.1.SNAPSHOT You'll be able to say hello with web services. You can désactivate ws client module to run it without ws. To test validation, try to enter an empty text in the input, you'll be redirected to an error page. If Myfaces had this helper, a validation message could be shown to the user. Regards, Charlie (tcharl on twitter, cmorda...@gmail.com on gtalk) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTVAL-138) Make an helper class to configure Myfaces validator
[ https://issues.apache.org/jira/browse/EXTVAL-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13148157#comment-13148157 ] Leonardo Uribe commented on EXTVAL-138: --- In JSF 2, there exists a key over application map to do that: /** * The key in the ServletContext where the Bean Validation Factory can be found. * In a managed Java EE 6 environment, the container initializes the ValidatorFactory * and stores it in the ServletContext under this key. * If not present, the manually instantiated ValidatorFactory is stored in the ServletContext * under this key for caching purposes. */ public static final String VALIDATOR_FACTORY_KEY = javax.faces.validator.beanValidator.ValidatorFactory; I checked myfaces-bundle to see if javax.el package is imported (detect UEL) and it is correct, so in theory I don't see why a helper class could be necessary here. But I see that in myfaces-bundle there is no optional entry for javax.validation as import in MANIFEST.MF file . Checking api/pom.xml it is there, but on bundle/pom.xml it is not, so I suppose that's the cause of the problem. Make an helper class to configure Myfaces validator --- Key: EXTVAL-138 URL: https://issues.apache.org/jira/browse/EXTVAL-138 Project: MyFaces Extensions Validator Issue Type: New Feature Components: Bean Validation Environment: equinox/Felix Reporter: Charlie Mordant Hi, I made bean validation working well in an osgi environment. The problem is that it need to export the validator 'by hand'. As myfaces detects Hibernate validator automatically detected Hibernate implementation, I'm not able to wire these two framework. It would be cool to make and helper class allowing to manually wire jsr 303 implementation and Myfaces. I made an example of a running bean validation implementation in an osgi environment: http://hudson.osgiliath.net/job/orthank-sample%20Tag/ws/ In order to compile, you juste need to have maven 3 and run: mvn clean install -DskipTests=true (integration tests are not stable for now). then, in order to launch run: mvn pax:provision -Dframework=equinox (or -Dframework=felix) and point your browser to http://localhost:8080/net.osgiliath.orthank-sample.java.web.simple_1.0.1.SNAPSHOT You'll be able to say hello with web services. You can désactivate ws client module to run it without ws. To test validation, try to enter an empty text in the input, you'll be redirected to an error page. If Myfaces had this helper, a validation message could be shown to the user. Regards, Charlie (tcharl on twitter, cmorda...@gmail.com on gtalk) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3368) enable 'standard' checkstyle checks in myfaces-core
[ https://issues.apache.org/jira/browse/MYFACES-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13147411#comment-13147411 ] Leonardo Uribe commented on MYFACES-3368: - Fixed almost all checkstyle rules on shared module. The only one I can't fix is some methods on HtmlRendererUtils that has more than 10 parameters. enable 'standard' checkstyle checks in myfaces-core --- Key: MYFACES-3368 URL: https://issues.apache.org/jira/browse/MYFACES-3368 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.3 Reporter: Mark Struberg Assignee: Leonardo Uribe We currently only have the 'minimal' checks enabled in core, which actually only checks the correct license headers. We should go for the 'standard' checkstyle rules, even if this would take some time to fix (found errors only in the first module). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3388) DataModelListener is not notified the very first time the UIData's row index changes from -1 to 0
[
https://issues.apache.org/jira/browse/MYFACES-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146565#comment-13146565
]
Leonardo Uribe commented on MYFACES-3388:
-
I don't think add the code setValue() could be a good place to subscribe a
DataModelListener. The spec is not clear about if is necessary to call
setWrappedData() on the construction, but to honor the description on the spec
it is necessary to call it, because in that place the conditions for publish
DataModelEvent are checked. I think the only way to do what you expect is
extends from UIData but reimplement that part of the algorithm, just like
tomahawk does in its t:dataTable component. I'll close this issue as invalid,
because the current behavior comply with the spec. Anyway, the hack proposed
for your example sounds better than change myfaces core internals.
DataModelListener is not notified the very first time the UIData's row index
changes from -1 to 0
-
Key: MYFACES-3388
URL: https://issues.apache.org/jira/browse/MYFACES-3388
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.3
Reporter: Jesús Pérez Alcaide (ISBAN)
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
I'm writing a custom version of UIData component by extending the default
UIData class. I want to register a DataModelListener in order to be notified
on UIData's row index changes.
I have overridden the UIData#setValue(Object) method to register a
DataModelListener whenever a new value is set to the component:
@Override
public void setValue(Object value) {
super.setValue(value);
getDataModel().addDataModelListener(new MyDataModelListener());
}
But MyDataModelListener is not notified the very first time the UIData's row
index changes from -1 to 0.
Looking through the code, this is caused because when getDataModel() is first
called, it calls createDataModel() and then a new model instance is created
using the one-argument constructor. This one-argument constructor in all
variants of DataModel concrete classes calls the method setWrappedData() and,
as the specification of this method says:
If data is non-null, the currently selected row index must
be set to zero, and a DataModelEvent must be sent to the rowSelected() method
of all registered DataModelListeners indicating that this row is now
selected.
But this DataModelEvent will never be sent to any listeners, because this is
triggered from the constructor and so, it is impossible to have any listener
registered.
This issue has a very easy workaround, to reset the model's row index right
after its creation.
@Override
public void setValue(Object value) {
super.setValue(value);
DataModel? dm = getDataModel();
dm.setRowIndex(-1); // FIXME reset rowIndex due to bug
dm.addDataModelListener(new MyDataModelListener());
}
I think that one solution may be that the one-argument constructor of the
DataModel classes shouldn't call setWrappedData(), but instead assign its
internal variable directly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2157) Make class MethodBindingMethodExpression and MethodExpressionMethodBinding public
[ https://issues.apache.org/jira/browse/TRINIDAD-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146569#comment-13146569 ] Leonardo Uribe commented on TRINIDAD-2157: -- Note the patch is proposed for a change in Trinidad, so moved from MyFaces Core. Make class MethodBindingMethodExpression and MethodExpressionMethodBinding public - Key: TRINIDAD-2157 URL: https://issues.apache.org/jira/browse/TRINIDAD-2157 Project: MyFaces Trinidad Issue Type: Improvement Reporter: hongbing wang Attachments: expose-two-classes.patch While developing components, I need implement javax.faces.component.ActionSource and ActionSource2, which require to implement following methods: public MethodBinding getAction() public void setAction(MethodBinding binding) which need MethodBindingMethodExpression and MethodExpressionMethodBinding public. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3389) Duplicate Id error when model of forEach is changed
[
https://issues.apache.org/jira/browse/MYFACES-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146687#comment-13146687
]
Leonardo Uribe commented on MYFACES-3389:
-
Unfortunately by its original design, c:forEach does not allow that type of
manipulation, and there is no way we can fix it without change how it works.
c:forEach is a build view time tag. In other words, is a tag that when
is processed (the view is created or refreshed), it changes the view
adding or removing components. But to work in a reliable way, this tag
requires the values that iterate be stable, or in other words, they should
not change over the lifetime of the page. If they change, things like the
state get lost or mixed could happen.
In this case, facelets has another internal id used to check if two components
are the same. In myfaces is stored under the key:
org.apache.myfaces.view.facelets.MARK_ID
So, when the model is changed making disappear and appear the second row, this
internal id gets confused. It is something hard to explain, but in few words
the generated ids looks like this:
j_id83974898_48897493
j_id83974898_48897493_1
j_id83974898_48897493_2
when is removed the second row
j_id83974898_48897493
j_id83974898_48897493_1
but it should be:
j_id83974898_48897493
j_id83974898_48897493_2
So, on the next request, j_id83974898_48897493_1, but the state has is as
j_id83974898_48897493_2, and finally the state get lost. So, with or without
PSS c:forEach will not going to work correctly if the rule about the stability
of the model is not preserved.
I tried to set this param:
context-param
param-nameorg.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE/param-name
param-valuetrue/param-value
/context-param
And the example works. Partial state saving (PSS) algorithm impose some rules
over the view that must be preserved. See MYFACES-3329 for details. In
c:forEach case, it is not possible to save the iteration values to use it
later
on restore view phase and preserve PSS conditions by backward compatibility
with previous use cases (enforce iteration values to be Serializable). Note
I say it is not possible, but I'm not really sure, because c:forEach in
facelets is not a 1:1 copy of jsp c:forEach.
I tried this too:
c:forEach items=#{forEachBean.elementList} var=uipropgroupelem
varStatus=el
f:subview
h:inputText id=iT_#{uipropgroupelem.elementName}
value=#{uipropgroupelem.elementValue} /br /
/f:subview
/c:forEach
Apparently it works, but looking on the generated ids, you can see how the
second and the third row gets mixed.
Is there any other alternative? Look t:dataList
t:dataList value=#{itemsBean.items} var=item rowStatePreserved=true
It has a property called rowKey with this description:
... Used to assign a value expression that identify in a unique way a row.
This value will be used later instead of rowIndex as a key to be appended
to the container client id using getDerivedSubClientId() method. ...
It few words it allow to have components with full state per row and bind in
some way the component state with the model, so an addition/removal will
be handled correctly. But this will only works with PSS enabled and if
the component is not added dynamically to the tree using
ui:include src=#{...}/, because it relies on markInitialState() call to
setup the initial state of the row. See this link for more information:
http://lu4242.blogspot.com/2011/06/jsf-component-state-per-row-for.html
Thinking more about it, I think it is possible to use PostAddToViewEvent
to setup that initial state, in case markInitialState() cannot do it.
Considering all previous argument, my opinion is we should close this issue
as invalid.
Duplicate Id error when model of forEach is changed
---
Key: MYFACES-3389
URL: https://issues.apache.org/jira/browse/MYFACES-3389
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.2
Reporter: Michael Dietrich
Attachments: MyFaces212ForEachTest.war
We have a use case, where the model (i.e. items) of a forEach is changed in
the Invoke Application phase, in a way that rows are added or deleted in the
middle of the model.
During the buildView(...) in the Render Response phase, the forEach Tag
Handler recognizes, that the model has changed, and for example that now one
more row is available, but it does not recognize, that this row was not added
as last row. So the forEach Tag Handler logic starts to create additional
components for the additional row, but it creates these components for
entries at the end of the model. The issue is, that there already exist
components for the last row in the UIViewRoot and these componts already have
the same Ids than the newly created ones.
[jira] [Commented] (MYFACES-3383) Self nested Composite Component leads to EL Stack Overflow
[ https://issues.apache.org/jira/browse/MYFACES-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13144324#comment-13144324 ] Leonardo Uribe commented on MYFACES-3383: - I have checked the example provided, and unfortunately this is not going to work with the current strategy to resolve cc expressions. In few words, org.apache.myfaces.view.facelets.tag.TagAttributeImpl wraps every expression that resolve cc into a LocationValueExpression, and use the Location object to find the right instance. This hack has worked well so far but obviously fails in this case, because Location object is the same per composite component, and does not keep into account the position of the component in the tree, which is relevant in this case. This is a very, very rare use case. Solve this problem will not going to be easy. Self nested Composite Component leads to EL Stack Overflow -- Key: MYFACES-3383 URL: https://issues.apache.org/jira/browse/MYFACES-3383 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2 Environment: Windows Reporter: Michael Dietrich Attachments: TestStackOverflow.war If the same Composite Component is used inside itself, e.g. as child of an ui:include that is included in the Composite Component, an StackOverflow happens, if an EL Expression is refering CC interface attributes. The use case is a CC to include a facelet, given by name. If the included facelet uses the same CC to include another facelet, CompositeComponentELUtils.getCompositeComponentBasedOnLocation(..) does always find the same CC, which leads to an endless loop. Please see the attached file for an example of the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3350) Error data payload attribute names
[ https://issues.apache.org/jira/browse/MYFACES-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140586#comment-13140586 ] Leonardo Uribe commented on MYFACES-3350: - Change converted to unified diff patch format against 2.1.x (trunk) Error data payload attribute names -- Key: MYFACES-3350 URL: https://issues.apache.org/jira/browse/MYFACES-3350 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.9, 2.1.3 Reporter: Keith Wong Priority: Minor Attachments: Impl.js, MYFACES-3350-1.patch, jsf.js According to JSF 2.0 and 2.1 spec section 14.4.2 table 14-6, the attributes of error data payload are: type status description source responseCode responseXML responseText errorName errorMessage However, the attributes errorName and errorMessage are named as serverErrorName and serverErrorMessage respectively. I have identified the changes and attached as follows. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3358) Flash created in ExceptionHandler not work
[
https://issues.apache.org/jira/browse/MYFACES-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137429#comment-13137429
]
Leonardo Uribe commented on MYFACES-3358:
-
Spec issue created for reference:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1045
Flash created in ExceptionHandler not work
--
Key: MYFACES-3358
URL: https://issues.apache.org/jira/browse/MYFACES-3358
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.3
Environment: WebSphere 8.0
Reporter: Keith Wong
Assignee: Leonardo Uribe
I have a custom ExceptionHandler for handling ViewExpiredException as
occurred in session timeout or application restart. I have to tell the user
in the redirected page the reason for being redirected. Here is the handler:
public void handle() throws FacesException {
for (IteratorExceptionQueuedEvent
i=getUnhandledExceptionQueuedEvents().iterator(); i.hasNext(); ) {
ExceptionQueuedEventContext context =
i.next().getContext();
Throwable t = context.getException();
if (t instanceof ViewExpiredException) {
FacesContext ctx =
FacesContext.getCurrentInstance();
ViewExpiredException vee =
(ViewExpiredException)t;
try {
ctx.addMessage(null, new
FacesMessage(FacesMessage.SEVERITY_ERROR, vee.getClass().getName(),
vee.getMessage()));
Flash flash =
ctx.getExternalContext().getFlash();
flash.put(expiredViewId,
vee.getViewId());
flash.setKeepMessages(true);
ctx.getApplication().getNavigationHandler().handleNavigation(ctx, null,
/login?faces-redirect=true);
ctx.renderResponse();
}
finally {
i.remove();
}
}
}
super.handle();
}
In the login.xhtml, it has #{flash.expiredViewId} and f:messages but both
are empty when displayed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MFCOMMONS-33) Extended ResourceHandler implementation
[
https://issues.apache.org/jira/browse/MFCOMMONS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137826#comment-13137826
]
Leonardo Uribe commented on MFCOMMONS-33:
-
Really EL expressions are only allowed on CSS files (use
#{resource['']}), and it should be application scope, or in other words
return the same value each time they are evaluated, making them cacheable.
Extended ResourceHandler implementation
---
Key: MFCOMMONS-33
URL: https://issues.apache.org/jira/browse/MFCOMMONS-33
Project: MyFaces Commons
Issue Type: Task
Components: myfaces-commons-resourcehandler
Reporter: Leonardo Uribe
Assignee: Mark Struberg
Fix For: 1.0.2
myfaces-commons-resourcehandler module includes an AdvancedResourceHandler
with these objectives:
- relative paths between resources (css files referencing images without
using #resource['..'])
- caching resources in the client (disabled if ProjectStage == Development)
- GZIP compression and local cache in tmp dir (disabled if ProjectStage ==
Development)
- i18n (supporting country code and language).
This requires more discussion and work to create a full solution. In order to
create a enhanced implementation, I have a proposal on this issue:
- Replace AdvancedResourceHandler with ExtendedResourceHandler, which is a
more descriptive name,
- Use the same pattern from myfaces shared, because it is well tested.
- Use a SAXParser to load files, since the proposed solution is java 1.6
specific, and compatibility with jdk 1.5 is required.
I'll commit the proposal, but keep the previous code so we can discuss over
there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3259) Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode
[ https://issues.apache.org/jira/browse/MYFACES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13138034#comment-13138034 ] Leonardo Uribe commented on MYFACES-3259: - I checked again the solution proposed and now I'm sure this is the way to go. In theory if a composite component class implements EditableValueHolder should not allow f:validateBean to take effect inside its body, but if that so, it is not expected any other UIInput component should be into its body. f:validateBean is very special, but it has some problems like the one described in MYFACES-2528 that suggest the only way to fix them is create a validator that extends from BeanValidator, but it should work the same. Composite components usually are used to group components and derive more components. f:validateBean is used to fill the gap between JSF and JSR-303 bean validation, so really it try to decouple validation and move it from the view to the managed beans. It works as a controller for validation, so apply it across composite components does not cause any problem at all, because at the end the validation rules are on the managed beans. In f:ajax case, it is clear the client behavior applies to the composite component, not to the content. For other specific validators that does not has a similar intention like f:validateBean should not use wrap mode. But it is not really necessary to enforce that condition, instead, this should be let to the developer of such validator, but the jsf implementation should just allow it. If no objections I'll commit the proposed patch soon. Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode -- Key: MYFACES-3259 URL: https://issues.apache.org/jira/browse/MYFACES-3259 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson Assignee: Leonardo Uribe Attachments: MYFACES-3259-1.patch, MYFACES-3259.tar.gz, MYFACES-3259.tar.gz demo forthcoming; it would seem the FaceletCompositionContext would need to keep track of the delegate as well as the id of enclosing validators in order to be able to apply the xml attributes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3368) enable 'standard' checkstyle checks in myfaces-core
[ https://issues.apache.org/jira/browse/MYFACES-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13138042#comment-13138042 ] Leonardo Uribe commented on MYFACES-3368: - Ok, no problem, but give me some time, I want to commit MYFACES-3259 first and this patch changes ComponentTagHandlerDelegate#apply. The one I really don't want to change is FaceletViewDeclarationLanguage#retargetMethodExpressions, because it is a difficult algorithm and have it as is makes easier read it and update it. But I have lots of junit tests for that one, so after all it is ok to refactor it. enable 'standard' checkstyle checks in myfaces-core --- Key: MYFACES-3368 URL: https://issues.apache.org/jira/browse/MYFACES-3368 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.3 Reporter: Mark Struberg Assignee: Leonardo Uribe We currently only have the 'minimal' checks enabled in core, which actually only checks the correct license headers. We should go for the 'standard' checkstyle rules, even if this would take some time to fix (found errors only in the first module). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3368) enable 'standard' checkstyle checks in myfaces-core
[ https://issues.apache.org/jira/browse/MYFACES-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135166#comment-13135166 ] Leonardo Uribe commented on MYFACES-3368: - I checked them and fix the checkstyle errors is ok. enable 'standard' checkstyle checks in myfaces-core --- Key: MYFACES-3368 URL: https://issues.apache.org/jira/browse/MYFACES-3368 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.3 Reporter: Mark Struberg Assignee: Mark Struberg We currently only have the 'minimal' checks enabled in core, which actually only checks the correct license headers. We should go for the 'standard' checkstyle rules, even if this would take some time to fix (found errors only in the first module). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3368) enable 'standard' checkstyle checks in myfaces-core
[ https://issues.apache.org/jira/browse/MYFACES-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13134750#comment-13134750 ] Leonardo Uribe commented on MYFACES-3368: - Just one comment: apply this checkstyle will make harder keep in sync 2.0.x branch, because it mess up almost all files. Now, to apply a patch in both branches it is required to rewrite some parts and a svn merge from 2.0.x to 2.1.x will not work well. The right way to do it is apply on 2.0.x first and then on 2.1.x. Inclusive, there are some parts that change java api signature, introducing bugs on the TCK. By that reason, I'm forced to check every single file it was committed, wasting a lot of time. Please be more careful next time. enable 'standard' checkstyle checks in myfaces-core --- Key: MYFACES-3368 URL: https://issues.apache.org/jira/browse/MYFACES-3368 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.3 Reporter: Mark Struberg Assignee: Mark Struberg We currently only have the 'minimal' checks enabled in core, which actually only checks the correct license headers. We should go for the 'standard' checkstyle rules, even if this would take some time to fix (found errors only in the first module). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3367) Detect when to wpdate head or body target when content has been updated dynamically
[
https://issues.apache.org/jira/browse/MYFACES-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133442#comment-13133442
]
Leonardo Uribe commented on MYFACES-3367:
-
If no objection I'll commit this code soon.
Detect when to wpdate head or body target when content has been updated
dynamically
---
Key: MYFACES-3367
URL: https://issues.apache.org/jira/browse/MYFACES-3367
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: MYFACES-3367-1.patch
Related to topic sent on jsr344-experts list:
[jsr344-experts] Facelet page with dynamic content and update ajax content
does not work as user expects
Now take a look at this example:
include.xhtml
h:commandLink ...
f:ajax render=content/
/h:commandLink
...
f:subview id=content
ui:include src=#{testManagedBean.page}/
/f:subview
page1.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputText id=component1 value=Page 1/
!-- ... more components ... --
/ui:composition
page2.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputStylesheet ... /
h:outputText id=component2 value=Page 2/
!-- ... more components ... --
/ui:composition
Here the problem is if the dynamic content changes and add a resource under
head target (h:outputStylesheet does that), shouldn't be added a section
on the ajax payload to update the head section? In theory yes, because
this breaks encapsulation principle. If the user says render all inside
content if the head section changes it is responsability of the framework
(in this case PartialViewContext) to detect that an send the correct
payload, right?. Here we have two options:
a. Keep track of the resources rendered and save that on the state, then use
that information to check if the head should be rendered.
b. Use PostAddToViewEvent to check when a change on the component tree has
triggered a change on the head.
Option b. save some bytes on the state but it could cause render head
section more than necessary (for example a dynamic change but the head
has already rendered the resource, so it is not necessary). Option a.
impose that you need a way to check if the head was changed, and
require changes on the spec.
I'll solve this problem adding a web config param:
org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX
on MyFaces and doing some
changes on the algorithm, adding a flag to indicate if a view is being built
by first time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3168) Bound attribute values resolve to NULL during PreRenderViewEvent for nested composite components
[
https://issues.apache.org/jira/browse/MYFACES-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132926#comment-13132926
]
Leonardo Uribe commented on MYFACES-3168:
-
Hi Richard
I checked the comment on metawidget forum and it seems like a typo error. The
datatable definition is:
h:dataTable id=communications value=#{contact.currentCommunications}
var=_communication
but the metawidget usage is this:
m:metawidget value=#{communication.current.value} rendererType=simple
rendered=#{!contact.readOnly}/
It should be
m:metawidget value=#{_communication.current.value} rendererType=simple
rendered=#{!contact.readOnly}/
Now about this bug: I think we have done everything we can. I have discussed
earlier this problem with other people. The last thing done was on
MYFACES-3289. Here are some comments discussed earlier:
?? Also your workarounds of finding the components by executing
findComponent
?? are not really safe: findComponent does not setup the context of the
component
?? which you would need to have. Only invokeOnComponent or a treevisit can
do
?? this for you!
LU Yes, I know, but note both invokeOnComponent and visitTree requires a
clientId.
LU The problem is for example when the component is inside a datatable.
There is
LU only one real UIComponent instance, but it could be many virtual
instances
LU per row. Since PreRenderViewEvent is propagated to UIViewRoot, there is
no
LU associate context, so the only way to do it is create a findComponent
expression
LU to locate the real component instance.
LU I know in this case a invokeOnComponent or visitTree with a
findComponent
LU expression sounds better, but there is nothing on the spec that helps.
Usually
LU the tasks done in that location does not require the context, so it is
valid to
LU simplify this case and expect only one call per real component. In
conclusion,
LU I agree with the solution done in mojarra for this one, even if it is not
the
LU best we can do in this case.
LU Anyway, there is something missing on the spec. Some weeks ago, I sent a
mail
LU to the EG list under the name:
LU [jsr344-experts] Referencing composite component attributes in child
components
LU outside of a tree traversal
LU I think at the end there is something related to this one.
It would be great to have a way to call a visitTree or invokeOnComponent using
a find component expression. In that way, from PreRenderViewEvent the
developer can set up the context using such call. For now all that should be
done outside the spec.
Bound attribute values resolve to NULL during PreRenderViewEvent for nested
composite components
Key: MYFACES-3168
URL: https://issues.apache.org/jira/browse/MYFACES-3168
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.6, 2.1.0
Environment: Windows 7 x64 Enterprise.
JDK 1.6.0_25.
Eclipse Version: Helios Service Release 2
Build id: 20110218-0911
Reporter: MAtthew Sweeney
Assignee: Leonardo Uribe
Attachments: jsf-testing-2.zip, jsf-testing-myfaces.zip,
screenshot-1.jpg
When nesting custom composite components, any data bound attributes (eg
#{someValueExpression} ) will resolve to null during the PreRenderViewEvent.
This only occurs on the second level or deeper nested component (the
top-level component in the page works fine).
This same issue occurs on JSF RI 2.0.4, 2.1.x, 2.2.x
I have an eclipse project for upload that reproduces the problem.
I have no cause for the issue at this time.
Cheers,
Matt
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3106) Resources not loaded when using a dynamic ui:inlclude and rendered via ajax
[
https://issues.apache.org/jira/browse/MYFACES-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125377#comment-13125377
]
Leonardo Uribe commented on MYFACES-3106:
-
I tried the demo and at first time I thought it was a bug. Use ui:include
src=#{guiMB.viewID} causes new resources to be loaded on the page. Obviously
in this case we have resources equivalent to:
h:outputStylesheet target=head
When the action is executed, only the content is rendered. But even using the
standard f:ajax render=@all, the style links are not loaded, but the scripts
are executed. Really it is a problem in HTML and browser support itself. Once
the page is loaded, there is no way to update the head section using
javascript. I tried to fix this from server side, but it is useless, because
there is no way to fix the client side part.
In AjaxResponse.js you can found the following comments:
case this.P_VIEWHEAD:
//we cannot replace the head, almost no browser
allows this, some of them throw errors
//others simply ignore it or replace it and destroy
the dom that way!
/**
* replaces a current head theoretically,
* pratically only the scripts are evaled anew since nothing else
* can be changed.
*
* @param request the current request
* @param context the ajax context
* @param newData the data to be processed
*
* @return an xml representation of the page for further processing
if possible
*/
_replaceHead: function(request, context, newData) {
The only workaround in ensure all necessary css and js files are loaded on
head section, and again since ui:include src=#{...} works on build view
time, the algorithm just don't know the views returned by such expression. So,
at the end the only alternative is let that to the developer. The same problem
will happen with all tags that affects dynamically the view like c:if or c:when.
Other alternatives are:
- Use a component that renders just one component from a child set like myfaces
commons mc:renderOne
- Force a GET or a full POST, instead ajax.
Since unfortunately this is a dead end, I'll close this one as invalid, because
we can't advance more at this point.
Resources not loaded when using a dynamic ui:inlclude and rendered via ajax
---
Key: MYFACES-3106
URL: https://issues.apache.org/jira/browse/MYFACES-3106
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.4
Environment: Windows 7, JBoss AS 6, Richfaces 4.0.0 Final, JSF2
Reporter: Luciano Deriu
Attachments: Test.war
I'm migrating my project from JSF 1.2 to JSF2 and I was using a ui:include
src=#{guiMB.viewID} / tag wrapped in a a4j:outputPanel tag (from
RichFaces) and rendering the a4j:outputPanel via ajax. However in JSF2 this
doesn't load the resources for the page i'm including.
So anything i include dynamically like this doesn't have any of the styling
or javascript that should be loaded with it.
I have created a test project which demonstrates the issue so i'll attach for
you to replicate the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3307) update myfaces parent pom to use latest apache-parent and other dependencies
[ https://issues.apache.org/jira/browse/MYFACES-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13124378#comment-13124378 ] Leonardo Uribe commented on MYFACES-3307: - I think it is safe to move to maven 3 and include maven-site-plugin. I have seen some cases where site documentation is generated correctly using maven2 but not on maven3. In practice, before deploy site using maven 3 I have to add the following on each parent pom.xml per project: build !-- Since Maven 3.0, this is required to add scpexe as protocol for deploy. -- extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh-external/artifactId version1.0-beta-7/version /extension /extensions !-- SITE GENERATION -- plugin artifactIdmaven-javadoc-plugin/artifactId version2.8/version /plugin plugin artifactIdmaven-site-plugin/artifactId version3.0/version /plugin plugin artifactIdmaven-project-info-reports-plugin/artifactId version2.4/version /plugin plugin artifactIdmaven-jxr-plugin/artifactId version2.3/version /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdtaglist-maven-plugin/artifactId version2.4/version /plugin plugin artifactIdmaven-changelog-plugin/artifactId version2.2/version /plugin /plugins /pluginManagement update myfaces parent pom to use latest apache-parent and other dependencies Key: MYFACES-3307 URL: https://issues.apache.org/jira/browse/MYFACES-3307 Project: MyFaces Core Issue Type: Improvement Components: build process Affects Versions: 2.1.2 Reporter: Mark Struberg Assignee: Mark Struberg This is needed because we have an issue in the current setup of the checkstyle plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3307) update myfaces parent pom to use latest apache-parent and other dependencies
[ https://issues.apache.org/jira/browse/MYFACES-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13124407#comment-13124407 ] Leonardo Uribe commented on MYFACES-3307: - Ok, so can we close this issue and start a release of myfaces master pom? update myfaces parent pom to use latest apache-parent and other dependencies Key: MYFACES-3307 URL: https://issues.apache.org/jira/browse/MYFACES-3307 Project: MyFaces Core Issue Type: Improvement Components: build process Affects Versions: 2.1.2 Reporter: Mark Struberg Assignee: Mark Struberg This is needed because we have an issue in the current setup of the checkstyle plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3307) update myfaces parent pom to use latest apache-parent and other dependencies
[ https://issues.apache.org/jira/browse/MYFACES-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13124500#comment-13124500 ] Leonardo Uribe commented on MYFACES-3307: - +1 to add wagon-scp in the myfaces parent. I have already tried the changes proposed, adding them to myfaces core pom.xml or other projects, so it is safe to apply them. If something happens, you always can override them so let's apply them and close this issue, and after that I'll run a release procedure for that pom. update myfaces parent pom to use latest apache-parent and other dependencies Key: MYFACES-3307 URL: https://issues.apache.org/jira/browse/MYFACES-3307 Project: MyFaces Core Issue Type: Improvement Components: build process Affects Versions: 2.1.2 Reporter: Mark Struberg Assignee: Mark Struberg This is needed because we have an issue in the current setup of the checkstyle plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3313) Calculation of redirect URL does not preserve the extension used in Faces Servlet mapping
[
https://issues.apache.org/jira/browse/MYFACES-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123039#comment-13123039
]
Leonardo Uribe commented on MYFACES-3313:
-
I checked the spec finally I found this on section JSF 2.0 section 7.5.2
Default ViewHandler Implementation:
... The getActionURL() method must fulfill the following responsibilities: ...
If the argument viewId has an extension, and this extension is mapping,
the result is contextPath + viewId. For example “/cardemo/chooseLocale.faces
...
So the example proposed is on the spec. I agree use /page01.jsf is bad practice
because the effective viewId when the view is created is /page01.xhtml . It is
a long story, but at the end a change was introduced in JSF 2.1 to
differentiate between physical and logical view ids
(ViewHandler.deriveLogicalViewId).
Anyway, since this is described on the spec we should fix our implementation of
getActionURL() method.
Calculation of redirect URL does not preserve the extension used in Faces
Servlet mapping
-
Key: MYFACES-3313
URL: https://issues.apache.org/jira/browse/MYFACES-3313
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.2, 2.1.3
Reporter: Deryk Sinotte
I have a simple navigation test case that does a navigation between two
pages. Both pages have the same simple markup:
h:body
h2Page 01/h2
h:form
h:commandButton id=navButton
value=Nav
action=#{testBean.lastPage} /
/h:form
/h:body
The backing bean methods simply return the appropriate action outcome:
public String lastPage(){
return lastPage;
}
And the faces-config file has the following navigation rules:
navigation-rule
from-view-id*/from-view-id
navigation-case
from-outcomelastPage/from-outcome
to-view-id/page02.jsf/to-view-id
redirect/
/navigation-case
navigation-case
from-outcomefirstPage/from-outcome
to-view-id/page01.jsf/to-view-id
redirect/
/navigation-case
/navigation-rule
The web.xml has a servlet mapping for .jsf files:
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern*.jsf/url-pattern
/servlet-mapping
If I go to the page01.jsf, the page loads fine. When I click the Nav
button, the navigation occurs but the URL is page02.xhtml rather than
page02.jsf. Because the extension is not preserved and there is no mapping
for .xhtml in this case, the page doesn't get handled by the Faces Servlet.
The current version of Mojarra (2.1.3) does preserve the extension when the
redirect URL is encoded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3304) NullPointerException using h:selectOneRadio with an enum
[
https://issues.apache.org/jira/browse/MYFACES-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122008#comment-13122008
]
Leonardo Uribe commented on MYFACES-3304:
-
The following notations work:
f:selectItem itemValue=#{'VALUEA'} itemLabel=labelA/
f:selectItem itemValue=#{'VALUEB'} itemLabel=labelB/
f:selectItem itemValue=VALUEA itemLabel=labelA/
f:selectItem itemValue=VALUEB itemLabel=labelB/
public TestEnum getValueA()
{
return TestEnum.VALUEA;
}
public TestEnum getValueB()
{
return TestEnum.VALUEB;
}
f:selectItem itemValue=#{testLovsBean.valueA} itemLabel=labelA/
f:selectItem itemValue=#{testLovsBean.valueB} itemLabel=labelB/
So if #{VALUEA} and #{VALUEB} resolve to the expected enum value it should
work. The syntax used here is just invalid.
But the example shows another problem. I tried the same example with mojarra
and the page is rendered and the null option is a valid choice, but as soon as
you select it on the next request the selected radio button is unselected. If
you have a selectOne component attached to an enum, it is valid to add a null
option (but in practice if you are using an enum you usually use another option
on the enum). In that case, EnumConverter will fail to convert that null value
into a valid enum value anyway but you still can provide a custom converter
that check the null value and deal with it.
The other problem with this component is if you don't set value=, when the
form is submitted the value on will be passed (tried on firefox), so set
itemStrValue to is reasonable, but at the end this is resposibility of the
code that renders at the end the component. The reason why in mojarra that
option is unselected as soon as is selected and submited is != null, so when
is received, it is not associated to the null option.
In conclusion, we should at least behave the same as Mojarra in this case.
But I still have my doubts about that. For example, someone can say we should
honor javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL web config
param in this case. It that param is set to true, as soon as a is received,
it is converted to null, and since there is a null option, this option should
be selected. But if this is false, for this specific component an empty is
ALWAYS the same as a null value.
I think we should fix some parts of the code to reflect that. First of all
check for null before render an option value and render in that case. Second
take into account that for this specific case an empty is ALWAYS the same
as a null value. And finally don't return when a String value for the
renderer is calculated and return null, just for keep things clear. I'll attach
a patch for this one, but first we need to check if the change does not make
the TCK fails before commit.
NullPointerException using h:selectOneRadio with an enum
Key: MYFACES-3304
URL: https://issues.apache.org/jira/browse/MYFACES-3304
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.8
Environment: Ubuntu 11.0.4, Jetty 6.1.10, JDK 1.6, Myfaces Core
2.0.8, Primefaces 3.0.M3
Reporter: Joe Rossi
Priority: Minor
Trying to use a h:selectOneRadio to select one of two values for an enum and
it fails, throwing a NullPointerException. No explicit converter is in use so
(from debugging) it appears to be using the default EnumConverter.
Code snippets in question are as follows:
testLovs.xhtml:
h:panelGrid columns=1
Simple radio button with constant string values
h:selectOneRadio id=l1 value=#{testLovsBean.l1}
f:selectItem itemValue=A itemLabel=labelA/
f:selectItem itemValue=B itemLabel=labelB/
/h:selectOneRadio
h:outputText id=l1Str value=l1: #{testLovBean.l1AsString}/
p:separator/
Radio button for enum
h:selectOneRadio id=l2 value=#{testLovsBean.l2}
f:selectItem itemValue=#{VALUEA} itemLabel=labelA/
f:selectItem itemValue=#{VALUEB} itemLabel=labelB/
/h:selectOneRadio
h:outputText id=l2Str value=l2: #{testLovBean.l2AsString}/
p:separator/
p:commandButton id=commitCommand
action=#{testLovsBean.commitAction}
value=Submit
ajax=false/
TestLovsBean.java:
package tn.view.bean.test;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;
import tn.view.util.FacesUtils;
/**
* Class used for testing date controls
*/
@Component
@Scope(request)
public class TestLovsBean
{
public TestLovsBean()
{
}
public String getL1()
{
return _l1;
}
public void setL1(String l1)
{
_l1 = l1;
}
public String getL1AsString()
[jira] [Commented] (MYFACES-3304) NullPointerException using h:selectOneRadio with an enum
[
https://issues.apache.org/jira/browse/MYFACES-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122049#comment-13122049
]
Leonardo Uribe commented on MYFACES-3304:
-
In this case no. The reason is the renderer for h:selectOneRadio check if a
was received as submitted value, convert it to null and pass it to
EnumConverter, so it will never see . This is an extract of the code:
public static Object getConvertedUISelectOneValue(FacesContext
facesContext, UISelectOne output, Object submittedValue){
if (submittedValue != null !(submittedValue instanceof String))
{
throw new IllegalArgumentException(Submitted value of type String
for component :
+ getPathToComponent(output) + expected);
}
//To be compatible with jsf ri, and according to issue 69
//[ Permit the passing of a null value to SelectItem.setValue() ]
//If submittedValue == then convert to null.
if ((submittedValue != null) (submittedValue instanceof String)
(.equals(submittedValue)))
{
//Replace by null value
submittedValue = null;
Note the value stored on the component is not updated, so it still is .
That's the problem. We need to do the changes described on the patch, so if the
null option is selected it keeps selected after a postback and render value=
when null value is received, but just before the option is rendered, for the
other calculations keep the value as it was received.
Note this reasoning suppose Mojarra has a problem too in this part. I checked
against TCK and we can commit the code. If no objections I'll commit this code
soon.
NullPointerException using h:selectOneRadio with an enum
Key: MYFACES-3304
URL: https://issues.apache.org/jira/browse/MYFACES-3304
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.8
Environment: Ubuntu 11.0.4, Jetty 6.1.10, JDK 1.6, Myfaces Core
2.0.8, Primefaces 3.0.M3
Reporter: Joe Rossi
Priority: Minor
Attachments: MYFACES-3304-1.patch
Trying to use a h:selectOneRadio to select one of two values for an enum and
it fails, throwing a NullPointerException. No explicit converter is in use so
(from debugging) it appears to be using the default EnumConverter.
Code snippets in question are as follows:
testLovs.xhtml:
h:panelGrid columns=1
Simple radio button with constant string values
h:selectOneRadio id=l1 value=#{testLovsBean.l1}
f:selectItem itemValue=A itemLabel=labelA/
f:selectItem itemValue=B itemLabel=labelB/
/h:selectOneRadio
h:outputText id=l1Str value=l1: #{testLovBean.l1AsString}/
p:separator/
Radio button for enum
h:selectOneRadio id=l2 value=#{testLovsBean.l2}
f:selectItem itemValue=#{VALUEA} itemLabel=labelA/
f:selectItem itemValue=#{VALUEB} itemLabel=labelB/
/h:selectOneRadio
h:outputText id=l2Str value=l2: #{testLovBean.l2AsString}/
p:separator/
p:commandButton id=commitCommand
action=#{testLovsBean.commitAction}
value=Submit
ajax=false/
TestLovsBean.java:
package tn.view.bean.test;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;
import tn.view.util.FacesUtils;
/**
* Class used for testing date controls
*/
@Component
@Scope(request)
public class TestLovsBean
{
public TestLovsBean()
{
}
public String getL1()
{
return _l1;
}
public void setL1(String l1)
{
_l1 = l1;
}
public String getL1AsString()
{
return _l1;
}
public TestEnum getL2()
{
return _l2;
}
public void setL2(TestEnum l2)
{
_l2 = l2;
}
public String commitAction()
{
System.out.println(commitAction invoked);
FacesUtils.addInfoMessage(L1: + _l1);
FacesUtils.addInfoMessage(L2: + _l2);
return null;
}
private String _l1;
private TestEnum _l2;
}
TestEnum.java:
package tn.view.bean.test;
public enum TestEnum
{
VALUEA,
VALUEB,
}
Stack trace:
javax.servlet.ServletException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:221)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
tn.view.error.ResponseCapturingFilter.doFilter(ResponseCapturingFilter.java:83)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
tn.view.error.AbstractUncaughtExceptionInterceptor.doFilter(AbstractUncaughtExceptionInterceptor.java:66)
at
[jira] [Commented] (MYFACES-3347) Improve web config param logging and enhance @JSFWebConfigParam
[ https://issues.apache.org/jira/browse/MYFACES-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121125#comment-13121125 ] Leonardo Uribe commented on MYFACES-3347: - If no objections I'll commit this code soon. Improve web config param logging and enhance @JSFWebConfigParam --- Key: MYFACES-3347 URL: https://issues.apache.org/jira/browse/MYFACES-3347 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-3347-core.patch, MYFACES-3347-mbp.patch Right now, some params are logged when myfaces is started or shutdown. Such log is done on MyfacesConfig class. It has the following problems: - Logging about application startup should be done on AbstractFacesInitializer. - That log should only be done on Production and Development project stage. For UnitTest and SystemTest, it should be silently ignored. - A web config param should be used to enable/disable. - All web config params not configured should be logged, not only the ones defined on MyfacesConfig. - Deprecated params should not be logged. - Params with expected values should be checked, and if it fails, log a warning message. To solve all that problems, the idea is add the following fields to @JSFWebConfigParam: /** * The group which the param belongs. * * pThese are the groups used in myfaces core:/p * ul * listate/li * liresources/li * liviewhandler/li * livalidation/li * lirender/li * liEL/li * /ul * * @return */ String group() default ; /** * The tag(s) or clasification(s), separated by commas * that this web config param can be clasified. * * pThese are the tags used in myfaces core:/p * ul * litomahawk/li * liperformance/li * /ul * * * @return */ String tags() default ; /** * Indicate if the param was deprecated or not. * * @return */ boolean deprecated() default false; /** * Indicate an alias or alternate name for this param. * @return */ String alias() default ; /** * Indicate if this param ignore upper or lower case when read params * @return */ boolean ignoreUpperLowerCase() default false; /** * The java type or class which this param is converted * * @return */ String classType() default ; And create a class that generate this automatically using myfaces builder plugin make-config goal. In that way, each time we add a @JSFWebConfigParam annotation, the code will be synchronized automatically. Definitively this strategy is easier than create a class that hold all web config params, because it is more flexible and simple. Just create a constant, and the annotation and that's it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3344) selectManyCheckbox State Saving
[
https://issues.apache.org/jira/browse/MYFACES-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13120385#comment-13120385
]
Leonardo Uribe commented on MYFACES-3344:
-
I don't think this is a myfaces bug. If the passed instance is not serializable
or doesn't implement StateHolder interface, the code will throw an error. It is
not a good idea to check for a class that is an internal detail. The code in
primefaces should be fixed instead. I'll close this one as invalid. Thanks for
report this one.
selectManyCheckbox State Saving
Key: MYFACES-3344
URL: https://issues.apache.org/jira/browse/MYFACES-3344
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.3
Environment: Primefaces 3.0.RC1-SNAPSHOT, WebSphere 8.0
Reporter: Keith Wong
Hi,
I have a problem when using p:selectManyCheckbox, as well as
p:selectManyMenu, with MyFaces 2. Here is the page fragment:
p:inputTextarea value=#{customer.firstName} required=true/
p:selectManyCheckbox value=#{customer.phones}
f:selectItem itemValue=SS itemLabel=Samsung/
f:selectItem itemValue=LG itemLabel=LG/
f:selectItem itemValue=AP itemLabel=Apple/
/p:selectManyCheckbox
p:commandButton value=Submit process=@form update=@form/
Steps to reproduce the problem:
1. Let the firstName field empty and click Submit
2. Type something in the firstName field and click Submit
Then, the following exception occurs, amendment to MyFaces is needed to
capture the stack trace,
[2011/10/4 12:29:01:093 CST] 001d UIComponentBa W 类
javax/faces/component/UIComponentBase 非法访问 private 类
java/util/Arrays$ArrayList
java.lang.IllegalAccessException: 类
javax/faces/component/UIComponentBase 非法访问 private 类
java/util/Arrays$ArrayList
at java.lang.J9VMInternals.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1345)
at
javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1717)
at
javax.faces.component._DeltaStateHelper.restoreState(_DeltaStateHelper.java:614)
at
javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1885)
at javax.faces.component.UIOutput.restoreState(UIOutput.java:213)
at javax.faces.component.UIInput.restoreState(UIInput.java:1012)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:545)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:581)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:564)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:564)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:564)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:564)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:564)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreView(DefaultFaceletsStateManagementStrategy.java:241)
at
org.apache.myfaces.application.StateManagerImpl.restoreView(StateManagerImpl.java:113)
at
org.apache.myfaces.shared.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:106)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:1832)
at
org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:296)
at
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:123)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1147)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:722)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:449)
at
