[jira] Created: (MYFACES-1585) Remove workaround for bug in tomcat CompositeELResolver. Bugzilla 42077
Remove workaround for bug in tomcat CompositeELResolver. Bugzilla 42077 --- Key: MYFACES-1585 URL: https://issues.apache.org/jira/browse/MYFACES-1585 Project: MyFaces Core Issue Type: Task Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Mathias Broekelmann Assigned To: Mathias Broekelmann tomcats CompositeELResolver implementation contains a bug. The class org.apache.myfaces.el.CompositeELResolver contains a workaround to fix this. See http://issues.apache.org/bugzilla/show_bug.cgi?id=42077. As soon as this bug is fixed we can remove the myfaces implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1548) UIComponent State change if getValueBinding() is called.
[ https://issues.apache.org/jira/browse/MYFACES-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Broekelmann updated MYFACES-1548: - Resolution: Fixed Assignee: Mathias Broekelmann Status: Resolved (was: Patch Available) patch already applied UIComponent State change if getValueBinding() is called. Key: MYFACES-1548 URL: https://issues.apache.org/jira/browse/MYFACES-1548 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Martin Haimberger Assigned To: Mathias Broekelmann Fix For: 1.2.0-SNAPSHOT Attachments: UIComponentBase.patch, UIComponentBase_getValueBinding.patch The Component State change if getValueBinding() is called and no _valueExpressionMap is present. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Broekelmann reopened MYFACES-1577: -- unfortunately the tck fails now. The TCK expects it this way: getValue(Object base, int index) should throw NPE or return a null value if base is null getValue(Object base, int index) should throw IndexOutOfBoundsException if Index is out of bounds or return a null value PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Dennis Byrne Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1577.patch According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1579) VariableResolver throws IllegalStateException because scope is unknown
[ https://issues.apache.org/jira/browse/MYFACES-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Broekelmann updated MYFACES-1579: - Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT Status: Resolved (was: Patch Available) Application.getVariableResolver should return a resolver which delegates to the application el resolver. I fixed this and added a test for it. Thanks Paul! VariableResolver throws IllegalStateException because scope is unknown -- Key: MYFACES-1579 URL: https://issues.apache.org/jira/browse/MYFACES-1579 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Mathias Broekelmann Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1579.patch VariableResolverImpl tries to determine if it was invoked through the faces chain or jsp chain by looking for an attribute (Scope.getClassName()) in the RequestMap. However, that attribute is only set during the span of a call to FacesCompositeELResolver.getValue(). See FacesCompositeELResolver#invoke(), which calls setScope() and then unsetScope(). Therefore the following code always throws IllegalStateException VariableResolver resolver = application.getVariableResolver(); Object result = resolver.resolveVariable(facesContext, param); because when VariableResolverImpl.resolveVariable() looks for the scope in the request map (which happens outside the getValue() call) its always null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-1551) UIViewRoot.getPhaseListeners() must not be generated
[ https://issues.apache.org/jira/browse/MYFACES-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Broekelmann reopened MYFACES-1551: -- Now UIViewRoot is missing addPhaseListener and removePhaseListener methods. These methods can be implemented in UIViewRootTemplate but how can we save/restore the state of the added phase listeners? UIViewRoot.getPhaseListeners() must not be generated Key: MYFACES-1551 URL: https://issues.apache.org/jira/browse/MYFACES-1551 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Mathias Broekelmann Assigned To: Matthias Weßendorf The 1.2 RI API does not define the method UIViewRoot.getPhaseListeners(). But this method is generated into the myfaces 1.2 UIViewRoot class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1551) UIViewRoot.getPhaseListeners() must not be generated
UIViewRoot.getPhaseListeners() must not be generated Key: MYFACES-1551 URL: https://issues.apache.org/jira/browse/MYFACES-1551 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Mathias Broekelmann The 1.2 RI API does not define the method UIViewRoot.getPhaseListeners(). But this method is generated into the myfaces 1.2 UIViewRoot class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1542) declare versions of dependencies in dependencyManagement in core/pom.xml
declare versions of dependencies in dependencyManagement in core/pom.xml Key: MYFACES-1542 URL: https://issues.apache.org/jira/browse/MYFACES-1542 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Mathias Broekelmann Assigned To: Mathias Broekelmann Priority: Minor mavens dependencyManagement structure should be used to define the versions of the dependencies that are used in api and impl. see http://maven.apache.org/pom.html#Dependency%20Management -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1246) JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instanti
[ https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475337 ] Mathias Broekelmann commented on MYFACES-1246: -- I looked into the spec section 5.4. Besides PostConstruct and PreDestroy there should also be a way to inject various j2ee container specific resources. As this is definitly out of scope for myfaces implementation I think we should find a way for j2ee containers to define their own implementation for this. Suns RI uses some kind of InjectionProvider which is implemented by j2ee containers. I think we schould do it in the same way. JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Key: MYFACES-1246 URL: https://issues.apache.org/jira/browse/MYFACES-1246 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Dennis Byrne Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=252 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1441) Implement method: ApplicationImpl.getResourceBundle(FacesContext ,String)
[ https://issues.apache.org/jira/browse/MYFACES-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Broekelmann resolved MYFACES-1441. -- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT implemented in r511030 Implement method: ApplicationImpl.getResourceBundle(FacesContext ,String) - Key: MYFACES-1441 URL: https://issues.apache.org/jira/browse/MYFACES-1441 Project: MyFaces Core Issue Type: Sub-task Components: JSR-252 Reporter: Bruno Aranda Assigned To: Mathias Broekelmann Fix For: 1.2.0-SNAPSHOT Implement method: ApplicationImpl.getResourceBundle(FacesContext ,String) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1223) JSR-252 Issue #54: Added new extension elements to the Faces XML schema.
[ https://issues.apache.org/jira/browse/MYFACES-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Broekelmann resolved MYFACES-1223. -- Resolution: Later Fix Version/s: 1.2.0-SNAPSHOT as long as we don't need these extensions there is no need to implement them. JSR-252 Issue #54: Added new extension elements to the Faces XML schema. Key: MYFACES-1223 URL: https://issues.apache.org/jira/browse/MYFACES-1223 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Mathias Broekelmann Fix For: 1.2.0-SNAPSHOT Added new extension elements to the Faces XML schema. Please see Section 1.1 XML Schema Definition. Also see https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1246) JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instanti
[ https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475134 ] Mathias Broekelmann commented on MYFACES-1246: -- Hi Dennis, any progress on this? JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Key: MYFACES-1246 URL: https://issues.apache.org/jira/browse/MYFACES-1246 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Dennis Byrne Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=252 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1109) UIInputs in DataTable (UIData) lose submitted values when UICommands are set to immediate=true
[ https://issues.apache.org/jira/browse/MYFACES-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474659 ] Mathias Broekelmann commented on MYFACES-1109: -- I can't see how we can fix this in h:datatable for jsf 1.1 or 1.2. The spec clearly states what should happen if a UIData component encodeBegin method is called: In addition to the default behavior, ensure that any saved per-row state for our child input components is discarded unless it is needed to rerender the current page with errors. see Javadoc for 1.1: http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/javax/faces/component/UIData.html#encodeBegin(javax.faces.context.FacesContext) see Javadoc for 1.2: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/component/UIData.html#encodeBegin(javax.faces.context.FacesContext) There is an important reason why this must be handled in this way . The invoked action could modify the datamodel source in a way which is not compatible to the saved state. For instance if an action removes a row in the dataset and the per- row state is not discarded restoring the state will either produce currupt rendering or will result in an exception. There is no link between a row in the datamodel and it's saved state but the row index. But I think it should be able to add that support to t:datatable. UIInputs in DataTable (UIData) lose submitted values when UICommands are set to immediate=true -- Key: MYFACES-1109 URL: https://issues.apache.org/jira/browse/MYFACES-1109 Project: MyFaces Core Issue Type: Bug Components: General, JSR-252 Affects Versions: 1.1.0, 1.1.1, 1.1.2-SNAPSHOT, 1.1.2, 1.1.3 Reporter: David Green Attachments: FaceletsTestExampleByMikeKienenberger.zip, TestExampleByDavidGreen.zip Similar to MYFACES-335, DataTable values do not reflect a form submission is an action is performed with immediate=true Perform the following actions: Failure Scenario: 1. load the page in your browser Test.jsp 2. Press the Add button once to add a row to the data table. 3. Enter some data in the text field in the added row. 4. Press Add again to add a second row to the data table. 5. Notice that the rendered page now has two rows in the data table, however text entered into the text field in the first row is now lost. Success Scenario: 1. Repeat steps 1 to 4 of the failure scenario (above). 2. Now press Delete on the second row in the data table. 3. Notice that the rendered page now has only one row and it is containing text entered in step 3 as expected. This test confirms that data tables work as expected when immediate=true is not used, but that data tables fail to work as expected when immediate=true is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1536) Resolvers assume that all JSPs produce a FacesContext
[
https://issues.apache.org/jira/browse/MYFACES-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathias Broekelmann resolved MYFACES-1536.
--
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
patch applied. Thanks Paul!
Resolvers assume that all JSPs produce a FacesContext
--
Key: MYFACES-1536
URL: https://issues.apache.org/jira/browse/MYFACES-1536
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Mathias Broekelmann
Priority: Critical
Fix For: 1.2.0-SNAPSHOT
Attachments: MYFACES-1536.patch
It seems that when MyFaces has been enabled it assumes that all the JSPs in a
web app will produce a FacesContext. But that's not the case for JSPs like
the following:
%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
%
java.util.ArrayList mylist = new java.util.ArrayList();
mylist.add(one);
mylist.add(two);
mylist.add(three);
pageContext.setAttribute(mylist, mylist);
%
c:forEach var=x items=${mylist}
p${x}/p
/c:forEach
And the error is:
java.lang.NullPointerException
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.externalContext(ManagedBeanResolver.java:217)
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:146)
javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:45)
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:101)
org.apache.jsp.index_jsp._jspx_meth_c_005fforEach_005f0(index_jsp.java:95)
org.apache.jsp.index_jsp._jspService(index_jsp.java:68)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:384)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
This looks like there's a problem in the resolvers where the ELContext is
expected to always have a FacesContext.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-17) t:commandSortHeader processes action / actionListener before updating values of sortColumn and sortAscending
[ http://issues.apache.org/jira/browse/TOMAHAWK-17?page=all ] Mathias Broekelmann resolved TOMAHAWK-17. - Fix Version/s: 1.1.5-SNAPSHOT Resolution: Fixed the action / actionlisteners will now be called after the new values has been set t:commandSortHeader processes action / actionListener before updating values of sortColumn and sortAscending -- Key: TOMAHAWK-17 URL: http://issues.apache.org/jira/browse/TOMAHAWK-17 Project: MyFaces Tomahawk Issue Type: Bug Components: Sort Header Reporter: Erik-Berndt Scheper Assigned To: Mathias Broekelmann Fix For: 1.1.5-SNAPSHOT At the moment t:CommandSortHeader processes an action / actionListener before updating the values of sortColumn and sortAscending. The reason is that in the broadcast() method of HtmlCommandSortHeader.java, the method super.broadcast(event) is executed before the values are updated. The consequence of this bug is that in the methods called by the action / actionListener, the sortColumn and sortAscending properties of the datatable still have the old value. Which in turn means that any sorting performed in the action / actionListener methods lead to incorrect results. Suggested solution: call super.broadcast(event) AFTER the values of the datatable have been updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1118) DefaultAddResource cache disabled because of the Maven build
[ http://issues.apache.org/jira/browse/MYFACES-1118?page=comments#action_12366389 ] Mathias Broekelmann commented on MYFACES-1118: -- Resource caching still works. It is done by a timestamp held in the application scope. The timestamp will be renewed in every deployment of the webapp. See org.apache.myfaces.renderkit.html.util.DefaultAddResource.getCacheKey(...). If lastModified is not found the current system time will be used for the inital value. I think that behavior is ok. Is it ok to remove the obsolete property file? DefaultAddResource cache disabled because of the Maven build Key: MYFACES-1118 URL: http://issues.apache.org/jira/browse/MYFACES-1118 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Reporter: Sylvain Vieujot Since the build is done by Maven, the ant code that was parsing the commons/src/main/resources/org/apache/myfaces/renderkit/html/util/AddResource.properties by replacing the @lastModified@ tag with the build date is gone. So the file in the jar now contains [EMAIL PROTECTED]@ instead of something like : lastModified=2006-02-14 23:47:48 +0400 The effect of this is that the resource files aren't cached anymore. I'm still very new to maven, so I don't know yet how to restore this in the maven build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-595) Context Problems when using target option in commandLink
[ http://issues.apache.org/jira/browse/MYFACES-595?page=all ] Mathias Broekelmann closed MYFACES-595: --- Fix Version: Nightly Resolution: Fixed It should be fixed now with the new state handling implementation. Context Problems when using target option in commandLink Key: MYFACES-595 URL: http://issues.apache.org/jira/browse/MYFACES-595 Project: MyFaces Type: Bug Components: General Versions: 1.0.9m9 Environment: Windows 2000; Tomcat 5.5.9, jdk1.5 Reporter: Frank Weismantel Assignee: Mathias Broekelmann Fix For: Nightly I am using a commandLink to open a new window to show a report. To do this, i use the commandLink option target and set it to _blank. When i am now click on this link the first time, my report window is opened perfectly. But when i am now pressing a second time the link, a new window is opened and the page with the link is show in this window and not the report. When i use Sun's JSF RI, it works without any problems -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1026) StateManager.restoreView has bad side effects
[ http://issues.apache.org/jira/browse/MYFACES-1026?page=comments#action_12365258 ] Mathias Broekelmann commented on MYFACES-1026: -- The state index is incremented on reading because multiple requests on the same time for the same session are possible. Does anyone know a better solution which still supports the multiple request case? StateManager.restoreView has bad side effects - Key: MYFACES-1026 URL: http://issues.apache.org/jira/browse/MYFACES-1026 Project: MyFaces Type: Bug Components: Implementation Versions: Nightly, 1.1.1 Reporter: Howard Abrams Assignee: Mathias Broekelmann Calling StateManager.restoreView has the side effect of messing up the stored state. In 1.1.1, calling this method would remove the state from the session, and therefore it would be lost forever if the lifecycle didn't re-render causing the state to be re-stored. In 1.1.2, multiple states are now stored, but calling this method causes the index number of the current state to be incremented even though a new state may never be stored. While this bug isn't seen in normal use, it pops up quite quickly when attempting more complicated/different AJAX-style lifecycles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1034) Allow customisable AddResource implementations
[ http://issues.apache.org/jira/browse/MYFACES-1034?page=comments#action_12362953 ] Mathias Broekelmann commented on MYFACES-1034: -- sounds nice to me. Allow customisable AddResource implementations -- Key: MYFACES-1034 URL: http://issues.apache.org/jira/browse/MYFACES-1034 Project: MyFaces Type: Improvement Components: Tomahawk Versions: Nightly Reporter: Peter Mahoney I use an alternative version of the AddResource. class The two areas which I have customised are the getResourceUri() method (which rewrites the URL to call resources through a forwarding controller servlet) and writeWithFullHeader() (which has different rules as to where insertions will take place when there is no head or body tags, as the applications only output HTML fragments). Currently to do this a custom MyFaces has to be built. Ideally, AddResource would be an interface. An AddResourceFactory class would provide the getInstance() method (or equivalent). This method would check for a context parameter specifying the implementation class to use. If not specified, an instance of DefaultAddResource would be used. DefaultAddResource would be non-final and would therefore be subclassed to provide the customisations described above. Would this be a suitable change? If so, I would be happy to implement the change and supply a patch. Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1010) Extended Data Table: Action Event delivered more than one time
[
http://issues.apache.org/jira/browse/MYFACES-1010?page=comments#action_12362610
]
Mathias Broekelmann commented on MYFACES-1010:
--
I will add the implementation for getClientId. But it takes some time for me to
test it with the RI.
Extended Data Table: Action Event delivered more than one time
--
Key: MYFACES-1010
URL: http://issues.apache.org/jira/browse/MYFACES-1010
Project: MyFaces
Type: Bug
Components: Tomahawk (RI Compatability)
Versions: 1.1.1
Environment: Apache Tomcat 5.5.12 or OC4j 10.1.3 DP4, Win Xp, Sun RI 1.1.01
, JDK 1.5
Reporter: Claudio Tasso
Hi,
I'm trying using Tomahawk t:dataTable and it seems to me that its behaviour
is very different from the standard JSF h:dataTable.
Consider a column which contains a command button and a table with two rows.
When the user clicks on the button of the first row, two action events are
generated!
For example, look at this very simple code:
f:view
h:form
h:dataTable value=#{testBean.persons} var=item
binding=#{testBean.uiData}
h:column
h:commandButton value=Test
action=#{testBean.test}/h:commandButton
/h:column
h:column
h:outputText value=#{item.name}/h:outputText
/h:column
h:column
h:outputText value=#{item.surname}/h:outputText
/h:column
/h:dataTable
t:dataTable value=#{testBean.persons} var=item
binding=#{testBean.htmlDataTable} preserveDataModel=false
t:column
h:commandButton value=Test
action=#{testBean.test2}/h:commandButton
/t:column
t:column
h:outputText value=#{item.name}/h:outputText
/t:column
t:column
h:outputText value=#{item.surname}/h:outputText
/t:column
/t:dataTable
/h:form
/f:view
When the user clicks the Test button of the h:dataTable, the
testBean.test method is executed just one time.
But when the user clicks the Test button of the t:dataTable the
testBean.test2 method is executed twice ( or three times if the table has 3
rows, and so on...).
I suppose that the problem is that the elements of t:dataTable which
belongs to differnt rows have the same ID, and during the processDecode phase
the same event is broadcasted more than one time.
In fact, this is the html code which is generated by Tomahawk extended
datatable:
table
tbody id=_id0:_id8:tbody_element
tr
tdinput type=submit name=_id0:_id8:_id10 value=Test //td
tdJohn/td
tdSmith/td
/tr
trtdinput type=submit name=_id0:_id8:_id10 value=Test //td
tdMark/td
tdGreene/td
/tr/tbody
/table
and this is the html code which is generated by RI h:dataTable:
table
tbody
tr
tdinput type=submit name=_id0:_id1:0:_id3 value=Test //td
tdJohn/td
tdSmith/td
/tr
tr
tdinput type=submit name=_id0:_id1:1:_id3 value=Test //td
tdMark/td
tdGreene/td
/tr
/tbody
/table
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1010) Extended Data Table: Action Event delivered more than one time
[
http://issues.apache.org/jira/browse/MYFACES-1010?page=comments#action_12362252
]
Mathias Broekelmann commented on MYFACES-1010:
--
I think we should only call super.setRowIndex(..) if not myfaces impl is used.
Extended Data Table: Action Event delivered more than one time
--
Key: MYFACES-1010
URL: http://issues.apache.org/jira/browse/MYFACES-1010
Project: MyFaces
Type: Bug
Components: Tomahawk (RI Compatability)
Versions: 1.1.1
Environment: Apache Tomcat 5.5.12 or OC4j 10.1.3 DP4, Win Xp, Sun RI 1.1.01
, JDK 1.5
Reporter: Claudio Tasso
Hi,
I'm trying using Tomahawk t:dataTable and it seems to me that its behaviour
is very different from the standard JSF h:dataTable.
Consider a column which contains a command button and a table with two rows.
When the user clicks on the button of the first row, two action events are
generated!
For example, look at this very simple code:
f:view
h:form
h:dataTable value=#{testBean.persons} var=item
binding=#{testBean.uiData}
h:column
h:commandButton value=Test
action=#{testBean.test}/h:commandButton
/h:column
h:column
h:outputText value=#{item.name}/h:outputText
/h:column
h:column
h:outputText value=#{item.surname}/h:outputText
/h:column
/h:dataTable
t:dataTable value=#{testBean.persons} var=item
binding=#{testBean.htmlDataTable} preserveDataModel=false
t:column
h:commandButton value=Test
action=#{testBean.test2}/h:commandButton
/t:column
t:column
h:outputText value=#{item.name}/h:outputText
/t:column
t:column
h:outputText value=#{item.surname}/h:outputText
/t:column
/t:dataTable
/h:form
/f:view
When the user clicks the Test button of the h:dataTable, the
testBean.test method is executed just one time.
But when the user clicks the Test button of the t:dataTable the
testBean.test2 method is executed twice ( or three times if the table has 3
rows, and so on...).
I suppose that the problem is that the elements of t:dataTable which
belongs to differnt rows have the same ID, and during the processDecode phase
the same event is broadcasted more than one time.
In fact, this is the html code which is generated by Tomahawk extended
datatable:
table
tbody id=_id0:_id8:tbody_element
tr
tdinput type=submit name=_id0:_id8:_id10 value=Test //td
tdJohn/td
tdSmith/td
/tr
trtdinput type=submit name=_id0:_id8:_id10 value=Test //td
tdMark/td
tdGreene/td
/tr/tbody
/table
and this is the html code which is generated by RI h:dataTable:
table
tbody
tr
tdinput type=submit name=_id0:_id1:0:_id3 value=Test //td
tdJohn/td
tdSmith/td
/tr
tr
tdinput type=submit name=_id0:_id1:1:_id3 value=Test //td
tdMark/td
tdGreene/td
/tr
/tbody
/table
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1010) Extended Data Table: Action Event delivered more than one time
[
http://issues.apache.org/jira/browse/MYFACES-1010?page=comments#action_12362262
]
Mathias Broekelmann commented on MYFACES-1010:
--
I took a closer look into the sources. I now think that we should not call
super.setRowIndex(..) at all.
The problem is that this method implements the most tricky part of the UIData
class. It stores and restores the state of the nested components to iterate
through the rows. If we do it we would at least get the state saving/restoring
done 3 times (HtmlDataTableHack will do this a 3rd. time). I will not say that
this is not possible to do. It´s probably more a problem where we should call
the super method in setRowIndex. But after all it´s still a workaround.
The best solution would be to change the code in RI. Why do they not call
getRowIndex() in getClientId()?
Extended Data Table: Action Event delivered more than one time
--
Key: MYFACES-1010
URL: http://issues.apache.org/jira/browse/MYFACES-1010
Project: MyFaces
Type: Bug
Components: Tomahawk (RI Compatability)
Versions: 1.1.1
Environment: Apache Tomcat 5.5.12 or OC4j 10.1.3 DP4, Win Xp, Sun RI 1.1.01
, JDK 1.5
Reporter: Claudio Tasso
Hi,
I'm trying using Tomahawk t:dataTable and it seems to me that its behaviour
is very different from the standard JSF h:dataTable.
Consider a column which contains a command button and a table with two rows.
When the user clicks on the button of the first row, two action events are
generated!
For example, look at this very simple code:
f:view
h:form
h:dataTable value=#{testBean.persons} var=item
binding=#{testBean.uiData}
h:column
h:commandButton value=Test
action=#{testBean.test}/h:commandButton
/h:column
h:column
h:outputText value=#{item.name}/h:outputText
/h:column
h:column
h:outputText value=#{item.surname}/h:outputText
/h:column
/h:dataTable
t:dataTable value=#{testBean.persons} var=item
binding=#{testBean.htmlDataTable} preserveDataModel=false
t:column
h:commandButton value=Test
action=#{testBean.test2}/h:commandButton
/t:column
t:column
h:outputText value=#{item.name}/h:outputText
/t:column
t:column
h:outputText value=#{item.surname}/h:outputText
/t:column
/t:dataTable
/h:form
/f:view
When the user clicks the Test button of the h:dataTable, the
testBean.test method is executed just one time.
But when the user clicks the Test button of the t:dataTable the
testBean.test2 method is executed twice ( or three times if the table has 3
rows, and so on...).
I suppose that the problem is that the elements of t:dataTable which
belongs to differnt rows have the same ID, and during the processDecode phase
the same event is broadcasted more than one time.
In fact, this is the html code which is generated by Tomahawk extended
datatable:
table
tbody id=_id0:_id8:tbody_element
tr
tdinput type=submit name=_id0:_id8:_id10 value=Test //td
tdJohn/td
tdSmith/td
/tr
trtdinput type=submit name=_id0:_id8:_id10 value=Test //td
tdMark/td
tdGreene/td
/tr/tbody
/table
and this is the html code which is generated by RI h:dataTable:
table
tbody
tr
tdinput type=submit name=_id0:_id1:0:_id3 value=Test //td
tdJohn/td
tdSmith/td
/tr
tr
tdinput type=submit name=_id0:_id1:1:_id3 value=Test //td
tdMark/td
tdGreene/td
/tr
/tbody
/table
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361951 ] Mathias Broekelmann commented on MYFACES-985: - I will leave this issue open since it is working on Sun´s RI. UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361950 ] Mathias Broekelmann commented on MYFACES-985: - You could also use the rendered attribute to switch on or off rendering a component. UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361830 ] Mathias Broekelmann commented on MYFACES-985: - what version of myfaces do you use? UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361832 ] Mathias Broekelmann commented on MYFACES-985: - You are modifying the component tree by removing a component while rendering the children, which is the problem. Why do you need to remove a component child in the renderer? UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361840 ] Mathias Broekelmann commented on MYFACES-985: - You are still modifing the component tree while rendering. Why don´t you add your component in the the base component when it is created? UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361866 ] Mathias Broekelmann commented on MYFACES-985: - Can you explain what you want to achieve with your component? UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1006) Datatable do not support multple o
[ http://issues.apache.org/jira/browse/MYFACES-1006?page=comments#action_12361867 ] Mathias Broekelmann commented on MYFACES-1006: -- I´m not sure if I understand it right. But you can use value bindings or el expressions to solve this. Datatable do not support multple o -- Key: MYFACES-1006 URL: http://issues.apache.org/jira/browse/MYFACES-1006 Project: MyFaces Type: Improvement Reporter: Guy Bashan Data tables usually have the following look and feel: 1) rows are light/dark. 2) when moving over a row it is shown selected. For showing rows light/dark it is possible to do: rowClasses=reportRowLight,reportRowDark For showing selected row it is possible to do: rowOnMouseOver=this.className='reportRowOver' rowOnMouseOut=this.className='reportRowLight' but, it is not possible restoring the previous color of the row before the selection. since: rowOnMouseOut property do not support multiple rows. for example, something like this: rowOnMouseOver=this.className='reportRowOver' rowOnMouseOut=this.className='reportRowLight',this.className='reportRowLight' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-810) Javadoc for AddResource/ResourceHandler/ResourceLoader
[ http://issues.apache.org/jira/browse/MYFACES-810?page=comments#action_12357441 ] Mathias Broekelmann commented on MYFACES-810: - Great Job Simon. Writing the documentation is always a pain for me (since I did the AddResource modifications) so I´m very thankfully for your work. Javadoc for AddResource/ResourceHandler/ResourceLoader -- Key: MYFACES-810 URL: http://issues.apache.org/jira/browse/MYFACES-810 Project: MyFaces Type: Improvement Reporter: Simon Kitching Fix For: Nightly Attachments: AddResource.java.patch.txt, MyFacesResourceHandler.java.patch.txt, MyFacesResourceLoader.java.patch.txt, ResourceHandler.java.patch.txt, ResourceLoader.java.patch.txt Some nice refactoring of the AddResource class has happened recently, including adding the ability for non-myfaces classes to insert resources via AddResource. However this was not well documented. Attached are javadoc patches to the relevant classes to document this properly. I hope these patches are of interest. Regards, Simon -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-792) Improve documentation for tomahawk dataTable
[ http://issues.apache.org/jira/browse/MYFACES-792?page=all ] Mathias Broekelmann closed MYFACES-792: --- Fix Version: Nightly Resolution: Fixed patch commited Improve documentation for tomahawk dataTable Key: MYFACES-792 URL: http://issues.apache.org/jira/browse/MYFACES-792 Project: MyFaces Type: Improvement Reporter: Simon Kitching Priority: Minor Fix For: Nightly Attachments: extended_data_table_attributes.xml.patch From watching the email lists and the JIRA entries, there appears to be some confusion about how to use the sorting feature of t:dataTable. Attached is a patch to the TLD documentation that will hopefully make this clearer to people. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-794) AddResources javadoc enhancements
[ http://issues.apache.org/jira/browse/MYFACES-794?page=all ] Mathias Broekelmann closed MYFACES-794: --- Fix Version: Nightly Resolution: Fixed patch committed AddResources javadoc enhancements - Key: MYFACES-794 URL: http://issues.apache.org/jira/browse/MYFACES-794 Project: MyFaces Type: Improvement Reporter: Simon Kitching Fix For: Nightly Attachments: AddResource.java.patch.txt Attached is a patch to improve the javadoc for the AddResources class. It also makes the currently private constructor package-scope, which makes it much easier to write unit tests for the AddResource class; I'm in the process of writing these unit tests now. I hope you are interested in committing this patch... Regards, Simon -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-609) t:dataScroller fires unnecessary ScrollerActionEvents
[ http://issues.apache.org/jira/browse/MYFACES-609?page=all ] Mathias Broekelmann closed MYFACES-609: --- Fix Version: Nightly Resolution: Fixed fixed in trunk since r320698 t:dataScroller fires unnecessary ScrollerActionEvents - Key: MYFACES-609 URL: http://issues.apache.org/jira/browse/MYFACES-609 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.1 Environment: myfaces-20050922 Reporter: Csaba Sebastian Assignee: Mathias Broekelmann Priority: Minor Fix For: Nightly The dataScroller renderer on decode fires ScrollerActionEvent when param is empty string (and the component doesn't ativated by the user) (HtmlDataScrollerRenderer.java:77) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-767) Programming error in HtmlTextareaRenderer
[ http://issues.apache.org/jira/browse/MYFACES-767?page=all ] Mathias Broekelmann closed MYFACES-767: --- Fix Version: Nightly Resolution: Fixed fixed in r330011 Programming error in HtmlTextareaRenderer - Key: MYFACES-767 URL: http://issues.apache.org/jira/browse/MYFACES-767 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.0 Reporter: Ricardo Tercero Lozano Priority: Minor Fix For: Nightly There is a bug in org.apache.myfaces.renderkit.html.ext.HtmlTextareaRenderer in method: encodeEnd. Line 60 is: super.encodeTextArea(facesContext, uiComponent); super prefix is not neccessary (encodeTextArea is not overwritten) and this avoids calling to any encodeTextArea method from any child class. It should be: encodeTextArea(facesContext, uiComponent); A workaround for this is overwrite the encodeEnd method too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-766) documention for javascript listener
[ http://issues.apache.org/jira/browse/MYFACES-766?page=all ] Mathias Broekelmann closed MYFACES-766: --- Resolution: Fixed I´ve applied your patch. Thank you very much. documention for javascript listener --- Key: MYFACES-766 URL: http://issues.apache.org/jira/browse/MYFACES-766 Project: MyFaces Type: Improvement Components: Tomahawk Versions: Nightly Environment: N.A. Reporter: Sharath Reddy Assignee: Mathias Broekelmann Priority: Minor Attachments: jslistener I found a very powerful Tomahawk component 'Javascript Listener'. However, the existing documation on the usage of this component is poor, so I am submitting some docs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MYFACES-627) valueChangeListener not called for elements in HtmlDataTable
[ http://issues.apache.org/jira/browse/MYFACES-627?page=all ]
Mathias Broekelmann reopened MYFACES-627:
-
We now have a client id with double _0_0, _1_1 and so on. To solve this we have
to copy the implementation from UIComponentBase.getClientId() to the derived
UIData components. I will not do this since if someone changes this
implementation we have to copy the code again and again. Having the rowid
duplicated into the client id isn´t preverable either.
I rather suggest the ri users either to make an issue for the sun ri
implemtation to use getRowIndex(). This will be the most elegant solution but
can´t be achived by myfaces.
valueChangeListener not called for elements in HtmlDataTable
Key: MYFACES-627
URL: http://issues.apache.org/jira/browse/MYFACES-627
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Environment: JSF RI 1.1.01
Reporter: Keith Lynch
Assignee: Mathias Broekelmann
Priority: Critical
Fix For: Nightly
Attachments: HtmlDataTableHack.patch
The processValueChange method is never called in some cases and called only
for the first element in the list for others.
If the value of the first row inside the inputText component is changed then
the valueChangeListener is called. If the inputText component in any other
row is changed the valueChangeListener is not called.
The valueChangeListener is never called for the selectBooleanCheckbox.
I have not tested with any other sub-components.
This is possibly an RI compatibility issue however I cannot test with the
myfaces impl as I am using components which are not compatible with it.
x:dataTable value=#{ilrTestsMgr.details.currentPageContent}
var=test
rendered=true
rowClasses=even-row,odd-row
styleClass=bluelist
width=100%
h:column
f:facet name=header
h:outputText value=#{bundle.generic_enabled}/
/f:facet
h:selectBooleanCheckbox value=#{test.enabled}
valueChangeListener=#{ilrTestsMgr.details.processValueChange}/
/h:column
h:column
f:facet name=header
h:outputText value=#{bundle.testcase_value}/
/f:facet
h:inputText value=#{test.expected}
valueChangeListener=#{ilrTestsMgr.details.processValueChange}/
/h:column
/x:dataTable
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-627) valueChangeListener not called for elements in HtmlDataTable
[ http://issues.apache.org/jira/browse/MYFACES-627?page=all ]
Mathias Broekelmann closed MYFACES-627:
---
Resolution: Won't Fix
This can not be fixed by myfaces. file an issue for the sun ri.
valueChangeListener not called for elements in HtmlDataTable
Key: MYFACES-627
URL: http://issues.apache.org/jira/browse/MYFACES-627
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Environment: JSF RI 1.1.01
Reporter: Keith Lynch
Assignee: Mathias Broekelmann
Priority: Critical
Fix For: Nightly
Attachments: HtmlDataTableHack.patch
The processValueChange method is never called in some cases and called only
for the first element in the list for others.
If the value of the first row inside the inputText component is changed then
the valueChangeListener is called. If the inputText component in any other
row is changed the valueChangeListener is not called.
The valueChangeListener is never called for the selectBooleanCheckbox.
I have not tested with any other sub-components.
This is possibly an RI compatibility issue however I cannot test with the
myfaces impl as I am using components which are not compatible with it.
x:dataTable value=#{ilrTestsMgr.details.currentPageContent}
var=test
rendered=true
rowClasses=even-row,odd-row
styleClass=bluelist
width=100%
h:column
f:facet name=header
h:outputText value=#{bundle.generic_enabled}/
/f:facet
h:selectBooleanCheckbox value=#{test.enabled}
valueChangeListener=#{ilrTestsMgr.details.processValueChange}/
/h:column
h:column
f:facet name=header
h:outputText value=#{bundle.testcase_value}/
/f:facet
h:inputText value=#{test.expected}
valueChangeListener=#{ilrTestsMgr.details.processValueChange}/
/h:column
/x:dataTable
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-627) valueChangeListener not called for elements in HtmlDataTable
[ http://issues.apache.org/jira/browse/MYFACES-627?page=all ]
Mathias Broekelmann closed MYFACES-627:
---
Fix Version: Nightly
Resolution: Fixed
patch is applied. thanks to Senthil Chelladurai and Keith Lynch.
I also applied your patch to UIColumns which had the same problem when using
t:columns
valueChangeListener not called for elements in HtmlDataTable
Key: MYFACES-627
URL: http://issues.apache.org/jira/browse/MYFACES-627
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Environment: JSF RI 1.1.01
Reporter: Keith Lynch
Priority: Critical
Fix For: Nightly
Attachments: HtmlDataTableHack.patch
The processValueChange method is never called in some cases and called only
for the first element in the list for others.
If the value of the first row inside the inputText component is changed then
the valueChangeListener is called. If the inputText component in any other
row is changed the valueChangeListener is not called.
The valueChangeListener is never called for the selectBooleanCheckbox.
I have not tested with any other sub-components.
This is possibly an RI compatibility issue however I cannot test with the
myfaces impl as I am using components which are not compatible with it.
x:dataTable value=#{ilrTestsMgr.details.currentPageContent}
var=test
rendered=true
rowClasses=even-row,odd-row
styleClass=bluelist
width=100%
h:column
f:facet name=header
h:outputText value=#{bundle.generic_enabled}/
/f:facet
h:selectBooleanCheckbox value=#{test.enabled}
valueChangeListener=#{ilrTestsMgr.details.processValueChange}/
/h:column
h:column
f:facet name=header
h:outputText value=#{bundle.testcase_value}/
/f:facet
h:inputText value=#{test.expected}
valueChangeListener=#{ilrTestsMgr.details.processValueChange}/
/h:column
/x:dataTable
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-763) support of ellipsis (...) in data cells
[ http://issues.apache.org/jira/browse/MYFACES-763?page=comments#action_12356287 ] Mathias Broekelmann commented on MYFACES-763: - Cool stuff. I`m looking for this for month. Since this is more an css issue I wondering how we can integrate it easily. Adding the javascript to a page should be quite easy for the user. As far as I see the javascript functions are never called by page (special FF hooks?). I think it´s better to create a wiki entry for this which explains how this can be done. support of ellipsis (...) in data cells --- Key: MYFACES-763 URL: http://issues.apache.org/jira/browse/MYFACES-763 Project: MyFaces Type: Improvement Versions: 1.1.1 Environment: all. Reporter: Ronald van Kuijk If the value of a cell is to bigg, having it truncated and three dots shown (...) would be nice. this is a css3 feature text-overflow: ellipsis, but FF does not support this yet. On http://www.hedgerwow.com/360/dhtml/text_overflow/demo.php is a nice workaround which would be great to have in the extended datagrid -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-731) selectManyListbox calls converter getAsString passing in string value during form post
[ http://issues.apache.org/jira/browse/MYFACES-731?page=comments#action_12332689 ] Mathias Broekelmann commented on MYFACES-731: - I wasn´t able to reproduce the problem you described. Please post the affected jsp/bean code with some more details about the problem selectManyListbox calls converter getAsString passing in string value during form post -- Key: MYFACES-731 URL: http://issues.apache.org/jira/browse/MYFACES-731 Project: MyFaces Type: Bug Components: Implementation Versions: 1.1.0, Nightly Environment: JBoss 4.0.3 plus EJB 3.0rc3 on Linux/Sun JDK1.5.0_04 Reporter: Jonn Beames Assignee: Mathias Broekelmann Problem is pretty much the same as described in bug MYFACES-624 except that I'm experiencing it with the selectManyListbox. I first encountered this problem when switching to myfaces-1.1.0 from the version shipped with JBoss AS 4.0.3RC2. Sorry, I don't know what version was in RC2, but the MD5 sums look like this: 41db995e4201acaec1599f8a933926dc myfaces-api.jar 72cf887cb90f6ecfb7405d674de3a7cf myfaces-impl.jar I just tried again with the 20051019 nightly build and run into the same converter getAsString problem. For more on my particular setup, see: http://www.jboss.com/index.html?module=bbop=viewtopict=70678 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-723) ApplicationImpl: German ist instead of is in error messages
[ http://issues.apache.org/jira/browse/MYFACES-723?page=all ] Mathias Broekelmann closed MYFACES-723: --- Fix Version: Nightly Resolution: Fixed patch is applied. Thanks Mike! Just a note for the relative path´s. I use eclipse which is able to skip a defined amount of folders to navigate to the right position in the path. That is very nice and it is no problem to apply a patch with absolute path´s. ApplicationImpl: German ist instead of is in error messages --- Key: MYFACES-723 URL: http://issues.apache.org/jira/browse/MYFACES-723 Project: MyFaces Type: Bug Versions: Nightly Reporter: Mike Kienenberger Assignee: Mathias Broekelmann Priority: Trivial Fix For: Nightly Attachments: ApplicationImpl.java.patch, ApplicationImpl.java.patch.w.rel.paths Several occurrences of ist not allowed in ApplicationImpl.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-718) ExternalContext.redirect does not call responseComplete()
[ http://issues.apache.org/jira/browse/MYFACES-718?page=all ] Mathias Broekelmann closed MYFACES-718: --- Fix Version: Nightly Resolution: Fixed the myfaces navigation handler called the responseComplete() method so this should only be an issue if a custom navigation handler is used. I moved this call to the external context as specified in the spec. Thanks Nico Krijnen ExternalContext.redirect does not call responseComplete() - Key: MYFACES-718 URL: http://issues.apache.org/jira/browse/MYFACES-718 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9, 1.1.0, Nightly, 1.1.1 Reporter: Nico Krijnen Assignee: Mathias Broekelmann Priority: Minor Fix For: Nightly It seems that the redirect method in org.apache.myfaces.context.servlet.ServletExternalContextImpl does not call responseComplete() as it should. The official API documentation states: Redirect a request to the specified URL, and cause the responseComplete() method to be called on the FacesContext instance for the current request. See: http://java.sun.com/j2ee/javaserverfaces/1.1/docs/api/javax/faces/context/ExternalContext.html#redirect(java.lang.String) When I look at the redirect method in the current trunk it does not call responseComplete() http://svn.apache.org/repos/asf/myfaces/impl/trunk/src/java/org/apache/myfaces/context/servlet/ServletExternalContextImpl.java The same goes for the Portlet version of the ExternalContext implementation. I did a quick search and found the same issue reported in the user list two and a half months ago by Richard Wallace (http://www.mail-archive.com/users@myfaces.apache.org/msg06486.html). It does not seem to be reported in JIRA, so I added it here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-721) DataTable erroneously discard saved state when validation error in non child field
[ http://issues.apache.org/jira/browse/MYFACES-721?page=all ]
Mathias Broekelmann closed MYFACES-721:
---
Fix Version: Nightly
Resolution: Fixed
fixed, thanks Guillaume LE STUM
DataTable erroneously discard saved state when validation error in non child
field
--
Key: MYFACES-721
URL: http://issues.apache.org/jira/browse/MYFACES-721
Project: MyFaces
Type: Bug
Components: General
Versions: 1.1.0
Reporter: Guillaume LE STUM
Assignee: Mathias Broekelmann
Fix For: Nightly
Data table state is reset when a validation error occurs but is neither in a
child component nor in a previous sibling.
Testcase:
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
f:view
h:form
t:divFirst data table:/t:div
t:dataTable id=myTable1 var=tableRow1 value=#{list1}
h:column
h:inputText id=rowInput1
value=#{tableRow1} /
h:message for=rowInput1
errorStyle=color:red/
/h:column
/t:dataTable
t:divSingle input field:/t:div
h:outputLabel for=inputLongLong value (preferably
2...):/h:outputLabel
h:inputText id=inputLong value=3
f:validateLongRange minimum=2 maximum=2 /
/h:inputText
h:message for=inputLong errorStyle=color:red/
t:divSecond data table:/t:div
t:dataTable id=myTable2 var=tableRow2 value=#{list2}
h:column
h:inputText id=rowInput2
value=#{tableRow2} /
h:message for=rowInput2
errorStyle=color:red/
/h:column
/t:dataTable
h:commandButton value=submit /
/h:form
/f:view
managed-bean
managed-bean-namelist1/managed-bean-name
managed-bean-classjava.util.ArrayList/managed-bean-class
managed-bean-scopeapplication/managed-bean-scope
list-entries
value-classjava.lang.String/value-class
valueEnter a String/value
/list-entries
/managed-bean
managed-bean
managed-bean-namelist2/managed-bean-name
managed-bean-classjava.util.ArrayList/managed-bean-class
managed-bean-scopeapplication/managed-bean-scope
list-entries
value-classjava.lang.String/value-class
valueEnter a String/value
/list-entries
/managed-bean
Enter something custom in first field
Enter 7 in second field as is (will cause a validation errror)
Enter something custom in third field
click submit button
The page is redisplayed because there is a validation error in second field
Second and third field have retained the entered values, but first field has
been reset.
First field should have retained its entered value as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-473) cannot use AddResource class to add resources of own components
[ http://issues.apache.org/jira/browse/MYFACES-473?page=all ]
Mathias Broekelmann closed MYFACES-473:
---
Fix Version: Nightly
Resolution: Fixed
AddResource.registerAccess(Class) added. It must be called before adding a
resource.
Custom components should define a ServletContextListener in their tld file
which calls the registerAccess method to work in clustered environments.
cannot use AddResource class to add resources of own components
---
Key: MYFACES-473
URL: http://issues.apache.org/jira/browse/MYFACES-473
Project: MyFaces
Type: Improvement
Components: Tomahawk
Versions: 1.1.0
Reporter: Csaba Sebastian
Fix For: Nightly
I wrote a new component based on MyFaces, and this component has an external
JS resource. While rendering, I want to add the reference of this resource by
the AddResource class: I tried simply to call
AddResource.addJavaScriptToHeader(...). But unfortunately this function can
handle only the resources of the MyFaces components, because of the line 203:
if( ! name.startsWith(COMPONENTS_PACKAGE) ){ log.error(
If I write my own AddResource class (functions like yours), the
ExtensionsFilter still references the old AddReource class (between lines 106
and 132), so I need to implement a new ExtensionFilter to handle my resources
well.
This solution of my problem works, but I won't use it. I need a more
structured solution. What shall I do to use the original AddResource class?
And what are these ?security reasons, why the restriction to the package
name is required?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-32) Multiple browser window problem with server state saving
[ http://issues.apache.org/jira/browse/MYFACES-32?page=all ] Mathias Broekelmann closed MYFACES-32: -- Fix Version: Nightly Resolution: Fixed fixed in next nightly Multiple browser window problem with server state saving Key: MYFACES-32 URL: http://issues.apache.org/jira/browse/MYFACES-32 Project: MyFaces Type: Bug Versions: 1.0.7 beta Reporter: Oliver Rossmueller Assignee: Mathias Broekelmann Priority: Minor Fix For: Nightly In response to sf bug #1008685 server-side view state is held in the session by viewId so for multiple windows the state is not lost. The issue remains for multiple browser windows showing the same view as in this scenario all windows share one server-side view state. This can only be resolved by making viewId unique using some window-dependent pre-/postfix to the current viewId (e.g. by providing a special custom component). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-164) Server-side state should be held
[ http://issues.apache.org/jira/browse/MYFACES-164?page=all ] Mathias Broekelmann closed MYFACES-164: --- Fix Version: Nightly Resolution: Fixed fixed in next nightly Server-side state should be held Key: MYFACES-164 URL: http://issues.apache.org/jira/browse/MYFACES-164 Project: MyFaces Type: Improvement Versions: 1.0.9m9 Environment: WindowsXP SP2;J2SE1.4.2_07;Tomcat4.1.31 Reporter: yamo Priority: Critical Fix For: Nightly When I navigate back to a form that has previously been submitted, using the browser back button, I need to click the submit button twice in order for the form to actually resubmit. In the mailing list (myfaces-user at 15 Nov 2004), Manfred said This problem does not exist for client-side state saving. To be sure, it seems work correctly, but client-side state saving have security problems. Client-side state is non encrypted data, so users can see the state, and tamper with it. It is necessary to hold sever-side state like JSF-RI 1.1_01 to use MyFaces for secure application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-543) Problems handling simultaneous request from the same session
[ http://issues.apache.org/jira/browse/MYFACES-543?page=all ] Mathias Broekelmann closed MYFACES-543: --- Fix Version: Nightly Resolution: Fixed fixed in next nightly Problems handling simultaneous request from the same session Key: MYFACES-543 URL: http://issues.apache.org/jira/browse/MYFACES-543 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9 Reporter: Marcus Schiesser Fix For: Nightly Attachments: semaphore.patch, sync.patch If someone tries to do simultaneous client requests from the same HttpSession instance (i used a direct resubmit in the form tag's onsubmit handler which leads to two simultaneous requests) it will lead to concurrent access problems. During my tests, it almost any time crashed in the UIViewRoot implementation. The reason is that it is not thread-safe which could be easily solved by synchronising the 4 process methods and the queueEvent method. But the question is where to put the synchronisation, i also tried synchronising the service method of the FacesServlet class, so that only one HttpSession could run at the time (IMHO something desirable). That way the simultaneous request are processed one after the other. But a further question arises then: How MyFaces handles the problem if two identically request are processed in the lifecycle - is this appart from the rendering (in my tests SocketExceptions occured as the connection has been reset before) a problem? Does it affect the state? What are your opinions concerning this topic? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MYFACES-543) Problems handling simultaneous request from the same session
[ http://issues.apache.org/jira/browse/MYFACES-543?page=all ] Mathias Broekelmann reopened MYFACES-543: - reopened since it not fixed. Problems handling simultaneous request from the same session Key: MYFACES-543 URL: http://issues.apache.org/jira/browse/MYFACES-543 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9 Reporter: Marcus Schiesser Fix For: Nightly Attachments: semaphore.patch, sync.patch If someone tries to do simultaneous client requests from the same HttpSession instance (i used a direct resubmit in the form tag's onsubmit handler which leads to two simultaneous requests) it will lead to concurrent access problems. During my tests, it almost any time crashed in the UIViewRoot implementation. The reason is that it is not thread-safe which could be easily solved by synchronising the 4 process methods and the queueEvent method. But the question is where to put the synchronisation, i also tried synchronising the service method of the FacesServlet class, so that only one HttpSession could run at the time (IMHO something desirable). That way the simultaneous request are processed one after the other. But a further question arises then: How MyFaces handles the problem if two identically request are processed in the lifecycle - is this appart from the rendering (in my tests SocketExceptions occured as the connection has been reset before) a problem? Does it affect the state? What are your opinions concerning this topic? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-543) Problems handling simultaneous request from the same session
[ http://issues.apache.org/jira/browse/MYFACES-543?page=all ] Mathias Broekelmann closed MYFACES-543: --- Resolution: Won't Fix Marcus try to implement your own FacesServlet by using the code from the existing one. IMO your problem is very specific and can´t be addressed in myfaces. Synchronizing the state of user session beans can only be solved by the user. Rendering the view does not guarantee that the user objects will not change. In fact if two request are processed at the same time (one of them changing the data, the other one is displaying the data) it is likly that the second response is corrupted since the data changed during the rendering. If you use UIData components you will see some strange things. Since UIData components maintains a state during processing and rendering and can´t be synchronized. So you definitly need different component instances for each request. Reusing an existing component tree may not be working since jsf defines no lifecycle (like the one for servlets) for the components. Some components don´t clean up their state if processing is finished. Problems handling simultaneous request from the same session Key: MYFACES-543 URL: http://issues.apache.org/jira/browse/MYFACES-543 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9 Reporter: Marcus Schiesser Fix For: Nightly Attachments: semaphore.patch, sync.patch If someone tries to do simultaneous client requests from the same HttpSession instance (i used a direct resubmit in the form tag's onsubmit handler which leads to two simultaneous requests) it will lead to concurrent access problems. During my tests, it almost any time crashed in the UIViewRoot implementation. The reason is that it is not thread-safe which could be easily solved by synchronising the 4 process methods and the queueEvent method. But the question is where to put the synchronisation, i also tried synchronising the service method of the FacesServlet class, so that only one HttpSession could run at the time (IMHO something desirable). That way the simultaneous request are processed one after the other. But a further question arises then: How MyFaces handles the problem if two identically request are processed in the lifecycle - is this appart from the rendering (in my tests SocketExceptions occured as the connection has been reset before) a problem? Does it affect the state? What are your opinions concerning this topic? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-666) generated form action should include existing query string if posting to same view
[ http://issues.apache.org/jira/browse/MYFACES-666?page=all ] Mathias Broekelmann closed MYFACES-666: --- Resolution: Won't Fix If we would add existing query params we would create an infinite number of params if the user navigates some pages in you app generated form action should include existing query string if posting to same view -- Key: MYFACES-666 URL: http://issues.apache.org/jira/browse/MYFACES-666 Project: MyFaces Type: Improvement Components: Implementation Reporter: Thomas Timbul Priority: Critical the method getActionURL in the JspViewHandlerImpl should also append existing query string to the returned url. If the view relies on certain parameters to be set (e.g. viewPage.jsf?pageId=5) and does not render the same response, then any form submit is ignored (submit button is not found, so its action method is not invoked). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-677) HtmlSelectOneMenu conversion error with SelectItemGroup
[ http://issues.apache.org/jira/browse/MYFACES-677?page=all ]
Mathias Broekelmann closed MYFACES-677:
---
Fix Version: Nightly
1.1.1
Resolution: Fixed
fixed in trunk and branch for 1.1.1 release
HtmlSelectOneMenu conversion error with SelectItemGroup
---
Key: MYFACES-677
URL: http://issues.apache.org/jira/browse/MYFACES-677
Project: MyFaces
Type: Bug
Versions: 1.1.0
Environment: JRE 1.4.2_08 , Tomcat 4.1.27, Firefox
Reporter: Thomas A. Valletta
Assignee: Mathias Broekelmann
Fix For: 1.1.1, Nightly
While attempting to match the selected SelectItem for an HtmlSelectOneMenu,
the matchValue method of SelectItemsUtil calls the getConvertedValue method
before checking to see if the SelectItem is really a SelectItemGroup. This
causes conversion errors. If the SelectItem.getValue() is null (I think that
it was before MyFaces1.1) then it would not call the getConvertedValue. But
now you get one ConversionException for every SelectItemGroup that has to be
checked before the matching SelectItem is found.
Here is the method stack:
_SelectItemsUtil.matchValue(FacesContext, Object, Iterator,
_SelectItemsUtil$_ValueConverter) line: 46
HtmlSelectOneMenu(UISelectOne).validateValue(FacesContext, Object) line: 52
HtmlSelectOneMenu(UIInput).validate(FacesContext) line: 269
HtmlSelectOneMenu(UIInput).processValidators(FacesContext) line: 144
Here is the method in MyFaces 1.1:
/**
* @param context the faces context
* @param value the value to check
* @param converter
* @param iterator contains instances of SelectItem
* @return if the value of a selectitem is equal to the given value
*/
public static boolean matchValue(FacesContext context, Object value,
Iterator selectItemsIter, _ValueConverter converter)
{
while (selectItemsIter.hasNext())
{
SelectItem item = (SelectItem) selectItemsIter.next();
Object itemValue = item.getValue();
if(converter != null itemValue instanceof String)
{
itemValue = converter.getConvertedValue(context,
(String)itemValue);
}
if (value.equals(itemValue))
{
return true;
}
if (item instanceof SelectItemGroup)
{
SelectItemGroup itemgroup = (SelectItemGroup) item;
SelectItem[] selectItems = itemgroup.getSelectItems();
if (selectItems != null
selectItems.length 0
matchValue(context, value, Arrays.asList(
selectItems).iterator(),
converter))
{
return true;
}
}
}
return false;
}
Thanks,
Tom
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-476) commandButton doesn't renders well the application-dependent image urls
[ http://issues.apache.org/jira/browse/MYFACES-476?page=all ] Mathias Broekelmann closed MYFACES-476: --- Fix Version: Nightly 1.1.1 Resolution: Fixed fixed in trunk and 1.1.1 branch commandButton doesn't renders well the application-dependent image urls --- Key: MYFACES-476 URL: http://issues.apache.org/jira/browse/MYFACES-476 Project: MyFaces Type: Bug Components: Implementation Versions: 1.1.1 Environment: Version 2005.08.28 Reporter: Csaba Sebastian Assignee: Mathias Broekelmann Fix For: Nightly, 1.1.1 Whenever the graphicImage component renders it's url attribute by passing it through the viewhandler (see org.apache.myfaces.renderkit.html.HtmlImageRendererBase.java: line 66-70), and encoded as an application-dependent url if required; if I set the image attribute for a commandButton component, it's image attribute rendered as it is (see org.apache.myfaces.renderkit.html.HtmlButtonRendererBase.java: line 91). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-699) selectOneMenu misery error
[
http://issues.apache.org/jira/browse/MYFACES-699?page=comments#action_12331921
]
Mathias Broekelmann commented on MYFACES-699:
-
can you post the stacktrace too?
selectOneMenu misery error
--
Key: MYFACES-699
URL: http://issues.apache.org/jira/browse/MYFACES-699
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly
Environment: Tomcat 5.0.28, Nightly build 10/10/2005
Reporter: Zhong Li
Priority: Critical
0 ERROR [http8080-Processor23] renderkit.RendererUtils - Property not
found - called by component : {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId:
/dealeradmin/dealer_message.jsp][Class: org.apache.myfaces.custom.div.Div,Id:
pagebody][Class: javax.faces.component.html.HtmlPanelGrid,Id: _id44][Class:
javax.faces.component.html.HtmlPanelGroup,Id: _id45][Class:
javax.faces.component.html.HtmlForm,Id: unitItemViewList][Class:
org.apache.myfaces.component.html.ext.HtmlDataTable,Id: _id47][Class:
javax.faces.component.UIColumn,Id: _id56][Class:
javax.faces.component.html.HtmlOutputText,Id: _id58]}
It works on 1.0.9, if my page have a selectOneMenu in panelGroup, when it
navigate to other page, it will raised above error, I change navigation rules
to redirect, all works fine.
I don't know what's going on inside myfaces team. but I feel after version
1.0.9, it baddly demaged myfaces. Just because I have products using myfaces,
I have to use it. My few friends give up away from myfaces already.
Guys, what's going on
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-694) t:dataTable bind calculate order error
[ http://issues.apache.org/jira/browse/MYFACES-694?page=all ]
Mathias Broekelmann closed MYFACES-694:
---
Resolution: Invalid
HTML 4.01 spec says:
TFOOT must appear before TBODY within a TABLE definition so that user agents
can render the foot before receiving all of the (potentially numerous) rows of
data.
Which is the reason why myfaces renders the footer before the body.
t:dataTable bind calculate order error
---
Key: MYFACES-694
URL: http://issues.apache.org/jira/browse/MYFACES-694
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly
Environment: Tomcat 5.0.28, nightly build 10/10/2005
Reporter: Zhong Li
Priority: Critical
I have a list used in a datatable
t:dataTable value=#{playlistFactory.currentUnitMPOSPlayList}
var=playlistItem
h:column
f:facet name=header
h:outputText
value=#{messages['dealer_admin_length']}/
/f:facet
h:outputText
value=#{playlistItem.length}/
f:facet name=footer
h:outputText
value=#{playlistFactory.totalLength}/
/f:facet
/h:column
/t:dataTable
playlistFactory.totalLength called before
playlistFactory.currentUnitMPOSPlayList called. So I got totalLength always
0, playlistFactory.totalLengtht should be called after
playlistFactory.currentUnitMPOSPlayList
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-694) t:dataTable bind calculate order error
[
http://issues.apache.org/jira/browse/MYFACES-694?page=comments#action_12331825
]
Mathias Broekelmann commented on MYFACES-694:
-
forgot the link for the HTML 4.01 spec:
http://www.w3.org/TR/html4/struct/tables.html#h-11.2.3
t:dataTable bind calculate order error
---
Key: MYFACES-694
URL: http://issues.apache.org/jira/browse/MYFACES-694
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly
Environment: Tomcat 5.0.28, nightly build 10/10/2005
Reporter: Zhong Li
Priority: Critical
I have a list used in a datatable
t:dataTable value=#{playlistFactory.currentUnitMPOSPlayList}
var=playlistItem
h:column
f:facet name=header
h:outputText
value=#{messages['dealer_admin_length']}/
/f:facet
h:outputText
value=#{playlistItem.length}/
f:facet name=footer
h:outputText
value=#{playlistFactory.totalLength}/
/f:facet
/h:column
/t:dataTable
playlistFactory.totalLength called before
playlistFactory.currentUnitMPOSPlayList called. So I got totalLength always
0, playlistFactory.totalLengtht should be called after
playlistFactory.currentUnitMPOSPlayList
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-677) HtmlSelectOneMenu conversion error with SelectItemGroup
[
http://issues.apache.org/jira/browse/MYFACES-677?page=comments#action_12331594
]
Mathias Broekelmann commented on MYFACES-677:
-
IMO it´s a problem with the converter. The converter could handle empty strings
by simply returning null.
If someone uses a complex object for the value and an empty string to indicate
a null value he wouldn´t be able to use that if we don´t pass the empty string
to the converter.
HtmlSelectOneMenu conversion error with SelectItemGroup
---
Key: MYFACES-677
URL: http://issues.apache.org/jira/browse/MYFACES-677
Project: MyFaces
Type: Bug
Versions: 1.1.0
Environment: JRE 1.4.2_08 , Tomcat 4.1.27, Firefox
Reporter: Thomas A. Valletta
Assignee: Mathias Broekelmann
While attempting to match the selected SelectItem for an HtmlSelectOneMenu,
the matchValue method of SelectItemsUtil calls the getConvertedValue method
before checking to see if the SelectItem is really a SelectItemGroup. This
causes conversion errors. If the SelectItem.getValue() is null (I think that
it was before MyFaces1.1) then it would not call the getConvertedValue. But
now you get one ConversionException for every SelectItemGroup that has to be
checked before the matching SelectItem is found.
Here is the method stack:
_SelectItemsUtil.matchValue(FacesContext, Object, Iterator,
_SelectItemsUtil$_ValueConverter) line: 46
HtmlSelectOneMenu(UISelectOne).validateValue(FacesContext, Object) line: 52
HtmlSelectOneMenu(UIInput).validate(FacesContext) line: 269
HtmlSelectOneMenu(UIInput).processValidators(FacesContext) line: 144
Here is the method in MyFaces 1.1:
/**
* @param context the faces context
* @param value the value to check
* @param converter
* @param iterator contains instances of SelectItem
* @return if the value of a selectitem is equal to the given value
*/
public static boolean matchValue(FacesContext context, Object value,
Iterator selectItemsIter, _ValueConverter converter)
{
while (selectItemsIter.hasNext())
{
SelectItem item = (SelectItem) selectItemsIter.next();
Object itemValue = item.getValue();
if(converter != null itemValue instanceof String)
{
itemValue = converter.getConvertedValue(context,
(String)itemValue);
}
if (value.equals(itemValue))
{
return true;
}
if (item instanceof SelectItemGroup)
{
SelectItemGroup itemgroup = (SelectItemGroup) item;
SelectItem[] selectItems = itemgroup.getSelectItems();
if (selectItems != null
selectItems.length 0
matchValue(context, value, Arrays.asList(
selectItems).iterator(),
converter))
{
return true;
}
}
}
return false;
}
Thanks,
Tom
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-677) HtmlSelectOneMenu conversion error with SelectItemGroup
[
http://issues.apache.org/jira/browse/MYFACES-677?page=comments#action_12331598
]
Mathias Broekelmann commented on MYFACES-677:
-
that´s much better. The only thing is that I´m not sure if a SelectItemGroup is
not selectable in every case.
HtmlSelectOneMenu conversion error with SelectItemGroup
---
Key: MYFACES-677
URL: http://issues.apache.org/jira/browse/MYFACES-677
Project: MyFaces
Type: Bug
Versions: 1.1.0
Environment: JRE 1.4.2_08 , Tomcat 4.1.27, Firefox
Reporter: Thomas A. Valletta
Assignee: Mathias Broekelmann
While attempting to match the selected SelectItem for an HtmlSelectOneMenu,
the matchValue method of SelectItemsUtil calls the getConvertedValue method
before checking to see if the SelectItem is really a SelectItemGroup. This
causes conversion errors. If the SelectItem.getValue() is null (I think that
it was before MyFaces1.1) then it would not call the getConvertedValue. But
now you get one ConversionException for every SelectItemGroup that has to be
checked before the matching SelectItem is found.
Here is the method stack:
_SelectItemsUtil.matchValue(FacesContext, Object, Iterator,
_SelectItemsUtil$_ValueConverter) line: 46
HtmlSelectOneMenu(UISelectOne).validateValue(FacesContext, Object) line: 52
HtmlSelectOneMenu(UIInput).validate(FacesContext) line: 269
HtmlSelectOneMenu(UIInput).processValidators(FacesContext) line: 144
Here is the method in MyFaces 1.1:
/**
* @param context the faces context
* @param value the value to check
* @param converter
* @param iterator contains instances of SelectItem
* @return if the value of a selectitem is equal to the given value
*/
public static boolean matchValue(FacesContext context, Object value,
Iterator selectItemsIter, _ValueConverter converter)
{
while (selectItemsIter.hasNext())
{
SelectItem item = (SelectItem) selectItemsIter.next();
Object itemValue = item.getValue();
if(converter != null itemValue instanceof String)
{
itemValue = converter.getConvertedValue(context,
(String)itemValue);
}
if (value.equals(itemValue))
{
return true;
}
if (item instanceof SelectItemGroup)
{
SelectItemGroup itemgroup = (SelectItemGroup) item;
SelectItem[] selectItems = itemgroup.getSelectItems();
if (selectItems != null
selectItems.length 0
matchValue(context, value, Arrays.asList(
selectItems).iterator(),
converter))
{
return true;
}
}
}
return false;
}
Thanks,
Tom
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-680) x:selectOneRadio tag cannot be nested within the h:dataTable tag in version 1.1.0
[ http://issues.apache.org/jira/browse/MYFACES-680?page=all ]
Mathias Broekelmann closed MYFACES-680:
---
Resolution: Duplicate
it´s already fixed. See MYFACES-592. It should be available with 1.1.1 release
(or current release candidate)
x:selectOneRadio tag cannot be nested within the h:dataTable tag in version
1.1.0
-
Key: MYFACES-680
URL: http://issues.apache.org/jira/browse/MYFACES-680
Project: MyFaces
Type: Bug
Versions: 1.1.0
Environment: Windows XP Pro sp2, Tomcat 4.1.31
Reporter: Jason Allen
Priority: Minor
I've run into an issue with version 1.1.0 when trying to implement a
x:selectOneRadio tag within the h:dataTable tag where only one row from the
data table can have the radio button selected. In version 1.0.9, I used the
forceId and forceIdIndex attributes in the x:selectOneRadio tag to force the
id of each x:selectOneRadio to be the same. Each row in the h:dataTable will
have x:selectOneRadio with only one SelectItem in it, but since the id's are
the same, the browser handles it correctly.
However, with version 1.1.0 in the validateValue(FacesContext, Object) method
of the javax.faces.component.UISelectOne class, there is a call to
_SelectItemsUtil.matchValue(FacesContext, Object, Iterator, _ValueConverter)
which checks to see if the selected value of the x:selectOneRadio exists in
the list of SelectItems. Since each row in the data table has a
x:selectOneRadio with only one SelectItem, this check will only return true
for the row where the radio button is selected. All other rows cause this
check to fail and add a 'Value is not a valid option' error to the context
messages list, which prevents the page from performing any other actions.
Here is an example of how I am using the x:selectOneRadio:
h:dataTable
cellspacing=0
style=padding-top: 0px; padding-bottom: 0px;
styleClass=form-sub-table
value=#{backingBean.personList}
var=person
h:column
h:outputText value=#{person.firstName} #{person.lastName}
escape=false /
/h:column
h:column
x:selectOneRadio id=preside
forceId=true
forceIdIndex=0
value=#{backingBean.presidePersonId}
valueChangeListener=#{backingBean.presideOverride}
style=margin: 0px; border: 0px;
border=0
f:selectItem itemValue=#{person.personId}
itemLabel= /
/x:selectOneRadio
/h:column
/h:dataTable
It's not completely clear to me why the existence of the x:selectOneRadio
value in it's child SelectItems needs to be enforced so strictly. I propose
that this check be either optional or eliminated all toghether.
Thanks,
Jason Allen
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-675) Unexpected tag table in dataScroller paginator
[ http://issues.apache.org/jira/browse/MYFACES-675?page=all ] Mathias Broekelmann closed MYFACES-675: --- Resolution: Fixed fixed in r306652 Unexpected tag table in dataScroller paginator -- Key: MYFACES-675 URL: http://issues.apache.org/jira/browse/MYFACES-675 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.0 Environment: Windows XP; Apache Tomcat 5.5; IE 6 and Firefox 1.0 Reporter: Diego Trombetta Priority: Minor When rendering the dataScroller component that displays the info about the number of pages, the current page, ... after the span tag that includes this information there in an empty table: span class=standard994 Cars found, displaying 10 cars, from 1 to 10. Page 1 / 100/spantabletr/tr/table If you want to obtain this behaviour, just look at the DataScroller example in the standard myfaces examples. This empty table compromises the layout of the pages... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-224) x:dataTable, x:columns and x:commandSortHeader not sorting the data
[
http://issues.apache.org/jira/browse/MYFACES-224?page=comments#action_12331360
]
Mathias Broekelmann commented on MYFACES-224:
-
Please post the jsp/bean code which produces it.
x:dataTable, x:columns and x:commandSortHeader not sorting the data
---
Key: MYFACES-224
URL: http://issues.apache.org/jira/browse/MYFACES-224
Project: MyFaces
Type: Bug
Versions: 1.0.9m9
Environment: tomcat5.5, java5 update 3,
Reporter: Alex Mayer
The x:commandSortHeader is not working if nested inside of x:columns (which
is nested in x:dataTable)
my code is like this:
x:dataTable id=data value=#{manager.sortList.dataObjectsToSort} var=b
rows=4
sortColumn=#{manager.sortList.sort}
sortAscending=#{manager.sortList.ascending}
preserveSort=true preserveDataModel=true
x:columns value=#{manager.headerStrings} var=column
f:facet name=header
h:panelGroup
h:selectBooleanCheckbox /
x:commandSortHeader columnName=#{column}
arrow=true
h:outputText value=#{column} /
/x:commandSortHeader
/h:panelGroup
/f:facet
h:outputText value=#{b[column]} /
/x:columns
/x:dataTable
in case I use a component-binding for the x:dataTable to generate a
corresponding table in a bean, everything works fine.
I believe this is, because the x:columns-tag assigns to every childcomponent
of type commandSortHeader the same id.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-636) t:selectOneRadio validation messages in dataTable
[ http://issues.apache.org/jira/browse/MYFACES-636?page=all ] Mathias Broekelmann closed MYFACES-636: --- Fix Version: 1.1.1 Resolution: Fixed commited the patch into the 1.1.1 branch (will be merged later into trunk) t:selectOneRadio validation messages in dataTable - Key: MYFACES-636 URL: http://issues.apache.org/jira/browse/MYFACES-636 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.0, 1.0.9m9, Nightly Environment: All Tested (JBoss, Tomcat on Win 2000, and Win 2003). Code analysis identifies that this bug would occour on all environments. Reporter: Jamie Cash Assignee: Mathias Broekelmann Fix For: 1.1.1 Attachments: 636.patch.diff, 636_2.patch.diff If the tomahawk selectOneRadio is used in a datatable (forceId = true, forceIdIndex = false) and required is true and no items are selected, then a validation error message will be added for every radio button in the data table. This message should only occour once for the set. forceId = true and forceIdIndex = false identifies that all radio buttons with the same id are within the same group, and should be validated accordingly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-604) CommandLink CommandButton do not invoke action if render inside the table
[ http://issues.apache.org/jira/browse/MYFACES-604?page=all ]
Mathias Broekelmann closed MYFACES-604:
---
Resolution: Won't Fix
the datatable needs it´s value during the processDecode phase. Please make sure
that your returned datamodel contains some data and is not null. Place a
breakpoint in your value getter method of the datatable and hit the
commandlink. If you return null or an empty datamodel (or collection) the
datatable is not able to iterate through the rows and can not fire the action
events.
CommandLink CommandButton do not invoke action if render inside the table
---
Key: MYFACES-604
URL: http://issues.apache.org/jira/browse/MYFACES-604
Project: MyFaces
Type: Bug
Versions: 1.1.0
Environment: XP professional, IE, Firefox
Reporter: Hovan
I have the table 3 columns, one column i render as commandLink or
commandButton. The problem is the action at the backend never got invoke.
I try another test by put one link out side of the table block. It works very
OK.
One more thing is: if csCardSearchHandler has session scope it's also OK. But
in my case csCardSearchHandler has request scope. I did try version 1.0.9 and
then 1.1.0 neither of those work.
x:dataTable id=accountResult value=#{csCardSearchHandler.accountResult}
var=account
rows=10 rowIndexVar = rowIdx renderedIfEmpty=false
h:column
f:facet name=header
h:outputText value=[No.]/
/f:facet
h:outputText value=#{rowIdx}/
/h:column
h:column
f:facet name=header
h:outputText value=[Account No.]/
/f:facet
!-- THIS DOES NOT WORK --
x:commandLink action=#{csCardSearchHandler.processResume}
value=#{account.number}
/x:commandLink
/h:column
h:column
f:facet name=header
h:outputText value=[Name]/
/f:facet
h:outputText value=#{account.name}/
/h:column
h:column
f:facet name=header
h:outputText value=[SSN]/
/f:facet
h:outputText value=#{account.ssn}/
/h:column
/x:dataTable
!-- THIS IS OK--
x:commandLink action=#{csCardSearchHandler.processResume}
value=test
x:updateActionListener
property=#{csCardRequestHandler.accountNumber}
value=/
x:updateActionListener
property=#{csCardRequestHandler.cardDetail.name}
value=/
/x:commandLink
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-621) Tree2 commandLink not firing until second click
[ http://issues.apache.org/jira/browse/MYFACES-621?page=comments#action_12330566 ] Mathias Broekelmann commented on MYFACES-621: - we could process the nodes regardless of the expanded state of their parent. Tree2 commandLink not firing until second click --- Key: MYFACES-621 URL: http://issues.apache.org/jira/browse/MYFACES-621 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: Windows XP, IE Reporter: Ryan Wynn Priority: Minor Tree2 node commandLinks are not firing their associated method bindings until the commandLink is clicked the second time. This only happens when the node is shown for the first time after being expanded. For example, given tree A |_ B When tree is in collapsed state, simply A and then expanded as shown above, the first click to B does not invoke associated method binding for B. A subsequent click to B will work properly. This is happening subsequent to MYFACES-580, which fixed the bug where duplicate ids where being complained about. Not sure if the 2 are related. This is ocurring in 9/24 nightly build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-606) Tomahawk selectOneRadio doesn't validate. This is a side affect of patch for fixed issue 592.
[ http://issues.apache.org/jira/browse/MYFACES-606?page=comments#action_12330569 ] Mathias Broekelmann commented on MYFACES-606: - I´ve applied your patch (r291894). I have modified it a little bit since you used JDK 1.5 syntax for autoboxing. It seams to work now but if you make the radio button required you get a validator exception for each row which might not be desired. Tomahawk selectOneRadio doesn't validate. This is a side affect of patch for fixed issue 592. - Key: MYFACES-606 URL: http://issues.apache.org/jira/browse/MYFACES-606 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: All Reporter: Jamie Cash Attachments: 606.patch.txt I have rewritten my patch for issue 592 to avoid the side affects described above. I couldn't add the patch to 592 as that was closed so have had to raise this issue instead. Patch to follow shortly. After the patch is applied, the component will now behave exacly as before (call to super), if forceId is false or forceIdIndex is true, but will branch into logic similar to that in UIInput if forceId is true AND forceIdIndex is false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-562) t:commandSortHeader processes action / actionListener before updating values of sortColumn and sortAscending
[ http://issues.apache.org/jira/browse/MYFACES-562?page=comments#action_12330571 ] Mathias Broekelmann commented on MYFACES-562: - t:datatable don´t have action or actionListener properties. If your have created your own component which supports it you have to make sure that the action is fired in the invoke application phase which comes right after the update phase. t:commandSortHeader processes action / actionListener before updating values of sortColumn and sortAscending -- Key: MYFACES-562 URL: http://issues.apache.org/jira/browse/MYFACES-562 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.0 Reporter: Erik-Berndt Scheper At the moment t:CommandSortHeader processes an action / actionListener before updating the values of sortColumn and sortAscending. The reason is that in the broadcast() method of HtmlCommandSortHeader.java, the method super.broadcast(event) is executed before the values are updated. The consequence of this bug is that in the methods called by the action / actionListener, the sortColumn and sortAscending properties of the datatable still have the old value. Which in turn means that any sorting performed in the action / actionListener methods lead to incorrect results. Suggested solution: call super.broadcast(event) AFTER the values of the datatable have been updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-581) Frames
[
http://issues.apache.org/jira/browse/MYFACES-581?page=comments#action_12330572
]
Mathias Broekelmann commented on MYFACES-581:
-
Could it be a problem with the state? Are you using server or client state?
myfaces currently only holds the last state if using server state. RI holds up
to 15 AFAIK.
Frames
--
Key: MYFACES-581
URL: http://issues.apache.org/jira/browse/MYFACES-581
Project: MyFaces
Type: Bug
Components: Implementation
Environment: any
Reporter: SergeyM
Priority: Critical
Actions for tabbed panel
I have two frames. First navigation frame has command buttons.
h:form id=form1 target=secondFrame
h:commandButton value=action1 action=#{testBean.action1}/
h:commandButton value=action2 action=#{testBean.action2}/
/h:form
Second frame has to get result depending on selected button of the first
frame(target=secondFrame).
When I ckicks first time on the Action1 then the second frame gets result of
the action1 - OK.(Action executed)
But if I clicks second time on the button the first frame is in the second
frame - WRONG. (Action didn't execute) Must be result as in previous step.
Third time when I ckicks on the Action1 then the second frame gets result of
the action1 - OK.
Fourth - WRONG an so on.
I found if action doesn't redirect to another page then it seems OK.
Action executes each time when I press an action button on the first page.
I have tried this sample using SUN RI and everything OK.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-606) Tomahawk selectOneRadio doesn't validate. This is a side affect of patch for fixed issue 592.
[ http://issues.apache.org/jira/browse/MYFACES-606?page=all ] Mathias Broekelmann closed MYFACES-606: --- Resolution: Fixed Tomahawk selectOneRadio doesn't validate. This is a side affect of patch for fixed issue 592. - Key: MYFACES-606 URL: http://issues.apache.org/jira/browse/MYFACES-606 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: All Reporter: Jamie Cash Attachments: 606.patch.txt I have rewritten my patch for issue 592 to avoid the side affects described above. I couldn't add the patch to 592 as that was closed so have had to raise this issue instead. Patch to follow shortly. After the patch is applied, the component will now behave exacly as before (call to super), if forceId is false or forceIdIndex is true, but will branch into logic similar to that in UIInput if forceId is true AND forceIdIndex is false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-592) tomahawke SelectOneRadio in datatable no longer working
[ http://issues.apache.org/jira/browse/MYFACES-592?page=all ]
Mathias Broekelmann closed MYFACES-592:
---
Resolution: Fixed
tomahawke SelectOneRadio in datatable no longer working
---
Key: MYFACES-592
URL: http://issues.apache.org/jira/browse/MYFACES-592
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.0, Nightly Build
Environment: Tomcat 5.5 running under JBoss on Windows Server 2003
Reporter: Jamie Cash
Assignee: Grant Smith
Fix For: Nightly Build
Attachments: 606.patch.txt, diff.txt, screenprint.bmp
The tomahawke selectOneRadio (t:selectOneRadio previously x:selectOneRadio)
in a datatable no longer works correctly. On selection of an item and
submission of the form a ('Validation Error', {0}: Value is not a valid
option') message is added to the messages.
This worked correctly in myfaces 1.0.9 but not in the last nightly build.
Below is a subset of my jsp that outputs the column:
h:column
f:facet name=header
h:outputText value=#{bundle.label_select}/
/f:facet
t:selectOneRadio id=selectRadio forceId=true forceIdIndex=false
required=true value=#{ClientSearchBean.selectedExtClientId}
f:selectItem itemValue=#{client.extClientId} itemLabel=/
/t:selectOneRadio
/h:column
The 'value; points to a string value in the backing bean and the itemValue
points to the same string value in the Client domain object, of which the
table is driven from.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-597) HTMLRadioRenderer not showing selected item
[ http://issues.apache.org/jira/browse/MYFACES-597?page=all ] Mathias Broekelmann closed MYFACES-597: --- Resolution: Fixed already fixed. see MYFACES-570 HTMLRadioRenderer not showing selected item --- Key: MYFACES-597 URL: http://issues.apache.org/jira/browse/MYFACES-597 Project: MyFaces Type: Bug Components: Implementation Versions: 1.1.0 Reporter: Timo Thomas Assignee: Mathias Broekelmann This bug is similar to MYFACES-144 (http://issues.apache.org/jira/browse/MYFACES-144) To reproduce the bug a complex object (other than string) must be used as the value for SelectItem. The object is converted by using a Converter to a string value. The method HtmlRendererBase.renderGroupOrItemRadio(...) tests the complex object with the converted value which is only working if a string is used as a value for the selectitem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-586) NPE in UIData.restoreDescendantComponentStates()
[ http://issues.apache.org/jira/browse/MYFACES-586?page=all ]
Mathias Broekelmann closed MYFACES-586:
---
Resolution: Fixed
Thanks a lot for tracking this down!
I´ve commited a fix for this in r290681
NPE in UIData.restoreDescendantComponentStates()
Key: MYFACES-586
URL: http://issues.apache.org/jira/browse/MYFACES-586
Project: MyFaces
Type: Bug
Components: Implementation
Versions: 1.1.0
Environment: w2k, jboss-4.0.2, tomcat55
Reporter: Pavel Stetsuk
Assignee: Mathias Broekelmann
Error like MYFACES-520
I have JSP like:
f:view
...
h:form id=form-edit
...
h:dataTable id=grid
value=#{nagrevBean.nagrevDTOs} var=nagrevDTO
h:column id=flagSaveColumn
rendered=#{!authenticationBean.guestAuthorized}
f:facet name=header
h:outputText id=flagSaveColumnHeader value=+ /
/f:facet
h:selectBooleanCheckbox id=flagSaveInput
value=#{nagrevDTO.flagSave} rendered=#{nagrevDTO.canSave} /
/h:column
/h:dataTable
/h:form
/f:view
When a value is entered in the required inputText field, the form submits
successfully. But in RENDER_RESPONSE phase i have error
java.lang.NullPointerException
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
at javax.faces.component.UIData.setRowIndex(UIData.java:186)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeInnerHtml(HtmlTableRendererBase.java:135)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeChildren(HtmlTableRendererBase.java:94)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319)
at
javax.faces.webapp.UIComponentTag.encodeChildren(UIComponentTag.java:343)
at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:251)
at
org.apache.myfaces.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:55)
at
org.apache.jsp.nagrev_jsp._jspx_meth_h_dataTable_0(org.apache.jsp.nagrev_jsp:1672)
at org.apache.jsp.nagrev_jsp._jspService(org.apache.jsp.nagrev_jsp:286)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:95)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
com.azovstal.asctp.web.HibernateFilter.doFilter(HibernateFilter.java:35)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
[jira] Commented: (MYFACES-586) NPE in UIData.restoreDescendantComponentStates()
[
http://issues.apache.org/jira/browse/MYFACES-586?page=comments#action_12329973
]
Mathias Broekelmann commented on MYFACES-586:
-
I wasn´t able to reproduce the problem.
I think the problem is somthing else.
Can you post the whole jsp source of your datatable?
NPE in UIData.restoreDescendantComponentStates()
Key: MYFACES-586
URL: http://issues.apache.org/jira/browse/MYFACES-586
Project: MyFaces
Type: Bug
Components: Implementation
Versions: 1.1.0
Environment: w2k, jboss-4.0.2, tomcat55
Reporter: Pavel Stetsuk
Assignee: Mathias Broekelmann
Error like MYFACES-520
I have JSP like:
f:view
...
h:form id=form-edit
...
h:dataTable id=grid
value=#{nagrevBean.nagrevDTOs} var=nagrevDTO
h:column id=flagSaveColumn
rendered=#{!authenticationBean.guestAuthorized}
f:facet name=header
h:outputText id=flagSaveColumnHeader value=+ /
/f:facet
h:selectBooleanCheckbox id=flagSaveInput
value=#{nagrevDTO.flagSave} rendered=#{nagrevDTO.canSave} /
/h:column
/h:dataTable
/h:form
/f:view
When a value is entered in the required inputText field, the form submits
successfully. But in RENDER_RESPONSE phase i have error
java.lang.NullPointerException
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
at javax.faces.component.UIData.setRowIndex(UIData.java:186)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeInnerHtml(HtmlTableRendererBase.java:135)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeChildren(HtmlTableRendererBase.java:94)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319)
at
javax.faces.webapp.UIComponentTag.encodeChildren(UIComponentTag.java:343)
at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:251)
at
org.apache.myfaces.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:55)
at
org.apache.jsp.nagrev_jsp._jspx_meth_h_dataTable_0(org.apache.jsp.nagrev_jsp:1672)
at org.apache.jsp.nagrev_jsp._jspService(org.apache.jsp.nagrev_jsp:286)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:95)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
com.azovstal.asctp.web.HibernateFilter.doFilter(HibernateFilter.java:35)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
[jira] Commented: (MYFACES-562) t:commandSortHeader processes action / actionListener before updating values of sortColumn and sortAscending
[ http://issues.apache.org/jira/browse/MYFACES-562?page=comments#action_12329407 ] Mathias Broekelmann commented on MYFACES-562: - Are you sure that you use 1.0.10m10? We fixed that already and the examples do work. It was not working in 1.0.9. t:commandSortHeader processes action / actionListener before updating values of sortColumn and sortAscending -- Key: MYFACES-562 URL: http://issues.apache.org/jira/browse/MYFACES-562 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.0.10m10 Reporter: Erik-Berndt Scheper At the moment t:CommandSortHeader processes an action / actionListener before updating the values of sortColumn and sortAscending. The reason is that in the broadcast() method of HtmlCommandSortHeader.java, the method super.broadcast(event) is executed before the values are updated. The consequence of this bug is that in the methods called by the action / actionListener, the sortColumn and sortAscending properties of the datatable still have the old value. Which in turn means that any sorting performed in the action / actionListener methods lead to incorrect results. Suggested solution: call super.broadcast(event) AFTER the values of the datatable have been updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-522) PreserveDataModel not working (java.lang.IllegalArgumentException: row is unavailable)
[
http://issues.apache.org/jira/browse/MYFACES-522?page=comments#action_12329409
]
Mathias Broekelmann commented on MYFACES-522:
-
I´ve tried to reproduce the problem but found everything working with the
current nightly.
dataModel.setRowIndex(...) only throws an IllegalArgumentException if the given
value is less than -1 which is not the case.
Is it possible to post a stacktrace of the Exception you get?
PreserveDataModel not working (java.lang.IllegalArgumentException: row is
unavailable)
--
Key: MYFACES-522
URL: http://issues.apache.org/jira/browse/MYFACES-522
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly Build
Environment: N/A
Reporter: Enrique Medina Montenegro
Attachments: _SerializableDataModel_Patch.txt
When setting the preserveDataModel attribute in a dataTable, a new
_SerializableDataModel is internally build by MyFaces.
However, if the number of rows to display is less than the total number of
possible rows, an IllegalArgumentException is thrown. This problem is caused
by the following bunch of lines in the _SerializableDataModel constructor
(public _SerializableDataModel(int first, int rows, DataModel dataModel)):
_list = new ArrayList(rows);
for (int i = 0; i _rows; i++)
{
dataModel.setRowIndex(_first + i);
if (!dataModel.isRowAvailable()) break;
_list.add(dataModel.getRowData());
}
_rowIndex = -1;
As can be clearly seen, first the dataModel.setRowIndex is set, independently
of whether the row is really available or not, as it is checked after.
The solution would be as simple as swapping the order:
_list = new ArrayList(rows);
for (int i = 0; i _rows; i++)
{
if (!dataModel.isRowAvailable()) break;
dataModel.setRowIndex(_first + i);
_list.add(dataModel.getRowData());
}
_rowIndex = -1;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-522) PreserveDataModel not working (java.lang.IllegalArgumentException: row is unavailable)
[ http://issues.apache.org/jira/browse/MYFACES-522?page=all ]
Mathias Broekelmann closed MYFACES-522:
---
Resolution: Cannot Reproduce
problem can not be reproduced with the current nightly.
PreserveDataModel not working (java.lang.IllegalArgumentException: row is
unavailable)
--
Key: MYFACES-522
URL: http://issues.apache.org/jira/browse/MYFACES-522
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly Build
Environment: N/A
Reporter: Enrique Medina Montenegro
Attachments: _SerializableDataModel_Patch.txt
When setting the preserveDataModel attribute in a dataTable, a new
_SerializableDataModel is internally build by MyFaces.
However, if the number of rows to display is less than the total number of
possible rows, an IllegalArgumentException is thrown. This problem is caused
by the following bunch of lines in the _SerializableDataModel constructor
(public _SerializableDataModel(int first, int rows, DataModel dataModel)):
_list = new ArrayList(rows);
for (int i = 0; i _rows; i++)
{
dataModel.setRowIndex(_first + i);
if (!dataModel.isRowAvailable()) break;
_list.add(dataModel.getRowData());
}
_rowIndex = -1;
As can be clearly seen, first the dataModel.setRowIndex is set, independently
of whether the row is really available or not, as it is checked after.
The solution would be as simple as swapping the order:
_list = new ArrayList(rows);
for (int i = 0; i _rows; i++)
{
if (!dataModel.isRowAvailable()) break;
dataModel.setRowIndex(_first + i);
_list.add(dataModel.getRowData());
}
_rowIndex = -1;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-570) selectOneRadio does not render the inital selected radio button if using an other than String for the SelectItems value.
selectOneRadio does not render the inital selected radio button if using an other than String for the SelectItems value. Key: MYFACES-570 URL: http://issues.apache.org/jira/browse/MYFACES-570 Project: MyFaces Type: Bug Components: Implementation Reporter: Mathias Broekelmann Assigned to: Mathias Broekelmann The value of the SelectItem is converted to String before it checked for equality against the current value which is still a complex value if it was returned by UISelectOne.getValue(). I will commit a fix for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-570) selectOneRadio does not render the inital selected radio button if using an other than String for the SelectItems value.
[ http://issues.apache.org/jira/browse/MYFACES-570?page=all ] Mathias Broekelmann closed MYFACES-570: --- Resolution: Fixed fixed in r289194 selectOneRadio does not render the inital selected radio button if using an other than String for the SelectItems value. Key: MYFACES-570 URL: http://issues.apache.org/jira/browse/MYFACES-570 Project: MyFaces Type: Bug Components: Implementation Reporter: Mathias Broekelmann Assignee: Mathias Broekelmann The value of the SelectItem is converted to String before it checked for equality against the current value which is still a complex value if it was returned by UISelectOne.getValue(). I will commit a fix for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-562) t:commandSortHeader processes action / actionListener before updating values of sortColumn and sortAscending
[ http://issues.apache.org/jira/browse/MYFACES-562?page=comments#action_12324526 ] Mathias Broekelmann commented on MYFACES-562: - sortheader component uses immediate=true for default. Please verify if you set immediate=false for the sortheader component. t:commandSortHeader processes action / actionListener before updating values of sortColumn and sortAscending -- Key: MYFACES-562 URL: http://issues.apache.org/jira/browse/MYFACES-562 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.0.10m10 Reporter: Erik-Berndt Scheper At the moment t:CommandSortHeader processes an action / actionListener before updating the values of sortColumn and sortAscending. The reason is that in the broadcast() method of HtmlCommandSortHeader.java, the method super.broadcast(event) is executed before the values are updated. The consequence of this bug is that in the methods called by the action / actionListener, the sortColumn and sortAscending properties of the datatable still have the old value. Which in turn means that any sorting performed in the action / actionListener methods lead to incorrect results. Suggested solution: call super.broadcast(event) AFTER the values of the datatable have been updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-564) tree2 node toggle is alway immediate if server side toggle is used.
tree2 node toggle is alway immediate if server side toggle is used. --- Key: MYFACES-564 URL: http://issues.apache.org/jira/browse/MYFACES-564 Project: MyFaces Type: Bug Components: Tomahawk Reporter: Mathias Broekelmann Assigned to: Mathias Broekelmann if using an input component in a node facet, the processDecode, processValidation, processUpdate methods of nested UIInput component gets called even if the parent node wasn´t expanded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-564) tree2 node toggle is alway immediate if server side toggle is used.
[ http://issues.apache.org/jira/browse/MYFACES-564?page=all ] Mathias Broekelmann closed MYFACES-564: --- Resolution: Fixed fixed in r280882 tree2 node toggle is alway immediate if server side toggle is used. --- Key: MYFACES-564 URL: http://issues.apache.org/jira/browse/MYFACES-564 Project: MyFaces Type: Bug Components: Tomahawk Reporter: Mathias Broekelmann Assignee: Mathias Broekelmann if using an input component in a node facet, the processDecode, processValidation, processUpdate methods of nested UIInput component gets called even if the parent node wasn´t expanded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-445) inputCalendar popup calendar displays incorrectly if year field is left blank
[ http://issues.apache.org/jira/browse/MYFACES-445?page=comments#action_12329359 ] Mathias Broekelmann commented on MYFACES-445: - year selection in popup is not working at all. inputCalendar popup calendar displays incorrectly if year field is left blank - Key: MYFACES-445 URL: http://issues.apache.org/jira/browse/MYFACES-445 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: Windows XP/Solaris 8 Tomcat 5.0.28 Reporter: Mark Faine Assignee: Martin Marinschek Priority: Blocker Fix For: Nightly Build Attachments: myfacespatchff2.txt If the year field is left blank the popup calandar will display horizontally. The year field will show NaN. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-558) Implementation of rowOnClick attribute for t:dataTable breaks underlying links in columns
[ http://issues.apache.org/jira/browse/MYFACES-558?page=all ] Mathias Broekelmann closed MYFACES-558: --- Resolution: Invalid I don´t see why we should change this. IMO rowOnClick is exactly meant to work as tr onClick= If you need td onClick=... use t:column for that. The only thing I see is to introduce something like rowOnClickAction and rowOnClickActionListener which let the user bind an action to the row event onClick. Implementation of rowOnClick attribute for t:dataTable breaks underlying links in columns - Key: MYFACES-558 URL: http://issues.apache.org/jira/browse/MYFACES-558 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.0.10m10 Reporter: Erik-Berndt Scheper The current implementation of rowOnClick in t:dataTable generates the following template html: tr onclick=. td/td td/td /tr This sounds a logical implementation, but it has one severe drawback: In Internet Explorer (yuk) and Firefox this implies that links in the columns (such as a command link) are no longer executed, because the tr onclick handler gets precedence. I suggest to change the implementation to tr td onclick=./td td onclick=./td /tr However, care must be taken that the onclick handler on the td attribute is NOT generated if the column contains an ActionSource. Otherwise it is still impossible to click on the underlying links :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-476) commandButton doesn't renders well the application-dependent image urls
[ http://issues.apache.org/jira/browse/MYFACES-476?page=comments#action_12323034 ] Mathias Broekelmann commented on MYFACES-476: - the application context path should be prefixed to the path given by the image attribute. I could not find a note about this in the spec. So I agree changing this. Although that would break existing apps if they used a workaround for that. Any other opinions? commandButton doesn't renders well the application-dependent image urls --- Key: MYFACES-476 URL: http://issues.apache.org/jira/browse/MYFACES-476 Project: MyFaces Type: Bug Components: Implementation Versions: Nightly Build Environment: Version 2005.08.28 Reporter: Csaba Sebastian Whenever the graphicImage component renders it's url attribute by passing it through the viewhandler (see org.apache.myfaces.renderkit.html.HtmlImageRendererBase.java: line 66-70), and encoded as an application-dependent url if required; if I set the image attribute for a commandButton component, it's image attribute rendered as it is (see org.apache.myfaces.renderkit.html.HtmlButtonRendererBase.java: line 91). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-543) Problems handling simultaneous request from the same session
[ http://issues.apache.org/jira/browse/MYFACES-543?page=comments#action_12323038 ] Mathias Broekelmann commented on MYFACES-543: - Do you use client or server state saving? Problems handling simultaneous request from the same session Key: MYFACES-543 URL: http://issues.apache.org/jira/browse/MYFACES-543 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9 Reporter: Marcus Schiesser If someone tries to do simultaneous client requests from the same HttpSession instance (i used a direct resubmit in the form tag's onsubmit handler which leads to two simultaneous requests) it will lead to concurrent access problems. During my tests, it almost any time crashed in the UIViewRoot implementation. The reason is that it is not thread-safe which could be easily solved by synchronising the 4 process methods and the queueEvent method. But the question is where to put the synchronisation, i also tried synchronising the service method of the FacesServlet class, so that only one HttpSession could run at the time (IMHO something desirable). That way the simultaneous request are processed one after the other. But a further question arises then: How MyFaces handles the problem if two identically request are processed in the lifecycle - is this appart from the rendering (in my tests SocketExceptions occured as the connection has been reset before) a problem? Does it affect the state? What are your opinions concerning this topic? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-543) Problems handling simultaneous request from the same session
[ http://issues.apache.org/jira/browse/MYFACES-543?page=comments#action_12323043 ] Mathias Broekelmann commented on MYFACES-543: - I mean the setting of javax.faces.STATE_SAVING_METHOD in your web.xml Problems handling simultaneous request from the same session Key: MYFACES-543 URL: http://issues.apache.org/jira/browse/MYFACES-543 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9 Reporter: Marcus Schiesser If someone tries to do simultaneous client requests from the same HttpSession instance (i used a direct resubmit in the form tag's onsubmit handler which leads to two simultaneous requests) it will lead to concurrent access problems. During my tests, it almost any time crashed in the UIViewRoot implementation. The reason is that it is not thread-safe which could be easily solved by synchronising the 4 process methods and the queueEvent method. But the question is where to put the synchronisation, i also tried synchronising the service method of the FacesServlet class, so that only one HttpSession could run at the time (IMHO something desirable). That way the simultaneous request are processed one after the other. But a further question arises then: How MyFaces handles the problem if two identically request are processed in the lifecycle - is this appart from the rendering (in my tests SocketExceptions occured as the connection has been reset before) a problem? Does it affect the state? What are your opinions concerning this topic? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-509) StateManager.saveSerializedView must throw an IllegalStateException when View contains duplicate IDs
[ http://issues.apache.org/jira/browse/MYFACES-509?page=all ] Mathias Broekelmann updated MYFACES-509: Attachment: myfaces509.diff I could have commited this but to avoid a discussion in through commits I attach a patch to this issue: It uses the compontent ids and NamingContainer to check duplicate ids. StateManager.saveSerializedView must throw an IllegalStateException when View contains duplicate IDs Key: MYFACES-509 URL: http://issues.apache.org/jira/browse/MYFACES-509 Project: MyFaces Type: Bug Components: JSR-127 Versions: 1.0.9m9 Reporter: Bruno Aranda Assignee: Martin Marinschek Fix For: Nightly Build Attachments: myfaces509.diff Acording to the javadocs, the method StateManager.saveSerializedView must throw an IllegalStateException if more than one component or facet within the same NamingContainer in this view has the same non-null component id. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-509) StateManager.saveSerializedView must throw an IllegalStateException when View contains duplicate IDs
[ http://issues.apache.org/jira/browse/MYFACES-509?page=all ] Mathias Broekelmann closed MYFACES-509: --- Resolution: Fixed just added my patch StateManager.saveSerializedView must throw an IllegalStateException when View contains duplicate IDs Key: MYFACES-509 URL: http://issues.apache.org/jira/browse/MYFACES-509 Project: MyFaces Type: Bug Components: JSR-127 Versions: 1.0.9m9 Reporter: Bruno Aranda Assignee: Mathias Broekelmann Fix For: Nightly Build Attachments: myfaces509.diff Acording to the javadocs, the method StateManager.saveSerializedView must throw an IllegalStateException if more than one component or facet within the same NamingContainer in this view has the same non-null component id. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-528) JspStateManagerImpl.checkForDuplicateIds breaks dataScroller component
[ http://issues.apache.org/jira/browse/MYFACES-528?page=all ] Mathias Broekelmann closed MYFACES-528: --- Resolution: Fixed Assign To: Mathias Broekelmann Fix is commited. Renderer of DataScroller added the scroller facets to the created links which results in a copy in the component tree. Check for unique component ids will work now. JspStateManagerImpl.checkForDuplicateIds breaks dataScroller component -- Key: MYFACES-528 URL: http://issues.apache.org/jira/browse/MYFACES-528 Project: MyFaces Type: Bug Components: Implementation Versions: Nightly Build Environment: Any Reporter: Erik-Berndt Scheper Assignee: Mathias Broekelmann Priority: Critical A javax.faces.FacesException is thrown if duplicate Id´s are detected by the JspStateManagerImpl.checkForDuplicateIds(). However, this breaks the dataScroller component when a paginator with graphic images is used. (such as in the Data Scroller example (in simple.war) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-532) NoSuchElementException in SelectItemsIterator
[ http://issues.apache.org/jira/browse/MYFACES-532?page=all ] Mathias Broekelmann closed MYFACES-532: --- Resolution: Fixed fix is commited NoSuchElementException in SelectItemsIterator - Key: MYFACES-532 URL: http://issues.apache.org/jira/browse/MYFACES-532 Project: MyFaces Type: Bug Components: Implementation Versions: Nightly Build Reporter: Peter Mahoney Assignee: Mathias Broekelmann I have recently started to get the following exception thrown: java.util.NoSuchElementException at org.apache.myfaces.util.SelectItemsIterator.next(SelectItemsIterator.java:67) at org.apache.myfaces.util.SelectItemsIterator.next(SelectItemsIterator.java:155) at org.apache.myfaces.renderkit.RendererUtils.internalGetSelectItemList(RendererUtils.java:487) at org.apache.myfaces.renderkit.RendererUtils.getSelectItemList(RendererUtils.java:461) at org.apache.myfaces.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:277) at org.apache.myfaces.renderkit.html.HtmlRendererUtils.renderListbox(HtmlRendererUtils.java:240) at org.apache.myfaces.renderkit.html.HtmlListboxRendererBase.encodeEnd(HtmlListboxRendererBase.java:73) ... where the SelectItem list which causes the problem has no elements. However RendererUtil.internalGetSelectItemList does a hasNext() check, so this must be returning true for next() to be called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-513) record skip in selectItems
[ http://issues.apache.org/jira/browse/MYFACES-513?page=all ] Mathias Broekelmann closed MYFACES-513: --- Fix Version: Nightly Build Resolution: Fixed according to the given stacktrace this is already solved in the current svn head. See MYFACES-486. Please use the latest nightly or the latest svn to verify this. record skip in selectItems -- Key: MYFACES-513 URL: http://issues.apache.org/jira/browse/MYFACES-513 Project: MyFaces Type: Bug Components: General Environment: Linux, Tomcat 5.0.30,tiger Reporter: Arash Bijanzadeh Assignee: Mathias Broekelmann Fix For: Nightly Build selectItem renders just one of every two items in the collection. It seems to me that next() method called twice in somewhere -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-520) NPE in UIData.restoreDescendantComponentStates()
[
http://issues.apache.org/jira/browse/MYFACES-520?page=comments#action_12322732
]
Mathias Broekelmann commented on MYFACES-520:
-
Peter, I couldn´t reproduce it as you described it. Is it possible to attach an
example which causes the exception? That would help a lot.
Your patch might be ok but childState shouldn´t be null. If it is null it must
be a problem in the saveDescState method.
NPE in UIData.restoreDescendantComponentStates()
Key: MYFACES-520
URL: http://issues.apache.org/jira/browse/MYFACES-520
Project: MyFaces
Type: Bug
Components: Implementation
Versions: Nightly Build
Reporter: Peter Mahoney
Assignee: Mathias Broekelmann
I have a form which contains some inputText fields (one of which is
required), and a dataTable which contains an inputText field and a
selectOneMenu field, plus and inner dataTable containing inputText fields.
When a value is entered in the required inputText field, the form submits
successfully. However, when the required field is left blank the following
exception is thrown when processing the selectOneMenu field in the outer
dataTable:
java.lang.NullPointerException
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:221)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:233)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:233)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:233)
at javax.faces.component.UIData.setRowIndex(UIData.java:191)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeInnerHtml(HtmlTableRendererBase.java:135)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeChildren(HtmlTableRendererBase.java:94)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:444)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:62)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331)
at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:349)
at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:253)
at
org.apache.myfaces.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:55)
at
org.apache.jsp.cppolls_jsp._jspx_meth_h_panelGroup_0(cppolls_jsp.java:297)
at
org.apache.jsp.cppolls_jsp._jspx_meth_f_subview_0(cppolls_jsp.java:255)
at org.apache.jsp.cppolls_jsp._jspx_meth_f_view_0(cppolls_jsp.java:134)
...
The following change to UIData seems to fix the problem:
...
if (descendantStateIterator != null
descendantStateIterator.hasNext())
{
System.out.println(has dsi);
Object[] object = (Object[]) descendantStateIterator.next();
childState = object[0];
descendantState = object[1];
if (component instanceof EditableValueHolder childState !=
null)
{
((EditableValueHolderState) childState)
.restoreState((EditableValueHolder) component);
}
}
...
However, should this patch be necessary, or is there a problem elsewhere?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-520) NPE in UIData.restoreDescendantComponentStates()
[ http://issues.apache.org/jira/browse/MYFACES-520?page=all ]
Mathias Broekelmann closed MYFACES-520:
---
Fix Version: Nightly Build
Resolution: Fixed
NPE in UIData.restoreDescendantComponentStates()
Key: MYFACES-520
URL: http://issues.apache.org/jira/browse/MYFACES-520
Project: MyFaces
Type: Bug
Components: Implementation
Versions: Nightly Build
Reporter: Peter Mahoney
Assignee: Mathias Broekelmann
Fix For: Nightly Build
I have a form which contains some inputText fields (one of which is
required), and a dataTable which contains an inputText field and a
selectOneMenu field, plus and inner dataTable containing inputText fields.
When a value is entered in the required inputText field, the form submits
successfully. However, when the required field is left blank the following
exception is thrown when processing the selectOneMenu field in the outer
dataTable:
java.lang.NullPointerException
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:221)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:233)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:233)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:233)
at javax.faces.component.UIData.setRowIndex(UIData.java:191)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeInnerHtml(HtmlTableRendererBase.java:135)
at
org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeChildren(HtmlTableRendererBase.java:94)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:444)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448)
at
org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427)
at
org.apache.myfaces.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:62)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331)
at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:349)
at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:253)
at
org.apache.myfaces.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:55)
at
org.apache.jsp.cppolls_jsp._jspx_meth_h_panelGroup_0(cppolls_jsp.java:297)
at
org.apache.jsp.cppolls_jsp._jspx_meth_f_subview_0(cppolls_jsp.java:255)
at org.apache.jsp.cppolls_jsp._jspx_meth_f_view_0(cppolls_jsp.java:134)
...
The following change to UIData seems to fix the problem:
...
if (descendantStateIterator != null
descendantStateIterator.hasNext())
{
System.out.println(has dsi);
Object[] object = (Object[]) descendantStateIterator.next();
childState = object[0];
descendantState = object[1];
if (component instanceof EditableValueHolder childState !=
null)
{
((EditableValueHolderState) childState)
.restoreState((EditableValueHolder) component);
}
}
...
However, should this patch be necessary, or is there a problem elsewhere?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-486) Exception with sample application
[ http://issues.apache.org/jira/browse/MYFACES-486?page=all ] Mathias Broekelmann closed MYFACES-486: --- Resolution: Fixed Assign To: Mathias Broekelmann Exception with sample application - Key: MYFACES-486 URL: http://issues.apache.org/jira/browse/MYFACES-486 Project: MyFaces Type: Bug Versions: Nightly Build Environment: Nightly Build 20050903 Reporter: Manfred Klug Assignee: Mathias Broekelmann When I try to display the 'Sample 2' page I get the following Exception: java.util.NoSuchElementException at java.util.AbstractList$Itr.next(AbstractList.java:427) at org.apache.myfaces.util.SelectItemsIterator.next(SelectItemsIterator.java:82) at org.apache.myfaces.renderkit.RendererUtils.internalGetSelectItemList(RendererUtils.java:487) at org.apache.myfaces.renderkit.RendererUtils.getSelectItemList(RendererUtils.java:470) at org.apache.myfaces.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:273) at org.apache.myfaces.renderkit.html.HtmlRendererUtils.renderListbox(HtmlRendererUtils.java:246) at org.apache.myfaces.renderkit.html.HtmlListboxRendererBase.encodeEnd(HtmlListboxRendererBase.java:56) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:450) at org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448) at org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427) at org.apache.myfaces.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:62) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:349) at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:253) at org.apache.myfaces.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:55) at org.apache.jsp.sample2_jsp._jspx_meth_h_panelGroup_0(sample2_jsp.java:254) at org.apache.jsp.sample2_jsp._jspx_meth_f_view_0(sample2_jsp.java:183) at org.apache.jsp.sample2_jsp._jspService(sample2_jsp.java:130) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:696) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:474) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:409) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:95) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
[jira] Reopened: (MYFACES-72) HtmlSelectOneRadio does not correctly validate the required case
[ http://issues.apache.org/jira/browse/MYFACES-72?page=all ] Mathias Broekelmann reopened MYFACES-72: Assign To: Mathias Broekelmann I think I found a way to make it work without violating the spec. Initialy it was only a problem with HtmlRadioRendererBase.decode() called HtmlRendererUtils.decodeUIInput instead of HtmlRendererUtils.decodeUISelectOne(). But to make MYFACES-465 work an empty string couldn´t be used. It is possible that an identifier of a select item is equal to an empty string. A special constant (RendererUtils.NOTHING) is used instead. I will commit that. HtmlSelectOneRadio does not correctly validate the required case Key: MYFACES-72 URL: http://issues.apache.org/jira/browse/MYFACES-72 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.8 beta Environment: WSAD 5.1.2, IE 6 Reporter: Heath Borders-Wing Assignee: Mathias Broekelmann If an HtmlSelectOneRadio does not initially have a value, none of its options are initially rendered as selected. If none are selected and a form submit occurs IE 6 (possibly others browsers?) does not submit any name/value pair for that input. In the renderer, this is just ignored, and no error is thrown. It would probably be best to put logic in the renderer to account for this case. I can do this, but I wanted opinions on the issue before I wrote the fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-72) HtmlSelectOneRadio does not correctly validate the required case
[ http://issues.apache.org/jira/browse/MYFACES-72?page=all ] Mathias Broekelmann closed MYFACES-72: -- Resolution: Fixed just commit the changes HtmlSelectOneRadio does not correctly validate the required case Key: MYFACES-72 URL: http://issues.apache.org/jira/browse/MYFACES-72 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.8 beta Environment: WSAD 5.1.2, IE 6 Reporter: Heath Borders-Wing Assignee: Mathias Broekelmann If an HtmlSelectOneRadio does not initially have a value, none of its options are initially rendered as selected. If none are selected and a form submit occurs IE 6 (possibly others browsers?) does not submit any name/value pair for that input. In the renderer, this is just ignored, and no error is thrown. It would probably be best to put logic in the renderer to account for this case. I can do this, but I wanted opinions on the issue before I wrote the fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-465) Implement UISelectOne.validate(FacesContext)
[ http://issues.apache.org/jira/browse/MYFACES-465?page=all ] Mathias Broekelmann closed MYFACES-465: --- Resolution: Fixed Implement UISelectOne.validate(FacesContext) Key: MYFACES-465 URL: http://issues.apache.org/jira/browse/MYFACES-465 Project: MyFaces Type: Bug Components: JSR-127 Versions: 1.0.10m10 Reporter: Oliver Rossmueller Assignee: Mathias Broekelmann From the javadoc: In addition to the standard validation behavior inherited from UIInput, ensure that any specified value is equal to one of the available options. If it is not, enqueue an error message and set the valid property to false. as the comment in the method body states: //TODO: see javadoc: iterate through UISelectItem and UISelectItems and check //current value against these items -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-464) UIInput.submittedValue is set to empty string even if there is no submitted value in the request
[ http://issues.apache.org/jira/browse/MYFACES-464?page=comments#action_12320892 ] Mathias Broekelmann commented on MYFACES-464: - You are right. The problem is that the value for input fields can not be null. The request always contain the empty string. The RI has the same problem. The only solution I see is to check the previous value and if it is null and the converted value is an empty string we set the value to null and don´t queue the value change event. But is that working and don´t violates the spec too? UIInput.submittedValue is set to empty string even if there is no submitted value in the request Key: MYFACES-464 URL: http://issues.apache.org/jira/browse/MYFACES-464 Project: MyFaces Type: Bug Components: JSR-127 Versions: 1.0.10m10 Reporter: Oliver Rossmueller UIInput.submittedValue is set to empty string even if there is no submitted value at all. This causes a ValueChangeEvent to be queued for ANY_PHASE although there was no value change from the submitted values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-471) UISelectMany does not completely implement validate method
[ http://issues.apache.org/jira/browse/MYFACES-471?page=all ] Mathias Broekelmann closed MYFACES-471: --- Resolution: Fixed fixed UISelectMany does not completely implement validate method -- Key: MYFACES-471 URL: http://issues.apache.org/jira/browse/MYFACES-471 Project: MyFaces Type: Bug Components: JSR-127 Versions: 1.0.9m9 Reporter: sean schofield Assignee: Mathias Broekelmann In addition to the standard validation behavior inherited from UIInput, ensure that any specified value is equal to one of the available options. If it is not, enqueue an error message and set the valid property to false. Source code contains documentation marking this as todo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-478) t:inputDate: new attribute timeZone
[ http://issues.apache.org/jira/browse/MYFACES-478?page=all ] Mathias Broekelmann closed MYFACES-478: --- Resolution: Fixed I´ve commited the patch. I´ve also modified HtmlInputData.getTimeZone() to make value bindings work. Thanks Kai. t:inputDate: new attribute timeZone --- Key: MYFACES-478 URL: http://issues.apache.org/jira/browse/MYFACES-478 Project: MyFaces Type: Improvement Components: Tomahawk Versions: Nightly Build Reporter: Kai Heinecke Assignee: Mathias Broekelmann Priority: Minor Attachments: timeZone-tld.diff, timeZone.diff We had a minor problem using the very nice t:inputDate/: The dates we are working on have to be in GMT. With h:outputText/ it is easy to use f:convertDateTime timeZone=GMT/ to do the job. To get t:inputDate timeZone=GMT/ to work I made the following patches on the HEAD of MyFaces. Maybe you are interested in the patch and verify and commit my changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-462) UIComponent.processSaveState implementation not correct
[ http://issues.apache.org/jira/browse/MYFACES-462?page=all ] Mathias Broekelmann closed MYFACES-462: --- Never mind. I think its ok. I haven´t seen that the transient flag is still checked in the processSaveState method. UIComponent.processSaveState implementation not correct --- Key: MYFACES-462 URL: http://issues.apache.org/jira/browse/MYFACES-462 Project: MyFaces Type: Bug Components: JSR-127 Versions: Nightly Build Reporter: Oliver Rossmueller Assignee: Oliver Rossmueller Fix For: Nightly Build I think the test for child.isTransient in line 449 of UIComponentBase has to be removed as the javadoc says * Call the processSaveState() method of all facets and children of this UIComponent in the order determined by a call to getFacetsAndChildren(). There is no unless the facet of child is transient so processSaveState has to be called for all facets/children whether they are transient or not -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-479) rowStyleClass and rowStyle attributes for t:datatable
rowStyleClass and rowStyle attributes for t:datatable - Key: MYFACES-479 URL: http://issues.apache.org/jira/browse/MYFACES-479 Project: MyFaces Type: New Feature Components: Tomahawk Reporter: Mathias Broekelmann Assigned to: Mathias Broekelmann Priority: Minor add rowStyleClass and rowStyle attributes to t:datatable component to allow data specific styles for the tr element -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-412) _SerializableArrayDataModel throws ArrayIndexOutOfBoundsException when x:DataScroller advanced to second page on x:dataTable backed by array
[ http://issues.apache.org/jira/browse/MYFACES-412?page=all ]
Mathias Broekelmann closed MYFACES-412:
---
Fix Version: Nightly Build
Resolution: Fixed
Assign To: Mathias Broekelmann
fixed
Thanks to Mark Schechter for reporting and supplying a patch.
_SerializableArrayDataModel throws ArrayIndexOutOfBoundsException when
x:DataScroller advanced to second page on x:dataTable backed by array
Key: MYFACES-412
URL: http://issues.apache.org/jira/browse/MYFACES-412
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly Build
Environment: Windows 2000, Tomcat 5.5.
Reporter: Mark Schechter
Assignee: Mathias Broekelmann
Fix For: Nightly Build
When the bound property in the backing bean for an x:dataTable ('value'
element) is an array, and the x:dataScroller is used,
_SerializableArrayDataModel throws an ArrayIndexOutOfBounds exception when
trying to advance to the second page. Debugging through this code:
1public _SerializableArrayDataModel(int first, int rows, Object[] array)
2 {
3_first = first;
4_rows = rows;
5_rowCount = array.length;
6if (_rows = 0)
7{
8_rows = _rowCount - first;
9}
10_list = new ArrayList(_rows);
11 for (int i = 0; i _rowCount; i++)
12{
13_list.add(array[_first + i]);
14}
15}
the exception occurs on line 13 above, because on any page other than the
first page, _first will be non-zero (say 20 on the second page if displaying
20 rows at a time), and adding this to i which goes up to _rowCount will
exceed the length of the array. The problem appears to be on line 11, i
_rowCount; I presume it should be _rows instead, or better, some size, as
calculated for example by similar code in class _SerializableListDataModel.
When I switch the bound property in the backing bean to be a List instead of
an array, it works fine (I presume because _SerializableListDataModel is
being used instead).
Here is the dump from Tomcat 5.5:
java.lang.ArrayIndexOutOfBoundsException: 164
at
org.apache.myfaces.component.html.ext._SerializableArrayDataModel.init(_SerializableArrayDataModel.java:42)
at
org.apache.myfaces.component.html.ext.HtmlDataTable.createSerializableDataModel(HtmlDataTable.java:493)
at
org.apache.myfaces.component.html.ext.HtmlDataTable.getSerializableDataModel(HtmlDataTable.java:470)
at
org.apache.myfaces.component.html.ext.HtmlDataTable.saveState(HtmlDataTable.java:369)
at
javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:456)
at
javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:452)
at
javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:452)
at
javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:440)
at
javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:452)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.getComponentStateToSave(JspStateManagerImpl.java:70)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:213)
at org.apache.myfaces.taglib.core.ViewTag.doEndTag(ViewTag.java:122)
at
org.apache.jsp.listTaggedItems_jsp._jspx_meth_f_view_0(org.apache.jsp.listTaggedItems_jsp:191)
ETC.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
