RE: [jira] Updated: (MYFACES-272) MyFaces unnecessary encodes all non-latin characters as numeric character references even if response character encoding is set to UTF-8
-Original Message- From: Adam Winer [mailto:[EMAIL PROTECTED] Sent: Saturday, September 03, 2005 6:47 PM To: MyFaces Development Subject: Re: [jira] Updated: (MYFACES-272) MyFaces unnecessary encodes all non-latin characters as numeric character references even if response character encoding is set to UTF-8 On 9/2/05, Kalle Korhonen (JIRA) myfaces-dev@incubator.apache.org wrote: A tip for people trying it out, to properly set UTF-8, you need to use an encoding filter. Why? This shouldn't be necessary, since a JSF implementation should restore the character encoding during Restore View. (I think this is in the spec, though I'm being lazy right now and not checking...) Once set, restoring the character encoding works correctly in both RI and MyFaces if I remember correctly (works that way for locale at least). But that's not the problem; if you set it on the page with a page directive, MyFaces has already tried to read it from the request and reverted to default encoding (ISO-8859-1) if not set (I've only used MyFaces with Tiles, that could make a difference in this case). Now that's probably a bug, but I don't know exactly what shouldn't be necessary, but I do know what's necessary to make things work with the current MyFaces. Kalle
[jira] Created: (MYFACES-517) /WEB-INF/faces-config.xml parsed twice
/WEB-INF/faces-config.xml parsed twice -- Key: MYFACES-517 URL: http://issues.apache.org/jira/browse/MYFACES-517 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9 Reporter: Holger Schimanski If the config file is named faces-config.xml and it is configured web.xml context-param param-namejavax.faces.CONFIG_FILES/param-name param-value/WEB-INF/faces-config.xml/param-value /context-param it is parsed twice by org.apache.myfaces.config.FacesConfigurator -- once in feedWebAppConfig() and once again in feedContextSpecifiedConfig(). The result is, that for example configured PhaseListeners are instantiated twice and both called during lifecycle. feedContextSpecifiedConfig() should skip /WEB-INF/faces-config.xml, because this is read in by feedWebAppConfig(). -- 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-518) inputDate component handles readonly attribute incorrect
inputDate component handles readonly attribute incorrect Key: MYFACES-518 URL: http://issues.apache.org/jira/browse/MYFACES-518 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: v20050904, Firefox/1.0.4 Reporter: Csaba Sebastian Setting readonly attribute to true on an inputDate component causes the combo box for the month doesn't rendered as readonly (nor disabled) -- 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-517) /WEB-INF/faces-config.xml parsed twice
[ http://issues.apache.org/jira/browse/MYFACES-517?page=all ] Martin Marinschek closed MYFACES-517: - Fix Version: Nightly Build Resolution: Invalid Assign To: Martin Marinschek /WEB-INF/faces-config.xml parsed twice -- Key: MYFACES-517 URL: http://issues.apache.org/jira/browse/MYFACES-517 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9 Reporter: Holger Schimanski Assignee: Martin Marinschek Fix For: Nightly Build If the config file is named faces-config.xml and it is configured web.xml context-param param-namejavax.faces.CONFIG_FILES/param-name param-value/WEB-INF/faces-config.xml/param-value /context-param it is parsed twice by org.apache.myfaces.config.FacesConfigurator -- once in feedWebAppConfig() and once again in feedContextSpecifiedConfig(). The result is, that for example configured PhaseListeners are instantiated twice and both called during lifecycle. feedContextSpecifiedConfig() should skip /WEB-INF/faces-config.xml, because this is read in by feedWebAppConfig(). -- 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-515) web.xml - XML validation error in sample applications
[ http://issues.apache.org/jira/browse/MYFACES-515?page=all ] Martin Marinschek closed MYFACES-515: - Fix Version: Nightly Build Resolution: Won't Fix Ok, as we are using the 2.3 dtd in this file, this would be ok - for 2.4 you will need to change this yourself. regards, Martin web.xml - XML validation error in sample applications - Key: MYFACES-515 URL: http://issues.apache.org/jira/browse/MYFACES-515 Project: MyFaces Type: Bug Components: General Versions: Nightly Build Environment: WebLogic 9.0 (J2EE 1.4, Servlet 2.4) Reporter: Andy Assignee: Martin Marinschek Priority: Trivial Fix For: Nightly Build The sample application (simple.war) does not deploy on WebLogic 9.0. The following in web.xml does not seem to pass the validation (param-name/param-value before description element): context-param param-namejavax.faces.CONFIG_FILES/param-name param-value/WEB-INF/examples-config.xml/param-value description Comma separated list of URIs of (additional) faces config files. (e.g. /WEB-INF/my-config.xml) See JSF 1.0 PRD2, 10.3.2 /description /context-param This works (description element before param-name element): context-param description Comma separated list of URIs of (additional) faces config files. (e.g. /WEB-INF/my-config.xml) See JSF 1.0 PRD2, 10.3.2 /description param-namejavax.faces.CONFIG_FILES/param-name param-value/WEB-INF/examples-config.xml/param-value /context-param -- 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-517) /WEB-INF/faces-config.xml parsed twice
[ http://issues.apache.org/jira/browse/MYFACES-517?page=comments#action_12322723 ] Martin Marinschek commented on MYFACES-517: --- I thought I did comment - obviously my comment was lost. the faces-config.xml file in your WEB-INF directory will automatically be parsed - no need to specify it as a context-param in your web.xml. If you do so, the faces-config.xml file will be (fully according to the spec) parsed twice. regards, Martin /WEB-INF/faces-config.xml parsed twice -- Key: MYFACES-517 URL: http://issues.apache.org/jira/browse/MYFACES-517 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9 Reporter: Holger Schimanski Assignee: Martin Marinschek Fix For: Nightly Build If the config file is named faces-config.xml and it is configured web.xml context-param param-namejavax.faces.CONFIG_FILES/param-name param-value/WEB-INF/faces-config.xml/param-value /context-param it is parsed twice by org.apache.myfaces.config.FacesConfigurator -- once in feedWebAppConfig() and once again in feedContextSpecifiedConfig(). The result is, that for example configured PhaseListeners are instantiated twice and both called during lifecycle. feedContextSpecifiedConfig() should skip /WEB-INF/faces-config.xml, because this is read in by feedWebAppConfig(). -- 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-513) record skip in selectItems
[ http://issues.apache.org/jira/browse/MYFACES-513?page=comments#action_12322724 ] Arash Bijanzadeh commented on MYFACES-513: -- Yes I am using he head from SVN 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 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-513) record skip in selectItems
[ http://issues.apache.org/jira/browse/MYFACES-513?page=comments#action_12322725 ] Arash Bijanzadeh commented on MYFACES-513: -- When the element number is even everything fine( but the number of items you can see) and when it is odd : 2005-09-06 14:51:02 ApplicationDispatcher[/hamyar] Servlet.service() for servlet jsp threw 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:461) at org.apache.myfaces.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:277) at org.apache.myfaces.renderkit.html.HtmlRendererUtils.renderMenu(HtmlRendererUtils.java:251) at org.apache.myfaces.renderkit.html.HtmlMenuRendererBase.encodeEnd(HtmlMenuRendererBase.java:54) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:450) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:203) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:85) 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.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:203) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:85) 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.custom.layout.HtmlLayoutRenderer.renderTableCell(HtmlLayoutRenderer.java:259) at org.apache.myfaces.custom.layout.HtmlLayoutRenderer.renderClassic(HtmlLayoutRenderer.java:118) at org.apache.myfaces.custom.layout.HtmlLayoutRenderer.encodeEnd(HtmlLayoutRenderer.java:66) 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.template.template_jsp._jspx_meth_x_panelLayout_0(template_jsp.java:221) at org.apache.jsp.template.template_jsp._jspx_meth_f_view_0(template_jsp.java:160) at org.apache.jsp.template.template_jsp._jspService(template_jsp.java:91) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 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:802) 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.JspTilesViewHandlerImpl.dispatch(JspTilesViewHandlerImpl.java:233) at org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl.renderView(JspTilesViewHandlerImpl.java:219) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:95) at
[jira] Commented: (MYFACES-513) record skip in selectItems
[ http://issues.apache.org/jira/browse/MYFACES-513?page=comments#action_12322726 ] Martin Marinschek commented on MYFACES-513: --- Ok, this is code newly added by Mathias... I am assigning this to him.. regards, Martin 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 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] 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
Re: Sandbox
Hello Martin,
No, I never committed it.
I think a new package would be great, but where do you want to put it ?
The logic would be to have it first in the sandbox, and then move it class by class tomahawk.
Maybe a better package name would be org.apache.myfaces.utils
as jsfutils is redundant with myfaces. I also dropped the tomahawk part as it would be in the sandbox first, but I'm not sure about this.
If you agree, I can commit those classes to the sandbox's org.apache.myfaces.utils package, and we can start from here.
Sylvain.
On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
Sylvain,
did you ever get around to commit this stuff? I didn't find it in the sources...
I'd like to use that as an example for something I am writing on -
would be great if I could just point to the MyFaces sourcebase.
How about a new package
org apache myfaces tomahawk jsfutils
We could also have the user contributions like the message-remembering
facilities and the newly added remember request-bean over redirect
facilities there...
regards,
Martin
On 5/11/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
I'm fine with that and find it simpler to have it in the trunk.
I have a related question.
Right now, I have done 2 little utilities that help me resolve small
problems.
They are 2 abstract implementations of Map : ActionMap and TestMap, and I
find them handy to use in many common cases.
Here are 2 examples :
1) ActionMap : For example, when you have a list of file, and want to have
a checkbox to delete a file, you just add the following code in your page :
h:column
h:selectBooleanCheckbox value=#{pageFace.removeFileName[file.name]}/
h:outputText value=delete/
/h:column
And in your backing bean : public ActionsMap getRemoveFileName(){
return new ActionsMap(){
@Override
public void performAction(String fileName) {
getFiles().remove( fileName );
}
};
}
2) TestMap : I use it to pass parameters to methods using a map, and
getting a boolean result.
For example, if you want to render a component if a user is in 2 roles, the
visibleOnUserRole isn't enough.
So, in my backing bean, I have this method :
public TestsMap getUserInRole(){
return new TestsMap(){
@Override
public boolean getTest(String roleName) {
return getHttpServletRequest().isUserInRole( roleName );
}
};
}
And now, I can do any test I want in EL :
#{myBean.isUserInRole['Accountant'] myBean.isUserInRole['CountryUnit']}
It's quite limited now, but due to the limitations of the EL, small
utilities like that can help.
My suggestion is to do a utilities library (similar to commons.lang, with
StringUtils, ...) for EL, and maybe for JSF if more good candidates emerge.
So, I wonder first if you guys feels this is of any use to include this in
MyFaces, and if so, how do we handle that ?
Those aren't components, but should we do a sandbox for libraries to, or
just an additional myfaces-utilities.jar
Thanks,
Sylvain.
On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
I recall correctly, the consensus was to have a sandbox subproject
for new components. I would like to propose a simpler solution: Why not
have the sandbox as a subdirectory of the existing project. Then we can
just specify all s: components as sandbox components until they are
completely accepted by the community. At that time they can become x:
components.
Would this satisfy the ASF's requirement for All New Components Must Go
Through the Incubator ? Hopefully...
[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
Re: What is the purpose of _dataModelMap in UIData?
Mathias, Just became aware that I never congratulated (and thanked) you for refactoring the DataTable. Sorry, if I did scare you with my objections in the beginning. And thanks, that you have not been discouraged. ;-) -Manfred 2005/9/5, Mathias Brökelmann [EMAIL PROTECTED]: Martin is right. During the processing of the jsf phases we don´t call getValue() for every time we need to access the UIData value. We cache them in that map. To support nested UIDatas it´s necessary to hold the datamodel in depend of the client id of the parent. The client id changes if it is nested within a UIData during the iteration. 2005/9/5, Martin Marinschek [EMAIL PROTECTED]: That has to do with the fact that we correctly remember the state of UIData's which are children of the parent UIData - the RI won't do that, at least the last time we looked at that. regards, Martin On 9/5/05, Oliver Rossmueller [EMAIL PROTECTED] wrote: Hi folks, I just stumbled over the fact that UIData holds a map where it stores data models with it's parent's clientId used as key - see UIData.getDataModel(). I have no clue what this is for and why the data model is not stored in a simple instance variable like the RI does. Someone who can explain this? Oliver -- Oliver Rossmueller Software Engineer and IT-Consultant Hamburg, Germany http://www.rossmueller.com -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German -- Mathias
[jira] Commented: (MYFACES-520) NPE in UIData.restoreDescendantComponentStates()
[
http://issues.apache.org/jira/browse/MYFACES-520?page=comments#action_12322734
]
Peter Mahoney commented on MYFACES-520:
---
Interestingly, if the patch is applied without the childState != null,
then the SelectOneMenu component does now work, but the submit still fails with
the same problem when processing the inputText field.
I will look to try and produce a suitable example of the problem.
Thanks
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
MyFaces Tiles and JSF Sun RI
I have much trouble with the combination of Tiles, MyFaces and javax.faces.STATE_SAVING_METHOD=server. Now I tried out, to get Tiles with tomahawk.jar (nightly build) and Sun RI 1.1.01. To use the tiles-feature (I think, they are from Martin Marinschek) of tomahawk, I have to use org.apache.myfaces.webapp.StartupServletContextListener which is in myfaces-impl.jar. That means, I can't use tomahawk-tiles with sun RI. Is there any chance to move the configuration stuff for tiles to tomahawk.jar aswell? Better soulution would be a fix of JIRA MYFACES-418 but I would need more time to understand that bug then moving to Sun RI.
[jira] Commented: (MYFACES-520) NPE in UIData.restoreDescendantComponentStates()
[
http://issues.apache.org/jira/browse/MYFACES-520?page=comments#action_12322739
]
Peter Mahoney commented on MYFACES-520:
---
The following JSP causes the problem:
f:view
h:form id=editform
h:inputText id=questionTitle value=#{pollHandler.poll.title}
required=true/
h:message for=questionTitle/
h:dataTable value=#{pollHandler.poll.questions} var=question
h:column
h:outputText value=hello/
f:verbatimbr//f:verbatim
h:selectOneMenu id=questionType
value=#{question.type} required=true
f:selectItems
value=#{pollHandler.questionTypeItems}/
/h:selectOneMenu
h:inputText id=questionText
value=#{question.text}/
/h:column
/h:dataTable
h:commandButton/
/h:form
/f:view
If the f:verbatim tag is removed, the problem goes away. If you need further
code, let me know. Thanks.
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)
[jira] Commented: (MYFACES-418) Tiles does not work with javax.faces.STATE_SAVING_METHOD=server.
[ http://issues.apache.org/jira/browse/MYFACES-418?page=comments#action_12322741 ] Carsten Fregin commented on MYFACES-418: Found the problem. The exception is an IllegalStateException: Cannot create a session after the response has been commited. In the myfaces-tiles-example/template/template.jsp is a %@ page session=false% entry, preventing the servlet container to create a session. Removing that line fixes the bug. Could someone remove that line? I see no point in disabeling the session on that page. Tiles does not work with javax.faces.STATE_SAVING_METHOD=server. Key: MYFACES-418 URL: http://issues.apache.org/jira/browse/MYFACES-418 Project: MyFaces Type: Bug Components: General Versions: 1.0.9m9 Environment: Tested with Tomcat 5.5 under Gentoo linux and Windows XP Home Reporter: Carsten Fregin Assignee: Thomas Spiegl Problem: When I set the javax.faces.STATE_SAVING_METHOD in the web.xml to server and try out the tiles-example, I get a java.lang.IllegalStateException: Cannot create a session after the response has been commited. Analysis: The problem happens only while calling a tiles page directly. So, calling response.sendRedirect(page1.jsf); or entering the url (/myfaces-tiles-example/page1.jsp) results in the error. If you create a jsf page without tiles support, you are able to jump to a tiles page by navigation-rule. Proof: try to call /myfaces-tiles-example/non-tile.jsf directly in your browser and press the back button. Workaround: use javax.faces.STATE_SAVING_METHOD=client (generates much bandwidth) or create an index.jsp with a commandLink to your tiles page. -- 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] Resolved: (MYFACES-418) Tiles does not work with javax.faces.STATE_SAVING_METHOD=server.
[ http://issues.apache.org/jira/browse/MYFACES-418?page=all ] Matthias Weßendorf resolved MYFACES-418: Resolution: Fixed thx for reporting it Tiles does not work with javax.faces.STATE_SAVING_METHOD=server. Key: MYFACES-418 URL: http://issues.apache.org/jira/browse/MYFACES-418 Project: MyFaces Type: Bug Components: General Versions: 1.0.9m9 Environment: Tested with Tomcat 5.5 under Gentoo linux and Windows XP Home Reporter: Carsten Fregin Assignee: Thomas Spiegl Problem: When I set the javax.faces.STATE_SAVING_METHOD in the web.xml to server and try out the tiles-example, I get a java.lang.IllegalStateException: Cannot create a session after the response has been commited. Analysis: The problem happens only while calling a tiles page directly. So, calling response.sendRedirect(page1.jsf); or entering the url (/myfaces-tiles-example/page1.jsp) results in the error. If you create a jsf page without tiles support, you are able to jump to a tiles page by navigation-rule. Proof: try to call /myfaces-tiles-example/non-tile.jsf directly in your browser and press the back button. Workaround: use javax.faces.STATE_SAVING_METHOD=client (generates much bandwidth) or create an index.jsp with a commandLink to your tiles page. -- 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-518) inputDate component handles readonly attribute incorrect
[ http://issues.apache.org/jira/browse/MYFACES-518?page=all ] Bruno Aranda closed MYFACES-518: Fix Version: 1.0.10m10 Resolution: Fixed This should be fixed on the SVN and available in the next nighlty... inputDate component handles readonly attribute incorrect Key: MYFACES-518 URL: http://issues.apache.org/jira/browse/MYFACES-518 Project: MyFaces Type: Bug Components: Tomahawk Versions: Nightly Build Environment: v20050904, Firefox/1.0.4 Reporter: Csaba Sebastian Fix For: 1.0.10m10 Setting readonly attribute to true on an inputDate component causes the combo box for the month doesn't rendered as readonly (nor disabled) -- 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-523) No error condition was raised when managed bean contained a reference to another bean with a potentially shorter scope than what the bean was configured for.
No error condition was raised when managed bean contained a reference to another bean with a potentially shorter scope than what the bean was configured for. - Key: MYFACES-523 URL: http://issues.apache.org/jira/browse/MYFACES-523 Project: MyFaces Type: Bug Components: JSR-127 Versions: 1.0.9m9 Reporter: Bruno Aranda Acording to the spec (section 5.3.1.3, p5-11): It is an error for a managed bean created through this facility to have a property that points at an object stored in a scope with a (potentially) shorter life span. Specifically, this means, for an object created with the specified managed-beanscope, then value evaluations can only point at created objects with the specified managed bean scope: - none -- none - application -- none, application - session -- none, application, session - request -- none, application, session, request I guess the ManagedBeanFactory should throw a FacesException in that case. (managedBeanScopedReferencesTest) -- 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-521) Errors in TLDs
[ http://issues.apache.org/jira/browse/MYFACES-521?page=comments#action_12322753 ] Wendy Smoak commented on MYFACES-521: - The error message is pointing out the line number: myfaces_html.tld:2585 It's at the bottom of selectOneMenu: attributenameenabledClass/name requiredfalse/required rtexprvaluefalse/rtexprvalue/attribute attributenamedisabledClass/name requiredfalse/required rtexprvaluefalse/rtexprvalue/attribute ant /tag Actually the extra text is in the entity standard_select_one_menu_attributes; http://svn.apache.org/repos/asf/myfaces/impl/trunk/tld/entities/standard_select_one_menu_attributes.xml Errors in TLDs -- Key: MYFACES-521 URL: http://issues.apache.org/jira/browse/MYFACES-521 Project: MyFaces Type: Bug Components: General Versions: Nightly Build Environment: Windows, JDK 1.4.2, Resin 3.0.14 Reporter: Boris Kovalenko Attachments: tlds.zip Errors in TLDs... Resin compains like: log4j:WARN Please initialize the log4j system properly. [19:06:20.731] com.caucho.xml.XmlParseException: jar:file:/C:/Development/Projec ts/Ubs/WEB-INF/lib/myfaces-all.jar!/META-INF/myfaces_html.tld:2585: The followin g text is not allowed in this context. [19:06:20.731] [19:06:20.731] ant [19:06:20.731] [19:06:20.731] [19:06:20.731] [19:06:20.731] attribute or [19:06:20.731] example are expected, [19:06:20.731] or /tag may close. -- 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] Resolved: (MYFACES-521) Errors in TLDs
[ http://issues.apache.org/jira/browse/MYFACES-521?page=all ] Matthias Weßendorf resolved MYFACES-521: Resolution: Fixed Wendy, thanks for pointing it out! fixed in SVN Errors in TLDs -- Key: MYFACES-521 URL: http://issues.apache.org/jira/browse/MYFACES-521 Project: MyFaces Type: Bug Components: General Versions: Nightly Build Environment: Windows, JDK 1.4.2, Resin 3.0.14 Reporter: Boris Kovalenko Attachments: tlds.zip Errors in TLDs... Resin compains like: log4j:WARN Please initialize the log4j system properly. [19:06:20.731] com.caucho.xml.XmlParseException: jar:file:/C:/Development/Projec ts/Ubs/WEB-INF/lib/myfaces-all.jar!/META-INF/myfaces_html.tld:2585: The followin g text is not allowed in this context. [19:06:20.731] [19:06:20.731] ant [19:06:20.731] [19:06:20.731] [19:06:20.731] [19:06:20.731] attribute or [19:06:20.731] example are expected, [19:06:20.731] or /tag may close. -- 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-525) Myfaces does not handle correctly the from-view-id's with wildcards
[ http://issues.apache.org/jira/browse/MYFACES-525?page=comments#action_12322757 ] Bruno Aranda commented on MYFACES-525: -- I think that 'hibernate'... I wanted to say 'myfaces' instead. A co-worker was asking me a question about hibernate when I was writing this :-) Myfaces does not handle correctly the from-view-id's with wildcards --- Key: MYFACES-525 URL: http://issues.apache.org/jira/browse/MYFACES-525 Project: MyFaces Type: Bug Components: JSR-127 Versions: 1.0.9m9 Reporter: Bruno Aranda From the spec (section 7.4.2, p5-10/11), when talking about the NavigationHandler: Rule instances are considered in the following order: - An exact match of the view identifier against a from-view-id pattern that does not end with an asterisk (*) character. - For from-view-id patterns that end with an asterisk, an exact match on characters preceding the asterisk against the prefix of the view id. If the patterns for multiple navigation rules match, pick the longest matching prefix first. - If there is a navigation-rule with a from-view-id pattern of only an asterisk, it matches any view identifier. In myfaces something happens with the from-view-id's with asterisk. Lets illustrate a case: 1. from-view-idtest3/from-view-id 2. from-view-idtest*/from-view-id 3. from-view-id*/from-view-id I think that hibernate does not understand correctly the from-view-id's with asterisk. For instance, if I am in the a view with id 'tes' (sic), the from-view-id used is the #2 when it should be the number #3. -- 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-521) Errors in TLDs
[ http://issues.apache.org/jira/browse/MYFACES-521?page=all ] Matthias Weßendorf closed MYFACES-521: -- Assign To: Matthias Weßendorf Errors in TLDs -- Key: MYFACES-521 URL: http://issues.apache.org/jira/browse/MYFACES-521 Project: MyFaces Type: Bug Components: General Versions: Nightly Build Environment: Windows, JDK 1.4.2, Resin 3.0.14 Reporter: Boris Kovalenko Assignee: Matthias Weßendorf Attachments: tlds.zip Errors in TLDs... Resin compains like: log4j:WARN Please initialize the log4j system properly. [19:06:20.731] com.caucho.xml.XmlParseException: jar:file:/C:/Development/Projec ts/Ubs/WEB-INF/lib/myfaces-all.jar!/META-INF/myfaces_html.tld:2585: The followin g text is not allowed in this context. [19:06:20.731] [19:06:20.731] ant [19:06:20.731] [19:06:20.731] [19:06:20.731] [19:06:20.731] attribute or [19:06:20.731] example are expected, [19:06:20.731] or /tag may close. -- 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
RE: Access default portlet preferences from backing bean (JSR-168 portlet)
Access to portlet preferences is not defined in the JSF spec. I have
spoken to the JSF spec lead about it so we can take care of this in JSF
2.0.
For now, you can get the RenderResponse from the ExternalContext as you
showed. In MyFaces, you can protect your code with a guard clause like
this:
if (PortletUtil.isRenderRequest(facesContext)) {
// cast request to a RenderRequest
}
Another approach is to extend MyFacesGenericPortlet and put portlet
preferences into an appropriate context such as the session. This makes
them available from the ExternalContext without casting.
Stan Silvert
JBoss, Inc.
[EMAIL PROTECTED]
callto://stansilvert
-Original Message-
From: j m [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 03, 2005 1:22 PM
To: dev@myfaces.apache.org
Subject: Access default portlet preferences from backing bean (JSR-168
portlet)
hi,
I'm using MyFaces snapshot 20050826 for my JSR-168 portlets.
I'd like to access default portlet preferences which are stored in
portlet.xml from my backing bean. But this didn't work - can anybody
help
me?
What I managed was to store and get portlet preferences from my
running portlet - so
these preferences are not stored in portle.xml but are managed by a
persistance manager of the portlet container.
But I need to get some default pref. from portlet.xml - which are
normally available
within the PortletPreferences object.
This is the code I'm using to access the portlet preferences:
int prefCount =
((javax.portlet.RenderRequest)FacesContext.getCurrentInstance().getExter
na
lContext().getRequest()).getPreferences().getMap().size();
I also tried to cast the faces request to PortletRequest and
ActionRequest but that didn't help.
Thanks in advance
jm
Re: Additional TLD with tomahawk sandbox
Not a bad idea. We'll need to be careful to not break the release build (which can't have any sandbox stuff in it.) Just make sure everything builds fine with or without sandbox. At some point we should also change the examples to use 'sbx' instead of 's' or 'x' (like we discussed earlier.) Also I noticed the Tobago stuff uses 't' which might get confusing ... sean On 9/6/05, Martin Marinschek [EMAIL PROTECTED] wrote: no problem for me. except that we will not have much drive towards moving components from sandbox to tomahawk then, but that's something we should be able to cope with, I'd say. regards, Martin On 9/6/05, Sylvain Vieujot [EMAIL PROTECTED] wrote: Hello, As we have a myfaces-all.jar, it would be nice to also add a corresponding tld with urihttp://myfaces.apache.org/all /uri to this jar. This tld would roughly concatenate the ones from tomahawk from sandbox. That way, we could recycle the old x: prefix, and avoid changing the applications when a component moves from the sandbox to tomahawk. I think it would be very convenient for those using sandbox's components in their applications (at least, it would be very convenient for me ). Any thoughts ? Sylvain. -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
[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
Java 5 code in Sandbox ?
Hello,
I was about to commit the few Maps util classes I have when I realized it's all Java 5 code (with many generics and a few annotations).
Removing the generics would really be bad as those classes needs to be extended, and the generics add a lot of safety.
For me it would be ok to add Java 5, and later to move it to tomahawk when we move to JSF 1.2, but I would need the approval of the others to do that, as it would break the sandbox compilation on Java 1.4.
What do you think ?
Sylvain.
On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
Yes...
Let's put it there, and go on from this!
regards,
Martin
On 9/6/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Hello Martin,
No, I never committed it.
I think a new package would be great, but where do you want to put it ?
The logic would be to have it first in the sandbox, and then move it class
by class tomahawk.
Maybe a better package name would be org.apache.myfaces.utils
as jsfutils is redundant with myfaces. I also dropped the tomahawk part as
it would be in the sandbox first, but I'm not sure about this.
If you agree, I can commit those classes to the sandbox's
org.apache.myfaces.utils package, and we can start from here.
Sylvain.
On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
Sylvain,
did you ever get around to commit this stuff? I didn't find it in the
sources...
I'd like to use that as an example for something I am writing on -
would be great if I could just point to the MyFaces sourcebase.
How about a new package
org apache myfaces tomahawk jsfutils
We could also have the user contributions like the message-remembering
facilities and the newly added remember request-bean over redirect
facilities there...
regards,
Martin
On 5/11/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
I'm fine with that and find it simpler to have it in the trunk.
I have a related question.
Right now, I have done 2 little utilities that help me resolve small
problems.
They are 2 abstract implementations of Map : ActionMap and TestMap, and I
find them handy to use in many common cases.
Here are 2 examples :
1) ActionMap : For example, when you have a list of file, and want to have
a checkbox to delete a file, you just add the following code in your page
:
h:column
h:selectBooleanCheckbox value=#{pageFace.removeFileName[file.name]}/
h:outputText value=delete/
/h:column
And in your backing bean : public ActionsMap getRemoveFileName(){
return new ActionsMap(){
@Override
public void performAction(String fileName) {
getFiles().remove( fileName );
}
};
}
2) TestMap : I use it to pass parameters to methods using a map, and
getting a boolean result.
For example, if you want to render a component if a user is in 2 roles,
the
visibleOnUserRole isn't enough.
So, in my backing bean, I have this method :
public TestsMap getUserInRole(){
return new TestsMap(){
@Override
public boolean getTest(String roleName) {
return getHttpServletRequest().isUserInRole( roleName );
}
};
}
And now, I can do any test I want in EL :
#{myBean.isUserInRole['Accountant'] myBean.isUserInRole['CountryUnit']}
It's quite limited now, but due to the limitations of the EL, small
utilities like that can help.
My suggestion is to do a utilities library (similar to commons.lang, with
StringUtils, ...) for EL, and maybe for JSF if more good candidates
emerge.
So, I wonder first if you guys feels this is of any use to include this in
MyFaces, and if so, how do we handle that ?
Those aren't components, but should we do a sandbox for libraries to, or
just an additional myfaces-utilities.jar
Thanks,
Sylvain.
On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
I recall correctly, the consensus was to have a sandbox subproject
for new components. I would like to propose a simpler solution: Why not
have the sandbox as a subdirectory of the existing project. Then we can
just specify all s: components as sandbox components until they are
completely accepted by the community. At that time they can become x:
components.
Would this satisfy the ASF's requirement for All New Components Must Go
Through the Incubator ? Hopefully...
Re: Java 5 code in Sandbox ?
IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
but chance it to 1.4 when moving to tomahawk? What would be the point
of that?
Why not refactor before adding to sandbox if this is the eventual plan?
I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
but I definitely don't think we should add stuff and hope to refactor
it later.
sean
On 9/6/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Hello,
I was about to commit the few Maps util classes I have when I realized it's
all Java 5 code (with many generics and a few annotations).
Removing the generics would really be bad as those classes needs to be
extended, and the generics add a lot of safety.
For me it would be ok to add Java 5, and later to move it to tomahawk when
we move to JSF 1.2, but I would need the approval of the others to do that,
as it would break the sandbox compilation on Java 1.4.
What do you think ?
Sylvain.
On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
Yes...
Let's put it there, and go on from this!
regards,
Martin
On 9/6/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Hello Martin,
No, I never committed it.
I think a new package would be great, but where do you want to put it ?
The logic would be to have it first in the sandbox, and then move it class
by class tomahawk.
Maybe a better package name would be org.apache.myfaces.utils
as jsfutils is redundant with myfaces. I also dropped the tomahawk part as
it would be in the sandbox first, but I'm not sure about this.
If you agree, I can commit those classes to the sandbox's
org.apache.myfaces.utils package, and we can start from here.
Sylvain.
On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
Sylvain,
did you ever get around to commit this stuff? I didn't find it in the
sources...
I'd like to use that as an example for something I am writing on -
would be great if I could just point to the MyFaces sourcebase.
How about a new package
org apache myfaces tomahawk jsfutils
We could also have the user contributions like the message-remembering
facilities and the newly added remember request-bean over redirect
facilities there...
regards,
Martin
On 5/11/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
I'm fine with that and find it simpler to have it in the trunk.
I have a related question.
Right now, I have done 2 little utilities that help me resolve small
problems.
They are 2 abstract implementations of Map : ActionMap and TestMap, and
I
find them handy to use in many common cases.
Here are 2 examples :
1) ActionMap : For example, when you have a list of file, and want to
have
a checkbox to delete a file, you just add the following code in your
page
:
h:column
h:selectBooleanCheckbox value=#{pageFace.removeFileName[file.name]}/
h:outputText value=delete/
/h:column
And in your backing bean : public ActionsMap getRemoveFileName(){
return new ActionsMap(){
@Override
public void performAction(String fileName) {
getFiles().remove( fileName );
}
};
}
2) TestMap : I use it to pass parameters to methods using a map, and
getting a boolean result.
For example, if you want to render a component if a user is in 2 roles,
the
visibleOnUserRole isn't enough.
So, in my backing bean, I have this method :
public TestsMap getUserInRole(){
return new TestsMap(){
@Override
public boolean getTest(String roleName) {
return getHttpServletRequest().isUserInRole( roleName
);
}
};
}
And now, I can do any test I want in EL :
#{myBean.isUserInRole['Accountant']
myBean.isUserInRole['CountryUnit']}
It's quite limited now, but due to the limitations of the EL, small
utilities like that can help.
My suggestion is to do a utilities library (similar to commons.lang,
with
StringUtils, ...) for EL, and maybe for JSF if more good candidates
emerge.
So, I wonder first if you guys feels this is of any use to include this
in
MyFaces, and if so, how do we handle that ?
Those aren't components, but should we do a sandbox for libraries to, or
just an additional myfaces-utilities.jar
Thanks,
Sylvain.
On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
I recall correctly, the consensus was to have a sandbox subproject
for new components. I would like to propose a simpler solution: Why not
have the sandbox as a subdirectory of the existing project. Then we can
just specify all s: components as sandbox components until they are
completely accepted by the community. At that time they can become x:
components.
Would this satisfy the ASF's requirement for All New Components Must Go
Through the Incubator ? Hopefully...
[jira] Commented: (MYFACES-517) /WEB-INF/faces-config.xml parsed twice
[ http://issues.apache.org/jira/browse/MYFACES-517?page=comments#action_12322780 ] Holger Schimanski commented on MYFACES-517: --- Hm, are you sure? I am asking because reading in the same config twice doesn't make sense. And the Reference Implementation doesn't do it, too. Best regards, Holger /WEB-INF/faces-config.xml parsed twice -- Key: MYFACES-517 URL: http://issues.apache.org/jira/browse/MYFACES-517 Project: MyFaces Type: Bug Components: Implementation Versions: 1.0.9m9 Reporter: Holger Schimanski Assignee: Martin Marinschek Fix For: Nightly Build If the config file is named faces-config.xml and it is configured web.xml context-param param-namejavax.faces.CONFIG_FILES/param-name param-value/WEB-INF/faces-config.xml/param-value /context-param it is parsed twice by org.apache.myfaces.config.FacesConfigurator -- once in feedWebAppConfig() and once again in feedContextSpecifiedConfig(). The result is, that for example configured PhaseListeners are instantiated twice and both called during lifecycle. feedContextSpecifiedConfig() should skip /WEB-INF/faces-config.xml, because this is read in by feedWebAppConfig(). -- 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
Re: Java 5 code in Sandbox ?
I didn't mean to include it in the sandbox and hope to refactor it later.
I meant to add it to the sandbox, and to move it to tomahawk only when we accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm not wrong).
The point is that be refactoring those classes, we lose a lot of safety, so I would prefer to either commit them to the sandbox if we accept JSE5 code into it, or just hold them until we do.
It's not crucial anyway, as those cases are still limited right now.
On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
but chance it to 1.4 when moving to tomahawk? What would be the point
of that?
Why not refactor before adding to sandbox if this is the eventual plan?
I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
but I definitely don't think we should add stuff and hope to refactor
it later.
sean
On 9/6/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Hello,
I was about to commit the few Maps util classes I have when I realized it's
all Java 5 code (with many generics and a few annotations).
Removing the generics would really be bad as those classes needs to be
extended, and the generics add a lot of safety.
For me it would be ok to add Java 5, and later to move it to tomahawk when
we move to JSF 1.2, but I would need the approval of the others to do that,
as it would break the sandbox compilation on Java 1.4.
What do you think ?
Sylvain.
On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
Yes...
Let's put it there, and go on from this!
regards,
Martin
On 9/6/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Hello Martin,
No, I never committed it.
I think a new package would be great, but where do you want to put it ?
The logic would be to have it first in the sandbox, and then move it class
by class tomahawk.
Maybe a better package name would be org.apache.myfaces.utils
as jsfutils is redundant with myfaces. I also dropped the tomahawk part as
it would be in the sandbox first, but I'm not sure about this.
If you agree, I can commit those classes to the sandbox's
org.apache.myfaces.utils package, and we can start from here.
Sylvain.
On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
Sylvain,
did you ever get around to commit this stuff? I didn't find it in the
sources...
I'd like to use that as an example for something I am writing on -
would be great if I could just point to the MyFaces sourcebase.
How about a new package
org apache myfaces tomahawk jsfutils
We could also have the user contributions like the message-remembering
facilities and the newly added remember request-bean over redirect
facilities there...
regards,
Martin
On 5/11/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
I'm fine with that and find it simpler to have it in the trunk.
I have a related question.
Right now, I have done 2 little utilities that help me resolve small
problems.
They are 2 abstract implementations of Map : ActionMap and TestMap, and
I
find them handy to use in many common cases.
Here are 2 examples :
1) ActionMap : For example, when you have a list of file, and want to
have
a checkbox to delete a file, you just add the following code in your
page
:
h:column
h:selectBooleanCheckbox value=#{pageFace.removeFileName[file.name]}/
h:outputText value=delete/
/h:column
And in your backing bean : public ActionsMap getRemoveFileName(){
return new ActionsMap(){
@Override
public void performAction(String fileName) {
getFiles().remove( fileName );
}
};
}
2) TestMap : I use it to pass parameters to methods using a map, and
getting a boolean result.
For example, if you want to render a component if a user is in 2 roles,
the
visibleOnUserRole isn't enough.
So, in my backing bean, I have this method :
public TestsMap getUserInRole(){
return new TestsMap(){
@Override
public boolean getTest(String roleName) {
return getHttpServletRequest().isUserInRole( roleName
);
}
};
}
And now, I can do any test I want in EL :
#{myBean.isUserInRole['Accountant']
myBean.isUserInRole['CountryUnit']}
It's quite limited now, but due to the limitations of the EL, small
utilities like that can help.
My suggestion is to do a utilities library (similar to commons.lang,
with
StringUtils, ...) for EL, and maybe for JSF if more good candidates
emerge.
So, I wonder first if you guys feels this is of any use to include this
in
MyFaces, and if so, how do we handle that ?
Those aren't components, but should we do a sandbox for libraries to, or
just an additional myfaces-utilities.jar
Thanks,
Sylvain.
On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
I recall
[jira] Commented: (MYFACES-509) StateManager.saveSerializedView must throw an IllegalStateException when View contains duplicate IDs
[ http://issues.apache.org/jira/browse/MYFACES-509?page=comments#action_12322794 ] Oliver Rossmueller commented on MYFACES-509: r279199: Changed the exception thrown by checkForDuplicateIds to IllegalStateException 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 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] Commented: (MYFACES-521) Errors in TLDs
[ http://issues.apache.org/jira/browse/MYFACES-521?page=comments#action_12322796 ] Boris Kovalenko commented on MYFACES-521: - I'm sorry as new nightly build not yet available so I can't check, but have You changed in all files? Errors was in html, ext and tomahawk TLDs. Errors in TLDs -- Key: MYFACES-521 URL: http://issues.apache.org/jira/browse/MYFACES-521 Project: MyFaces Type: Bug Components: General Versions: Nightly Build Environment: Windows, JDK 1.4.2, Resin 3.0.14 Reporter: Boris Kovalenko Assignee: Matthias Weßendorf Attachments: tlds.zip Errors in TLDs... Resin compains like: log4j:WARN Please initialize the log4j system properly. [19:06:20.731] com.caucho.xml.XmlParseException: jar:file:/C:/Development/Projec ts/Ubs/WEB-INF/lib/myfaces-all.jar!/META-INF/myfaces_html.tld:2585: The followin g text is not allowed in this context. [19:06:20.731] [19:06:20.731] ant [19:06:20.731] [19:06:20.731] [19:06:20.731] [19:06:20.731] attribute or [19:06:20.731] example are expected, [19:06:20.731] or /tag may close. -- 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
Re: Java 5 code in Sandbox ?
yes, ok, let's wait!
JDK 1.5 in the sandbox right now is not a good idea, I think.
regards,
Martin
On 9/7/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Well doing a branch for the few classes I have right now really isn't worth
it.
Maybe it's better to hold on this until we start JSF 1.2.
On Wed, 2005-09-07 at 00:21 +0200, Bruno Aranda wrote:
I do not thing that including JDK5.0 code in the sandbox and not in
the rest is a good idea. It might create confusion... maybe we could
add a JDK5.0 branch to the sandbox SVN tree and then we would keep
your need code, but, IMO valid JDK1.4 code should be everywhere...
Bruno
P.S Currently, I am developing all my projects in JDK5.0. I have to
think twice when programming for myfaces! ;-)
2005/9/7, Sylvain Vieujot [EMAIL PROTECTED]:
I didn't mean to include it in the sandbox and hope to refactor it later.
I meant to add it to the sandbox, and to move it to tomahawk only when we
accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm not
wrong).
The point is that be refactoring those classes, we lose a lot of safety,
so
I would prefer to either commit them to the sandbox if we accept JSE5 code
into it, or just hold them until we do.
It's not crucial anyway, as those cases are still limited right now.
On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
but chance it to 1.4 when moving to tomahawk? What would be the point
of that?
Why not refactor before adding to sandbox if this is the eventual plan?
I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
but I definitely don't think we should add stuff and hope to refactor
it later.
sean
On 9/6/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Hello,
I was about to commit the few Maps util classes I have when I realized
it's
all Java 5 code (with many generics and a few annotations).
Removing the generics would really be bad as those classes needs to be
extended, and the generics add a lot of safety.
For me it would be ok to add Java 5, and later to move it to tomahawk
when
we move to JSF 1.2, but I would need the approval of the others to do
that,
as it would break the sandbox compilation on Java 1.4.
What do you think ?
Sylvain.
On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
Yes...
Let's put it there, and go on from this!
regards,
Martin
On 9/6/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
Hello Martin,
No, I never committed it.
I think a new package would be great, but where do you want to put it
?
The logic would be to have it first in the sandbox, and then move it
class
by class tomahawk.
Maybe a better package name would be org.apache.myfaces.utils
as jsfutils is redundant with myfaces. I also dropped the tomahawk
part
as
it would be in the sandbox first, but I'm not sure about this.
If you agree, I can commit those classes to the sandbox's
org.apache.myfaces.utils package, and we can start from here.
Sylvain.
On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
Sylvain,
did you ever get around to commit this stuff? I didn't find it in the
sources...
I'd like to use that as an example for something I am writing on -
would be great if I could just point to the MyFaces sourcebase.
How about a new package
org apache myfaces tomahawk jsfutils
We could also have the user contributions like the message-remembering
facilities and the newly added remember request-bean over redirect
facilities there...
regards,
Martin
On 5/11/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
I'm fine with that and find it simpler to have it in the trunk.
I have a related question.
Right now, I have done 2 little utilities that help me resolve small
problems.
They are 2 abstract implementations of Map : ActionMap and TestMap,
and
I
find them handy to use in many common cases.
Here are 2 examples :
1) ActionMap : For example, when you have a list of file, and want
to
have
a checkbox to delete a file, you just add the following code in your
page
:
h:column
h:selectBooleanCheckbox
value=#{pageFace.removeFileName[file.name]}/
h:outputText value=delete/
/h:column
And in your backing bean : public ActionsMap getRemoveFileName(){
return new ActionsMap(){
@Override
public void performAction(String fileName) {
getFiles().remove( fileName );
}
};
}
2) TestMap : I use it to pass parameters to methods using a map, and
getting a boolean result.
For example, if you want to render a component if a user is in 2
[jira] Commented: (MYFACES-509) StateManager.saveSerializedView must throw an IllegalStateException when View contains duplicate IDs
[ http://issues.apache.org/jira/browse/MYFACES-509?page=comments#action_12322804 ] Martin Marinschek commented on MYFACES-509: --- We ought to check for clientIds, not ids. What was wrong was that a clientId of null was not accepted - of course it should be as the RI does ;) If we check for ids, we would need to remember naming containers and compare only the children of naming containers to each other. Would be possible to, but it should work as implemented as well, even though going through the naming containers might be more performant. regards, Martin 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 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
